(ro) option au noyau

kolap · Mars 31, 2018, 6:59pm

hello,
-) Est il normale que l’option “ro” a passer au noyau ne soit pas ajoutée par un update-grub /os_prober ?

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'BunsenLabs GNU/Linux 8.9 (Hydrogen) (8.9) (sur /dev/sda7)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-1caa5f76-04cd-4400-97bb-8c2f622b65c3' {
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,msdos7' --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7  1caa5f76-04cd-4400-97bb-8c2f622b65c3
	else
	  search --no-floppy --fs-uuid --set=root 1caa5f76-04cd-4400-97bb-8c2f622b65c3
	fi
	linux /vmlinuz root=/dev/sda7
	initrd /initrd.img
}

Si on se base sur ceci:
Cet argument indique au noyau de monter le système de fichiers racine en lecture seule. Ceci est fait pour que le programme fsck puisse vérifier et réparer un système de fichiers Linux.

-) Cette option est elle obligatoire ?

Merci

PascalHambourg · Mars 30, 2018, 10:00pm

Le montage initial de la racine en lecture seule n’est pas obligatoire s’il n’est pas nécessaire. Il me semble d’ailleurs qu’il n’est pas nécessaire pour pouvoir vérifier le système de fichiers racine avec les versions récentes de Debian car l’initramfs peut le vérifier avant de le monter.

Ce n’est pas la seule “anomalie” de cette entrée de menu. Une autre est que la ligne de commande “linux” désigne le système de fichiers racine par son nom de périphérique /dev/sda7 au lieu de son UUID.

Il faut savoir que certains paramètres des entrées de menu d’un système GNU/Linux détecté par os-prober sont susceptibles d’être extraits du fichier /boot/grub/grub.cfg du système en question.

kolap · Mars 31, 2018, 6:58pm

re,
Merci pour le retour:wink:
Voici tjs quelques informations:
-) j’ai complètement abandonné windows et cela depuis deja maintenant plusieurs années, donc pc 100% linux
-) Grub2 dans mbr
-) Une partition primaire sda1 avec mon système principale…

$ apt-cache policy libc6
libc6:
  Installé : 2.19-18+deb8u10
  Candidat : 2.19-18+deb8u10
 Table de version :
 *** 2.19-18+deb8u10 0
        500 http://ftp.be.debian.org/debian/ jessie/main i386 Packages
        500 http://security.debian.org/ jessie/updates/main i386 Packages
        100 /var/lib/dpkg/status

-) une partition étendue sda2 avec divers partitions logiques…

En faite, a la base je n’utilise pas os_prober, l’entrée du fichier /etc/defaut/grub est sur true

GRUB_DISABLE_OS_PROBER=“true”

Quand j’installe une distribution sur une partition logique, je n’installe jamais le gestionnaire de boot et configure cela via une configuration personnelle…
Si on regarde le grub.cfg, ont vois que l’option “ro” est tjs passée quand un noyau est installé sur sda1…
Extrais du grub.cfg:

### BEGIN /etc/grub.d/10_linux ###
menuentry 'MX GNU/Linux' --class mx --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-2630b494-8ca2-4672-bae9-fa29b58ab472' {
set root='hd0,msdos1'
linux	/boot/vmlinuz-4.10.1-antix.1-486-smp root=UUID=2630b494-8ca2-4672-bae9-fa29b58ab472 ro  quiet
echo	'Chargement du disque mémoire initial…'
initrd	/boot/initrd.img-4.10.1-antix.1-486-smp

menuentry 'MX GNU/Linux, avec Linux 3.16.0-4-686-pae' --class mx --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-686-pae-advanced-2630b494-8ca2-4672-bae9-fa29b58ab472' {
set root='hd0,msdos1'
linux	/boot/vmlinuz-3.16.0-4-686-pae root=UUID=2630b494-8ca2-4672-bae9-fa29b58ab472 ro  quiet
echo	'Chargement du disque mémoire initial…'
initrd	/boot/initrd.img-3.16.0-4-686-pae

Par curiosité, j’ai passé a false GRUB_DISABLE_OS_PROBER=“false” pour voir l’entrée dans le grub.cfg
La j’ai remarqué que update-grub ne passait pas l’option “ro” au noyau pour une distribution sur une partition logique
D’ou ma question pour l’option “ro” comme je configure moi même cela…
sda1 partition primaire
sda* partition logique

