Erreur de débutant, oubli de /boot/EFI car tout LVM

Support Debian
#1

Bonjour,

Je me suis acheté un PC portable sur mesure et tout à la joie de le configurer aux petits oignons j’ai oublié l’essentiel qui est de prévoir de la place pour l’amorçage.

Il faut dire que je suis habitué aux serveurs (HP Proliant), et pour ceux-ci il y a un contrôleur de disques RAID, et les disques sont tous présentés à l’OS de la même manière : un /dev/sdX qui peut être intégré comme un volume physique LVM même pour le disque qui sert à l’amorçage. Comme grub supporte LVM, c’est très simple et on peut gérer avec les commandes LVM.

J’ai un problème de vision et il me faut absolument une version du bureau qui permette un Zoom de tout le bureau. Dans xfce (xfwm4) cette option Zoom Desktop n’est présente que dans la version testing de Debian (pas dans jessie).
J’ai donc fait un

sudo dd if=debian-testing-amd64-xfce-CD-1.iso of=/dev/sdc bs=1M

sur une clé USB et j’ai eu l’installateur Debian (19 décembre 2016) qui s’est lancé. Je passe en mode expert, et je choisis de continuer l’installation à distance avec une commande du genre

ssh installer@IP

La commande ssh étant fournie par Putty sur un système Windows doté d’un agrandisseur d’écran.

Je n’ai pas fait attention à cette histoire d’UEFI. Il faut dire, que réserver une (ou des ?) partition(s) explicitement formattées en truc largement obsolète comme FAT32 cela m’a complètement échappé.

Après l’étape “détecter les disques”, j’ai basculé dans une console et

pvcreate /dev/sda
pvcreate /dev/sdc
vgcreate pacha_vg /dev/sda /dev/sdc
lvcreate --name var_lv --size 4G pacha_vg /dev/sdc
lvcreate --name root-lv --size 8G pacha_vg /dev/sda
...

Ici /dev/sda est un SSD de 128Go et /dev/sdc un disque dur 1To

Bref, c’est tout bon, sauf qu’on ne peut pas installer un grub (EFI) qui permette de démarrer.

