[systemd] boot arrêté après le montage de /home (résolu)

[mimile]

Coucou, me revoilou

Sur ma Arch en dur, et en suivant les wiki français et anglais, j'ai installé systemd puis j'ai créé les fichiers de configuration (hostname, vconsole, timezone et locale) ; ensuite j'ai ajouté init=/bin/systemd à la fin de la ligne du noyau dans le grub.cfg que j'utilise (celui de Squeeze qui est monté en rw dans mon fstab).

En ce qui concerne /etc/modules.load.d/*.conf et /etc/modprobe.d/*.conf, le wiki français n'étant pas très explicite, je me suis abstenu.

Selon le Wiki anglais, j'aurais sans doute dû créer un fichier /etc/modules.load.d/fuse.conf dans lequel j'aurais écrit simplement "fuse" (sans les guillemets).

Dans la même optique, j'aurais sans doute dû créer un fichier /etc/modules.modprobe.d/xyz.conf (contenant les différents démons mentionnés dans rc.conf : syslog-ng dbus alsa networkmanager cupsd acpid crond ntpd pcscd (mais un par ligne précédé de option si j'ai bien suivi).

Code : Tout sélectionner

 Using files in /etc/modprobe.d/

To pass options to a module using modprobe config files, a .conf file with any name (you can even use /etc/modprobe.d/modprobe.conf) needs to be placed in /etc/modprobe.d/ with this syntax:

/etc/modprobe.d/myfilename.conf

options modname parametername=parametercontents

Dans le doute, je me suis abstenu, partant du principe que, n'ayant pas supprimé initscripts, rc.conf restait en piste.

Bref, j'ai redémarré et j'ai vu défiler à une vitesse Vv' une quantité importante de lignes rapportant les opérations en cours.

Mais problème, à la ligne mount /home, ça s'arrête et il ne se passe plus rien.

Bref, étant coincé (pas tty accessible) Ctrl-C puis reboot et là, affichage d'un tas de message d'erreurs avec pour finir un message me demandant mon login root ou de faire ctrl D mais ça n'a eu aucun effet.

Donc, nouveau Ctrl-C pour accéder à Squeeze afin de supprimer init=/bin/systemd de la ligne de grub.cfg pour pouvoir booter correctement Arch.

Pourquoi le boot s'est-il arrêter à mount /home (alors que sur ma version virtuelle), il poursuit normalement (dans les deux cas, je démarre gnome /etc/inittab - mais j'ai aussi ~/.xinitrc qui contient : exec ck-launch-session gnome-session).

Merci pour vos avis et - probablement - vos reproches (je commence à m'y faire ).

Amicalement,

[FoolEcho]

En ce qui concerne /etc/modules.load.d/*.conf et /etc/modprobe.d/*.conf, le wiki français n'étant pas très explicite, je me suis abstenu.

Je ne vois pas ce qui n'est pas clair. Systemd -> Kernel_modules
- /etc/modules.load.d/*.conf sert à indiquer les modules à charger explicitement (équivalent au MODULES du rc.conf).
- /etc/modprobe.d/*.conf sert au paramétrage de tel ou tel module (ceci inclu le blacklist).

Selon le Wiki anglais, j'aurais sans doute dû créer un fichier /etc/modules.load.d/fuse.conf dans lequel j'aurais écrit simplement "fuse" (sans les guillemets).

Oui.

Dans la même optique, j'aurais sans doute dû créer un fichier /etc/modules.modprobe.d/xyz.conf (contenant les différents démons mentionnés dans rc.conf : syslog-ng dbus alsa networkmanager cupsd acpid crond ntpd pcscd (mais un par ligne précédé de option si j'ai bien suivi).

Absolument pas. Un service n'est pas un module.

Bref, étant coincé (pas tty accessible) Ctrl-C puis reboot et là, affichage d'un tas de message d'erreurs avec pour finir un message me demandant mon login root ou de faire ctrl D mais ça n'a eu aucun effet.

Tu sais qu'on ne va pas deviner les erreurs ? (... logs ou un journal...)

Pourquoi le boot s'est-il arrêter à mount /home (alors que sur ma version virtuelle), il poursuit normalement (dans les deux cas, je démarre gnome /etc/inittab - mais j'ai aussi ~/.xinitrc qui contient : exec ck-launch-session gnome-session).

Tu démarres gdm, tu veux dire ? As-tu installé systemd-arch-units (qui contient le fichier de service de gdm) ?

[mimile]

Merci pour ta patience à mon égard.

Je vais essayer de répondre à tes remarques :

Dans ma arch en dur, fuse est dans la rubrique MODULES et il n'y a que lui.
En revanche dans ma Arch virtuelle, fuse est dans les DAEMONS

Quand j'exécute lsmod, j'obtiens ceci :

Code : Tout sélectionner

Module                  Size  Used by
reiserfs              225067  2 
nouveau               715255  2 
video                   9915  1 nouveau
mxm_wmi                 1101  1 nouveau
wmi                     7259  2 mxm_wmi,nouveau
i2c_algo_bit            4615  1 nouveau
drm_kms_helper         29235  1 nouveau
ttm                    46507  1 nouveau
drm                   170883  4 ttm,drm_kms_helper,nouveau
snd_intel8x0           22768  2 
snd_ac97_codec         89868  1 snd_intel8x0
ac97_bus                 874  1 snd_ac97_codec
snd_pcm                61237  2 snd_ac97_codec,snd_intel8x0
snd_page_alloc          5901  2 snd_intel8x0,snd_pcm
snd_timer              14902  1 snd_pcm
snd                    44394  8 snd_ac97_codec,snd_intel8x0,snd_timer,snd_pcm
soundcore               4378  1 snd
i2c_amd756              3585  0 
nvidia_agp              4160  1 
agpgart                21967  3 drm,ttm,nvidia_agp
forcedeth              50533  0 
shpchp                 22557  0 
i2c_core               16653  5 drm,i2c_amd756,drm_kms_helper,i2c_algo_bit,nouveau
pci_hotplug            20534  1 shpchp
ppdev                   4750  0 
parport_pc             26633  0 
parport                26063  2 ppdev,parport_pc
serio_raw               3709  0 
psmouse                70891  0 
processor              23815  0 
pcspkr                  1455  0 
evdev                   7630  7 
button                  3614  1 nouveau
fuse                   60090  12 
ext4                  386184  4 
crc16                   1091  1 ext4
jbd2                   62469  1 ext4
mbcache                 4345  1 ext4
sd_mod                 26991  14 
sr_mod                 13180  0 
cdrom                  30472  1 sr_mod
pata_acpi               2388  0 
pata_amd                8155  12 
ata_generic             2391  0 
libata                146087  3 pata_acpi,pata_amd,ata_generic
scsi_mod              112495  3 libata,sd_mod,sr_mod
ohci_hcd               19056  0 
ehci_hcd               35958  0 
usbcore               123457  3 ohci_hcd,ehci_hcd
usb_common               622  1 usbcore
floppy                 48805  0 

Dois-je créer un fichier par modules ? ou bien puis les indiquer comme il apparaissent ici (un par ligne) ?

Dans modprobe.conf, je n'ai que ceci :

cat /etc/modprobe.d/modprobe.conf
options nouveau modeset=1
---------------
En ce qui concerne les services, pourrais-tu m'expliquer comment on fait pour les activer sous systemd ?

Tu vas sans doute me dire que c'est dans le wiki mais personnellement je ne vois pas bien où c'est expliqué ; je dois avouer que je m'y perds dans ces notions de target et d'unités.
----------------
Question journal, celui du boot contient un vide entre 14 h 46 et 16 h 26, et c'est dans cet intervalle que j'ai tenté mon boot sous systemd. Les journaux des erreurs errors.log, log1, log2, log3, etc... sont tous identiques. Je t'en fournis un extrait de celui d'ajourd'hui pour info et tu remarqueras aussi l'intervalle entre deux démarrages :

Code : Tout sélectionner

Aug 15 14:46:09 localhost pulseaudio[1024]: [pulseaudio] pid.c: Daemon already running.
Aug 15 14:46:14 localhost kernel: [   51.766713] end_request: I/O error, dev fd0, sector 0
Aug 15 14:46:14 localhost kernel: [   51.790079] end_request: I/O error, dev fd0, sector 0
Aug 15 14:46:25 localhost kernel: [   62.662172] [drm] nouveau 0000:01:00.0: illegal object class: 0x99
Aug 15 14:46:25 localhost kernel: [   62.662184] [drm] nouveau 0000:01:00.0: Error creating object: -22 (2/0xbeef0001)
Aug 15 16:26:04 localhost dhcpcd[497]: eth0: sendmsg: Cannot assign requested address
Aug 15 16:26:05 localhost colord-sane: io/hpmud/pp.c 627: unable to read device-id ret=-1
Aug 15 16:26:05 localhost /usr/sbin/crond[589]: (CRON) INFO (Syslog will be used instead of sendmail.): Aucun fichier ou dossier de ce type
Aug 15 16:26:11 localhost colord-sane: io/hpmud/pp.c 627: unable to read device-id ret=-1
Aug 15 16:26:14 localhost kernel: [   26.288401] [drm] nouveau 0000:01:00.0: illegal object class: 0x99
Aug 15 16:26:14 localhost kernel: [   26.288412] [drm] nouveau 0000:01:00.0: Error creating object: -22 (2/0xbeef0001)
Aug 15 16:26:18 localhost pulseaudio[870]: [pulseaudio] bluetooth-util.c: org.bluez.Manager.ListAdapters() failed: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
Aug 15 16:26:29 localhost pulseaudio[990]: [pulseaudio] bluetooth-util.c: org.bluez.Manager.ListAdapters() failed: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
Aug 15 16:26:31 localhost pulseaudio[1024]: [pulseaudio] pid.c: Daemon already running.
Aug 15 16:26:37 localhost kernel: [   48.366734] end_request: I/O error, dev fd0, sector 0
Aug 15 16:26:37 localhost kernel: [   48.390056] end_request: I/O error, dev fd0, sector 0
Aug 15 16:26:45 localhost kernel: [   57.153079] [drm] nouveau 0000:01:00.0: illegal object class: 0x99
Aug 15 16:26:45 localhost kernel: [   57.153091] [drm] nouveau 0000:01:00.0: Error creating object: -22 (2/0xbeef0001)

----------------
GDM : oui mais finalement, j'ignore si c'est inittab ou .xinitrc qui le démarre.
systemd-arch-units : non, pas (encore) installé ; je le fais de suite et fait une nouvelle tentative.

Je reviens dès que possible.

EDIT : Me revoilà : même problème.

Manifestement, le boot opère le montage de ce qui se trouve dans fstab et les deux dernières lignes sont :
mounting /home
mounted /home (ou /home mounted)
puis ça fige.

NB : toujours rien dans le journal de boot et dans errors.log

[FoolEcho]

Dans ma arch en dur, fuse est dans la rubrique MODULES et il n'y a que lui.
En revanche dans ma Arch virtuelle, fuse est dans les DAEMONS

Normalement, fuse est un module (voir sortie de ton lsmod).

Dois-je créer un fichier par modules ? ou bien puis les indiquer comme il apparaissent ici (un par ligne) ?

Il devrait être évident que non.
Ceci n'est valable que pour des modules que le kernel ne charge pas d'emblée mais que l'on veut (donc l'équivalent de ceux de MODULES du rc.conf).

En ce qui concerne les services, pourrais-tu m'expliquer comment on fait pour les activer sous systemd ?

Tu vas sans doute me dire que c'est dans le wiki mais personnellement je ne vois pas bien où c'est expliqué ; je dois avouer que je m'y perds dans ces notions de target et d'unités.

http://wiki.archlinux.fr/Systemd#Commandes
Donc le fonctionnement, c'est similaire à rc.d.
Tu as

Code : Tout sélectionner

systemctl start <unit>
systemctl stop <unit>
systemctl restart <unit>
systemctl reload <unit>

pour démarrer, arrêter, redémarrer un service pour la session en cours.

Pour établir/enlever un service au démarrage (l'équivalent du DAEMONS du rc.conf), il suffit de faire:

Code : Tout sélectionner

systemctl enable <unit>
systemctl disable <unit>

Exemple:
Démarrage du réseau filiaire (équivalent du service network / voir Services pour la liste des choses les plus courantes) pour la session en cours:

Code : Tout sélectionner

systemctl start dhcpcd@.service

Pour l'établir au démarrage (équivalent à DAEMONS du rc.conf, donc, mais dans du pur systemd, il n'y a pas de rc.conf, donc pas de DAEMONS):

Code : Tout sélectionner

systemctl enable dhcpcd@.service

GDM : oui mais finalement, j'ignore si c'est inittab ou .xinitrc qui le démarre.

http://wiki.archlinux.fr/Systemd#Compat ... nitscripts
C'est forcément inittab (le .xinitrc n'est lu que si tu lances startx ou par slim par exemple, mais gdm s'en fiche). Et inittab est ignoré sous systemd, il te faut donc démarrer gdm par systemctl en root ou ton environnement gnome par startx avec ton utilisateur (et si tu n'as rien comrpis à mes explications précédentes, je ne peux plus rien pour toi ).

En gros, comme tu es en mode mixte (systemd + initscripts), en dehors de certains services qu'il te faut lancer par systemctl (gdm ici), l'essentiel des services devrait déjà être lancé au démarrage (le rc.conf est lu en mode mixte, donc les DAEMONS également).

[jean_no]

salut

peux-tu nous montrer le contenu de ton fstab ( cat /etc/fstab )

[mimile]

@ Foolecho

J'avais évidemment bien compris la finalité des différentes commandes systemctl.

Comme tu me l'as indiqué, j'ai fait : systemctl enable gdm.service qui m'a créé un lien symbolique avec display-manager.service

En revanche, ce que je ne comprends pas bien, c'est comment faire en sorte que les services qu'on utilise démarrent automatiquement lors du boot.

Voici les miens (les "DAEMONS") contenus dans rc.conf :

Code : Tout sélectionner

syslog-ng dbus alsa networkmanager cupsd acpid crond ntpd pcscd

Par exemple dois-je faire (en console): systemctl enable <chaque service> ?

Désolé pour ces questions qui doivent te paraître élémentaires.

A noter que j'ai ré-essayé un démarrage avec systemd et qu'à nouveau, il a bloqué après avoir monté /home (je ne sais pas, à ce stade, faire de copier/coller de ce qui précède).

Au vu de mon fstab (voir ci-dessous), y aurait-il un problème avec le montage des partitions ntfs qui suivent ?

*******************

EDIT : j'ai ajouté init=/bin/systemd à la ligne fallback dans grub.cfg puis j'ai booté sur fallback.

Comme d'habitude, il s'est arrêté après /home mounted et cette fois, j'ai attendu un bon moment pour voir apparaître ceci :

Code : Tout sélectionner

[ TIME   ] timed out waiting for device dev-disk-by\x2duuid-16b661b241d50656.device (cet UUID n'apparaît pas quand j'utilise blkid)
[ DEPEND ] depedency failed for /media/disk_usb4
[ DEPEND ] depedency failed for Local File Systems
[ DEPEND ] depedency failed for Basic Systems
[ DEPEND ] depedency failed for Permit User Sessions
[ DEPEND ] depedency failed for Gnome Display Manager
[ DEPEND ] depedency failed for /etc/rc.local compatibility
[ DEPEND ] depedency failed for Multi-User
[ DEPEND ] depedency failed for Graphical Interface
Welcome to emergency mode
Use "System default" or ^D to enter default
Give root passworg for maitenance
(or type CTRL-D to continue)

Ni mon mot de passe root ni ctrl-d ne réagissent.

Je dois avoir recours au très windowsien ctrl-alt-del pour voir apparaître une série de ligne annonçant le démontage de ce qui avait été monté avant.

J'ajoute que quand je tape en console : systemctl, j'ai en réponse :

Code : Tout sélectionner

[okapi@Archibald ~]$ systemctl
Failed to get D-Bus connection: No connection to service manager.

Plus ça va, moins va ...
***********************
EDIT-bis : dans mon fstab, il y avait des lignes de montages des 4 partitions se trouvant sur un disque USB externe. Il s'agit des 4 dernières lignes Dans sa représentation ci-dessous.

Je me rends compte que c'était le montage de la 4ème ligne (UUID) qui posait problème.

J'ai commenté ces 4 lignes puis j'ai booté sur fallback et là, ça passe !

J'ai donc ajouté à grub.cfg la ligne init=/bin/systemd pour travailler sur la version normale et là déception, à nouveau freeze après mounted /home puis apparition des messages indiqués dans mon 1er EDIT...

*************************

@Jean_no : voici mon fstab :

Code : Tout sélectionner

[okapi@Archibald ~]$ cat /etc/fstab
# 
# /etc/fstab: static file system information
#
# <file system>	<dir>	<type>	<options>	<dump>	<pass>
tmpfs		/tmp	tmpfs	nodev,nosuid	0	0
/dev/sda5 / ext4 defaults 0 1
/dev/sda6 /home ext4 defaults 0 1
UUID=c0f8bfc2-22fc-4423-8226-6df419c1cf9f       swap    swap    defaults 0 0

UUID=5288BBC688BBA6C0   /media/windows  ntfs-3g ro,noatime      0       0
UUID=4E9CCE6B9CCE4CE1   /media/win_1    ntfs-3g rw,noatime      0       0
UUID=1FD4F91475412DAD   /media/win_2    ntfs-3g rw,noatime      0       0
UUID=7AF5571B5E79D157   /media/win_3    ntfs-3g rw,noatime      0       0
UUID=4E54627654626127   /media/windows7 ntfs-3g rw,noatime      0       0

UUID=dc427604-1c17-4054-9083-9cc28a4dad84       /media/Squeeze_root     ext3    rw,noatime      0       0
UUID=7f86dfda-43cf-4619-baea-17980d3c7ab2       /media/Squeeze_home     ext3    rw,noatime      0       0

UUID=cb833b14-3a5e-4d43-8704-5a1471784893       /media/Lenny_root       reiserfs ro,noatime     0       0
UUID=43a98b54-cc00-4f38-888f-94a7551358d1       /media/Lenny_home       reiserfs rw,noatime     0       0

UUID=7EEA9309666F4B67	/media/disk_usb1	ntfs-3g	rw,noatime,user,umask=0	0	0
UUID=4CF8C1270DB4D623	/media/disk_usb2	ntfs-3g	rw,noatime,user,umask=0	0	0
UUID=0CE8AECFE8AEB67C	/media/disk_usb3	ntfs-3g	rw,noatime,user,umask=0	0	0
UUID=16B661B241D50656	/media/disk_usb4	ntfs-3g	rw,noatime,user,umask=0	0	0

[tuxce]

Par exemple dois-je faire (en console): systemctl enable <chaque service> ?

oui

Comme d'habitude, il s'est arrêté après /home mounted et cette fois, j'ai attendu un bon moment pour voir apparaître ceci :

Par défaut, systemd attend 90s avant de redonner la main si un montage a un problème.

[ DEPEND ] depedency failed for /media/disk_usb4

/media/disk_usb4 n'apparaît pas dans ton /etc/fstab

Je dois avoir recours au très windowsien ctrl-alt-del

C'est pas parce qu'on apprend quelque chose sur un OS que c'est spécifique à ce dernier

J'ajoute que quand je tape en console : systemctl, j'ai en réponse :

Code : Tout sélectionner

[okapi@Archibald ~]$ systemctl
Failed to get D-Bus connection: No connection to service manager.

Tu ne peux pas utiliser systemctl si le système n'a pas démarré avec systemd. (Tu peux néanmoins faire des liens, mais pour expliquer, c'est une autre paire de manches )

[mimile]

Bonjour

Peut-être n'as-tu pas pris connaissance de deux EDIT que j'ai ajoutés à ma précédente réponse.

Maintenant, quand je boot Fallback, ça passe sans problème et voici ce que me renvoie systemctl : http://pastebin.archlinux.fr/449508

Bizaremment, ça continue à coincer quand je boote sur Archlinux.

[tuxce]

Effectivement, je n'avais pas vu, ceci dit, là je suis perplexe (surtout parce que je ne veux pas faire une conclusion hâtive ).
Le boot, à partir de systemd (ou initscripts) n'est pas lié à l'initrd (fallback ou pas), par contre, pour ce qui nous intéresse (à savoir le montage), c'est lié au fstab. Donc je me pose la question à savoir, est ce que t'es sûr d'utiliser la même racine sur les 2 entrées (normal et fallback), parce que comme ça, je ne vois pas trop comment il peut deviner un /media/disk_usb4 (tu dis que c'est les mêmes messages) s'il n'y en a pas dans le fstab

[mimile]

Bonjour,

Merci pour ta réponse.

Le problème du montage des partitions indiquées dans le fstab a disparu depuis que j'ai commenté les quatre lignes concernant les quatre partitions de mon DD USB externe USB (ces lignes étaient là parce que Arch ne réagissait pas du tout à la mise en marche du DD externe et qu'il me suffisait de faire un mount -all pour y accéder).

Avant que j'installe systemd, lors du boot, si le DD externe était éteint, j'avais simplement 4 lignes d'erreurs annonçant immédiatement l'impossibilité de monter ses partitions, mais c'était instantané.

En revanche, avec systemd, manifestement, la durée du timeout de la recherche est très long au point de faire croire que le boot est freezé, ce qui justifie le titre de mon poste.

Ce matin, alors que j'étais encore dans ce cas de figure, je me suis éloigné de mon PC une dizaine de minutes et quand je suis revenu, j'ai vu que s'affichait ce que j'ai renseigné dans mon premier EDIT :

Code : Tout sélectionner

[ TIME   ] timed out waiting for device dev-disk-by\x2duuid-16b661b241d50656.device (cet UUID n'apparaît pas quand j'utilise blkid)
[ DEPEND ] depedency failed for /media/disk_usb4
[ DEPEND ] depedency failed for Local File Systems
[ DEPEND ] depedency failed for Basic Systems
[ DEPEND ] depedency failed for Permit User Sessions
[ DEPEND ] depedency failed for Gnome Display Manager
[ DEPEND ] depedency failed for /etc/rc.local compatibility
[ DEPEND ] depedency failed for Multi-User
[ DEPEND ] depedency failed for Graphical Interface
Welcome to emergency mode
Use "System default" or ^D to enter default
Give root passworg for maitenance
(or type CTRL-D to continue)

NB : j'ai ajouté

Code : Tout sélectionner

(cet UUID n'apparaît pas quand j'utilise blkid)

parce qu'à ce moment, mon DD externe était éteint.

En vérifiant dans mon fstab, j'ai vu qu'une des partitions de mon DD externe possédait effectivement l'UUID indiquée dans le timeout.

J'ai donc commenté ces lignes et maintenant, le boot se déroule sans interruption avec l'image-fallback.

Au passage, je ne vois pas en quoi que l'échec de montage d'une partition non trouvée provoquerait tous les messages d'erreurs qui suivent (tous les DEPEND] quand je boot sur l'image normale.

Donc pour résumer :

- Je boot sur l'image normale d'Arch et, après le "/home mounted", je vois apparaître tous les DEPEND puis le message Welcome to emergency mode etc...

- Je boot sur l'image-fallback et ça passe les doigts dans le nez.

Qu'est-ce qui peut justifier cette différence de comportement ?

Pour répondre à ta question, voici ce que contient mon grib.cfg :

Code : Tout sélectionner

menuentry "Arch Linux (on /dev/sda5)" {
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set 8d61cac4-118f-476f-9974-5d1b7800deac
	linux /boot/vmlinuz-linux root=/dev/sda5 ro init=/bin/systemd vga=791
	initrd /boot/initramfs-linux.img
}
menuentry "Arch Linux Fallback (on /dev/sda5)" {
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos5)'
	search --no-floppy --fs-uuid --set 8d61cac4-118f-476f-9974-5d1b7800deac
	linux /boot/vmlinuz-linux root=/dev/sda5 ro init=/bin/systemd
	initrd /boot/initramfs-linux-fallback.img

Pour moi, y'a pas photo : les deux sont identiques hormis l'image des initrd

Bizarre non ?

[Blueicefield]

Je pense que cela s'explique par le fait qu'il n'y ait pas le hook autodetect dans l'initramfs de faillback, si ma mémoire est bonne !

[mimile]

C'est à devenir fou !!!

Dans mon précédent message, j'indiquais que le boot se faisait sans problème avec l'image-fallback mais que ça plantait avec l'image normale.

Pour voir, je tente un boot sur l'image normale et ... ça passe !!!

Je reboote sur l'image normale, ça plante !!!

ctrl-alt-delete puis je reboote sur l'image normale ... ça passe

J'ai renouvelé l'opération à 7 ou 8 reprises et une fois ou deux fois, ça a planté en indiquant à chaque les mêmes messages que précédemment.

@ blueicefield : merci d'intervenir, mais je ne vois pas ce que je devrais faire pour remédier à ce que tu dis.

[Blueicefield]

Si cela fonctionne à tout les coups avec la version fallback, il y a un test que tu peux faire :
- Edite le fichier /etc/mkinitcpio.conf et supprime autodetect dans les HOOKS.
- Régénère l'initramfs :

Code : Tout sélectionner

mkinitcpio -p linux

Et boot à nouveau en normal pour tester.

PS/ Pour remettre les choses à leur état d'origine, tu refais le tout en faisant l'inverse à l'étape 1.
PS2/ C'est la seule diff entre le mode normal et le mode fallback à ma connaissance.

[mimile]

Ce qui revient à dire que l'image normale et celle de fallback seront identiques si je comprends bien ...

Dans les minutes qui ont précédé, j'ai encore fait quelques reboot sur l'image "normale" et je n'ai plus eu de problème.

Je garde ta suggestion en réserve si le problème revenait.

Merci en tout cas.

Au fait, à quoi sert ce "autodetect" ?

EDIT : j'ai vu sur le net à quoi ça servait.

Et comme par hasard, après un petit tour sur windows, Arch a planté au boot.

Donc, je vais faire ce que tu suggères

Cordialement,

[Blueicefield]

Alors le hook autodetect est uniquement activé sur l'initramfs par défaut (pas sur la version fallback), il sert à détecter les modules liés aux hooks listés après lui pour ne charger que ceux nécessaires selon ta configuration.

Il se pourrait donc que celui-ci désactive des modules dont tu as véritablement besoin au boot, mais cela n'est qu'une hypothèse car je ne connais pas exactement son mécanisme interne. Cependant, c'est une hypothèse qui se tient sinon je ne vois pas pourquoi le mode fallback le désactiverait.

Note complémentaire : Les hooks de l'initramfs, sont des fonctionnalités supplémentaires que l'on peut ajouter à l'initramfs, par exemple, pour apporter le support des partitionnement LVM ou le support des partitions encryptées ou encore le démarrage sur un périphérique USB.

[mimile]

Merci pour ces explications.

J'ai retiré autodetect des hooks de mkinitcpio.conf et fait quelques reboot sans erreur.

Pourvu que ça dure ...

Amicalement,

[Blueicefield]

Je viens de m'apercevoir que j'ai un peu foiré mon explication, l'autodetect ne désactive pas des hooks de l'initramfs mais plutôt des modules exploités par l'initramfs (selon ses hooks). En gros, il va réduire les modules au stricte minimum selon ta config. En mode fallback, l'autodetect n'est pas activé et donc la totalité des modules est chargée.

J'édite ma précédente intervention pour rectifier le tir histoire de garder une info pertinente sur le forum.

[tuxce]

Juste pour être sûr : t'es sûr que c'est les même message d'erreur ? à savoir ceux qui parlent de /media/disk_usb4 alors que tu ne l'as plus

Je ne comprends pas quel est l'intérêt de le supprimer autodetect ?
Si tu ne veux pas démarrer sur l'image qui l'as, il suffit de sélectionner l'autre ! Générer deux images identiques, c'est ... inutile.
Pour ce qui est de l'hypothèse d'un module manquant dans l'image normale, elle ne tient pas si on prend en compte le fait que ça démarre de temps en temps.

[Blueicefield]

@tuxce : Ce n'est pas une solution que je lui ai indiqué mais juste une démarche visant à confirmer ou informer que son problème provient d'une hypothétique différence entre son initramfs par défaut et celui de fallback.

[mimile]

[MODO: précédent message]

Juste pour être sûr : t'es sûr que c'est les même message d'erreur ? à savoir ceux qui parlent de /media/disk_usb4 alors que tu ne l'as plus

Bonjour,

Effectivement, l'erreur concernant /media/disk_usb4 n'apparaît plus ; j'avais fait un copier/coller de mon premier affichage en omettant d'effacer les lignes qui y faisaient référence ; en revanche, quand le boot plante, les autres apparaissent bel et bien.

Pour le surplus, vous remarquerez que j'ai retiré "résolu" du titre de mon poste.

En effet, ce matin, en mettant en marche mon PC et en bootant sur l'image normale, j'ai été bloqué dans mon boot qui a de nouveau affiché les lignes d'erreurs habituelles.

ctrl-alt-del puis reboot sur l'image normale et là, ça a passé.

Tant qu'à faire et au vu de vos explications, j'ai remis autodetect dans les hooks de mkinitcpio et j'ai recréé les images.

Ce côté aléatoire des boot qui passent ou pas est assez déconcertant et rend quasiment impossible une réflexion sur l'origine du problème.
[/MODO]

J'ai cru effectivement que le fallback ne posait pas problème, ayant fait quelques reboot réussis hier, ce qui m'a donc décidé à suivre la suggestion de blueicefield, savoir retiré "autodetect" des hooks de mkinitcpio.conf.

Ce matin, après le plantage avec l'image "normale", j'ai rebooté sur celle-ci et c'est passé.

A titre expérimental, je suis passé sous Squeeze puis je suis revenu sur Arch-fallback qui a planté aussi (une première !). Je me suis donc dit que le hook autodetect n'avait pas la responsabilité du problème et j'ai donc rétabli mon image normale en y remettant autodetect.

Il n'y a vraiment aucune logique dans ces plantages qui surviennent de manière complètement aléatoire.

Ce que j'ai observé en tout cas, c'est qu'il n'y a jamais deux plantages de suite ; après un plantage, les reboot suivant réussissent systématiquement.

Autre constatation : si je boote sur une autre distro (que ce soit Squeeze ou Windows), la plupart du temps, le premier boot d'Arch plante et les messages d'erreur apparaissent toujours après l'échec du montage d'une partition quelconque.

J'observe d'ailleurs un problème vaguement similaire quand, après avoir utilisé Windows, je démarre Lenny ou Squeeze, le boot bloque à la 4ème ligne du boot (de mémoire, c'est : waiting for udev fully populated) ; je dois alors éteindre le PC à l'arraché et quand je relance Lenny ou Squeeze, le boot se déroule normalement. Arch, quant à lui, ne pose pas ce genre de problème ...

J'ai déjà posté à ce sujet sur un autre forum que je fréquente assidûment mais malgré le haut niveau de compétence de quelques membres très actifs, aucune solution n'a été trouvée à ce comportement étrange.