Probléme sous linux

J’ai noter 2 comportement anormal sous linux:

  • Si ont as asser de ram le cache/buffer ne marche pas, la preuve ont vas beaucoup plus vite avec un ram disk qu’avec un dossier temporaire en ext4 alors que tyout devrai tourner en ram car le fichier est créer, puis lu/écrit et enfin détruit
  • Sous kde quand on lance 70 application en parallèle (erreur de ma part), linux plante, hors avec windows j’ai pas de problème.
  • Sous kde les menu issu d’un clique droit, qu’il soit des menus dynamique ou statique sont long à s’afficher si il y as une charge disque dur, et instantanné sous windows.

Voila mon retour du jour. Malgré ces inconvénients, linux + kde reste le meilleur Os pour mon utilisation.

Boot pxe linux partie 2

Création ou transfert d’un système

Transférer un système

Si vous avez un système existant, le plus simple est de le transférer.

Par exemple, on imagine que votre système est sur une seule partition, la /dev/sda1, voilà ce qu’il faut faire.

Créer un dossier temporaire :

mkdir /mnt/temp

Monter la partition sur votre serveur, pour ça vous devez avoir branché votre disque dur contenant votre système sur le serveur.

mount /dev/sda1 /mnt/temp

Copier notre système dans le dossier dans un nouveau dossier, puis l’adapter :

Ensuite penser à adapter votre système. Voir plus bas.

Création d’un système

Nous allons créer un système, ici se référer à votre distribution si vous voulez une distribution spécifique. Préférez une distribution s’installant en chroot.

Je vais ici donner un exemple avec un stage3 de Gentoo (micro système déjà fait) :
On télécharge l’archive, vous pouvez aller sur mon miroir personnel. Allez dans le dossier correspondant à votre architecture (x86 pour le pc 32Bits, amd64 pour tout les 64Bits), puis current/, puis stages/, puis on décompresse le fichier. Vous pouvez installer une Gentoo complète : dans ce cas, merci de vous référer au guide Gentoo :

http://www.gentoo.org/doc/fr/

Adapter votre système

Ensuite, il faut configurer et adapter votre système, tout est relatif au système exporté. Quand je dit /etc/fstab, éditez /mnt/nfs/simple/etc/fstab.

Maintenant, éditons le fichier du système exporté en nfs, éditez le fichier /etc/fstab (donc ici /mnt/nfs/simple/etc/fstab), supprimez tout ce qui fait référence aux partitions de vos disques durs, soit toutes les lignes avec /dev/sdaX ou /dev/hdaX.

Si vous avez un firewall, désactivez-le. Vous le configurerez plus finement par la suite.

Supprimez ou désactivez toute auto-configuration de votre interface réseau (elle sera faite par le noyau) ; pour le système Gentoo que l’on vient d’installer dans /mnt/nfs/simple/, il faut éditer le fichier /etc/conf.d/rc (/mnt/nfs/simple/etc/conf.d/rc) et changer :

Code : Autre – Sélectionner

1
RC_PLUG_SERVICES=""

en

Code : Autre – Sélectionner

1
RC_PLUG_SERVICES="!net.eth0"

N’hésitez à personnaliser votre fichier /mnt/pxe/pxelinux0.cfg/default pour faire pointer vers votre propre noyau. Et votre propre initrd, si par exemple vous utilisez une image externe (utilisée direct dans le client, qui gère lui-même la branche en lecture seule et la branche en lecture-écriture).

Avec des ordinateurs virtuels

Si vous utilisez le mode NAT, c’est l’ordinateur supportant les PC virtuels qui servira de serveur de boot.

En mode bridged, c’est le serveur de boot qui est sur votre réseau local qui sera utilisé.

Si vous avez du kvm, avec le contrôleur réseau e1000 vous pouvez simplement booter sur le réseau par -boot n dans votre ligne de commande traditionnelle.

Par contre, en para-virtualisé, utilisé le controleur réseau virtio.


Je mettrais l’accent sur un point : je pense que pour les novices, vmware est le meilleur pour la virtualisation car tout est simple et en interface.

Par contre, grâce à l’intégration du code kvm au noyau, à l’impeccable travail fourni par ces développeurs et la para-virtualisation, kvm est de loin le meilleur en termes de flexibilité (ajout ram et cpu à chaud, divers périphériques de stockage, choix du matériel simulé, …) et de performances car il n’y a pas (ou presque) de pertes grâce à la para-virtualisation.