~ # parted --list /dev/sda
Error: /dev/sda: unrecognised disk label
Model: ATA KINGSTON SMS200S (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

Warning: The driver descriptor says the physical block size is 2048 bytes, but
Linux says it is 512 bytes.
Ignore/Cancel?

Et la commande parted me liste tous les LV avec à la fin

Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/pacha_vg-var_lv: 4295MB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number  Start  End     Size    File system  Flags
 1      0.00B  4295MB  4295MB  xfs


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/pacha_vg-swap_lv: 12.9GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:

Number  Start  End     Size    File system     Flags
 1      0.00B  12.9GB  12.9GB  linux-swap(v1)

Je n’y connais rien en UEFI ni en partitionnement GPT (comment s’appelle l’équivalent de fdisk présent dans l’installeur ? )

~ # gdisk -l /dev/sda
/bin/sh: gdisk: not found
~ #

En résumé, il faut que je recommence tout au début, quelle commande passer pour avoir un amorçage correct ? Le pvcreate sur le SSD m’a écrasé le secteur d’amorçage du disque.

De plus, il semblerait nécessaire d’avoir des pilotes non libres sur cette machine

~ # lspci -mk | grep -i realte
03:00.0 "Unassigned class [ff00]" "Realtek Semiconductor Co., Ltd." "RTS5229 PCI Express Card Reader" -r01 "CLEVO/KAPOK Computer" "Device 6504"
05:00.0 "Unassigned class [ff00]" "Realtek Semiconductor Co., Ltd." "RTL8411B PCI Express Card Reader" -r01 "CLEVO/KAPOK Computer" "Device 6504"
05:00.1 "Ethernet controller" "Realtek Semiconductor Co., Ltd." "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller" -r12 "CLEVO/KAPOK Computer" "Device 6504"
~ #

il me semble avoir vu une référence à rtl_nic/rt8411-2.fw pour la carte réseau (au moment de la détection du réseau, mais j’ai pu continuer). Quel est le paquet de non-free ?
Pour le Wifi, je n’ai pas pu noter le nom du paquet à installer.

D’avance merci.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.
Bureau Veritas
Département Recherche, le département de l’excellence technique.

Fier d’être depuis 41 ans au service de Bureau Veritas, branche Marine & Offshore.

#2

Tu fais un VG à cheval sur un SSD et un disque dur ? Drôle d’idée. J’aurais fait des VG séparés pour m’assurer que les LV qui doivent être rapides soient sur le SSD.

GRUB sait lire LVM pour charger sa config, ses modules, le noyau… Par contre la dernière fois que j’ai testé sur une Debian Jessie à jour on ne pouvait toujours pas embarquer la core image de GRUB dans un PV LVM. LVM permet de réserver un espace dédié pour le chargeur d’amorçage dans un PV (en plus de quelques secteurs non utilisés au début du PV), mais grub-install n’était pas capable d’en tirer profit.

Néanmoins si le paquet grub-pc de Debian testing supporte cette option et si le PC peut encore démarrer en mode BIOS/legacy (CSM), alors il ne sera pas nécessaire de réinstaller.

Le partitionneur de l’étape “gestion des disques” est partman, un programme spécifique à l’installateur Debian qui utilise libparted. Dans le shell de l’installateur de Jessie, fdisk (compatible GPT depuis Jessie) et en option parted sont disponibles.

Si tu veux ou dois faire un amorçage EFI, il faudra une table de partition (de préférence GPT) sur un des disques, de type système EFI, de taille quelconque (l’image EFI de GRUB prend moins d’1 Mo) formatée en FAT16 ou FAT32. Elle devrait être montée sur /boot/efi. Le reste du disque pourra être affecté à une partition servant de PV LVM.

Pour les firmwares non libres Realtek, installer le paquet firmware-realtek.

#3

J’ai effectivement des erreurs fatales au moment du grub-install depuis l’intallateur Debian.

Cela redonne espoir, car

~ # ls -l /sys/firmware/
drwxr-xr-x    5 root     root             0 Dec 19 16:40 acpi
drwxr-xr-x    4 root     root             0 Dec 19 11:34 dmi
drwxr-xr-x   23 root     root             0 Dec 19 16:40 memmap
~ # ls -l /sys/firmware/efi
ls: /sys/firmware/efi: No such file or directory
~ #

semble indiquer que l’amorçage n’était pas en UEFI.
Reste la condition “si le paquet grub-pc de Debian testing supporte cette option”, et l’installation n’est pas si longue que cela.

Je pense que je vais revenir aux fondamentaux. :grinning: Une partition amorçable en début de disque (SSD) crée avec ce cher fdisk, et le reste du disque /dev/sda2 sera la base d’un PV. [quote=“PascalHambourg, post:2, topic:72072”]
Tu fais un VG à cheval sur un SSD et un disque dur ? Drôle d’idée. J’aurais fait des VG séparés pour m’assurer que les LV qui doivent être rapides soient sur le SSD.
[/quote]
Initialement j’avais l’idée de créer ssd_vg et hdd_vg. Mais en précisant au moment du lvcreate sur quel disque physique on veut se placer, cela revient au même. Il est vrai qu’il n’y a pas de garde fou pour prévenir le fait d’avoir un espace disque à cheval sur des technologies radicalement différentes peut être vu comme une limitation. Le gros avantage que je vois dans LVM est sa flexibilité d’une part, mais surtout son immunité à être pollué par des technologies Microsoft d’autre part. (encore une barrière anti virus :slight_smile: )

ok, mais il me semble tout aussi simple de faire mon partman à la mimine, en tapant les commandes. Si il y a une erreur, je sais alors qui a fait la gaffe.

Voilà où j’en suis

~ # lvmdiskscan
  /dev/sda              [     111.79 GiB] LVM physical volume
  /dev/pacha_vg/swap_lv [      12.00 GiB]
  /dev/pacha_vg/var_lv  [       4.00 GiB]
  /dev/pacha_vg/data_lv [     128.00 GiB]
  /dev/pacha_vg/root_lv [       8.00 GiB]
  /dev/pacha_vg/home_lv [      24.00 GiB]
  /dev/sdb1             [     648.00 MiB]
  /dev/sdc              [     931.51 GiB] LVM physical volume
  5 disks
  1 partition
  2 LVM physical volume whole disks
  0 LVM physical volumes
~ #

En recommençant tout le processus, nous aurons un /dev/sda1 pour /boot, quelle taille choisir (je n’installerai que des distributions Linux) et quel type de système de fichiers ( ext2/3/4 ) ?

D’autre part, serait-il pertinent de prévoir un tmp_lv sur le HDD pour /tmp ? taille, fstype ?
De même un swap rapide swapr_lv sur le SSD ? 4Go ? et réduire le swap_lv sur le HDD à 8Go (taille RAM) pour l’hibernation ?

Après recherche, j’ai effectivement téléchargé les versions pour stretch

-rw-r--r-- 1 fp2x fp2x  5243130 déc.  19 18:54 firmware-iwlwifi_20160824-1_all.deb
-rw-r--r-- 1 fp2x fp2x   306466 déc.  19 18:58 firmware-realtek_20160824-1_all.deb

Si je ne trouve pas comment intégrer ces micro-logiciels via le menu du mode expert, je ferai un

dpkg -i firmware*.deb

depuis le shell.

Merci à Pascal Hambourg pour ses précieux conseils toujours aussi avisés.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac

#4

Cela peut aussi être causé par l’absence de partition système EFI si l’installateur a démarré en mode EFI.

Oui, ou bien les modules EFI (efivars, efivarfs) ne sont pas chargés, ou bien le noyau est incompatible avec l’architecture du firmware EFI (cas d’un noyau 32 bits avec un firmware 64 bits, mais normalement il faut vraiment le faire exprès pour arriver à lancer l’installateur Debian dans une telle configuration, donc on le sait).

Si ça n’a pas changé avec Stretch, il est facile de savoir si l’installateur Debian a été amorcé en mode EFI ou BIOS : en mode BIOS le menu de démarrage est celui d’ISOLinux alors qu’en mode EFI c’est celui de GRUB.

Les fondamentaux ne suffisent plus toujours :

  • pour l’amorçage EFI, il faut une partition système EFI
  • pour l’amorçage en mode BIOS, si la table de partition est au format GPT il est recommandé de créer une partition de type “BIOS boot” (non formatée) dans laquelle GRUB peut l’installer sa core image.

J’ai oublié d’écrire une information dans mon message précédent : puisque les deux disques sont dans le même VG, si tu ne veux pas réinstaller tu peux “vider” un disque en déplaçant ses LV vers l’autre avec pvmove, puis le partitionner, installer le chargeur de GRUB et redéplacer les LV.

Edit : la phrase peut laisser penser que tu comptes partager la partition /boot entre plusieurs systèmes. Je le déconseille formellement car c’est de nature à perturber la détection automatique d’update-grub qui risque de ne pas s’y retrouver entre les noyaux et les systèmes.

La taille va dépendre du nombre de noyaux ou d’autre images que tu vas installer. 100 Mo peuvent suffire pour un noyau + GRUB (en prenant large), mais si tu n’es pas à 1 Go près tu peux allouer 1 Go. Après tout, ce sera le seul système de fichiers qui ne pourra pas être agrandi facilement puisque hors LVM.

Quant au système de fichiers, j’avoue que je n’ai pas de religion. ext2 est simple mais l’absence de journalisation peut nécessiter l’exécution de fsck avant de pouvoir le remonter après un arrêt “sale”, alors que dans les même circonstances ext4 pourra être corrigé au montage en rejouant le journal. Mais l’important est : comment va réagir GRUB dans ce genre de circonstances ? Je manque d’expérience dans ce domaine. Je doute qu’il rejoue le journal et corrige les incohérences, et s’il ne peut pas lire un système de fichiers ext4 qui n’a pas été arrêté proprement, ext4 n’a pas d’intérêt. En tout cas ext3 est hors course car il n’apporte rien par rapport à ext4. Un autre avantage d’ext4 sur les deux autres est le support du TRIM (discard) pour le SSD.

Pas d’avis sur le système de fichiers. Plutôt sur le SSD pour la rapidité. Ou en tmpfs, avec suffisamment de swap (sur le SSD aussi).

Les tailles sont à définir en fonction de l’usage, mais tu peux créer un swap sur chaque disque et donner la priorité à celui du SSD (option prio= dans fstab, cf. man swapon) pour qu’il soit utilisé préférentiellement, sinon les deux swaps sont utilisés à égalité.[quote=“littlejohn75, post:3, topic:72072”]
Après recherche, j’ai effectivement téléchargé les versions pour stretch
[/quote]
Le paquet firmware-iwlwifi n’est utile qu’avec une carte wifi Intel compatible.
Les fichiers de paquets de firmware .deb doivent être à la racine d’un système de fichiers FAT situé sur un support autre que l’installateur (ou alors il faut bidouiller avec le shell pour les lui faire reconnaître).

#5

Salut @littlejohn75, pour le paquet realtek, rien de plus simple, n’est-ce pas ! :wink:
Pour le wifi, sans + de référence, on ne va pas pouvoir t’aider + :stuck_out_tongue:

Le reste, je préfère me taire, car je manque d’assurance … juste qu’il m’a semblait comprendre en effet qu’il fallait une toute petite partition EFI pour le boot - qui est créé par l’installeur, quand tu le laisses faire.

Peut-être ‘cfdisk’ ?!

#6

Bonjour et bonne année.

Le problème est résolu. Sur une machine toute neuve, je n’avais pas pensé que quand bien même si grub-pc supporte LVM l’installation de ses composants logiciels ne peut pas se faire que si au moins un disque d’amorçage a une table de partition (à l’ancienne ou GPT peu importe). Comme en plus j’ai vu que le BIOS ne faisait allusion à ces histoires d’EFI/UEFI que dans un item non modifiable (désactivé) avec un commentaire parlant de Windows, je suis revenu aux fondamentaux (comme le dit Bernard Laporte) et j’ai donc créé une table de partitions DOS qui permet de mettre la première partie de grub dans le MBR et l’espace de 2Mo entre la table de partitions et le début de la première partition.

fp2@debpacha:~$ sudo fdisk -l /dev/sda
Disque /dev/sda : 111,8 GiB, 120034123776 octets, 234441648 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x29bdfac9

Périphérique Amorçage   Début       Fin  Secteurs Taille Id Type
/dev/sda1    *           2048   4196351   4194304     2G 83 Linux
/dev/sda2             4196352 234441647 230245296 109,8G 8e LVM Linux
fp2@debpacha:~$

La partition 1 sert pour /boot
fp2@debpacha:~$ df -hT | fgrep -v tmpfs Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur /dev/mapper/pacha_vg-root_lv ext4 7,9G 3,0G 4,5G 40% / /dev/sda1 ext4 2,0G 41M 1,8G 3% /boot /dev/mapper/pacha_vg-home_lv ext4 24G 445M 23G 2% /home /dev/mapper/pacha_vg-tmp_lv xfs 8,0G 33M 8,0G 1% /tmp /dev/mapper/pacha_vg-data_lv ext4 125G 69M 123G 1% /data /dev/mapper/pacha_vg-var_lv xfs 4,0G 673M 3,4G 17% /var fp2@debpacha:~$
Un deuxième piège (bug de l’installateur pour stretch) a été le choix du noyau à installer dans /boot . Je ne me rappelle plus très bien (c’était il y a 2 semaines), mais il me semble que le noyau générique (méta paquet) linux-image-amd64 proposé par défaut ne fonctionnait pas, il a fallu choisir l’entrée correspondant à linux-image-4.8.0-2-amd64.

Pour les micro-logiciels non libres, après une installation via un câble Ethernet l’installation des paquets firmware-realtek et firmware-iwlwifi ne pose pas de problème.

Ceci étant, suite à un changement majeur de situation (passage de salarié à retraité + consultant) et à une panne de Numericable, je n’ai pas eu le temps de vous faire part de la solution.

Finalement, j’ai un portable sous xfce (stretch) qui s’éteint en 4 secondes et démarre en une vingtaine de secondes :slight_smile:

Pour les problèmes restants j’ouvrirai des fils distincts.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

1 J'aime
#7

Bonjour littlejohn75

Petit “pinaillage” :

Ce sont des secteurs de 512 octets => 2048 x 512 = 1Mio
La première partition commence donc à 1Mio du début du disque,
donc, 2047 secteurs après le MBR (MBR qui occupe le premier secteur du disque)