Partition : créer une nouvelle

Ben je vois qu’il m’en reste encore beaucoup à apprendre dans ce domaine du partitionnement et du chargeur grub.
Je vais éplucher ton message et je te réponds point par point.

Plein de problèmes persos, alors mes réponses se font attendre.
Je répondrai complètement plus tard mais en premier :

[quote]Dans la Jessie du SSD essaie de mettre à jour le fstab et regénérer l’initramfs avec update-initramfs -u.

EDIT : voir dans /etc/initramfs-tools/conf.d/resume[/quote]

Je suis allé voir dans ‘resume’ et la ligne présente est bien l’ancien UUID, celui (celle ?) qui pose problème.
Question :
est-ce que je régénère avec la commande : "update-initramfs -u"
ou
est-ce que je modifie a la mano cette ligne par la nouvelle UUID :question:

Tu modifies /etc/initramfs-tools/conf.d/resume avec le nouvel UUID et ensuite tu regénères l’initramfs pour qu’il en tienne compte.

Mais attention si tes deux systèmes utilisent la même partition de swap pour l’hibernation. Si tu hibernes un système, il faudra impérativement redémarrer sur celui-ci (et donc le sélectionner dans le menu de GRUB si ce n’est pas le système par défaut).

Personnellement, je définirais un swap distinct pour chaque système, de préférence sur le même disque que ses partitions racine, home… afin de les rendre indépendants au maximum. Je peux néanmoins comprendre que tu veuilles mettre tous les swap sur le SSD qui est plus rapide.

Pour ce qu’il conviendrait de faire pour que ce soit le mieux, on verra après.
Pour l’instant, je vais déjà tester ça et … la soupe.

C’est mieux mais ça vérifie encore la swap de sdb = 1 mn 30, ce qui semble conforme à ce que tu avais dit.
Comme je ne suis pas à une installation prêt, ne penses-tu pas qu’il serait préférable de recommencer celle de cette future Sid sur le DD sata :question:
Si c’est mieux, il faudra que tu m’explique ce qu’il convient de faire et surtout de ne pas faire en matière de chargeur Grub, quand il demande le choix à la fin de l’installation.

Comment ça ? Tu as mis un swap sur sdb ?

Il y était.
je crois que c’est lors de ma première installation dur ce DD.
J’avais dû déconnecter le SSD pour éviter les problèmes, et donc, j’avais créé un swap, qui est resté en place.
Que dois-je faire, le supprimer ? comment ?

Mais :

À la rigueur, l’hibernation, je peux m’en passer mais la mise en veille, je l’emploie fréquemment.

EDIT :
Pour info, pas de problème de connexion sur la nouvelle future-sid sdb1
Vérif du swap employé dans … resume : celui de sda.
Idem pour la ligne swap du fstab.
Conclusion : le swap de sdb ne sert pas ???

À noter que je ne me servirai jamais de la mise en veille sur le sdb.

Je m’y perds.
Qu’entendais-tu exactement par “ça vérifie encore la swap de sdb = 1 mn 30” ? Qu’est-ce que ça affiche ? Est-ce toujours d’actualité ?

Lors de l’installation de la future Sid, tu as demandé à utiliser quelle partition de swap ? A priori celle du SSD /dev/sda2, déjà utilisée par la Jessie de /dev/sda1 ?

[quote=“ricardo”]je crois que c’est lors de ma première installation dur ce DD.
J’avais dû déconnecter le SSD pour éviter les problèmes, et donc, j’avais créé un swap, qui est resté en place.
Que dois-je faire, le supprimer ? comment ?[/quote]
“Première installation” = l’ancienne Wheezy que tu as remplacé par la future Sid ? Ubuntu ?
Si aucun système ne l’utilise, tu peux la supprimer, avec n’importe quel programme de gestion des partitions compatible GPT (gparted, gdisk…). Ou bien tu peux la réutiliser pour la future Sid.