Adapter votre système

Ensuite, il faut configurer et adapter votre système, tout est relatif au système exporté. Quand je dit /etc/fstab, éditez /mnt/nfs/simple/etc/fstab.

Maintenant, éditons le fichier du système exporté en nfs, éditez le fichier /etc/fstab (donc ici /mnt/nfs/simple/etc/fstab), supprimez tout ce qui fait référence aux partitions de vos disques durs, soit toutes les lignes avec /dev/sdaX ou /dev/hdaX.

Si vous avez un firewall, désactivez-le. Vous le configurerez plus finement par la suite.

Supprimez ou désactivez toute auto-configuration de votre interface réseau (elle sera faite par le noyau) ; pour le système Gentoo que l’on vient d’installer dans /mnt/nfs/simple/, il faut éditer le fichier /etc/conf.d/rc (/mnt/nfs/simple/etc/conf.d/rc) et changer :

Code : Autre – Sélectionner

1
RC_PLUG_SERVICES=""

en

Code : Autre – Sélectionner

1
RC_PLUG_SERVICES="!net.eth0"

N’hésitez à personnaliser votre fichier /mnt/pxe/pxelinux0.cfg/default pour faire pointer vers votre propre noyau. Et votre propre initrd, si par exemple vous utilisez une image externe (utilisée direct dans le client, qui gère lui-même la branche en lecture seule et la branche en lecture-écriture).

Avec des ordinateurs virtuels

Si vous utilisez le mode NAT, c’est l’ordinateur supportant les PC virtuels qui servira de serveur de boot.

En mode bridged, c’est le serveur de boot qui est sur votre réseau local qui sera utilisé.

Si vous avez du kvm, avec le contrôleur réseau e1000 vous pouvez simplement booter sur le réseau par -boot n dans votre ligne de commande traditionnelle.

Par contre, en para-virtualisé, utilisé le controleur réseau virtio.


Je mettrais l’accent sur un point : je pense que pour les novices, vmware est le meilleur pour la virtualisation car tout est simple et en interface.

Par contre, grâce à l’intégration du code kvm au noyau, à l’impeccable travail fourni par ces développeurs et la para-virtualisation, kvm est de loin le meilleur en termes de flexibilité (ajout ram et cpu à chaud, divers périphériques de stockage, choix du matériel simulé, …) et de performances car il n’y a pas (ou presque) de pertes grâce à la para-virtualisation.

Les images systèmes

Nous allons commencer par créer une image du système que nous avons mis dans /mnt/nfs/simple/ et nous allons l’enregistrer comme /mnt/nfs/squashfs/image.sqfs.

