Le Sun, 15 Apr 2018 12:38:21 +0200, Pascal Hambourg a écrit :
Penser à enlever l'option "ro" par la même occasion, ça évitera de devoir remonter la racine en lecture-écriture.
Toujours vérifier le support avant de le monter (particulièrement après un crash)
Quel support ?
Hugolino
Le 15-04-2018, Jo Engo a écrit :
Le Sat, 14 Apr 2018 23:08:43 +0200, Hugolino a écrit :
Ça ne marche plus de booter avec init=/bin/bash dans la ligne de commande de grub ? J'ai fait ça il y a longtemps.
Avant initramfs, peut-être ?
Sans doute... -- J'ai appris qu'il était question de mettre la gestion du système solaire sous Linux, c'est Dieu qui va etre content. Hugo (né il y a 1 703 444 126 secondes)
Le 15-04-2018, Jo Engo <yl@icite.fr> a écrit :
Le Sat, 14 Apr 2018 23:08:43 +0200, Hugolino a écrit :
Ça ne marche plus de booter avec init=/bin/bash dans la ligne de
commande de grub ?
J'ai fait ça il y a longtemps.
Avant initramfs, peut-être ?
Sans doute...
--
J'ai appris qu'il était question de mettre la gestion du système
solaire sous Linux, c'est Dieu qui va etre content.
Hugo (né il y a 1 703 444 126 secondes)
Le Sat, 14 Apr 2018 23:08:43 +0200, Hugolino a écrit :
Ça ne marche plus de booter avec init=/bin/bash dans la ligne de commande de grub ? J'ai fait ça il y a longtemps.
Avant initramfs, peut-être ?
Sans doute... -- J'ai appris qu'il était question de mettre la gestion du système solaire sous Linux, c'est Dieu qui va etre content. Hugo (né il y a 1 703 444 126 secondes)
Jo Engo
Le Tue, 17 Apr 2018 19:39:05 +0200, Pascal Hambourg a écrit :
Toujours vérifier le support avant de le monter (particulièrement après un crash)
Quel support ?
le système de fichier. Je propose de faire fsck /dev/sdx1 avant de monter sdx1
Le Tue, 17 Apr 2018 19:39:05 +0200, Pascal Hambourg a écrit :
Toujours vérifier le support avant de le monter (particulièrement après
un crash)
Quel support ?
le système de fichier. Je propose de faire fsck /dev/sdx1 avant de monter
sdx1
Le Tue, 17 Apr 2018 19:39:05 +0200, Pascal Hambourg a écrit :
Toujours vérifier le support avant de le monter (particulièrement après un crash)
Quel support ?
le système de fichier. Je propose de faire fsck /dev/sdx1 avant de monter sdx1
Pascal Hambourg
Le 17/04/2018 à 22:33, Jo Engo a écrit :
Le Tue, 17 Apr 2018 19:39:05 +0200, Pascal Hambourg a écrit :
Toujours vérifier le support avant de le monter (particulièrement après un crash)
Quel support ?
le système de fichier. Je propose de faire fsck /dev/sdx1 avant de monter sdx1
On parle toujours de démarrer avec init=/bin/bash ? Quand on aura la main, le système de fichiers racine sera déjà monté (forcément, /bin/bash est sur la racine). Et il se peut que l'initramfs l'ait déjà vérifié. Celui de Debian le fait, quand le programme fsck.<filesystem> correspondant existe.
Le 17/04/2018 à 22:33, Jo Engo a écrit :
Le Tue, 17 Apr 2018 19:39:05 +0200, Pascal Hambourg a écrit :
Toujours vérifier le support avant de le monter (particulièrement après
un crash)
Quel support ?
le système de fichier. Je propose de faire fsck /dev/sdx1 avant de monter
sdx1
On parle toujours de démarrer avec init=/bin/bash ?
Quand on aura la main, le système de fichiers racine sera déjà monté
(forcément, /bin/bash est sur la racine). Et il se peut que l'initramfs
l'ait déjà vérifié. Celui de Debian le fait, quand le programme
fsck.<filesystem> correspondant existe.
Le Tue, 17 Apr 2018 19:39:05 +0200, Pascal Hambourg a écrit :
Toujours vérifier le support avant de le monter (particulièrement après un crash)
Quel support ?
le système de fichier. Je propose de faire fsck /dev/sdx1 avant de monter sdx1
On parle toujours de démarrer avec init=/bin/bash ? Quand on aura la main, le système de fichiers racine sera déjà monté (forcément, /bin/bash est sur la racine). Et il se peut que l'initramfs l'ait déjà vérifié. Celui de Debian le fait, quand le programme fsck.<filesystem> correspondant existe.
Jo Engo
Le Tue, 17 Apr 2018 23:29:27 +0200, Pascal Hambourg a écrit :
On parle toujours de démarrer avec init=/bin/bash ? Quand on aura la main, le système de fichiers racine sera déjà monté (forcément, /bin/bash est sur la racine).
En read only
Et il se peut que l'initramfs l'ait déjà vérifié.
Il se peut ?!
Celui de Debian le fait, quand le programme fsck.<filesystem> correspondant existe.
Ah bon si tu le dis.
Le Tue, 17 Apr 2018 23:29:27 +0200, Pascal Hambourg a écrit :
On parle toujours de démarrer avec init=/bin/bash ?
Quand on aura la main, le système de fichiers racine sera déjà monté
(forcément, /bin/bash est sur la racine).
En read only
Et il se peut que l'initramfs
l'ait déjà vérifié.
Il se peut ?!
Celui de Debian le fait, quand le programme
fsck.<filesystem> correspondant existe.
Le Tue, 17 Apr 2018 23:29:27 +0200, Pascal Hambourg a écrit :
On parle toujours de démarrer avec init=/bin/bash ? Quand on aura la main, le système de fichiers racine sera déjà monté (forcément, /bin/bash est sur la racine).
En read only
Et il se peut que l'initramfs l'ait déjà vérifié.
Il se peut ?!
Celui de Debian le fait, quand le programme fsck.<filesystem> correspondant existe.
Ah bon si tu le dis.
Pascal Hambourg
Le 18/04/2018 à 02:55, Jo Engo a écrit :
Le Tue, 17 Apr 2018 23:29:27 +0200, Pascal Hambourg a écrit :
On parle toujours de démarrer avec init=/bin/bash ? Quand on aura la main, le système de fichiers racine sera déjà monté (forcément, /bin/bash est sur la racine).
En read only
Pas forcément. Ça dépend de plein de chose. Sans initramfs, ça dépend de la présence du paramètre "ro" dans la ligne de commande du noyau. Avec un initramfs, ça dépend de ce que fait l'initramfs puisque c'est lui qui monte la racine avec les options qu'il veut, s'il prend en compte le paramètre "ro" ou l'ignore... Au passage, j'ai vu un cas où un système de fichiers ext4 ne pouvait pas être monté en lecture seule car il était dans un état incohérent et sa réparation nécessitait de rejouer le journal, ce qui était apparemment impossible en lecture seule.
Et il se peut que l'initramfs l'ait déjà vérifié.
Il se peut ?!
Ben oui, ce n'est pas garanti. Déjà, il faut qu'il y ait un initramfs. Ensuite, il faut que l'initramfs soit construit pour contenir et exécuter fsck sur le système de fichiers racine avant de le monter. Dans Debian, c'est apparu avec le paquet initramfs-tools de la version 8 (Jessie, ancienne stable). Je ne serais pas étonné qu'il y ait à peu près autant de générateurs d'initramfs que de distributions, voire plusieurs générateurs disponibles pour une même distribution donc rien ne garantit que ce soit le cas avec Mint, bien que dérivée d'Ubuntu qui est dérivée de Debian. Enfin, il faut que le programme fsck.* pour le type de système de fichiers existe est soit installé. Ce n'est pas toujours le cas. Par exemple NILFS2 (système de fichiers structuré en log adapté pour les supports de stockages à mémoire flash) n'en a pas encore.
Le 18/04/2018 à 02:55, Jo Engo a écrit :
Le Tue, 17 Apr 2018 23:29:27 +0200, Pascal Hambourg a écrit :
On parle toujours de démarrer avec init=/bin/bash ?
Quand on aura la main, le système de fichiers racine sera déjà monté
(forcément, /bin/bash est sur la racine).
En read only
Pas forcément. Ça dépend de plein de chose.
Sans initramfs, ça dépend de la présence du paramètre "ro" dans la ligne
de commande du noyau.
Avec un initramfs, ça dépend de ce que fait l'initramfs puisque c'est
lui qui monte la racine avec les options qu'il veut, s'il prend en
compte le paramètre "ro" ou l'ignore...
Au passage, j'ai vu un cas où un système de fichiers ext4 ne pouvait pas
être monté en lecture seule car il était dans un état incohérent et sa
réparation nécessitait de rejouer le journal, ce qui était apparemment
impossible en lecture seule.
Et il se peut que l'initramfs l'ait déjà vérifié.
Il se peut ?!
Ben oui, ce n'est pas garanti. Déjà, il faut qu'il y ait un initramfs.
Ensuite, il faut que l'initramfs soit construit pour contenir et
exécuter fsck sur le système de fichiers racine avant de le monter. Dans
Debian, c'est apparu avec le paquet initramfs-tools de la version 8
(Jessie, ancienne stable). Je ne serais pas étonné qu'il y ait à peu
près autant de générateurs d'initramfs que de distributions, voire
plusieurs générateurs disponibles pour une même distribution donc rien
ne garantit que ce soit le cas avec Mint, bien que dérivée d'Ubuntu qui
est dérivée de Debian. Enfin, il faut que le programme fsck.* pour le
type de système de fichiers existe est soit installé. Ce n'est pas
toujours le cas. Par exemple NILFS2 (système de fichiers structuré en
log adapté pour les supports de stockages à mémoire flash) n'en a pas
encore.
Le Tue, 17 Apr 2018 23:29:27 +0200, Pascal Hambourg a écrit :
On parle toujours de démarrer avec init=/bin/bash ? Quand on aura la main, le système de fichiers racine sera déjà monté (forcément, /bin/bash est sur la racine).
En read only
Pas forcément. Ça dépend de plein de chose. Sans initramfs, ça dépend de la présence du paramètre "ro" dans la ligne de commande du noyau. Avec un initramfs, ça dépend de ce que fait l'initramfs puisque c'est lui qui monte la racine avec les options qu'il veut, s'il prend en compte le paramètre "ro" ou l'ignore... Au passage, j'ai vu un cas où un système de fichiers ext4 ne pouvait pas être monté en lecture seule car il était dans un état incohérent et sa réparation nécessitait de rejouer le journal, ce qui était apparemment impossible en lecture seule.
Et il se peut que l'initramfs l'ait déjà vérifié.
Il se peut ?!
Ben oui, ce n'est pas garanti. Déjà, il faut qu'il y ait un initramfs. Ensuite, il faut que l'initramfs soit construit pour contenir et exécuter fsck sur le système de fichiers racine avant de le monter. Dans Debian, c'est apparu avec le paquet initramfs-tools de la version 8 (Jessie, ancienne stable). Je ne serais pas étonné qu'il y ait à peu près autant de générateurs d'initramfs que de distributions, voire plusieurs générateurs disponibles pour une même distribution donc rien ne garantit que ce soit le cas avec Mint, bien que dérivée d'Ubuntu qui est dérivée de Debian. Enfin, il faut que le programme fsck.* pour le type de système de fichiers existe est soit installé. Ce n'est pas toujours le cas. Par exemple NILFS2 (système de fichiers structuré en log adapté pour les supports de stockages à mémoire flash) n'en a pas encore.
Jo Engo
Le Wed, 18 Apr 2018 20:06:53 +0200, Pascal Hambourg a écrit :
Et il se peut que l'initramfs l'ait déjà vérifié.
Il se peut ?!
Ben oui, ce n'est pas garanti.
Oui mais bon comme «il se peut» que pas aussi, n'est-il pas plus prudent de vérifier le fichier racine ? En tout cas c'et la procédure recommandée pur netBSD, bon ok, ça a rien à voir, si ? -- Réfléchir, c'est nier ce que l'on croit. -+- Émile Chartier, dit Alain (1868-1951), Propos sur la religion -+-
Le Wed, 18 Apr 2018 20:06:53 +0200, Pascal Hambourg a écrit :
Et il se peut que l'initramfs l'ait déjà vérifié.
Il se peut ?!
Ben oui, ce n'est pas garanti.
Oui mais bon comme «il se peut» que pas aussi, n'est-il pas plus prudent
de vérifier le fichier racine ? En tout cas c'et la procédure recommandée
pur netBSD, bon ok, ça a rien à voir, si ?
--
Réfléchir, c'est nier ce que l'on croit.
-+- Émile Chartier, dit Alain (1868-1951), Propos sur la religion
-+-
Le Wed, 18 Apr 2018 20:06:53 +0200, Pascal Hambourg a écrit :
Et il se peut que l'initramfs l'ait déjà vérifié.
Il se peut ?!
Ben oui, ce n'est pas garanti.
Oui mais bon comme «il se peut» que pas aussi, n'est-il pas plus prudent de vérifier le fichier racine ? En tout cas c'et la procédure recommandée pur netBSD, bon ok, ça a rien à voir, si ? -- Réfléchir, c'est nier ce que l'on croit. -+- Émile Chartier, dit Alain (1868-1951), Propos sur la religion -+-
Nicolas George
Jo Engo , dans le message <pan$c9280$f4548d82$6ec50e5e$, a écrit :
Oui mais bon comme «il se peut» que pas aussi, n'est-il pas plus prudent de vérifier le fichier racine ?
Il serait surtout plus malin de vérifier ce que fait l'initrd particulier qu'on utilise.
Jo Engo , dans le message
<pan$c9280$f4548d82$6ec50e5e$c1f56f92@icite.fr>, a écrit :
Oui mais bon comme «il se peut» que pas aussi, n'est-il pas plus prudent
de vérifier le fichier racine ?
Il serait surtout plus malin de vérifier ce que fait l'initrd
particulier qu'on utilise.
Jo Engo , dans le message <pan$c9280$f4548d82$6ec50e5e$, a écrit :
Oui mais bon comme «il se peut» que pas aussi, n'est-il pas plus prudent de vérifier le fichier racine ?
Il serait surtout plus malin de vérifier ce que fait l'initrd particulier qu'on utilise.
Jo Engo
Le Thu, 19 Apr 2018 10:03:54 +0000, Nicolas George a écrit :
Il serait surtout plus malin de vérifier ce que fait l'initrd particulier qu'on utilise.
«L'utilisateur type de Debian n'aura pas à se soucier d'initrd parce qu'il est créé automatiquement dans la phase de post-installation de l'image du noyau. On peut quand même configurer le comportement de ce processus avec le fichier /etc/kernel-img.conf. Note: Si ça marche, ne touchez à rien.» avec ça on est rassuré ;)
Le Thu, 19 Apr 2018 10:03:54 +0000, Nicolas George a écrit :
Il serait surtout plus malin de vérifier ce que fait l'initrd
particulier qu'on utilise.
«L'utilisateur type de Debian n'aura pas à se soucier d'initrd parce
qu'il est créé automatiquement dans la phase de post-installation de
l'image du noyau. On peut quand même configurer le comportement de ce
processus avec le fichier /etc/kernel-img.conf. Note: Si ça marche, ne
touchez à rien.» avec ça on est rassuré ;)
Le Thu, 19 Apr 2018 10:03:54 +0000, Nicolas George a écrit :
Il serait surtout plus malin de vérifier ce que fait l'initrd particulier qu'on utilise.
«L'utilisateur type de Debian n'aura pas à se soucier d'initrd parce qu'il est créé automatiquement dans la phase de post-installation de l'image du noyau. On peut quand même configurer le comportement de ce processus avec le fichier /etc/kernel-img.conf. Note: Si ça marche, ne touchez à rien.» avec ça on est rassuré ;)