[quote=“PascalHambourg”]Je m’y perds.
Qu’entendais-tu exactement par “ça vérifie encore la swap de sdb = 1 mn 30” ? Qu’est-ce que ça affiche ? Est-ce toujours d’actualité ?[/quote]
Oui, toujours d’actualité.
Au boot : liste du Grub/choix sda1 ; défilement 3 ou 4 lignes puis vérification d’une UUID (celle de swap sdb2) avec compteur qui tourne jusqu’à 1 mn 30 (petit clignotant rouge en tête de ligne pendant ce décompte). Puis continuation du chargement pendant quelques secondess.

Non, j’ai demandé l’utilisation de celle existante en sdb2
MAIS
À l’écriture sur le disque, il choisit D’OFFICE (je ne lui ai rien demandé) d’inclure aussi le formatage de la swap sda2.
Autrement dit, il formate systématiquement toutes les partitions swap qu’il trouve.

[quote=“PascalHambourg”]

[quote=“ricardo”]je crois que c’est lors de ma première installation dur ce DD.
J’avais dû déconnecter le SSD pour éviter les problèmes, et donc, j’avais créé un swap, qui est resté en place.
Que dois-je faire, le supprimer ? comment ?[/quote]
“Première installation” = l’ancienne Wheezy que tu as remplacé par la future Sid ? Ubuntu ? [/quote]
Par l’ancienne Wheezy maintenant future Sid = sdb1
Il est possible que Kubuntu l’exploite, je ne me souviens plus de leur système d’installation.
Je vais vérifier ce point MAIS, étant donné que je ne me sers qu’exceptionnellement de cette Buntu, une swap lui est-elle indispensable :question:

Si je la supprime, donc rester avec la seule swap sda2, est-ce que ça posera problème au niveau de la mise en veille de ma Jessie sda1 qui doit rester la machine fonctionnelle ?
Inconvénient que tu avais invoqué plus haut.

J’espère que je ne suis pas trop indigeste.

Ça devient un peu confus, on va essayer de faire le point. Peux-tu fournir la sortie de blikd relative aux partitions de swap, et sur chacune des deux Debian la ou les lignes de /etc/fstab relatives au swap et le contenu de /etc/initramfs-tools/conf.d/resume ?

Quel est le texte qui s’affiche exactement ?

[quote=“ricardo”]À l’écriture sur le disque, il choisit D’OFFICE (je ne lui ai rien demandé) d’inclure aussi le formatage de la swap sda2.
Autrement dit, il formate systématiquement toutes les partitions swap qu’il trouve.[/quote]
C’est très surprenant. Tu avais sélectionné le partitionnement manuel ?

Si la machine a assez de RAM et sans hibernation, non.
La mise en veille simple (suspend to RAM) n’a pas besoin de swap.

[quote=“PascalHambourg”]Ça devient un peu confus, on va essayer de faire le point. Peux-tu fournir la sortie de blikd relative aux partitions de swap, et sur chacune des deux Debian la ou les lignes de /etc/fstab relatives au swap et le contenu de /etc/initramfs-tools/conf.d/resume ?

Quel est le texte qui s’affiche exactement ?

[quote=“ricardo”]À l’écriture sur le disque, il choisit D’OFFICE (je ne lui ai rien demandé) d’inclure aussi le formatage de la swap sda2.
Autrement dit, il formate systématiquement toutes les partitions swap qu’il trouve.[/quote]
C’est très surprenant. Tu avais sélectionné le partitionnement manuel ?

Si la machine a assez de RAM et sans hibernation, non.
La mise en veille simple (suspend to RAM) n’a pas besoin de swap.[/quote]

