Reprise du message précédent :
 
 
Juste pour confirmation, il faut lancer la commande suivante ?

Oui en root

Merci

Toutafé.

 Le CD install / rescue de la Arch pour sauver... des autres distro (une Ubuntu la)  

 
Je m'en sers de temps en temps au taff sur du Debian / Redhat en serveur.
Note: ça marche aussi avec le cd de gentoo  

perso je n'utilise plus de CD d'install, je me crée une clé USB avec plein d'utilitaires de dépannage dont l'image ISO du cd d'install archlinux,

le principe c'est de comprendre comment fonctionne le gestionnaire de boot syslinux ( qui au départ était prévu pour le boot sur périphériques amovibles type USB, lecteur optique ),

on peut alors créer un fichier de configuration demandant à syslinux ( installé sur la clé USB ) de lancer le contenu des images ISO ( qu'on aura au préalable décompressé pour ne lancer que la partie utile afin d'éviter les parties redondantes de type boot CD ),

c'est ce principe qu'utilise d'ailleurs le CD de dépannage "ultimate boot cd", sauf que là j'ai tout personnalisé sur une clé USB de 4 Go en mettant les utilitaires de mon choix avec un menu de boot adapté

on peut aussi ajouter un driver USB 2.0 qui s'intercalera en mémoire au niveau du bios ( une interruption spéciale ) pour accélérer au boot le chargement des fichiers sur la clé USB pour les bios qui n'ont pas de pilotes USB2.0 pour le boot USB ( bien que le PC possède un contrôleur USB 2.0, certains bios même récents vont booter la clé en mode USB 1.0 d'où une extrême lenteur, c'est souvent le cas sur les bios de type award v6.00PG ), il suffit de demander à syslinux de lancer un fichier bin qui va ajouter en mémoire le pilote USB 2.0, et on revient ensuite au menu de boot syslinux de la clé USB

http://www.plop.at/en/bootmanager/download.html

avec toutes ces bidouilles je n'ai plus du tout besoin de lecteur/graveur DVD pour tout ce qui est boot, il me sert uniquement pour lire des DVD vidéos

Sauf que dans mon cas, c'était une de mes VM sous Proxmox, ce qui rend l'utilisation de l'USB plutôt fastidieuse.

je ne connais pas proxmox,
 
j'utilise virtualbox qui marche plutôt bien pour la gestion de l'USB, on peut faire booter la machine virtuelle sur une clé USB, il y a une manip à faire en créant un fichier pointant vers l'adresse de la clé USB

Est ce normal d'avoir ces warning lors de la maj du kernel?
 

Ça arrive quand le driver gère plusieurs chipsets et qu'il peut ou non avoir besoin d'un firmware. Si tout marche pour toi ne t'inquiète pas.

Et pour les permissions qui différent sur /boot?

c'est normal, ces avertissements sont présents chez tous les utilisateurs depuis 2 ou 3 mois, 3 avertissements concernant le noyau fallback :
 

 
c'est volontaire, ils n'ont pas tous mis comme firmware dans le noyau "fallback", ces messages je les ai à la fois sur un portable et une machine virtuelle virtualbox
 

 
tu as dû merder quelque part, genre modification à la main façon terminator dans /boot, ou utilisation d'un paquet douteux du dépot aur ( sachant que c'est un peu la roulette russe ce dépot )

Un filesystem qui supporte pas les droits ?
Sinon ba tu synchronises à la main  

Pour acquérir les bases avec SysLinux, t’es passé par un tuto ?

Tiens ça fait un bail que j'avais dit que je devais passer à un bootloader plus KISS que grub2 en UEFI mais je n'ai pas encore bougé mon popotin.
 
C'est quoi le state of the art actuellement sur arch ? Il semblerait que la mode soit à réincorporer l'initram dans le noyau compilé en tant que loader EFI ?
Des conseils pour moi ? Sinon je vais regarder syslinux6/gummiboot/refind.

pas vraiment, j'ai fait ça par tâtonnement, expérimentation et observation

