APT et montage de /usr, /boot... en lecture seule

Support Debian
#3

L’option -f est la version courte de --fake (et non --force). Cela ne force pas la commande, au contraire elle n’est pas réellement exécutée. Mais quel est l’intérêt de cette ligne alors ?
As-tu déterminé pourquoi le système n’accepte pas le remontage en lecture seule ? Peut-être des fichiers restés ouverts en lecture-écriture ?

L’avantage des commandes que je propose est qu’elles sont indépendantes du contenu de fstab. Mais je ne les ai pas encore testées en situation réelle.

Pour quelle raison ? Je viens de regarder la date des fichiers et répertoires de /boot sur ma machine, le plus récent est antérieur au dernier démarrage et date de la dernière regénération de l’initramfs lorsque j’ai installé btrfs-tools.

#4

Ohhh, oui !
Et, pourtant :

$ egrep "/boot|/usr|/tmp" /proc/mounts 
/dev/mapper/grp--siou-vol_usr /usr ext4 rw,nodev,relatime,data=ordered 0 0
/dev/md0 /boot ext4 ro,nodev,relatime,data=ordered 0 0
/dev/loop0 /tmp ext4 rw,nosuid,nodev,noexec,relatime,data=ordered 0 0

C’est Grub qui en a besoin, un de ses exécutables. :wink:
C’est le binaire ‘grub-editenv’ qui a besoin d’écrire dans la partition '/boot’
https://www.gnu.org/software/grub/manual/html_node/Environment-block.html
Et, clairement pour avoir testé, si /boot est en ‘ro’ … tu démarres mal.

PS : On digresse sérieusement :wink:

#5

Oui quoi ?
C’est bien ce que je disais, /usr reste monté en lecture-écriture.

Au fait, pourquoi /tmp est monté en loop alors que c’est un LV ?

Et qu’est-ce qui fait appel à grub-editenv sur ton système ?
Sur le mien ce n’est clairement pas le cas puisque si je l’exécute manuellement la date du fichier /boot/grub/grubenv est mise à jour.

Que s’est-il passé ? Là je ne peux pas tester, je n’ai pas de /boot séparé.

#6

En effet ; je m’étais focalisé sur /boot :stuck_out_tongue:

quote="PascalHambourg, post:15, topic:72079"
Que s’est-il passé ? Là je ne peux pas tester, je nr’ai pas de /boot séparé.
[/quote]

Sincèrement, depuis l’eau est passé sous les ponts. Et, je suis incapable de m’en souvenir …

#7

Bon, cette histoire m’a titillé alors j’ai installé un système de base Jessie avec /boot, /tmp et /usr séparés pour tester par moi-même.

  • /boot est monté en lecture seule dans /etc/fstab et le démarrage se déroule normalement, sans erreur.
    Cela ne m’étonne pas car je ne trouve aucun fichier installé par les paquets grub* dans les scripts d’init /etc/init.d ou systemd. Il doit y avoir quelque chose de particulier sur ton système qui exécute grub-editenv au démarrage.

  • Effectivement le remontage de /usr en lecture seule échoue après l’installation ou la mise à jour de paquets. Le remontage manuel réussit, donc je me suis dit qu’il y avait peut-être encore des écritures en cours. J’ai donc ajouté une commande sync avant les remontages, et maintenant /usr est automatiquement remonté en lecture seule sans erreur.

#8

C’est bien possible. J’avoue avoir blindé beaucoup de choses.
Tu sais quoi, je vais la repasser en ‘ro’ dès le démarrage … et je le redémarrerai :stuck_out_tongue:

Ça m’intéresse. Exemple, stp ?!

#9

Rien de transcendant, j’ai repris ton fichier en l’adaptant.

/etc/apt/apt.conf.d/000remount-rw :

DPkg::Pre-Invoke {
        "mount -o remount,rw /boot";
        "mount -o remount,exec /tmp";
        "mount -o remount,rw /usr";
};
DPkg::Post-Invoke {
        "sync";
        "mount -o remount /boot";
        "mount -o remount /tmp";
        "mount -o remount /usr";
};

(je ne remets pas les options inverses dans Post-Invoke puisqu’elles sont déjà dans /etc/fstab)

PS : j’ai splitté le sujet.

#10

Oki, merci.

tu es sûr de cela … parce que le manpage n’est pas si affirmatif …

The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn’t read fstab (or mtab) only when a device and dir are fully specified.
(…)
After this call mount reads fstab (or mtab) and merges these options with options from command line ( -o ).

