Re: Lenteur au boot : résolu
On 20 Aug 2023 16:14, ajh-valmer wrote: Hello, J'ai retrouvé une vitesse de boot plus digne. /etc/default/grub : GRUB_DISABLE_OS_PROBER=false (retirer le #) Pour info, "GRUB_DISABLE_OS_PROBER" n'a rien à voir avec le boot proprement dit. Ca ne sert qu'à détecter les autres OS installés sur ta machine, et uniquement lorsque "update-grub" se lance (penser dual boot), par exemple lors d'un update du kernel. D'ailleurs, c'est couillon mais c'est une double négation : disable + false = true, donc tu viens d'activer le prober. Si tu n'as pas d'autres OS installés sur ta machine, ou *surtout* si tu utilises un hyperviseur (virtualisation) avec des disques "passthrough-ed", je te conseille de le mettre à TRUE (l'autre option étant de carrément virer le paquet "os-prober"). Bonus, tu gagneras quelques secondes lors des prochains lancements de "update-grub", car il n'aura pas à parcourir tous tes disques à la recherche d'autres OS. PS: il faut lancer "update-grub" à chaque modif de "/etc/default/grub". /etc/boot/grub.cfg : /dev/sda5 indiquait msdos6 puis update-initramfs -u a remédié au problème. Je pense que tu voulais dire "/boot/grub.cfg". Bon dimanche. https://xkcd.com/386 ;) -- ++ zithro / Cyril
Re: Lenteur au boot : résolu
Hello, J'ai retrouvé une vitesse de boot plus digne. /etc/default/grub : GRUB_DISABLE_OS_PROBER=false (retirer le #) /etc/boot/grub.cfg : /dev/sda5 indiquait msdos6 puis update-initramfs -u a remédié au problème. Bon dimanche.
Re: Lenteur au boot
Salut, Le 17/08/23 à 22:56, ajh-valmer a écrit : Intéressant, je l'ignorais, peut-être une piste ? : # systemd-analyze blame 6.383s NetworkManager-wait-online.service soit quasi 7 secondes. Maintenant comment corriger le problème avec NetworkManager-wait-online ? Bonne fin de soirée. Comme expliqué dans la page de man, certains services prennent du temps à cause de leurs dépendances. À analyser avec cet aspect en tête. -- Jean-Marc OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Lenteur au boot
On Thursday 17 August 2023 22:36:43 Jean-Marc wrote: > J'interviens un peu à l'arrache dans ce fil de discussion. > As-tu essayer de voir ce que donne la commande "systemd-analyze blame" ? > Je ne sais pas si quelqu'un d'autre l'a déjà proposée. > Elle permet d'afficher quelles unités prennent le plus de temps lors de > l’amorçage. > Un coup d’œil sur la page de man éclaire aussi ce qu'il faut lire de la > sortie de cette commande : Intéressant, je l'ignorais, peut-être une piste ? : # systemd-analyze blame 6.383s NetworkManager-wait-online.service soit quasi 7 secondes. Maintenant comment corriger le problème avec NetworkManager-wait-online ? Bonne fin de soirée. On Thursday 17 August 2023 22:02:50 Gaëtan Perrier wrote: > Un firmware manquant ? : Oui mais lequel ? On Thursday 17 August 2023 22:18:16 Th.A.C wrote: > Tu peux aussi sortir le resultat de dmesg dans un fichier en utilisant > l'option qui affiche l'heure sous forme lisible (-H) : dmesg affiche trop de lignes, difficile de détecter ou est le blême. > > Le 14/08/2023 à 23:13, ajh-valmer a écrit : > >> Depuis la migration de mon portable à Bookworm, > >> le boot se bloque environ 10 secondes avec un tiret en haut à gauche. > >> Puis, les infos du boot défilent, et enfin le boot du bureau tdm-trinity. > >> Après, tout semble stable. > >> Que se passe t-il pour avoir une première étape de boot si longue ?
Re: Lenteur au boot
J'interviens un peu à l'arrache dans ce fil de discussion. As-tu essayer de voir ce que donne la commande "systemd-analyze blame" ? Je ne sais pas si quelqu'un d'autre l'a déjà proposée. Elle permet d'afficher quelles unités prennent le plus de temps lors de l’amorçage. Un coup d’œil sur la page de man éclaire aussi ce qu'il faut lire de la sortie de cette commende. Le 17/08/23 à 22:18, Th.A.C a écrit : Le 14/08/2023 à 23:13, ajh-valmer a écrit : Hello, Depuis la migration de mon portable à Bookworm, le boot se bloque environ 10 secondes avec un tiret en haut à gauche. Puis, les infos du boot défilent, et enfin le boot du bureau tdm-trinity. Après, tout semble stable. Que se passe t-il pour avoir une première étape de boot si longue ? Merci. A. Valmer -- Jean-Marc OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Lenteur au boot
Le 14/08/2023 à 23:13, ajh-valmer a écrit : Hello, Depuis la migration de mon portable à Bookworm, le boot se bloque environ 10 secondes avec un tiret en haut à gauche. Puis, les infos du boot défilent, et enfin le boot du bureau tdm-trinity. Après, tout semble stable. Que se passe t-il pour avoir une première étape de boot si longue ? Merci. A. Valmer Tu peux aussi sortir le resultat de dmesg dans un fichier en utilisant l'option qui affiche l'heure sous forme lisible (-H). En regardant les temps affichés, tu détecteras peut-être le/les moments qui prennent trop de temps... A faire juste après le boot
Re: Lenteur au boot
Un firmware manquant ? Le 17 août 2023 16:05:04 GMT+02:00, ajh-valmer a écrit : >> Le 14 août 2023 23:13:23 GMT+02:00, a. valmer a écrit : >> >Depuis la migration de mon portable à Bookworm, >> >le boot se bloque environ 10 secondes avec un tiret en haut à gauche. >> >Puis, les infos du boot défilent, et enfin le boot du bureau tdm-trinity. >> >Après, tout semble stable. >> >Que se passe t-il pour avoir une première étape de boot si longue ? > >On Monday 14 August 2023 23:44:14 Gaëtan Perrier wrote: >> Regardes du côté des montages. Moi j'avais un problème d'uuid avec >> le swap et ça me faisait pareil. > >Juste après avoir cliqué le choix de la partition Grub, j'ai un tiret >clignotant d'une longue durée. > >/etc/fstab : tout est ok. > ># journalctl | grep Error >J'ai de très nombreuses lignes comme ceci : >kernel: pcieport :00:1c.4: PCIe Bus Error: severity=Corrected, >type=Physical Layer, (Receiver ID). > >dmesg | grep Failed : rien > >Aussi, peut-être désactiver le bluetooth, mais comment ? > -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Lenteur au boot
> Le 14 août 2023 23:13:23 GMT+02:00, a. valmer a écrit : > >Depuis la migration de mon portable à Bookworm, > >le boot se bloque environ 10 secondes avec un tiret en haut à gauche. > >Puis, les infos du boot défilent, et enfin le boot du bureau tdm-trinity. > >Après, tout semble stable. > >Que se passe t-il pour avoir une première étape de boot si longue ? On Monday 14 August 2023 23:44:14 Gaëtan Perrier wrote: > Regardes du côté des montages. Moi j'avais un problème d'uuid avec > le swap et ça me faisait pareil. Juste après avoir cliqué le choix de la partition Grub, j'ai un tiret clignotant d'une longue durée. /etc/fstab : tout est ok. # journalctl | grep Error J'ai de très nombreuses lignes comme ceci : kernel: pcieport :00:1c.4: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID). dmesg | grep Failed : rien Aussi, peut-être désactiver le bluetooth, mais comment ?
Re: Lenteur au boot
Hello, Regardes du côté des montages. Moi j'avais un problème d'uuid avec le swap et ça me faisait pareil. Gaëtan Le 14 août 2023 23:13:23 GMT+02:00, ajh-valmer a écrit : >Hello, >Depuis la migration de mon portable à Bookworm, >le boot se bloque environ 10 secondes avec un tiret en haut à gauche. >Puis, les infos du boot défilent, et enfin le boot du bureau tdm-trinity. >Après, tout semble stable. >Que se passe t-il pour avoir une première étape de boot si longue ? >Merci. >A. Valmer > -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Lenteur au boot
Hello, Depuis la migration de mon portable à Bookworm, le boot se bloque environ 10 secondes avec un tiret en haut à gauche. Puis, les infos du boot défilent, et enfin le boot du bureau tdm-trinity. Après, tout semble stable. Que se passe t-il pour avoir une première étape de boot si longue ? Merci. A. Valmer
[Résolu par update-initramfs -u]Devenu lenteur au boot
Je fais un résumé de mon problème résolu dans un même message, pour faciliter la recherche de ceux qui le rencontraient. Comme ça ne bootait plus après le déplacement d'une deb sur un autre disque, j’ai utilisé le net install, il y a un sous-menu pour réparer une install… De plus, l’UUID de la partition swap n’était plus le bon, car comme elle n’était plus reconnue comme tel par gparted, je fais un mkswap, ce qui a peut-être modifié l’UUID... Du coup ça bootait, mais ça restait calé des plombes après "loading initial ramdisk" J'avais corrigé l'UUID de la swap qui n'était plus le bon, mais pas fait de : # update-initramfs -u Ce qui a résolu le problème…. Envoyé avec la messagerie sécurisée Proton Mail. --- Original Message --- Le jeudi 14 juillet 2022 à 11:18, didier gaumet a écrit : > Bonjour, > > J'ai suivi ça de loin mais je crois que tu as recréé ta partition EFI, > en VFAT? > Vérifie avec un outil de partitionnement qu'elle a bien les drapeaux > "boot" et "esp" et si ce n'est pas le cas, positionne ces drapeaux pour > cette partition (avec parted c'est la commande toggle, avec gparted > c'est le menu contextuel "gérer les drapeaux", avec d'autres outils je > ne sais pas). > Une hypothèse (pas forcément judicieuse) est que la partition EFI > n'étant pas identifiée comme telle (drapeau "esp"), il y a un mécanisme > pour chercher parmi les partitions si il y en a une formatée en VFAT qui > contient des fichiers UEFI, ce qui expliquerait le délai. > Je connais très mal tout ça donc je raconte peut-être n'importe quoi: > mon intervention est un grand suppositoire ;-)
Re : Re: Devenu lenteur au boot
Le jeudi 14 juillet 2022 à 15:20, Hugues Larrive a écrit : > --- Original Message --- > >> Fait, j'ai vérifié que chaque ligne du fstab affiche bien le bon UUID et de >> fait la swap n'avait pas le bon UUID. > Ça c'est une piste, car la partition de swap est utilisée pour l’hibernation > donc il faut peut-être mettre à jour l'initrd : > # update-initramfs -u > update-initramfs: Generating /boot/initrd.img-4.19.0-20-amd64 > I: The initramfs will attempt to resume from /dev/sda3 > I: (UUID=59ee9c7e-28f4-4ce4-be8c-7e6c07e8a2f5) > I: Set the RESUME variable to override this. Youyou Bingo !! J'avais corrigé l'UUID de la swap qui n'était plus le bon, mais pas fait de : # update-initramfs -u Je ne connaissais pas cette commande et ne sais pas ce que ça fait, j'irai lire le man, mais là ça boot normalement sans rester calé des plombes après "loading initial ramdisk". Un tout grand merci ! Avec gratitude, -- Benoit
Re: Devenu lenteur au boot
Bonjour, J'ai suivi ça de loin mais je crois que tu as recréé ta partition EFI, en VFAT? Vérifie avec un outil de partitionnement qu'elle a bien les drapeaux "boot" et "esp" et si ce n'est pas le cas, positionne ces drapeaux pour cette partition (avec parted c'est la commande toggle, avec gparted c'est le menu contextuel "gérer les drapeaux", avec d'autres outils je ne sais pas). Une hypothèse (pas forcément judicieuse) est que la partition EFI n'étant pas identifiée comme telle (drapeau "esp"), il y a un mécanisme pour chercher parmi les partitions si il y en a une formatée en VFAT qui contient des fichiers UEFI, ce qui expliquerait le délai. Je connais très mal tout ça donc je raconte peut-être n'importe quoi: mon intervention est un grand suppositoire ;-)
Devenu lenteur au boot
Ca boot, mais j'ai un nouveau problème, le POST (power-on self-test) se déroule bien, GUB me propose de booter sur debian, ça affiche "loading initial ramdisk" et puis juste un tiret qui clignote un long moment avant que les lignes de messages de démarrage se mettent à défiler normalement (quiet_boot="0" /etc/grub.d/10_linux est configuré pour montrer les lignes du démarrage). Je ne sais pas à quoi est dû ce long moment Là je suis perdu... --- Original Message --- Le mercredi 13 juillet 2022 à 02:40, Hugues Larrive a écrit > Normalement c'est une partition msdos, sur mon système j'ai une ligne dans > fstab : > UUID=9A05-3C9C /boot/efi vfat umask=0077 0 1 Ok pour ça. > # ls -R /boot/efi/ > /boot/efi/: > EFI > > /boot/efi/EFI: > debian > > /boot/efi/EFI/debian: > BOOTX64.CSV fbx64.efi grub.cfg grubx64.efi mmx64.efi shimx64.efi Ok pour ça. > Je ne sais pas si c'est standard, c'était à l'origine une installation debian > 8 i386 sur un core2 duo en MBR, que j'ai mis à jour en 9 puis 10 et > "crossgradé" en amd64. Elle doit en être également à son 3ème PC et 5ème > disque dur. > > Les fichiers .efi proviennent du package grub-efi-amd64 et de shim > (dépendance). Installé ok > Avec EFI/GPT il faut oublier le concept de partition active ou boot flag, les > informations > de boot sont stockées dans la NVRAM/CMOS de la carte-mère. On peut les lire > avec la commande efibootmgr : > # efibootmgr > BootCurrent: 000F > Timeout: 1 seconds > BootOrder: 0011,000F,000E,0003,0012,0004,0001,0006,0005 > Boot0001* Windows Boot Manager > Boot0003* IBA GE Slot 00C8 v1555 > Boot0004* UEFI: Built-in EFI Shell > Boot0005* Generic Usb Device > Boot0006* CD/DVD Device > Boot000E* TOSHIBA DT01ACA050 > Boot000F* debian > Boot0011* KingFast > Boot0012* USB2.0 CardReader > > Ici KingFast est le SSD où est installé ma debian, on peut voir qu'il est en > premier dans le BootOrder mais que BootCurrent est sur debian donc sans > "installation" ça n'aurait pas fonctionné. > >> Il faudra aussi réécrire un nouvel fstab avec de nouveau UUID je suppose que >> si on change la table de partition les UUID, ne sont plus les même ? > > Ça c'est effectivement la première chose à faire. Pour connaître les UUID qui > vont bien pour fstab j'utilise simplement la commande ls -l /dev/disk/by-uuid. Fait, j'ai vérifié que chaque ligne du fstab affiche bien le bon UUID et de fait la swap n'avait pas le bon UUID. > L'installation de grub-efi doit être effectuée dans un chroot avec la > partition efi montée, par exemple avec sda1 comme partition efi et sda2 comme > racine : > mkdir /mnt/target > mount /dev/sda2 /mnt/target > mount /dev/sda1 /mnt/target/boot/efi > cd /mnt/target > for m in dev dev/pts proc run sys sys/firmware/efi/efivars; do mount --bind > /$m $m; done > chroot . > grub-install /dev/sda > update-grub > exit > reboot J'ai pu le faire sans chroot du coup, puisque ça finit par booter après un long moment. update-grub me dit juste après coup qu'il ne cherche pas d'autres os mais comme je n'en ai qu'un tout est normal. J'ai juste des ACPI Warning dans l'output de dmesg, je ne sais pas si c'est une bonne piste. -- [ 1.309697] Freeing unused kernel image (text/rodata gap) memory: 2040K [ 1.310327] Freeing unused kernel image (rodata/data gap) memory: 1672K [ 1.406224] x86/mm: Checked W+X mappings: passed, no W+X pages found. [ 1.406226] x86/mm: Checking user space page tables [ 1.463409] x86/mm: Checked W+X mappings: passed, no W+X pages found. [ 1.463422] Run /init as init process [ 1.463424] with arguments: [ 1.463425] /init [ 1.463426] with environment: [ 1.463427] HOME=/ [ 1.463428] TERM=linux [ 1.463429] BOOT_IMAGE=/boot/vmlinuz-5.18.0-2-amd64 [ 1.577488] ACPI Warning: SystemIO range 0x0428- 0x042F conflicts with OpRegion 0x0400- 0x047F (\_SB.PCI0.LPCB.PMIO) (20211217/utaddress-204) [ 1.577501] ACPI: OSL: Resource conflict; ACPI support missing from driver? [ 1.577505] ACPI Warning: SystemIO range 0x0540- 0x054F conflicts with OpRegion 0x0500- 0x054B (\_SB.PCI0.LPCB.OGIO) (20211217/utaddress-204) [ 1.577512] ACPI: OSL: Resource conflict; ACPI support missing from driver? [ 1.577514] ACPI Warning: SystemIO range 0x0530- 0x053F conflicts with OpRegion 0x0500- 0x054B (\_SB.PCI0.LPCB.OGIO) (20211217/utaddress-204) [ 1.577521] ACPI: OSL: Resource conflict; ACPI support missing from driver? [ 1.577523] ACPI Warning: SystemIO range 0x0500- 0x052F conflicts with OpRegion 0x0500- 0x054B (\_SB.PCI0.LPCB.OGIO) (20211217/utaddress-204) [ 1.577529] ACPI: OSL: Resource conflict; ACPI support missing from driver? -- Benoît
Re: Changement de PC : lenteur au boot
On Friday 03 August 2018 16:07:26 lou wrote: > Est-ce que l'UUID de la swap est le même que dans le > fichier /etc/initramfs-tools/conf.d/resume? > Sinon, remplace le par le bon UUID de ta swap.. > Ensuite, fait un update-initramfs -u.. Merci, ça a bien marché. André
Re: Changement de PC : lenteur au boot
On Friday 03 August 2018 23:25:26 Pascal Hambourg wrote: > Le 03/08/2018 à 17:11, andre_deb...@numericable.fr a écrit : > > /etc/initramfs-tools/conf.d/resume : > Tu veux dire qu'il est vide ? > Pourtant d'après les messages que tu as cité, la variable RESUME avec un > UUID différent de celui du swap présent est bien enregistrée dans la > configuration d'initramfs-tools. Peux-tu chercher dans tous les autres > fichiers présents dans /etc/initramfs-tools et ses sous-répertoires, par > exemple avec > grep -r RESUME /etc/initramfs-tools Le fichier existe, avec bon UUID de la swap. > > update-initramfs -u ne fait aucun changement. > A quel point de vue ? > Tu veux dire dans /etc/initramfs-tools/conf.d/resume ? Ce n'est pas son > rôle. Il ne fait que le lire. > Ou tu veux parler de l'UUID enregistré dans l'initramfs généré ? Le fichier resume n'est pas automatiquement régénéré, il faut vérifier ou mettre à la mano le bon UUID de la swap. > > "resume" ne contient que l'UUID de la swap ? : Oui, c'est bon maintenant. > > Chez moi oui, s'il s'agit d'une partition, sous la forme citée par le > message d'avertissement : > RESUME=UUID=650bc976-62dc-4db9-99fc-30e0785eb060 Pareil chez moi. On Saturday 04 August 2018 11:13:00 Christophe De Natale wrote: > > update-initramfs: Generating /boot/initrd.img-4.9.0-6-686-pae > Ne serait-ce pas un problème de choix de noyau ? > Quelle est donc l'architecture de cette nouvelle machine ? Bon noyau. Le problème vient (est venu) par la copie via rsync d'un pc vers un nouveau, il faut donc réadapter un certain nombre de configs plus valables puisque celles de l'ancien pc. J'aurais pu réinstaller le nouvel ordinateur par une nouvelle install de stretch, mais je perds trop d'éléments, que je dois réinstaller, c'est pire que la 1ère méthode. Si vous avez une méthode plus idoine, je suis preneur :-) Merci pour votre aide, le système boot maintenant sans erreur, encore un peu lent par rapport à la stretch de secours-dépannage nouvellement installée sur une autre partition. Bonne journée, André
Re: Changement de PC : lenteur au boot
Le 03/08/2018 à 11:00, andre_deb...@numericable.fr a écrit : [...] Voici la réponse : update-initramfs: Generating /boot/initrd.img-4.9.0-6-686-pae [...] Ne serait-ce pas un problème de choix de noyau ? Quelle est donc l'architecture de cette nouvelle machine ? -- Christophe De Natale
Re: Changement de PC : lenteur au boot
Le 03/08/2018 à 17:11, andre_deb...@numericable.fr a écrit : /etc/initramfs-tools/conf.d/resume : Tu veux dire qu'il est vide ? Pourtant d'après les messages que tu as cité, la variable RESUME avec un UUID différent de celui du swap présent est bien enregistrée dans la configuration d'initramfs-tools. Peux-tu chercher dans tous les autres fichiers présents dans /etc/initramfs-tools et ses sous-répertoires, par exemple avec grep -r RESUME /etc/initramfs-tools update-initramfs -u ne fait aucun changement. A quel point de vue ? Tu veux dire dans /etc/initramfs-tools/conf.d/resume ? Ce n'est pas son rôle. Il ne fait que le lire. Ou tu veux parler de l'UUID enregistré dans l'initramfs généré ? Si je le déplace du répertoire, update-initramfs -u ne le recrée pas. Comme déjà dit, ce n'est pas son rôle. "resume" ne contient que l'UUID de la swap ? Chez moi oui, s'il s'agit d'une partition, sous la forme citée par le message d'avertissement : RESUME=UUID=650bc976-62dc-4db9-99fc-30e0785eb060
Re: Changement de PC : lenteur au boot
Le 03/08/2018 à 11:00, andre_deb...@numericable.fr a écrit : On Friday 03 August 2018 07:29:06 Pascal Hambourg wrote: Le 02/08/2018 à 23:40, andre_deb...@numericable.fr a écrit : J'ai copié ma Debian Stretch vers un nouveau pc. Tout marche bien sauf qu'au boot apparait un tiret "-", je dois attendre 20 bonnes secondes, puis apparait exactement ce message : "Gave up waiting for suspend / resume device Copié comment ? L'UUID du swap a été préservé ? : J'ai bien modifié son UUID. Cette réponse est ambiguë. Peux-tu préciser ? Regarde dans /etc/initramfs-tools/conf.d/resume. Si c'est vide, tu peux essayer de reconstruire l'initramfs avec update-initramfs -u Voici la réponse : update-initramfs: Generating /boot/initrd.img-4.9.0-6-686-pae W: initramfs-tools configuration sets RESUME=UUID=650bc976-62dc-4db9-99fc-30e0785eb060 W: but no matching swap device is available. I: The initramfs will attempt to resume from /dev/sda7 I: (UUID=3e213513-9ea9-4a4e-a0b4-8466e0f23281) I: Set the RESUME variable to override this. Pourquoi "resume from /dev/sda7" qui ma partition swap ? Parce qu'apparemment c'est le swap actif et que c'est là que les données d'hibernation vont être écrites. Il faut donc indiquer à l'initramfs que c'est là qu'il faut les lire lors de la reprise.
Re: Changement de PC : lenteur au boot
On Friday 03 August 2018 16:07:26 lou wrote: > Le Fri, 3 Aug 2018 11:00:20 andre_deb...@numericable.fr a écrit : > > On Friday 03 August 2018 07:29:06 Pascal Hambourg wrote: > > > Le 02/08/2018 à 23:40, andre_deb...@numericable.fr a écrit : > > > > J'ai copié ma Debian Stretch vers un nouveau pc. > > > > Tout marche bien sauf qu'au boot apparait un tiret "-", > > > > je dois attendre 20 bonnes secondes, > > > > puis apparait exactement ce message : > > > > "Gave up waiting for suspend / resume device > Est-ce que l'UUID de la swap est le même que dans le > fichier /etc/initramfs-tools/conf.d/resume? > Sinon, remplace le par le bon UUID de ta swap.. > Ensuite, fait un update-initramfs -u.. /etc/initramfs-tools/conf.d/resume : update-initramfs -u ne fait aucun changement. Si je le déplace du répertoire, update-initramfs -u ne le recrée pas. "resume" ne contient que l'UUID de la swap ? Merci,
Re: Changement de PC : lenteur au boot
Le Fri, 3 Aug 2018 11:00:20 +0200, andre_deb...@numericable.fr a écrit : > On Friday 03 August 2018 07:29:06 Pascal Hambourg wrote: > > Le 02/08/2018 à 23:40, andre_deb...@numericable.fr a écrit : > > > J'ai copié ma Debian Stretch vers un nouveau pc. > > > Tout marche bien sauf qu'au boot apparait un tiret "-", > > > je dois attendre 20 bonnes secondes, > > > puis apparait exactement ce message : > > > "Gave up waiting for suspend / resume device > > > Copié comment ? L'UUID du swap a été préservé ? : > J'ai bien modifié son UUID. > > > Regarde dans /etc/initramfs-tools/conf.d/resume. > > Si c'est vide, tu peux essayer de reconstruire l'initramfs avec > > update-initramfs -u > Voici la réponse : > update-initramfs: Generating /boot/initrd.img-4.9.0-6-686-pae > W: initramfs-tools configuration sets > RESUME=UUID=650bc976-62dc-4db9-99fc-30e0785eb060 > W: but no matching swap device is available. > I: The initramfs will attempt to resume from /dev/sda7 > I: (UUID=3e213513-9ea9-4a4e-a0b4-8466e0f23281) > I: Set the RESUME variable to override this. > > Pourquoi "resume from /dev/sda7" > qui ma partition swap ? > > > > dmesg donne ce message : > > > "[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is > > > invalid, remainder is 99" > > > Problème avec la carte graphique ou l'écran. Ça ne vient pas de la > > configuration de Debian. > Ok, je vais voir. > > Merci, > > André > Est-ce que l'UUID de la swap est le même que dans le fichier /etc/initramfs-tools/conf.d/resume? Sinon, remplace le par le bon UUID de ta swap.. Ensuite, fait un update-initramfs -u..
Re: Changement de PC : lenteur au boot
On Friday 03 August 2018 07:29:06 Pascal Hambourg wrote: > Le 02/08/2018 à 23:40, andre_deb...@numericable.fr a écrit : > > J'ai copié ma Debian Stretch vers un nouveau pc. > > Tout marche bien sauf qu'au boot apparait un tiret "-", > > je dois attendre 20 bonnes secondes, > > puis apparait exactement ce message : > > "Gave up waiting for suspend / resume device > Copié comment ? L'UUID du swap a été préservé ? : J'ai bien modifié son UUID. > Regarde dans /etc/initramfs-tools/conf.d/resume. > Si c'est vide, tu peux essayer de reconstruire l'initramfs avec > update-initramfs -u Voici la réponse : update-initramfs: Generating /boot/initrd.img-4.9.0-6-686-pae W: initramfs-tools configuration sets RESUME=UUID=650bc976-62dc-4db9-99fc-30e0785eb060 W: but no matching swap device is available. I: The initramfs will attempt to resume from /dev/sda7 I: (UUID=3e213513-9ea9-4a4e-a0b4-8466e0f23281) I: Set the RESUME variable to override this. Pourquoi "resume from /dev/sda7" qui ma partition swap ? > > dmesg donne ce message : > > "[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, > > remainder is 99" > Problème avec la carte graphique ou l'écran. Ça ne vient pas de la > configuration de Debian. Ok, je vais voir. Merci, André
Re: Changement de PC : lenteur au boot
Le 02/08/2018 à 23:40, andre_deb...@numericable.fr a écrit : J'ai copié ma Debian Stretch vers un nouveau pc. Tout marche bien sauf qu'au boot apparait un tiret "-", je dois attendre 20 bonnes secondes, puis apparait exactement ce message : "Gave up waiting for suspend / resume device Copié comment ? L'UUID du swap a été préservé ? Regarde dans /etc/initramfs-tools/conf.d/resume. Si c'est vide, tu peux essayer de reconstruire l'initramfs avec update-initramfs -u dmesg donne ce message : "[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 99" Problème avec la carte graphique ou l'écran. Ça ne vient pas de la configuration de Debian.
Changement de PC : lenteur au boot
Bonsoir, J'ai copié ma Debian Stretch vers un nouveau pc. Tout marche bien sauf qu'au boot apparait un tiret "-", je dois attendre 20 bonnes secondes, puis apparait exactement ce message : "Gave up waiting for suspend / resume device" Ce problème n'apparait pas au boot d'une nouvelle Stretch, installée depuis une image net-install. dmesg donne ce message : "[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 99" Il doit y avoir une ancienne config ou un device qui gêne le démarrage, mais comment savoir laquelle ? Merci d'une piste... André