Je te réponds en vrac mais je pense avoir réglé l’affaire et supprimant la swap de sdb (sdb2) et en modifiant les UUIDs des ‘fstab’ et des ‘resume’ des 3 distributions/branches : Jessie sda1 ; Sid sdb1 ; Kubuntu ; sdb10.
Je charge maintenant sans problèmes ces trois “machines”, les SSD et DDsata en place. Plus de vérifcation d’1 mn 30 , donc super rapide, comme avant.
Il me reste à tester le chargement du SSD seul. Le DDsata, lui, ne sera jamais utilisé seul.

Oui, toujours en install manuelle

Pour les fstabs, comme dit plus haut : tout vérifié.
Pour les … ‘resume’, celui de sda1 a été vérifié et ‘update-initramfs -u’
a bien été fait.
Pour la Sid (qui n’est plus “future” mais ‘dist-upgradé’) de sdb1, le …resume est vide; Ça ne me pose pas de problème car je ne la mettrai jamais en veille.
Pour la Buntu, je crois qu’il est vide aussi mais idem dessus : m’en fous !

de plus, comme tu dis que la mise en veille ne nécessite pas de swap, ça roule.

La ligne exacte, de mémoire, est la même, sauf le compteur qui tourne et un petit rectangle rouge en tête qui clignote.

Je teste avec SSD seul et je reviens.

EDIT :
Le 'resume ’ de la Sid était bien garni avec la bonne UUID et update-initramfs -u fait.

EDIT 2 :
Sur le SSD seul en place en quelques secondes :023
Apparemment donc, le chargeur complet est bien implanté sur ce SSD ?

EDIT 3 :
sur Kubuntu : chargement rapide, pas de recherches … et pour cause car j’avais supprimé purement et simplement la ligne swap du fstab car elle ne me semble pas utile là. Pas de resume non plus, bien évidemment.

Un peu de repos du cerveau maintenant car il va exploser.
À ce soir

Compare le menu de démarrage, notamment l’ordre des entrées Debian, avec le SSD seul et avec les deux disques.

Comparer quoi exactement ?
OK, j’avais pas percuté.

Laquelle des deux Debian est en premier dans le menu de GRUB lorsque le SSD est seul et lorsque le disque dur est présent.

La Jessie SSD en premier, suivi de Sid puis de Buntu

EDIT :
vérifié de nouveau : c’est bien identique avec les lignes intermédiaire en mode dépannage.

Même quand le disque dur est présent ?
Si la Jessie du SSD est en premier dans le menu, c’est son GRUB qui se lance. Lors de l’installation de la Jessie-devenue-Sid sur le disque dur, tu as dû spécifier un autre emplacement que le MBR du SSD. Tu peux vérifier avec la commande suivante depuis la Sid :

La ligne grub-pc/install_devices contient le périphérique d’installation de la boot image, sous la forme /dev/disk/by-id/xxx ou xxx est construit à partir du nom du modèle et du numéro de série, et le cas échéant du numéro de partition. C’est un lien symbolique qui pointe vers le nom de périphérique /dev/sd*, visible avec [mono]ls -l[/mono] ou [mono]readlink[/mono].

Vérifié de nouveau : Jessie sur SSD toujours en tête, avec ou sans la présence du DD sata.

[code]ricardo@sid-sdb:~$ sudo debconf-show grub-pc
[sudo] password for ricardo:
grub-pc/timeout: 5
grub-pc/partition_description:
grub-pc/install_devices_empty: false
grub2/device_map_regenerated:
grub-pc/disk_description:
grub2/kfreebsd_cmdline_default: quiet

  • grub2/linux_cmdline:
    grub-pc/kopt_extracted: false
  • grub-pc/install_devices:
    grub-pc/mixed_legacy_and_grub2: true
    grub2/force_efi_extra_removable: false
    grub-pc/chainload_from_menu.lst: true
    grub-pc/install_devices_failed: false
    grub-pc/install_devices_failed_upgrade: true
    grub-pc/hidden_timeout: false
    grub-pc/install_devices_disks_changed:
    grub-pc/postrm_purge_boot_grub: false
  • grub2/linux_cmdline_default: quiet
    grub2/kfreebsd_cmdline:[/code]

