Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 12-11-2017 17:11:50

cledefa49
Membre
Inscription : 08-11-2017

[Resolu]Debian Stretch très long à démarer suite un dual boot

Bonjour à tous
Sur un portable Toshiba Stallite Pro, j'ai partitionné le disque comme suit:
2 partitions de 30 GB en ext4 pour les systèmes, 1 partition swap de 4 Gb et le reste du disque en ext4 pour le home.

Sur la seconde partition, j'ai installé Debian Stretch. RAS tout fonctionne bien.

Sur la première partition, j'ai ensuite installé PrimTux3 (basé sur Stretch) et là, problème, grub ne reconnaît plus que Primtux et ne voit pas Debian.

J'ai alors remplacé PrimTux3 par PrimTux2 basé sur Jessie et là grub voit bien mes 2 systèmes.

Le problème qui reste est le suivant:
Si je démarre sur PrimTux, tout va bien, le boot se déroule correctement.

Mais si je démarre sur Debian, c'est très très long:
Le curseur clignote pendant environ 40 secondes. Puis j'ai les messages suivants:

Gave up waiting for suspend/resume device
/dev/sda2 clean
ERROR CPU Pipe B FIFO underrun
A start job is running for dev-disk-by\un identifiant bien complexe



Ce dernier message reste pendant 1 minute 30 secondes
puis le boot se poursuit et enfin Debian est utilisable tout à fait normalement

Je n'ai pas réussi à comprendre d'où vient le problème puisque quand Debian Stretch était seul installé, ces messages n'apparaissaient pas.
Quelqu'un pourrait-i m'aider à résoudre ce problème ?

[ajout] À noter que le seul message que je retrouve dans la lecture de "dmesg" est "ERROR CPU Pipe B FIFO underrun"

Cordialement

Dernière modification par cledefa49 (12-11-2017 23:28:08)


Bon, eh bien je vais partir en Théorie, parce que "en théorie, tout se passe bien"
(Mais je ne sais pas de qui est cette citation ...)

Hors ligne

#2 12-11-2017 22:48:49

raleur
Membre
Inscription : 03-10-2014

Re : [Resolu]Debian Stretch très long à démarer suite un dual boot

L'installation de Primtux a modifié l'UUID du swap et Stretch ne le trouve plus. Grand classique. Ne jamais laisser un nouveau système utiliser le swap d'un autre pendant l'installation.

Dans Debian, corriger l'UUID du swap dans /etc/fstab et /etc/initramfs-tools/conf.d/resume pour qu'elle corresponde à ce qu'affiche blkid et reconstruire l'initramfs avec

update-initramfs -u

Dernière modification par raleur (12-11-2017 22:49:02)

Hors ligne

#3 12-11-2017 23:27:17

cledefa49
Membre
Inscription : 08-11-2017

Re : [Resolu]Debian Stretch très long à démarer suite un dual boot

Merci raleur, mon problème est résolu.

Cela voudrait donc dire que quand on fait une installation avec un double boot, il faut prévoir 2 partitions de swap différentes ?
Jusqu'à présent, je ne m'en étais jamais préoccupé.

Bon, eh bien je vais partir en Théorie, parce que "en théorie, tout se passe bien"
(Mais je ne sais pas de qui est cette citation ...)

Hors ligne

#4 13-11-2017 11:42:04

raleur
Membre
Inscription : 03-10-2014

Re : [Resolu]Debian Stretch très long à démarer suite un dual boot

En partitionnement manuel, l'installateur de Debian (et probablement de ses dérivées) marque automatiquement les swaps existants "utiliser comme swap" et les reformate si on laisse comme ça, ce qui risque de perturber un système existant qui utilize déjà ce swap. Même si on crée un autre swap, il faut penser à marquer les swaps existants "ne pas utiliser". Je ne sais pas ce qui se passe en partitionnement assisté car je ne l'utilise pas (trop mauvais). Je ne sais pas non plus ce que font les installateurs des autres distributions.

On peut ajouter un swap dans /etc/fstab après l'installation pour éviter de perturber un système existant.

On peut aussi, avant d'installer le nouveau système, spécifier le swap dans /etc/fstab du système existant avec un identifiant persistant qui n'est pas modifié par le reformatage, donc pas l'UUID ni le LABEL. En partitionnement GPT, on peut utiliser le PARTUUID ou le PARTLABEL. En partitionnement MSDOS, on peut utiliser seulement le PARTUUID (ce n'est pas un vrai UUID mais simulé par le noyau, mais c'est mieux que rien).

A savoir : Avec le partitionnement GPT et systemd, par défaut les partitions de swap du disque système sont automatiquement utilisées sans qu'il soit nécessaire de les déclarer dans l'installateur ni dans /etc/fstab. On peut donc les marquer "ne pas utiliser" pendant l'installation et elles seront quand même utilisées par le système installé. Il faut modifier un indicateur dans la table de partition avec gdisk pour désactiver l'utilisation automatique.

Hors ligne

#5 13-11-2017 13:26:16

smolski
administrateur quasi...modo
Lieu : AIN
Distrib. : 8 (jessie) 64 bits + backports
Noyau : 3.16.0-4-amd64 - 3.16.39-1
(G)UI : gnome 1:3.14+3
Inscription : 21-10-2008

Re : [Resolu]Debian Stretch très long à démarer suite un dual boot


"Théo et Adama te rappellent pourquoi Zyed et Bouna couraient…"
"L'utopie ne signifie pas l'irréalisable, mais l'irréalisée." - T Monod (source :  La zone de Siné)
"Je peux rire de tout mais pas avec n'importe qui." - P Desproges
"saque eud dun" (patois chtimi : fonce dedans)

Hors ligne

#6 13-11-2017 21:59:41

cledefa49
Membre
Inscription : 08-11-2017

Re : [Resolu]Debian Stretch très long à démarer suite un dual boot

Merci "raleur" pour ces précisions
Merci "smolski" pour le lien; ça pourra m'être utile.

A noter que j'ai refait une installation de PrimTux3.
Le menu Grub est OK après correction avec l'outil boot-repair

J'ai donc maintenant sur ce portable l'installation telle que je la souhaitais.

Encore merci

Bon, eh bien je vais partir en Théorie, parce que "en théorie, tout se passe bien"
(Mais je ne sais pas de qui est cette citation ...)

Hors ligne

#7 13-11-2017 22:46:05

raleur
Membre
Inscription : 03-10-2014

Re : [Resolu]Debian Stretch très long à démarer suite un dual boot

cledefa49 a écrit :

Le menu Grub est OK après correction avec l'outil boot-repair


Il aurait mieux valu déterminer la cause du problème et la corriger.
Là, 'est comme si tu avais modifié grub.cfg à la main. L'ennui, c'est que le problème risque de réapparaître à la prochaine opération qui exécutera update-grub et recréera automatiquement grub.cfg. Exemple : mise à jour du noyau.

Dernière modification par raleur (13-11-2017 22:47:16)

Hors ligne

Pied de page des forums