mksquashfs -no-sparse /mnt/nfs/simple/* /mnt/nfs/squashfs/image.sqfs

La procédure est la même, que ce soit pour l’utilisation en interne ou en externe d’image.
Pour l’utilisation externe, les commandes de mise en place sont faites dans l’initrd de l’ordinateur qui boot.
Quand elles sont utilisées en interne, ces commandes sont faites par le serveur.

Nous allons monter notre image système en lecture dans le point prévu à cet effet :

mount /mnt/nfs/squashfs/image.sqfs /mnt/ro/

Nous allons fusionner pour une branche en lecture seule et une branche en écriture ou serons stocké les différences avec l’image en lecture seule.
Les écritures seront faites dans le dossier en écriture /mnt/rw/interne/, ce procédé s’appelle l’union. Ici le choix de aufs est délibéré car c’est pour l’instant la meilleure implémentation proposée.

mount -t aufs -o dirs=/mnt/rw/interne/:/mnt/ro/=ro none /mnt/nfs/image-interne/

Faire son initrd


Et dans vos fichiers de conf pxe vous pouvez mettre:
LABEL Gentoo 64 console
kernel images/os/gentoo/linux-gentoo-x86_64-console
append splash=silent,theme:livecd-2007.0 CONSOLE=/dev/tty1 initrd=images/os/gentoo/initrd-gentoo-64.lzma quiet fastboot cifspath=//192.168.158.10/images-pxe os=gentoo-x86_64-console.sqfs
IPAPPEND 1
LABEL Gentoo 64 kde4
kernel images/os/gentoo/linux-gentoo-x86_64-kde4
append splash=silent,theme:livecd-2007.0 CONSOLE=/dev/tty1 initrd=images/os/gentoo/initrd-gentoo-64.lzma quiet fastboot cifspath=//192.168.158.10/images-pxe os=gentoo-x86_64-kde4.sqfs
IPAPPEND 1
LABEL Gentoo i586 console
kernel images/os/gentoo/linux-gentoo-i586-console
append splash=silent,theme:livecd-2007.0 CONSOLE=/dev/tty1 initrd=images/os/gentoo/initrd-gentoo-32.lzma quiet fastboot cifspath=//192.168.158.10/images-pxe noapic nolapic os=gentoo-i586-console.sqfs
IPAPPEND 1

 

#!/bin/sh

 

. /etc/initrd.defaults

 

. /etc/initrd.scripts

 

splash() {

 

return 0

 

}

 

[ -e /etc/initrd.splash ] && . /etc/initrd.splash

 

# Clean input/output

 

exec >${CONSOLE} <${CONSOLE} 2>&1

 

if [ « $$ » != ‘1’ ]

 

then

 

echo ‘/linuxrc has to be run as the init process as the one’

 

echo ‘with a PID of 1. Try adding init= »/linuxrc » to the’

 

echo ‘kernel command line or running « exec /linuxrc ».’

 

exit 1

 

fi

 

mount -t proc proc /proc >/dev/null 2>&1

 

mount -o remount,rw / >/dev/null 2>&1

 

# Set up symlinks

 

if [ « $0 » = ‘/init’ ]

 

then

 

/bin/busybox –install -s

 

[ -e /linuxrc ] && rm /linuxrc

 

fi

 

quiet_kmsg

 

CMDLINE= »`cat /proc/cmdline` »

 

# Scan CMDLINE for any specified real_root= or cdroot arguments

 

for x in ${CMDLINE}

 

do

 

case « ${x} » in

 

domdadm)

 

USE_MDADM=1

 

;;

 

dodmraid)

 

USE_DMRAID_NORMAL=1

 

;;

 

dodmraid\=*)

 

DMRAID_OPTS=`parse_opt « ${x} »`

 

USE_DMRAID_NORMAL=1

 

;;

 

# Debug Options

 

debug)

 

DEBUG=’yes’

 

;;

 

# Module no-loads

 

doload\=*)

 

MDOLIST=`parse_opt « ${x} »`

 

MDOLIST= »`echo ${MDOLIST} | sed -e ‘s/,/ /g’` »

 

;;

 

nodetect)

 

NODETECT=1

 

;;

 

noload\=*)

 

MLIST=`parse_opt « ${x} »`

 

MLIST= »`echo ${MLIST} | sed -e ‘s/,/ /g’` »

 

export MLIST

 

;;

 

# Redirect output to a specific tty

 

CONSOLE\=*)

 

CONSOLE=`parse_opt « ${x} »`

 

exec >${CONSOLE} <${CONSOLE} 2>&1

 

;;

 

os\=*)

 

OS=`parse_opt « ${x} »`

 

;;

 

cifspath\=*)

 

CIFSPATH=`parse_opt « ${x} »`

 

;;

 

esac

 

done

 

splash ‘init’

 

detect_sbp2_devices

 

cmdline_hwopts

 

# Mount sysfs

 

mount_sysfs

 

# Start udev/devfs

 

start_dev_mgr

 

# Setup md device nodes if they dont exist

 

setup_md_device

 

# Scan volumes

 

startVolumes

 

# Set up unionfs

 

mkdir -p /newroot/

 

loadkmap < /lib/keymaps/fr.map

 

mkdir /squashfs

 

mkdir /tmp

 

mkdir /ro

 

mkdir /rw

 

mount -t cifs ${cifspath} /squashfs -o username=guest,guest,ro

 

mount /squashfs/ »${os} » /ro -o ro -n

 

mount -t tmpfs tmpfs /rw -n

 

mount -t aufs -o br=/rw=rw:/ro=ro none /newroot

 

# Run debug shell if requested

 

rundebugshell

 

verbose_kmsg

 

[ ! -e /newroot/dev/console ] && mknod /newroot/dev/console c 5 1

 

[ ! -e /newroot/dev/tty1 ] && mknod /newroot/dev/tty1 c 4 1

 

echo -ne « ${GOOD}>>${NORMAL}${BOLD} Booting (initramfs)${NORMAL} »

 

cd /newroot

 

mkdir /newroot/proc /newroot/sys 2>/dev/null

 

echo -ne « ${BOLD}.${NORMAL} »

 

umount /sys || echo ‘*: Failed to unmount the initrd /sys!’

 

umount /proc || echo ‘*: Failed to unmount the initrd /proc!’

 

echo -e « ${BOLD}.${NORMAL} »

 

exec switch_root -c « /dev/console » « /newroot/ » ${REAL_INIT:-/sbin/init} ${INIT_OPTS}

 

splash ‘verbose’

 

echo ‘A fatal error has probably occured since /sbin/init did not’

 

echo ‘boot correctly. Trying to open a shell…’

 

echo

 

exec /bin/bash

 

exec /bin/sh

 

exec /bin/ash

 

exec sh


Faites les commandes en root.

Créez le dossier temporaire, allez dedans, puis téléchargez depuis un emplacement distant :

mkdir initrdcd initrd/wget [url]

Pour décompresser un initrd tapez la commande suivante, tous les fichiers seront décompressés dans le dossier courant :

gzip -dc nom_de_l_initrd | cpio -id

Modifiez le script d’initialisation par exemple par en y mettent les lignes qui vont bien :

nano linuxrc

Faites le ménage :

rm nom_de_l_initrd -f

Créez l’initrd dans le dossier parent :

find ./ | cpio -H newc -o > ../nom_de_l_initrd

Boot pxe linux partie 1

Pré-requis et environnement typique

Cas de mise en place

Comment faire son choix parmi toutes les solutions que je vais vous proposer ?

Voilà les différentes solutions et leurs implications.

Le choix d’un système par nfs, le système sera contenu dans un dossier simple ce qui le rendra facilement modifiable


  • Avantages :

    • simple à mettre en oeuvre
    • éprouvé depuis longtemps
    • pas de réelle modification du système exporté
  • Inconvénients :

    • fragmentation assez importante car tous les fichiers requis par le système sont répartis sur tout le disque dur
    • débit réseau important
    • cache disque du serveur divisé entre tous les systèmes


Le choix d’une image système à l’intérieur du serveur, le système sera contenu dans une image en lecture seule et les modifications seront stockées dans un dossier


  • Avantages :

    • économie de l’espace disque car seuls les différences sont stockées<puce>restauration rapide de l’image de base supprimant toutes les différences<puce>possibilité d’intervenir simplement sur le système

    • pas de réelle modification du système exporté
  • Inconvénients :

    • débit réseau important
    • cache disque du serveur divisé entre tous les systèmes
    • cela peut devenir très lourd lors de nombreux points de montage


Le choix d’une image système sur la machine qui boot, le système sera contenu dans une image en lecture seule et les modifications seront stockées dans un dossier


  • Avantages :

    • économie de l’espace disque car seules les différences sont stockées
    • restauration rapide de l’image de base en supprimant toutes les différences
    • économie de la bande passante
    • cache disque mieux utilisé car le serveur ne fait que desservir quelques images principales et brasser quelques fichiers, le cache des machines bootant sur le réseau est aussi utilisé.
  • Inconvénients :

    • intervenir sur une images peut devenir très compliqué ;
    • obligation d’avoir un initrd (micro-système de boot) personnalisé.
Les deux structures typiques
Je vais vous présenter deux structures typiques :
 

  • un serveur, un switch, des ordinateurs : c’est le cas le plus courant, et sûrement le cas que vous allez utiliser. L’utilisation de la bande passante doit être maitrisée ;
  • un serveur réel et des serveurs virtuels : vous avez un serveur réel, et des machines virtuelles dessus, ce qui permet de ne plus travailler avec des disques durs virtuels mais utilisé un partage réseau pour stocker son système, ce qui fait qui vous n’aurez plus d’espace alloué et ne servant à rien dans un gros fichier représentant le disque. Au vu de la structure, seul le serveur va gérer le système de fichiers, ce qui produit un gain de performance.
Le noyau du serveur
Nous allons travailler avec samba, la majorité des noyaux sont compatible.  Pour travailler sur un serveur ne faisant qu’exporter une image système, il est conseillé d’activer les options suivantes.
 

File systems --->
Miscellaneous filesystems --->
 <*> SquashFS - Squashed file system support
 [*] Additional option for memory-constrained systems
 (3) Number of fragments cached
Le noyau du client
Quelle que soit votre mise en place, vous aurez besoin de cela sur le client :
 

File systems ---> Network File Systems ---> <*> Vifs/samba fs
Miscellaneous filesystems --->
 <*> Another unionfs Maximum number of branches (127) --->
 [ ] Use <sysfs>/fs/aufs/stat 
 [*] Use inotify to detect actions on a branch 
 [*] NFS-exportable aufs
 [ ] Aufs as an readonly branch of another aufs mount
 [*] Delegate the internal branch access the kernel thread
 [ ] Show whiteouts 
 [*] Make squashfs branch RR (real readonly) by default
 [*] splice.patch for sendfile(2) and splice(2)
 [ ] Debug aufs
 [ ] Compatibility with Unionfs (obsolete)
 [ ] Unionfs-2.2 or later patch is applied or not (obsolete)
 [ ] Unionfs-2.3 or later patch is applied or not (obsolete) 
 <*> SquashFS 3.3 - Squashed file system support
 [*] Additional option for memory-constrained systems
 (3) Number of fragments cached
<*> SquashFS 3.3 - Squashed file system support
 [*] Additional option for memory-constrained systems (3) Number of fragments cached
Networking support --->
Networking options --->
[*] IP: kernel level autoconfiguration
[*] IP: DHCP support
[*] IP: BOOTP support

Et mettez en dur toutes les cartes réseaux.

Peu ou presqu’aucun noyau pré-compilé ne propose ces options. Il faut un noyau patché avec aufs, voir http://aufs.sourceforge.net/ qui explique très bien comment patcher son noyau. Attention, il faut compiler une fois sont noyau avant d’installer aufs. Pour pouvoir utiliser votre client dans tous les modes, je vous conseille d’avoir toutes les options pour pouvoir changer sans tout recompiler.
Logiciel, version et matériels
Je vous conseille d’utiliser au maximum des versions récentes mais stables. Dans mon cas, j’ai choisi sur le client et le serveur :
 

  • Gentoo netinstall,
  • noyau 2.6.30-r18,
  • aufs en cvs,
  • squashfs 3.4,
  • samba 3.5

Coté serveur :

  • samba 3.5,
  • dhcp-3.1.0,
  • tftp-hpa-0.48.

Pour l’ordinateur démarrant sur le réseau, il faut activer dans le BIOS ROM NETWORK dans onboard devices ou équivalent, sauvegarder, rebooter, aller dans le BIOS, puis dans le menu boot order, sélectionner le réseau en premier. Merci de vous référer au guide de votre carte mère pour plus d’informations. Tous les ordinateurs ne sont pas capables de booter en réseau. Dans ce cas, il existe des alternatives telles que mettre un BIOS open source capable de booter sur le réseau (coreboot + gPXE, coreboot + grub, …), ou installer sur un média bootable un chargeur de démarrage, le noyau et l’initrd de votre système réseau. Tous les PC virtuels que je connais sont capables de booter en réseau, il ne faut que le sélectionner dans le BIOS (vmware), ou dans la ligne de commande (kvm) les options adéquates.

Je considére que appartir de maintenant toutes mes images sont dans le partage samba « images-pxe »

Le serveur dhcp, tftp, samba

Serveur dhcp
Mais c’est quoi, un serveur dhcp ? Un serveur dhcp, c’est un serveur qui va automatiquement configurer votre carte réseau, remplir le DNS, la passerelle, l’IP, … Il s’occupe aussi de configurer l’environnement de boot en réseau. L’IP de l’interface amenant internet au serveur (et le réseau coté internet) ne doit pas être en 192.168.0.X, ou, si on change tous les 192.168.0.X en 192.168.1.X ci-dessus et par la suite. Un fichier d’exemple est toujours plus parlant, situé chez moi à /etc/dhcp/dhcpd.conf :
 

123456789101112131415161718192021222324252627282930313233
# bootallow booting;allow bootp;filename "pxelinux.0";ping-check = 1;# dhcpdefault-lease-time 2678400;max-lease-time 2678400;# domain et dnsoption domain-name "monnom.local";ddns-update-style none;# Serveur dhcp unique sur le réseauauthoritative;# interface desserviesubnet 192.168.0.0 netmask 255.255.255.0 {  option domain-name "monnom.local";# remplacer par votre serveur DNS  option domain-name-servers 192.168.0.1;  range 192.168.0.10 192.168.0.99;# désactivé si votre serveur ne sert pas de passerelle  option routers 192.168.0.1;}host pcenipfixe {# remplacer par l'adresse MAC de votre carte réseauhardware ethernet 00:1A:4D:58:85:4F;# remplacer par l'IP fixe vouluefixed-address 192.168.0.10;}
L’IP de votre serveur doit être fixe (pas de configuration automatique par dhcp) à 192.168.0.1. Installer votre serveur dhcp, sous Gentoo :
emerge -av dhcp
Remplir le fichier /etc/dhcp/dhpcd.conf, lancer le serveur dhcp.
Autorisé le partage de connexion internet:
echo 1 > /proc/sys/net/ipv4/ip_forward
Sous Gentoo, éditez le fichier /etc/sysctl.conf et décommentez pour l’avoir au démarage :
1
net.ipv4.ip_forward = 1
Serveur tftp

Le serveur tftp est en fait un serveur ftp minimal. Il permet de distribuer le fichier de boot, et tous les fichiers utiles au lancement du système, tels que les noyaux, les initrd, …

Voir ce lien pour voir le dossier d’exemple /mnt/pxe/ :

http://files.first-world.info/howto/pxe-exemple/mnt/pxe/

Tout le dossier est téléchargeable ici :

http://files.first-world.info/howto/pxe-exemple/mnt/pxe.tar.bz2

Le fichier pxelinux.0 sert de rom pour faire chargeur de démarrage.

Le dossier pxelinux.cfg contient le menu principal par défaut (pxelinux.cfg/default) mais on peut spécifier un fichier spécifique à un PC en l’identifiant par son adresse MAC. Je ne m’attarderai pas plus dessus.

J’ai rempli le dossier d’exemples divers, d’installeur réseau (pour installer par le réseau au lieu des cd), de live système, d’utilitaires, … j’ai mis aussi des fonds d’écran dans chaque menu, à vous de l’explorer un peu.

Dans votre distribution, installer le packet tftp-hpa, sous Gentoo

Sous gentoo, éditer le fichier /etc/conf.d/in.tftpd puis y mettre :

Code : Autre – Sélectionner

12
INTFTPD_PATH="/mnt/pxe/"INTFTPD_OPTS="-R 4096:5120 -a 192.168.0.1 -u nobody -s ${INTFTPD_PATH}"

Vous pouvez lancer le serveur in.tftpd, si votre distribution le supporte, vous pouvez le lancer comme un service

Serveur samba
Installez samba.
Mon smb.conf la ou « user » est mon utilisateur courant. Ensuite lancer samba.
[Global]
workgroup = WORKGROUP
netbiosname = PXE
server string = PXE Samba Server
log level = 1
log file = /var/log/samba/all.log
max log size = 50
hosts allow = 192.168.0.0/255.255.255.0 fe80::/10
hosts deny = 0.0.0.0/0
security = share
guest account = user
share modes = yes
encrypt passwords = yes
null passwords = yes
directory security mask = 0700
directory mode = 0700
create mask = 0600
force directory mode = 0700
force security mode = 0600
invalid users = root
map to guest = bad user
dos charset = 850
unix charset = ISO8859-15
obey pam restrictions = yes
pam password change = no
[images-pxe]
path = /mnt/share/read/iso/squashfs
read only = yes
browseable = yes
writable = no
guest ok = yes
guest only = yes
guest account = user
username = user
comment = PXE image for network boot
hosts allow = 192.168.0.0/255.255.255.0 fe80::/10
hosts deny = 0.0.0.0/0

Qt 4.6 compilé avec MinGW64 avec wine sous linux

Bonjour,

Vous devez sans doute en avoir mare de devoir lancé un machine virtuelle pour compiler vos application Qt sous windows, avec visual studio et ces dépendances? J’ai la solution, cela permet en autre d’automatiser la création, et donc de tout faire via un .sh:

  • Créer votre futur dossier wine
  • Lancer toujours wine et Qt avec le préfix WINEPREFIX= »/votre/chemin/ »
  • Installé TDM MinGW, et ajouter le à votre variable d’environnement PATH dans regedit en recherche la clef ayant pour nom PATH
  • Compilé le début de Qt en 32Bits avec TDM MinGW pour avoir notamment qmake.exe,uic.exe,moc.exe,rcc.exe en 32Bits
  • Garder ces exe dans un dossier à part, lancer une commande watch pour les recopier à intervalle régulier dans dans le dossier bin/ de Qt car avec la version MinGW64 c’est des exe 64Bits qui vont être généré, donc incompatible avec un wine 32Bits
  • renommer votre dossier MinGW
  • Installez MinWG64 la version snapshot la plus récente en MinGW-w64-mingw-i686.zip ou un truc comme ça
  • Copier tout les binaires dans bin/ de votre dossier MinGW qui est en 32Bits pour cible 64Bits et renommer les copies sans le mingw……- devant
  • Faite un mingw32-make distclean
  • lancer le configure puis le make comme pour une installation traditionnelle
  • Quand tout est compilé arréte le script qui ecrase vos binaires dans le dossier bin/ de Qt

J’ai rencontrer les erreurs suivantes:

  • Avec Qt 4.6.1 j’ai du désactivé le mmx, sse, sse2

Pour pouvoir avoir un maximum de compression du binaire final j’ai fait en static, pour notamment pouvoir le compresser avec upx en lzma quand upx supportera les binaires windows 64Bits.

Cette article vous permet aussi avec quelque adaptation de compiler Qt en 64Bits sous windows sans avoir besoin de visual studio en 64Bits, donc potentiellement d’utiliser Qt Creator ou tout autre IDE Qt portable basé sur MinGW.

Test de KDE 4.4 et KpackageKit pour gentoo et portage

Bonjour, je suis en train de tester l’overlay kde pour gentoo (en kde 4.3.82 car les autres il manque trés souvent les sources), de nombreux bug à signalé.

PyKDE ne marche pas, et de nouveau packet que je ne connait pas bloque à la compilation.

Et concernant Kpackagekit, l’installation que j’ai fait à la main ne semble pas marché, je teste via l’overlay et des le 1er packet j’ai:

../../src/eggdbus/eggdbustypes.h:31:38: error: eggdbus/eggdbusenumtypes.h: No such file or directory

Pas de bol.

Pour dolphin activé le use flag semantic-desktop et faite emerge -av nepomuk

ATI Radeon 4570 Mobile sous linux

Aprés une trés longue attente pour le support de ma ATI Radeon 4570 de mon portable dell inspiron 15 (studio 1555) sous linux, j’en vois enfin le bout.

Je suis sous gentoo amd64 avec un kernel 2.6.33 (et mesa 7.7 rc3, lib drm 2.4.16) qui active enfin la 3D en openGl 1.5 ce qui est déjà un début, et le signe que le DRM du kernel marche maintenant. Attention, ne pas activé KMS sous peine de crash kernel du genre:
radeon 0000:01:00.0: Fatal error during GPU init
[drm] radeon: finishing device
BUG: unable to handle kernel NULL pointer dereference at 0000000000048
IP: [] ttm_bo_reserve+0x18/0xec
PGD 0
Oops 0000 [#1] PREEMPT SMP
...
Call trace:
printk
rv770_suspend
rv770_fini
radeon_device_fini
radeon_driver_unload
radeon_driver_load_kms
drm_get_dev
local_pci_probe
..........

La transparence est bien plus rapide, j’ai 1500 sous glxgears, et trés peu d’extension openGL d’activé. Mais je suis déjà content d’avoir ça car ça avance. Je suis pressé d’avoir la 3D complétement pour KDE et aussi la gestion d’énergie de ma carte 3D.

Si non pour le reste du matos en général c’est bien supporté, controleur ahci, … et c’est bien optimisé, je note ce pendant:

  • conflicts with ACPI region SMBI
  • Virtualisation activé dans le bios mais pas sous linux car dans le dmesg il me dit que c’est désactivé dans le bios