$ sudo blkid
/dev/sda1: LABEL="rootMX-16" UUID="2630b494-8ca2-4672-bae9-fa29b58ab472" TYPE="ext4" PARTUUID="6b1f7ca2-01"
/dev/sda5: UUID="6835a32b-fd98-4a86-a98d-6b265b249e17" TYPE="swap" PARTUUID="6b1f7ca2-05"
/dev/sda6: UUID="b03c2da9-1914-44ef-8ac6-479d639758c8" TYPE="ext4" PARTUUID="6b1f7ca2-06"
/dev/sda7: UUID="1caa5f76-04cd-4400-97bb-8c2f622b65c3" TYPE="ext4" PARTUUID="6b1f7ca2-07"

merci

grandtoubab · Mars 31, 2018, 7:25pm

Salut

ça se passe à priori dans /etc/grub.d/10_linux du paquet grub-common où on trouve ces lignes

	linux	${rel_dirname}/${basename}.efi.signed root=${linux_root_device_thisversion} ro ${args}
	linux	${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}

Et c’est bien pour permettre l’exécution de fsck au boot
http://man7.org/linux/man-pages/man7/bootparam.7.html

  'ro' and 'rw'_
        The 'ro' option tells the kernel to mount the root filesystem_
       as 'read-only' so that filesystem consistency check programs_
       (fsck) can do their work on a quiescent filesystem.  No pro‐_
      cesses can write to files on the filesystem in question until_
       it is 'remounted' as read/write capable, for example, by_
      'mount -w -n -o remount /'.  (See also mount(8).)_

        The 'rw' option tells the kernel to mount the root filesystem_
       read/write.  This is the default.

Si tu te retrouves en rw, option par défaut, c’est que tu n’exécute pas etc/grub.d/10_linux

PascalHambourg · Mars 31, 2018, 8:53pm

D’après le test que je viens de faire, grub-mkconfig produit exactement ce résultat quand le système ajouté grâce à os-prober n’a pas de fichier /boot/grub/grub.cfg à partir duquel les paramètres du noyau pourraient être copiés : root spécifié par son nom de périphérique et pas d’autre option.

Mais non. Ce script génère les entrées de menu des noyaux du système depuis lequel grub-mkconfig est lancé. Les entrées des autres systèmes détectés sont générées par 30_os-prober.

Comme je l’ai déjà écrit, cette option est inutile quand le fsck sur la racine est lancé depuis l’initramfs, comme c’est le cas depuis Jessie.

grandtoubab · Avril 1, 2018, 8:36am

Que le fsck soit lancé pat initramfs, ok

root@debian:/var/run/initramfs# ls -alrt
total 4
-rw-r--r--  1 root root   0 avril  1 10:17 fsck-root
-rw-r--r--  1 root root 169 avril  1 10:17 fsck.log
drwxr-xr-x  2 root root  80 avril  1 10:17 .
drwxr-xr-x 31 root root 840 avril  1 10:17 ..
root@debian:/var/run/initramfs# cat fsck.log
Log of fsck -C -a -T -t ext4 /dev/sda1 
Sun Apr  1 08:17:01 2018

debian: clean, 258365/1246032 files, 3170173/5001216 blocks

Sun Apr  1 08:17:02 2018
----------------
root@debian:/var/run/initramfs#

Le log est en UTC.


Mais si on est en rw est-ce que fsck pourra fonctionner?

PascalHambourg · Avril 1, 2018, 8:59am

Oui puisque l’initramfs peut exécuter fsck avant de monter la racine, donc peu importe que la racine soit ensuite montée en lecture seule ou en lecture-écriture.

C’était différent quand le système n’utilisait pas d’initrd ou initramfs et le système de fichiers racine était monté directement par le noyau (1), avant l’exécution d’init et de tout autre programme, ou bien avec les systèmes comme les versions de Debian antérieures à Jessie où le fsck sur la racine fait partie de la séquence d’init, donc a lieu après le montage de la racine.

Si tu n’es pas convaincu, tu peux éditer la ligne de commande du noyau dans le menu de démarrage pour remplacer ro par rw et voir ce qui se passe.

(1) J’écris à l’imparfait mais j’ai encore une machine sous Debian sans initramfs ni udev avec un noyau maison qui nomme le disque hda.

kolap · Avril 2, 2018, 3:21pm

Merci a vous pour les informations, qui me permette de me diriger dans mes recherches…
-) ceci peut il confirmer que l’option “ro” n’est pas obligatoire ?

root@mx1:/media/sda7># pwd
/media/sda7/var/log
root@mx1:/media/sda7/var/log # grep sda7 syslog
Mar 27 22:28:20 debian kernel: [ 0.000000] Kernel command line: BOOT_IMAGE=(hd0,msdos7)/boot/vmlinuz-3.16.0-4-586 root=/dev/sda7
Mar 27 22:28:20 debian systemd-fsck[141]: /dev/sda7 : propre, 89312/1335296 fichiers, 519134/5339392 blocs
Mar 27 22:28:20 debian kernel: [ 3.454922] sda: sda1 sda2 < sda5 sda6 sda7 >
Mar 27 22:28:20 debian kernel: [ 10.117216] EXT4-fs (sda7): mounted filesystem with ordered data mode. Opts: (null)
Mar 27 22:28:20 debian kernel: [ 17.900354] EXT4-fs (sda7): re-mounted. Opts: errors=remount-ro