Ok, si je comprends bien le propos de la dernière ligne, si je n’ai pas d’option spécifiée, l’option ‘-o’ va lire seulement les infos depuis fstab … et les appliquer à nouveau sur la partition en question.

Très bien … j’ai hésité à le faire :stuck_out_tongue:

#11

Oui. Evidemment j’ai testé, et ça marche.

C’est la première fois que je scinde un sujet, j’ai bien galéré.

#12

Pour rendre le fichier encore plus polyvalent, j’ai voulu ajouter la vérification que le répertoire est un point de montage comme dans mon message initial, mais j’ai dû inverser la condition afin que l’expression retourne l’état"vrai" dans le cas contraire, sinon apt-get considère que la commande a terminé en erreur et s’interrompt. Voici ce que ça donne, testé sur une installation où tout est sur la racine et une où tout est séparé :

DPkg::Pre-Invoke {
        "! mountpoint -q /boot || mount -o remount,rw   /boot";
        "! mountpoint -q /tmp  || mount -o remount,exec /tmp";
        "! mountpoint -q /usr  || mount -o remount,rw   /usr";
};
DPkg::Post-Invoke {
        "sync";
        "! mountpoint -q /boot || mount -o remount /boot";
        "! mountpoint -q /tmp  || mount -o remount /tmp";
        "! mountpoint -q /usr  || mount -o remount /usr";
};

L’expression retourne “faux” seulement si le répertoire est un point de montage et le remontage échoue.

Bien sûr il faut que les options de montage devant être appliquées par défaut soient dans /etc/fstab. Si elles ont été appliquées par un autre moyen comme toi avec /etc/rc.local, elles ne seront pas réappliquées. Cela peut être le cas par exemple si /tmp est un tmpfs créé avec /etc/default/tmpfs et non avec /etc/fstab.

2 J'aime
#13

RAhhh, je viens de faire l’install sur une nouvelle Stable.
Dpkg ne prend pas en compte le fichier /etc/apt/apt.conf.d/00apt (ou ‘remount’, dans ton cas :p) …
Dans le cas où tu fais un : dpkg -i binaire.deb …

Une idée @PascalHambourg ?

#14

Je suppose qu’il faut mettre les commandes de remontage dans la configuration de dpkg : /etc/dpkg/dpkg.cfg ou dans un fichier du répertoire /etc/dpkg/dpkg.cfg.d/.

En fait c’était ma première idée quand je me suis penché sur le sujet, avant de voir ton exemple utilisant APT et de le reprendre.

#15

C’est à peu près ce que j’ai compris, j’ai vu qu’il y avait des options --pre-invoke et --post-invoke … mais je n’ai pas encore compris comment les utiliser dans le contexte d’un fichier de config à dpkg !

#16

Lire le chapitre “OPTIONS” de la page de manuel de dpkg :

Chaque ligne de ce fichier est soit une option
(identique à une option en ligne de commande mais sans tirets initiaux)

#17

Bon alors, je confirme que cela fonctionne !

J’ai créé un fichier /etc/dpkg/dpkg.conf.d/dpkg, dans lequel j’ai mis :

pre-invoke=(mount -o remount,rw /boot; mount -o remount,exec /tmp; mount -o remount,rw /opt; mount -o remount,rw /usr; mount -o remount,rw /usr/local; mount -o remount,exec /var; mount -o remount,exec /var/log; )
post-invoke=(mount -o remount /boot; mount -o remount /tmp; mount -o remount /opt; mount -o remount /usr; mount -o remount /usr/local; mount -o remount /var; mount -o remount /var/log; )

:wink:

#18

Merci du retour. Pas eu besoin de sync avant le remontage en lecture seule en post-invoke ?

#19

Ahhh, je ne l’ai pas rajouté :stuck_out_tongue: …
Ceci explique peut être pourquoi j’ai le message d’erreur avec la partition /usr … quid ?!

#20

Faudrait savoir, ça fonctionne ou il y a une erreur ?

#21

Je parle de l’erreur sur le remontage de la partition /usr tel que prévu dans le fichier /etc/fstab.

Autrement la gestion du fichier de configuration pour dpkg est correcte …

#22

Encore heureux. Si on ne peut plus se fier aux pages de manuel…

Par égards pour mon équilibre mental, les mêmes causes produisent les mêmes effets et le sync doit être aussi nécessaire avec dpkg qu’avec apt-get.