Pas bien compris la seconde commande :

ricardo@sid-sdb:~$ ls -l /dev/sd* brw-rw---- 1 root disk 8, 0 mai 19 00:00 /dev/sda brw-rw---- 1 root disk 8, 1 mai 19 00:00 /dev/sda1 brw-rw---- 1 root disk 8, 2 mai 19 00:00 /dev/sda2 brw-rw---- 1 root disk 8, 3 mai 19 00:00 /dev/sda3 brw-rw---- 1 root disk 8, 4 mai 19 00:00 /dev/sda4 brw-rw---- 1 root disk 8, 16 mai 19 00:00 /dev/sdb brw-rw---- 1 root disk 8, 17 mai 19 00:00 /dev/sdb1 brw-rw---- 1 root disk 8, 26 mai 19 00:00 /dev/sdb10 brw-rw---- 1 root disk 8, 27 mai 19 00:00 /dev/sdb11 brw-rw---- 1 root disk 8, 19 mai 19 00:00 /dev/sdb3 brw-rw---- 1 root disk 8, 20 mai 19 00:00 /dev/sdb4 brw-rw---- 1 root disk 8, 21 mai 19 00:00 /dev/sdb5 brw-rw---- 1 root disk 8, 22 mai 19 00:00 /dev/sdb6 brw-rw---- 1 root disk 8, 23 mai 19 00:00 /dev/sdb7 brw-rw---- 1 root disk 8, 24 mai 19 00:00 /dev/sdb8 brw-rw---- 1 root disk 8, 25 mai 19 00:00 /dev/sdb9 brw-rw---- 1 root disk 8, 32 mai 19 00:00 /dev/sdc

Pour comparaison, voici ce que ça donne à partir de Jessie sur sda1 du SSD

[code]ricardo@jessie-ssd:~$ sudo debconf-show grub-pc
[sudo] password for ricardo:
grub-pc/partition_description:
grub-pc/postrm_purge_boot_grub: false
grub2/device_map_regenerated:

  • grub-pc/install_devices: /dev/disk/by-id/ata-Samsung_SSD_840_Series_S19HNSBD505393L
    grub-pc/timeout: 5
    grub-pc/disk_description:
    grub2/kfreebsd_cmdline:
    grub-pc/install_devices_failed: false
    grub-pc/install_devices_disks_changed:
    grub-pc/kopt_extracted: false
    grub-pc/mixed_legacy_and_grub2: true
    grub2/kfreebsd_cmdline_default: quiet
    grub-pc/chainload_from_menu.lst: true
    grub2/force_efi_extra_removable: false
    grub-pc/install_devices_empty: false
    grub-pc/hidden_timeout: false
  • grub2/linux_cmdline_default: quiet
  • grub2/linux_cmdline:
    grub-pc/install_devices_failed_upgrade: true
    [/code]

Là on voit bien l’emplacement de l’installation sur le SSD

grub-pc/install_devices est vide, donc apparemment l’amorce du chargeur n’a été installée nulle part. Ce qui peut expliquer pourquoi le MBR du SSD contient encore l’amorce de la Jessie.
La seconde commande aurait été à exécuter avec la valeur si elle n’avait pas été vide, comme /dev/disk/by-id/ata-Samsung_SSD_840_Series_S19HNSBD505393L, pour la convertir en nom de périphérique en /dev/sd* si besoin.

Ça ne pose pas de problème qu’il n’y ait pas d’amorce sur le DD je suppose ?
Je laisse ainsi puisque tout semble fonctionner au mieux ?

Aucun problème si, comme tu l’as écrit, tu n’as pas besoin de pouvoir démarrer sur le disque dur sans le SSD.
Dans le cas contraire, il suffit d’exécuter

sur la Sid et de spécifier le MBR du disque dur (/dev/sdb) comme emplacement pour installer l’amorce du chargeur.