la première chose à faire c'est d'installer le secteur de boot de syslinux sur une clé USB ( formatée en FAT32, ou FAT si c'est une clé de 128~256 Mo ), ça passe par l'utilitaire syslinux.exe fourni dans les sources de syslinux, généralement la ligne de commande :

X: étant la lettre de la partition de la clé USB où il faut installer le mbr , "/boot/syslinux" étant le dossier où se trouvera les fichiers systèmes de syslinux ( créer le dossier /boot/syslinux avant de lancer syslinux.exe ) et les divers modules et le fichier de configuration syslinux.cfg sur la clé USB,

pour débuter façon "hello world" tu peux t'amuser à formater une clé USB en fat32, installer syslinux, puis mettre l'ISO de memtest ( testeur de mémoire ) et configurer le fichier syslinux.cfg de cette manière :

tu auras un menu permettant de lancer memtest au boot de la clé, il faudra penser à ajouter dans /boot/syslinux les fichiers chain.c32 , menu.c32, vesamenu.c32, libutil.c32, memdisk ( pour pouvoir lancer des fichiers ISO, image disquette ), tous ces fichiers sont présents dans le fichier des sources de syslinux, mettre aussi le fichier memtest.bin ( dispo sur le site de memtest ) dans /boot/syslinux de la clé USB,

pour lancer une disquette DOS ( ou n'importe quel utilitaire disponible sous forme d'image ISO ou disquette )

les images ISO, disquettes devront être présentes dans /boot/syslinux si on ne met pas de chemin direct

pour lancer le CD d'install d'archlinux :

explications :

- il faut d'abord décompresser l'ISO du CD d'archlinux ( avec un utilitaire comme 7zip ou celui dispo sous archlinux )

- sur la clé créer un dossier /progs/archlinux

- copier le fichier /arch/i686/root-image.fs.sfs ( ce qui donnera sur la clé /progs/archlinux/arch/i686/root-image.fs.sfs )

- copier l'intégralité du dossier /arch/boot ( ce qui donnera sur la clé /progs/archlinux/arch/boot )

- copier les fichiers présents à la racine de l'archive décompressée dans /progs/archlinux ( fichiers aitab  checksum.i686.md5  pkglist.x86_64.txt   checksum.x86_64.md5  pkglist.i686.txt )

- calculer l'uuid de la partition de la clé USB ( pour une partition FAT32 l'uuid correspond au numéro de série/numéro de volume ), puis reporter cette valeur dans le fichier de config de syslinux pour la valeur archisodevice ( dans mon cas archisodevice=/dev/disk/by-uuid/7744-D05E )

