Bonsoir à tous,
Soit une Debian Jessie toute bête : installation minimale en mode expert
avec juste une console (pas d'environnement de bureau etc.), un seul disque
et une seule partition / de 10GB en ext4. La machine est une VM VirtualBox
en l'occurrence mais je pense que ça n'a pas d'importance ici.
Au moment du boot dans le menu Grub, si je choisis le boot en mode recovery,
contrairement à ce qu'on pourrait penser, je me retrouve avec un / qui n'est
_pas_ monté en read-only. Je peux écrire dessus etc. J'ai pourtant bien vérifié
dans le menu Grub (je n'ai rien touché c'est une installation out-of-the-box),
il y a bien, pour le mode recovery, l'option "ro" qui est passée au noyau
Linux. Du coup, je ne comprends pas trop.
On est d'accord que ce n'est pas normal, n'est-ce pas ? Est-ce un bug ? Vous
constatez la même chose sur vos Jessie ?
Comment faire pour avoir un mode recovery où / est bien monté en read-only
_directement_ (comme c'est le cas sur Wheezy par exemple) ?
On est d'accord que je peux ruser par exemple en éditant avant le fstab et
en ajoutant l'option "ro" au montage de /. Mais c'est plus pénible car il
faut éditer le fichier puis ne pas oublier d'enlever la modif. Et puis
j'aimerais que le mode recovery fasse comme il a toujours fait (sauf erreur)
dans les versions précédentes de Debian, à savoir monter / en read-only ?
Où alors ma mémoire me fait défaut et ça ne fait pas forcément partie du
« contrat » du mode recovery ?
Merci d'avance pour vos lumières et Joyeuses Pâques. ;)
Bonsoir à tous,
Soit une Debian Jessie toute bête : installation minimale en mode expert
avec juste une console (pas d'environnement de bureau etc.), un seul disque
et une seule partition / de 10GB en ext4. La machine est une VM VirtualBox
en l'occurrence mais je pense que ça n'a pas d'importance ici.
Au moment du boot dans le menu Grub, si je choisis le boot en mode recovery,
contrairement à ce qu'on pourrait penser, je me retrouve avec un / qui n'est
_pas_ monté en read-only. Je peux écrire dessus etc. J'ai pourtant bien vérifié
dans le menu Grub (je n'ai rien touché c'est une installation out-of-the-box),
il y a bien, pour le mode recovery, l'option "ro" qui est passée au noyau
Linux. Du coup, je ne comprends pas trop.
On est d'accord que ce n'est pas normal, n'est-ce pas ? Est-ce un bug ? Vous
constatez la même chose sur vos Jessie ?
Comment faire pour avoir un mode recovery où / est bien monté en read-only
_directement_ (comme c'est le cas sur Wheezy par exemple) ?
On est d'accord que je peux ruser par exemple en éditant avant le fstab et
en ajoutant l'option "ro" au montage de /. Mais c'est plus pénible car il
faut éditer le fichier puis ne pas oublier d'enlever la modif. Et puis
j'aimerais que le mode recovery fasse comme il a toujours fait (sauf erreur)
dans les versions précédentes de Debian, à savoir monter / en read-only ?
Où alors ma mémoire me fait défaut et ça ne fait pas forcément partie du
« contrat » du mode recovery ?
Merci d'avance pour vos lumières et Joyeuses Pâques. ;)
Bonsoir à tous,
Soit une Debian Jessie toute bête : installation minimale en mode expert
avec juste une console (pas d'environnement de bureau etc.), un seul disque
et une seule partition / de 10GB en ext4. La machine est une VM VirtualBox
en l'occurrence mais je pense que ça n'a pas d'importance ici.
Au moment du boot dans le menu Grub, si je choisis le boot en mode recovery,
contrairement à ce qu'on pourrait penser, je me retrouve avec un / qui n'est
_pas_ monté en read-only. Je peux écrire dessus etc. J'ai pourtant bien vérifié
dans le menu Grub (je n'ai rien touché c'est une installation out-of-the-box),
il y a bien, pour le mode recovery, l'option "ro" qui est passée au noyau
Linux. Du coup, je ne comprends pas trop.
On est d'accord que ce n'est pas normal, n'est-ce pas ? Est-ce un bug ? Vous
constatez la même chose sur vos Jessie ?
Comment faire pour avoir un mode recovery où / est bien monté en read-only
_directement_ (comme c'est le cas sur Wheezy par exemple) ?
On est d'accord que je peux ruser par exemple en éditant avant le fstab et
en ajoutant l'option "ro" au montage de /. Mais c'est plus pénible car il
faut éditer le fichier puis ne pas oublier d'enlever la modif. Et puis
j'aimerais que le mode recovery fasse comme il a toujours fait (sauf erreur)
dans les versions précédentes de Debian, à savoir monter / en read-only ?
Où alors ma mémoire me fait défaut et ça ne fait pas forcément partie du
« contrat » du mode recovery ?
Merci d'avance pour vos lumières et Joyeuses Pâques. ;)
La différence entre le mode "recovery" et le mode "standard" est le paramètre "single".
En mode recovery, on est donc en mode mono-utilisateur (plus bcp de modules non chargés).
Par défaut, les 2 modes sont en read-only, et ce principalement pour permettre à fsck de faire son travail en toute quiétude.
Une fois tout en place, le système bascule le "root file system" en rw.
Tu peux vérifier la ligne de commande/paramètres en bootant dans chaque mode avec:
$ cat /proc/cmdline
Et dans /boot/grub/grub.cfg, (sauf modification), tu devrais aussi voir ro dans les 2 cas.
Je ne conseillerais pas de switcher le système de fichier en ro dans /etc/fstab, le système a besoin d'écrire.
Je jouerais plutôt avec les droits/attributs des fichiers/dossiers sensibles.
La différence entre le mode "recovery" et le mode "standard" est le paramètre "single".
En mode recovery, on est donc en mode mono-utilisateur (plus bcp de modules non chargés).
Par défaut, les 2 modes sont en read-only, et ce principalement pour permettre à fsck de faire son travail en toute quiétude.
Une fois tout en place, le système bascule le "root file system" en rw.
Tu peux vérifier la ligne de commande/paramètres en bootant dans chaque mode avec:
$ cat /proc/cmdline
Et dans /boot/grub/grub.cfg, (sauf modification), tu devrais aussi voir ro dans les 2 cas.
Je ne conseillerais pas de switcher le système de fichier en ro dans /etc/fstab, le système a besoin d'écrire.
Je jouerais plutôt avec les droits/attributs des fichiers/dossiers sensibles.
La différence entre le mode "recovery" et le mode "standard" est le paramètre "single".
En mode recovery, on est donc en mode mono-utilisateur (plus bcp de modules non chargés).
Par défaut, les 2 modes sont en read-only, et ce principalement pour permettre à fsck de faire son travail en toute quiétude.
Une fois tout en place, le système bascule le "root file system" en rw.
Tu peux vérifier la ligne de commande/paramètres en bootant dans chaque mode avec:
$ cat /proc/cmdline
Et dans /boot/grub/grub.cfg, (sauf modification), tu devrais aussi voir ro dans les 2 cas.
Je ne conseillerais pas de switcher le système de fichier en ro dans /etc/fstab, le système a besoin d'écrire.
Je jouerais plutôt avec les droits/attributs des fichiers/dossiers sensibles.
Bonjour,
On 27/03/2016 03:01, mireero wrote:La différence entre le mode "recovery" et le mode "standard" est le paramètre "single".
En mode recovery, on est donc en mode mono-utilisateur (plus bcp de modules non chargés).
Par défaut, les 2 modes sont en read-only, et ce principalement pour permettre à fsck de faire son travail en toute quiétude.
Une fois tout en place, le système bascule le "root file system" en rw.
Tu peux vérifier la ligne de commande/paramètres en bootant dans chaque mode avec:
$ cat /proc/cmdline
Et dans /boot/grub/grub.cfg, (sauf modification), tu devrais aussi voir ro dans les 2 cas.
Effectivement je viens de vérifier, c'est bien le cas.
Du coup, ça ne fait pas partir du « contrat » que d'avoir un / en read-only lors
d'un boot en mode recovery. De plus, j'ai re-vérifié aussi et, contrairement à
ce que je disais, sous Wheezy on a bien le même comportement (ie le / est
accessible en écriture en mode recovery).
En fait, ce qui m'a induit en erreur, c'est que sur Ubuntu Trusty le comportement
est différent. En effet, sur Trusty, un boot en mode recovery permet d'ouvrir un
shell avec _automatiquement_ un / en read-only.
Du coup, ma question serait plutôt : comment avoir ce même type de boot sous Debian
Jessie ? Y a-t-il une option du noyau particulière dans la ligne de boot à ajouter ?
Ce serait pratique dans mon cas. En effet, je me fais des boxes vagrant (ie des
petites VM virtualbox prêtes à l'emploi via la commande vagrant, ce qui me permet
dans le terminal d'instancier et de me ssher sur une VM clean et prête à l'emploi
en moins d'une minute le tout sans avoir à lancer la GUI virtualbox, juste avec une
simple commande en console). Mais avant d'exporter une VM virtualbox en une box
vagrant, il faut que je lance une commande dans la VM qui me permet de minimiser la
taille de ma future box vagrant. Il s'agit de la commande :
zerofree /dev/sda1 # on imagine que /dev/sda1 correspond à / dans la VM
Mais cette commande est possible que si / est monté en read-only. Du coup, sur Trusty,
c'est facile : je reboote la VM, je choisis le mode recovery où j'ai / en ro directement,
je lance la commande zerofree et c'est fini. Comment pourrais-je faire l'équivalent
sous Jessie ?Je ne conseillerais pas de switcher le système de fichier en ro dans /etc/fstab, le système a besoin d'écrire.
Pour la commande que je dois lancer, il me faut le / en ro sinon zerofree n'est
pas content.
Je jouerais plutôt avec les droits/attributs des fichiers/dossiers sensibles.
Je ne suis pas sûr d'avoir compris ce que tu veux dire là.
En tout cas merci pour ta réponse qui m'a bien éclairé sur ce qu'est réellement
le mode recovery (ie pas exactement ce que je croyais).
Bonjour,
On 27/03/2016 03:01, mireero wrote:
La différence entre le mode "recovery" et le mode "standard" est le paramètre "single".
En mode recovery, on est donc en mode mono-utilisateur (plus bcp de modules non chargés).
Par défaut, les 2 modes sont en read-only, et ce principalement pour permettre à fsck de faire son travail en toute quiétude.
Une fois tout en place, le système bascule le "root file system" en rw.
Tu peux vérifier la ligne de commande/paramètres en bootant dans chaque mode avec:
$ cat /proc/cmdline
Et dans /boot/grub/grub.cfg, (sauf modification), tu devrais aussi voir ro dans les 2 cas.
Effectivement je viens de vérifier, c'est bien le cas.
Du coup, ça ne fait pas partir du « contrat » que d'avoir un / en read-only lors
d'un boot en mode recovery. De plus, j'ai re-vérifié aussi et, contrairement à
ce que je disais, sous Wheezy on a bien le même comportement (ie le / est
accessible en écriture en mode recovery).
En fait, ce qui m'a induit en erreur, c'est que sur Ubuntu Trusty le comportement
est différent. En effet, sur Trusty, un boot en mode recovery permet d'ouvrir un
shell avec _automatiquement_ un / en read-only.
Du coup, ma question serait plutôt : comment avoir ce même type de boot sous Debian
Jessie ? Y a-t-il une option du noyau particulière dans la ligne de boot à ajouter ?
Ce serait pratique dans mon cas. En effet, je me fais des boxes vagrant (ie des
petites VM virtualbox prêtes à l'emploi via la commande vagrant, ce qui me permet
dans le terminal d'instancier et de me ssher sur une VM clean et prête à l'emploi
en moins d'une minute le tout sans avoir à lancer la GUI virtualbox, juste avec une
simple commande en console). Mais avant d'exporter une VM virtualbox en une box
vagrant, il faut que je lance une commande dans la VM qui me permet de minimiser la
taille de ma future box vagrant. Il s'agit de la commande :
zerofree /dev/sda1 # on imagine que /dev/sda1 correspond à / dans la VM
Mais cette commande est possible que si / est monté en read-only. Du coup, sur Trusty,
c'est facile : je reboote la VM, je choisis le mode recovery où j'ai / en ro directement,
je lance la commande zerofree et c'est fini. Comment pourrais-je faire l'équivalent
sous Jessie ?
Je ne conseillerais pas de switcher le système de fichier en ro dans /etc/fstab, le système a besoin d'écrire.
Pour la commande que je dois lancer, il me faut le / en ro sinon zerofree n'est
pas content.
Je jouerais plutôt avec les droits/attributs des fichiers/dossiers sensibles.
Je ne suis pas sûr d'avoir compris ce que tu veux dire là.
En tout cas merci pour ta réponse qui m'a bien éclairé sur ce qu'est réellement
le mode recovery (ie pas exactement ce que je croyais).
Bonjour,
On 27/03/2016 03:01, mireero wrote:La différence entre le mode "recovery" et le mode "standard" est le paramètre "single".
En mode recovery, on est donc en mode mono-utilisateur (plus bcp de modules non chargés).
Par défaut, les 2 modes sont en read-only, et ce principalement pour permettre à fsck de faire son travail en toute quiétude.
Une fois tout en place, le système bascule le "root file system" en rw.
Tu peux vérifier la ligne de commande/paramètres en bootant dans chaque mode avec:
$ cat /proc/cmdline
Et dans /boot/grub/grub.cfg, (sauf modification), tu devrais aussi voir ro dans les 2 cas.
Effectivement je viens de vérifier, c'est bien le cas.
Du coup, ça ne fait pas partir du « contrat » que d'avoir un / en read-only lors
d'un boot en mode recovery. De plus, j'ai re-vérifié aussi et, contrairement à
ce que je disais, sous Wheezy on a bien le même comportement (ie le / est
accessible en écriture en mode recovery).
En fait, ce qui m'a induit en erreur, c'est que sur Ubuntu Trusty le comportement
est différent. En effet, sur Trusty, un boot en mode recovery permet d'ouvrir un
shell avec _automatiquement_ un / en read-only.
Du coup, ma question serait plutôt : comment avoir ce même type de boot sous Debian
Jessie ? Y a-t-il une option du noyau particulière dans la ligne de boot à ajouter ?
Ce serait pratique dans mon cas. En effet, je me fais des boxes vagrant (ie des
petites VM virtualbox prêtes à l'emploi via la commande vagrant, ce qui me permet
dans le terminal d'instancier et de me ssher sur une VM clean et prête à l'emploi
en moins d'une minute le tout sans avoir à lancer la GUI virtualbox, juste avec une
simple commande en console). Mais avant d'exporter une VM virtualbox en une box
vagrant, il faut que je lance une commande dans la VM qui me permet de minimiser la
taille de ma future box vagrant. Il s'agit de la commande :
zerofree /dev/sda1 # on imagine que /dev/sda1 correspond à / dans la VM
Mais cette commande est possible que si / est monté en read-only. Du coup, sur Trusty,
c'est facile : je reboote la VM, je choisis le mode recovery où j'ai / en ro directement,
je lance la commande zerofree et c'est fini. Comment pourrais-je faire l'équivalent
sous Jessie ?Je ne conseillerais pas de switcher le système de fichier en ro dans /etc/fstab, le système a besoin d'écrire.
Pour la commande que je dois lancer, il me faut le / en ro sinon zerofree n'est
pas content.
Je jouerais plutôt avec les droits/attributs des fichiers/dossiers sensibles.
Je ne suis pas sûr d'avoir compris ce que tu veux dire là.
En tout cas merci pour ta réponse qui m'a bien éclairé sur ce qu'est réellement
le mode recovery (ie pas exactement ce que je croyais).
Tu pourrais pas faire simplement un:
# mount -o remount,ro /dev/sda1 && zerofree /dev/sda1
Je pensais que tu voulais peut-être protéger certains fichiers/dossiers contre l'écriture/écrasement en passant tout en ro
Tu pourrais pas faire simplement un:
# mount -o remount,ro /dev/sda1 && zerofree /dev/sda1
Je pensais que tu voulais peut-être protéger certains fichiers/dossiers contre l'écriture/écrasement en passant tout en ro
Tu pourrais pas faire simplement un:
# mount -o remount,ro /dev/sda1 && zerofree /dev/sda1
Je pensais que tu voulais peut-être protéger certains fichiers/dossiers contre l'écriture/écrasement en passant tout en ro
On 27/03/2016 18:10, mireero wrote:Tu pourrais pas faire simplement un:
# mount -o remount,ro /dev/sda1 && zerofree /dev/sda1
Oui j'avais tenté cela déjà mais la commande « mount -o remount,ro /dev/sda1 »
ne fonctionne pas. J'ai un message qui me dit que /dev/sda1 est occupé.
J'ai aussi tenté la commande alors que j'avais rebooté en mode recovery et
j'avais le même message d'erreur.Je pensais que tu voulais peut-être protéger certains fichiers/dossiers contre l'écriture/écrasement en passant tout en ro
Ah ok. Non, effectivement je ne suis pas dans ce cas. J'ai une commande à
lancer (une seule fois) et qui nécessite que / soit en read-only (temporairement
donc). Le mode recovery de Trusty répond parfaitement à mes besoins donc
mais pas celui de Jessie.
On 27/03/2016 18:10, mireero wrote:
Tu pourrais pas faire simplement un:
# mount -o remount,ro /dev/sda1 && zerofree /dev/sda1
Oui j'avais tenté cela déjà mais la commande « mount -o remount,ro /dev/sda1 »
ne fonctionne pas. J'ai un message qui me dit que /dev/sda1 est occupé.
J'ai aussi tenté la commande alors que j'avais rebooté en mode recovery et
j'avais le même message d'erreur.
Je pensais que tu voulais peut-être protéger certains fichiers/dossiers contre l'écriture/écrasement en passant tout en ro
Ah ok. Non, effectivement je ne suis pas dans ce cas. J'ai une commande à
lancer (une seule fois) et qui nécessite que / soit en read-only (temporairement
donc). Le mode recovery de Trusty répond parfaitement à mes besoins donc
mais pas celui de Jessie.
On 27/03/2016 18:10, mireero wrote:Tu pourrais pas faire simplement un:
# mount -o remount,ro /dev/sda1 && zerofree /dev/sda1
Oui j'avais tenté cela déjà mais la commande « mount -o remount,ro /dev/sda1 »
ne fonctionne pas. J'ai un message qui me dit que /dev/sda1 est occupé.
J'ai aussi tenté la commande alors que j'avais rebooté en mode recovery et
j'avais le même message d'erreur.Je pensais que tu voulais peut-être protéger certains fichiers/dossiers contre l'écriture/écrasement en passant tout en ro
Ah ok. Non, effectivement je ne suis pas dans ce cas. J'ai une commande à
lancer (une seule fois) et qui nécessite que / soit en read-only (temporairement
donc). Le mode recovery de Trusty répond parfaitement à mes besoins donc
mais pas celui de Jessie.
Quelques idées/pistes:
/var (ex: /var/run/*, var/log/*), /etc (ex: /etc/udev/rules.d/70*) et /tmp vont poser problème.
Déjà, tu peux mettre /tmp en tmpfs dans /etc/fstab
Utiliser 'noatime' dans /etc/fstab
# mount -no remount,ro /dev/sda1
// l'option 'n' pour ne pas toucher à /etc/mtab qui va se trouver du coup sur un système ro
$ fuser -v -m /
// Pour avoir une idée des processus qui utilisent le système de fichier /
$ lsof / | awk '$4 ~ /[0-9].*w/'
// Processus qui ont un fichier en cours d'écriture
// Chez moi, en mode single, je n'en ai que 2, hwdb et dhclient, si je les tue, ça marche.
Tuer des services susceptibles d'écrire, par exemple:
# service rsyslog stop
# service network-manager stop
# killall dhclient
# systemctl stop systemd-journald.socket
# systemctl stop systemd-journald.service
Ou tu peux essayer simplement:
# telinit 1
# mount -no remount,ro /
Ça fonctionne chez moi, cela peut sembler curieux.
J'ai regardé un peu, c'est "/lib/init/mount-functions.sh" qui positionne une variable $rootmode en la lisant dans 'fstab'. Ce fichier est sourcé par "/etc/init.d/checkroot.sh" qui, après avoir vérifié le système de fichier et s'être assuré qu'il est bien en read-only (on se demande un peu à quoi sert l'option du kernel), le bascule en rw le cas échéant. C'est donc checkroot.sh notre cible, et tu pourrais écraser la variable $rootmode, mais il te faudrait une condition, du genre si j'ai démarré en mode rescue, t'es à ro, sinon tu restes à rw.
En tout cas, il y a bien une différence booter directement en "single" ou booter en "multi" puis basculer en "single".
D'ailleurs, on peut noter que checkroot.sh et dans le niveau d'exécution S (pour start), donc qu'il n'est pas ré-exécuté quand on passe de 5 à 1.
Update: il est plus probable que ce script est ignoré et que le travail est fait par systemd-remount-fs.service.
Dans fstab, on a par défaut l'option "errors=remount-ro", j'ai une idée bête, créer une erreur délibérément (bon, je sais, no comment!).
Virtualbox ne fournirait-il pas des outils pour accéder/monter la partition à partir de l'hôte (sans booter la VM donc)? C'est possible avec VMWare par exemple.
Booter sur une iso Trusty en mode recovery, faire la manip.
Comparer les configurations de Trusty et Jessie et comprendre.
Voilà, bon courage (surtout si tu te lances dans le dernier point ;) )
Quelques idées/pistes:
/var (ex: /var/run/*, var/log/*), /etc (ex: /etc/udev/rules.d/70*) et /tmp vont poser problème.
Déjà, tu peux mettre /tmp en tmpfs dans /etc/fstab
Utiliser 'noatime' dans /etc/fstab
# mount -no remount,ro /dev/sda1
// l'option 'n' pour ne pas toucher à /etc/mtab qui va se trouver du coup sur un système ro
$ fuser -v -m /
// Pour avoir une idée des processus qui utilisent le système de fichier /
$ lsof / | awk '$4 ~ /[0-9].*w/'
// Processus qui ont un fichier en cours d'écriture
// Chez moi, en mode single, je n'en ai que 2, hwdb et dhclient, si je les tue, ça marche.
Tuer des services susceptibles d'écrire, par exemple:
# service rsyslog stop
# service network-manager stop
# killall dhclient
# systemctl stop systemd-journald.socket
# systemctl stop systemd-journald.service
Ou tu peux essayer simplement:
# telinit 1
# mount -no remount,ro /
Ça fonctionne chez moi, cela peut sembler curieux.
J'ai regardé un peu, c'est "/lib/init/mount-functions.sh" qui positionne une variable $rootmode en la lisant dans 'fstab'. Ce fichier est sourcé par "/etc/init.d/checkroot.sh" qui, après avoir vérifié le système de fichier et s'être assuré qu'il est bien en read-only (on se demande un peu à quoi sert l'option du kernel), le bascule en rw le cas échéant. C'est donc checkroot.sh notre cible, et tu pourrais écraser la variable $rootmode, mais il te faudrait une condition, du genre si j'ai démarré en mode rescue, t'es à ro, sinon tu restes à rw.
En tout cas, il y a bien une différence booter directement en "single" ou booter en "multi" puis basculer en "single".
D'ailleurs, on peut noter que checkroot.sh et dans le niveau d'exécution S (pour start), donc qu'il n'est pas ré-exécuté quand on passe de 5 à 1.
Update: il est plus probable que ce script est ignoré et que le travail est fait par systemd-remount-fs.service.
Dans fstab, on a par défaut l'option "errors=remount-ro", j'ai une idée bête, créer une erreur délibérément (bon, je sais, no comment!).
Virtualbox ne fournirait-il pas des outils pour accéder/monter la partition à partir de l'hôte (sans booter la VM donc)? C'est possible avec VMWare par exemple.
Booter sur une iso Trusty en mode recovery, faire la manip.
Comparer les configurations de Trusty et Jessie et comprendre.
Voilà, bon courage (surtout si tu te lances dans le dernier point ;) )
Quelques idées/pistes:
/var (ex: /var/run/*, var/log/*), /etc (ex: /etc/udev/rules.d/70*) et /tmp vont poser problème.
Déjà, tu peux mettre /tmp en tmpfs dans /etc/fstab
Utiliser 'noatime' dans /etc/fstab
# mount -no remount,ro /dev/sda1
// l'option 'n' pour ne pas toucher à /etc/mtab qui va se trouver du coup sur un système ro
$ fuser -v -m /
// Pour avoir une idée des processus qui utilisent le système de fichier /
$ lsof / | awk '$4 ~ /[0-9].*w/'
// Processus qui ont un fichier en cours d'écriture
// Chez moi, en mode single, je n'en ai que 2, hwdb et dhclient, si je les tue, ça marche.
Tuer des services susceptibles d'écrire, par exemple:
# service rsyslog stop
# service network-manager stop
# killall dhclient
# systemctl stop systemd-journald.socket
# systemctl stop systemd-journald.service
Ou tu peux essayer simplement:
# telinit 1
# mount -no remount,ro /
Ça fonctionne chez moi, cela peut sembler curieux.
J'ai regardé un peu, c'est "/lib/init/mount-functions.sh" qui positionne une variable $rootmode en la lisant dans 'fstab'. Ce fichier est sourcé par "/etc/init.d/checkroot.sh" qui, après avoir vérifié le système de fichier et s'être assuré qu'il est bien en read-only (on se demande un peu à quoi sert l'option du kernel), le bascule en rw le cas échéant. C'est donc checkroot.sh notre cible, et tu pourrais écraser la variable $rootmode, mais il te faudrait une condition, du genre si j'ai démarré en mode rescue, t'es à ro, sinon tu restes à rw.
En tout cas, il y a bien une différence booter directement en "single" ou booter en "multi" puis basculer en "single".
D'ailleurs, on peut noter que checkroot.sh et dans le niveau d'exécution S (pour start), donc qu'il n'est pas ré-exécuté quand on passe de 5 à 1.
Update: il est plus probable que ce script est ignoré et que le travail est fait par systemd-remount-fs.service.
Dans fstab, on a par défaut l'option "errors=remount-ro", j'ai une idée bête, créer une erreur délibérément (bon, je sais, no comment!).
Virtualbox ne fournirait-il pas des outils pour accéder/monter la partition à partir de l'hôte (sans booter la VM donc)? C'est possible avec VMWare par exemple.
Booter sur une iso Trusty en mode recovery, faire la manip.
Comparer les configurations de Trusty et Jessie et comprendre.
Voilà, bon courage (surtout si tu te lances dans le dernier point ;) )