root@mx1:/media/sda7/var/log # grep sda7 daemon.log
Mar 27 22:28:20 debian systemd-fsck[141]: /dev/sda7 : propre, 89312/1335296 fichiers, 519134/5339392 blocs

merci

PascalHambourg · Avril 2, 2018, 10:08pm

Si j’ai bien compris, tu as installé cette distribution BunsenLabs sans chargeur d’amorçage ? Donc elle n’a pas de fichier /boot/grub/grub.cfg, et c’est ce qui explique les paramètres de l’entrée de menu créée avec os-prober.

Pour y remédier, tu peux installer le paquet grub2-common dans BunsenLabs et y exécuter la commande update-grub pour générer un fichier grub.cfg. Cela n’installera pas de chargeur d’amorçage. Ensuite depuis la distribution principale, (MX) update-grub devrait regénérer les entrées de menu pour BunsenLabs avec UUID=xxx au lieu de sda7 (plus robuste car le nom du disque peut varier, pas l’UUID) et l’option ro.

grandtoubab · Avril 3, 2018, 6:40am

salut
On peut générer aussi soi-même une ligne de menu grub dans un fichier /boot/grub/custom.cfg
Exemple, dans mon installation Debian j’ai ajouté une ligne pour démarrer mon image Android qui est sous /

root@debian:/Phoenix# ls 
data  initrd.img  kernel  ramdisk.img  system.sfs
root@debian:/Phoenix#

debian:/boot/grub$ cat custom.cfg

menuentry 'Phoenix OS' --class android-x86 {
	search --set=root --file /Phoenix/kernel	
	linux /Phoenix/kernel root=/dev/ram0 logo.showlogo=1 androidboot.hardware=android_x86 androidboot.selinux=permissive SERIAL=random SRC= DATA=data
	initrd /Phoenix/initrd.img 
}

kolap · Avril 4, 2018, 8:35pm

re,

Exactement …

Intéressant, cela va me permettre d’avancé dans mon apprentissage sur la compréhension de “pour résumer” Grub/boot…

Je m’explique en deux mots, sur ce pc les ports usb sont inutilisables et le graveur on oublie.
De par ce fait, j’utilise la méthode “iso stockées sur DD et grub” pour démarrer, installer une distribution ou autres…

intéressante aussi, sans entrer dans le détail, cela correspond a"pour" une utilisation frugal, non ?

grandtoubab · Avril 4, 2018, 9:01pm

/boot/grub/custom.cfg permet de définir soi même ce que l’on veut .

on peut aussi le faire dans /etc/grub.d/40_custom

cat /etc/grub.d/40_custom

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the exec tail' line above.

https://openclassrooms.com/courses/apprenez-a-maitriser-grub/configurez-grub2

https://www.gnu.org/software/grub/manual/grub/html_node/Configuration.html#Configuration

kolap · Avril 4, 2018, 9:20pm

De mon côté j’utilise cela comme ceci
-) une entrée dans /40_custom qui pointe vers un fichier qui me sert de configuration

$ cat /etc/grub.d/40_custom

menuentry "Distribs lancées depuis leur fichier iso" { 
set root='hd0,msdos1'
configfile /isos/00_isoboot.cfg
}

-) Je le configure pour démarrer une iso et ou pour démarrer une distribution sur une autre partition

démarrer l’iso

$ cat /isos/00_isoboot.cfg

menuentry "bl-Deuterium-i386 install" {
set root='hd0,msdos1'		
set isofile="/isos/bl-Deuterium-i386+NonPAE_20170429.iso"
loopback loop (hd0,msdos1)$isofile
linux (loop)/install/gtk/vmlinuz findiso=${isofile}  video=vesa:ywrap,mtrr vga=788  -- quiet
initrd (loop)/install/gtk/initrd.gz
}

Démarrer la distribution sur sda7

$ cat /isos/00_isoboot.cfg

menuentry "bl-Deuterium-i386  sur sda7" {
insmod part_msdos
insmod ext2
set root='hd0,msdos7'		
linux (hd0,msdos7)/boot/vmlinuz-3.16.0-4-586 root=/dev/sda7	 pcie_aspm=force
initrd (hd0,msdos7)/boot/initrd.img-3.16.0-4-586
}