si vous avez respecté toutes ces étapes la clé USB devrait pouvoir vous donner la possibilité de démarrer sur le CD d'install d'archlinux ( version i686 mais c'est le même principe pour la version x64 )

si vous avez un vieux bios qui ne boot les clés USB qu'en mode USB 1.0 ( absence de pilote USB 2.0 dans le bios ) alors une solution c'est d'utiliser un pilote USB 2.0 qui va s'intercaler en mémoire, ça permettra de booter en mode usb 2.0 :

puis mettre le fichier plpbt.bin dans /boot/syslinux, fichier dispo dans le zip ici :

http://www.plop.at/en/bootmanager/download.html

au boot de syslinux on selectionne "plopboot manager", dans l'interface de plopboot on selectionne la clé USB, le pilote va s'installer en mémoire et on revient automatiquement au boot de syslinux, avec cette fois le mode USB 2.0 activé ( la clé sera très rapide ), très utile pour beaucoup de cartes mères même relativement récentes ( 2008~2010, la faute à certaines versions de bios award )

à noter que vous pouvez utiliser une machine virtuelle ( virtualbox ) pour tester le boot de la clé USB, c'est pratique pour mettre au point une clé USB de boot sans avoir à redémarrer son PC

Merci pour ces explications

Depuis les récentes mises à jour de Systemd (v208-1), j'ai un message d'erreur au boot.

ça pose pas vraiment de problèmes, ma partition swap est quand même bien activée, je le vois avec free ou swapon.
J'ai cherché mais pas trouvé grand chose pour supprimer ce message d'erreur, rien dans les logs.
Si quelqu'un à une idée?

tu utilises quelle version d'archlinux ? i686 ou la version 64 bits ?
 
perso je constate des bugs plus ou moins cachés/mineurs ( c'est à dire qu'il faut être curieux pour s'apercevoir de ces problèmes, ça passe quasi-inaperçu ) depuis la version 205 de systemd concernant la gestion des processus, des services, sauf que moi les bugs je les ai à la fermeture/redémarrage d'archlinux ( un délai plus long de fermeture, des processus qui ne veulent pas se fermer de manière classique, sigkill obligatoire de la part de systemd )
 
je pense que c'est lié à la tentative de l'auteur de systemd de résoudre le bug "cgroup", avant la version 205 on voyait régulierement de manière furtive lors de l'extinction ou du reboot ce message :
 

 
depuis qu'ils ont résolu ce problème d'autres problèmes sont apparus chez moi, tous sur des systèmes i686 avec des installations vieilles de plus d'un an

La version 64 bits.
oui ça me dit quelque chose ce message en rapport avec les cgroups/D-bus
 
J'ai remarqué aussi parfois lorsque je ferme ma session KDE, ça prend bien 15sec alors qu'en temps normal c'est quasi instantané
mais dès que je suis en console, si je reboot ou éteint la machine, là c'est rapide, je vois pas de différences.
mais bon c'est pas trop génant, ça se produit rarement et je sais même pas en fait si ça a un rapport avec systemd.

pour avoir le temps de lire les messages à l'extinction :

sous KDE tu lances konsole, puis tu tapes halt ou l'équivalent avec la commande shutdown suivi du bon paramètre, ça va lancer la procédure d'extinction mais sans éteindre automatiquement le PC ( faudra utiliser le bouton on/off du boitier ), ça laisse la possibilité de lire les messages d'erreurs,

chez moi le long délai provient d'un processus qui ne veut pas s'éteindre correctement à l'étape où systemd affiche la ligne :

à ce moment il va attendre 10 à 15 secondes avant d'afficher un :

sur un portable pentium 4 c'est kdesud qui ne veut pas s'éteindre, sous virtualbox sur un PC fixe c'est le processus vboxclient, ces processus ne sont pas bogués car j'arrive à les éteindre manuellement sous KDE via un kill classique, c'est vraiment lors de l'étape d'extinction/reboot depuis KDE que ça merde, comme s'il y avait une mauvaise synchronisation dans l'ordre d'extinction des processus/service, ou une collision en terme de timing, systemd qui se mord la queue dans la gestion des processus,

parfois le ralentissement ne se fait pas à cet étape mais avant, aucun message mais systemd attend de manière encore plus prolongée ( une minute )

Le truc des cgroups ils en ont parlé sur arch-dev mais je ne me souviens plus des détails, juste que normalement maintenant la solution "propre" au problème que je ne maîtrise pas devrait arriver avec les systemd récents.
 
Moi quand parfois ça met du temps à s’arrêter j'ai une erreur de watchdog sur la console juste avant l'extinction "watchdog0 did not stop" et ça pareil c'est un bug ouvert depuis pas mal de temps et peut-être même 2 kernels. Après ce n'est pas dit que ce soit la cause réelle...

Il y a eu un petit peu de nettoyage

Certains posts ont disparu, car pas en rapport avec le sujet de ce topic, suite à un fort soupçon de troll

Moi je suis contre l'effacement de nos posts.
Nous on etait correct, mais on est puni aussi

Vos posts étaient des réactions p/r à une tentative de troll, et n'apportaient rien d'utile au topic
 
Faut pas voir l'effacement de vos posts comme une punition, mais plutôt comme un nettoyage permettant d'éliminer un peu de "bruit" causé par un troll extérieur

Ça n'avait pas l'air très intéressant en plus.

pas très réactif le bugzilla de systemd, j'ai déposé un rapport de bug sur les problèmes de reboot/shutdown de systemd à partir de la version 205 et aucune réaction depuis 2 jours

Purée, il a pris du poids le gnu make 4.0
 

 
Étonné aussi de voir syslinux 6.02 passer en "stable" alors que l'upstream pour le moment chie un peu dans la colle avec le superblock BTRFS (corrigé par des patchs sur la Archlinux mais bon). Mais aussi content de voir aussi Rubinuis passer en community  \o/ même si j'avais réussi a compiler la 2.0 avec rbenv sur la Arch malgré les embuches que ça implique (par contre les perfs...).

D'un autre côté, btrfs n'est pas encore stable non plus  

Salut    
Je voudrais installer Emacs mais le paquet dans les dépôts officiels a comme dépendance Gconf et je souhaiterai m'en passer.
Alors j'ai regardé pour configurer le PKGBUILD avec les options qui vont bien et compiler Emacs.
 
Si j'ai bien compris je dois passer par abs, modifier les dépendances et le configure du PKGBUILD puis utiliser makepkg
C'est bien la bonne méthode?
 
Si Emacs est mis à jour dans les dépôts officiels, il se passe quoi lors d'un pacman -Syu ?
Ça écrase ma version ou dans le cas contraire est ce que j'ai la possibilité de savoir qu'une nouvelle version est dispo et refaire un build?

 
Installe emacs-nox, pas d'interface graphique, pas de soucis.

Hello,
 
petite question qui n'a pas avoir avec archlinux mais avec linux en gnéral (mais coe je suis sous arch, je poste ci):
 
j'ai un clé wifi (NetGear, WNA1000M 802.11bgn) dont le driver est mal supporté par le kernel linux:  Realtek RTL8188CUS (-+= à 8192cu)
 
Donc à chaque update du kenrel, je dois toujours réinstallé un patch (notament parce que l'id usb de cette clé n'est pas intégré au drive).
 
Ce problème perssite depuis un certain temps, pourquoi le correctif n'estpas intégré au kernel alors que bon nombre d'utilisateur ont rencontré ce problème et ont fait remonter le bug.
 
Pourquoi celà met tant de temps à être corrigé ars que les patch sont dispos et le problème bien identifié? je cherche à comprendre, pas à faire l'exigant ...
 
ex:
https://bugzilla.kernel.org/show_bug.cgi?id=46171
https://bugzilla.kernel.org/show_bug.cgi?id=45241
 
le patch sous archlinux:
https://aur.archlinux.org/packages/ [...] setlang=fr

j'ai regardé le contenu du patch, en fait le patch ne fait pas grand chose, il ne fait que rajouter des fonctions vides  
 

 
peut-être que les développeurs du noyau n'aiment pas trop cette manière de corriger un bug ( contourner le problème avec des fonctions vides, ça fait un peu trop bricolo/système D ), ils attendent peut-être une refonte totale du fichier os_intfs.c ( ou de tout le code qui gère le wifi ) afin que cela soit un peu plus élégant/optimisé en terme de code source,  
 
c'est une hypothèse pour expliquer ce retard,
 
à noter que Linus Torvalds a indiqué que la version linux 4.0 serait centrée sur la correction d'un maximum de bugs qui auraient dû être pris en compte depuis bien longtemps, à ce moment là ton problème sera probablement pris en compte par les développeurs

 
ok merci , je n'en demandais pas tant je voulais juste partager ma frustration et mon incompréhension ...
Merci en tout cas, bonne soirée

Enfin, vu la gueule du patch et le fait que ce soit un module dkms, c'est bizarre que tu aies à le recompiler à chaque fois.
T'aurais pas oublié de démarrer le service dkms par hasard ?

je viens d'installer archlinux 64 bits sur un PC,
 
tout s'est bien passé sauf qu'après un reboot de temps en temps KDE m'affiche ce message :
 

 
et là il m'affiche des périphériques comme des cartes sons qu'il semble avoir detecté en trop, en fait tout est ok, c'est juste que KDE affiche dans le centre de configuration plusieurs fois le même périphérique audio, ça ne crée pas de problème de son mais à chaque boot j'ai cette notification    
 
apparemment ce serait un bug entre phonon et un fichier de configuration de kde , en supprimant le fichier " ~/.kde4/share/config/phonondevicesrc" le problème est résolu, mais que temporairement, il revient périodiquement lors des reboots,
 
mon problème ressemble à ce topic :
 
http://forums.archlinux.fr/post121358.html#p121358
 
avez-vous rencontré le même problème ?

Pour ceux que ca amuse, le débat sur système avec le changement d init sur Debian est d assez bonne qualité. Il va y avoir un vote probablement.