Passant de Debian Squeeze à Debian Wheezy, je découvre que la commande dd
est désormais bloquée par un "device or ressource busy" lorsqu'elle est
appliquée à un périphérique dont le système de fichier est monté.
Cela empêche lilo de fonctionner sur une disquette (1).
Y a t'il un moyen de contourner ce blocage ?
Cordialement
Dominique.
(1) : lilo est un bon outil pour les systèmes embarqués, et les disquettes
sont de bon supports pédagogiques.
lilo utilise dd pour récupérer et modifier le {master, partition} boot record.
Cordialement
Dominique
Erwan David
Dominique MICOLLET écrivait :
Bonjour,
Erwan David wrote:
Ça me parait quand même un minimum d'empêcher d'écrire directement sur une partition montée...
Je sais bien que l'admin unix a le droit de se tirrer dans le pied avec un missile balistique, mais quand même !
C'est pourtant ce que doivent faire les installateurs de lanceur (lilo ou grub) pour modifier le {master, partition} boot record, et en même temps récupérer les adresses des secteurs du ou des noyaux.
Non, lilo ne va pas écrire dans sda1 (la partition montée, mais dans sda (le device).
Ça me parait quand même un minimum d'empêcher d'écrire directement sur
une partition montée...
Je sais bien que l'admin unix a le droit de se tirrer dans le pied avec
un missile balistique, mais quand même !
C'est pourtant ce que doivent faire les installateurs de lanceur (lilo ou
grub) pour modifier le {master, partition} boot record, et en même temps
récupérer les adresses des secteurs du ou des noyaux.
Non, lilo ne va pas écrire dans sda1 (la partition montée, mais dans
sda (le device).
Ça me parait quand même un minimum d'empêcher d'écrire directement sur une partition montée...
Je sais bien que l'admin unix a le droit de se tirrer dans le pied avec un missile balistique, mais quand même !
C'est pourtant ce que doivent faire les installateurs de lanceur (lilo ou grub) pour modifier le {master, partition} boot record, et en même temps récupérer les adresses des secteurs du ou des noyaux.
Non, lilo ne va pas écrire dans sda1 (la partition montée, mais dans sda (le device).
-- Les simplifications c'est trop compliqué
Pascal Hambourg
Salut,
Erwan David a écrit :
Non, lilo ne va pas écrire dans sda1 (la partition montée, mais dans sda (le device).
Ça dépend où on lui dit d'installer son amorce. Cela peut aussi être dans une partition. J'ai fait ça, jusqu'au jour où une nouvelle version de lilo me soutint mordicus que sda1 contenait un système de fichiers NTFS alors que c'était de l'ext2 et refusa de s'y installer.
Salut,
Erwan David a écrit :
Non, lilo ne va pas écrire dans sda1 (la partition montée, mais dans
sda (le device).
Ça dépend où on lui dit d'installer son amorce. Cela peut aussi être
dans une partition. J'ai fait ça, jusqu'au jour où une nouvelle version
de lilo me soutint mordicus que sda1 contenait un système de fichiers
NTFS alors que c'était de l'ext2 et refusa de s'y installer.
Non, lilo ne va pas écrire dans sda1 (la partition montée, mais dans sda (le device).
Ça dépend où on lui dit d'installer son amorce. Cela peut aussi être dans une partition. J'ai fait ça, jusqu'au jour où une nouvelle version de lilo me soutint mordicus que sda1 contenait un système de fichiers NTFS alors que c'était de l'ext2 et refusa de s'y installer.
Dominique MICOLLET
Bonjour,
Erwan David wrote:
Non, lilo ne va pas écrire dans sda1 (la partition montée, mais dans sda (le device).
Si. lilo va lire/écrire là où on le lui dit. Exemples d'extraits de lilo.conf : #pour une disquette non partitionnée boot=/dev/fd0 root=/dev/fd0
#pour un lanceur en partiton boot record qui sera lancé par le lanceur principal en master boot record boot=/dev/sda5 root=/dev/sda5
Le premier exemple ne fonctionne plus en Debian/Wheezy, alors qu'il a fonctionné auraparavant (a priori en Debian/Squeeze).
Je n'ai pas encore eu l'occasion de vérifier le deuxième.
Cordialement
Dominique
Bonjour,
Erwan David wrote:
Non, lilo ne va pas écrire dans sda1 (la partition montée, mais dans
sda (le device).
Si. lilo va lire/écrire là où on le lui dit.
Exemples d'extraits de lilo.conf :
#pour une disquette non partitionnée
boot=/dev/fd0
root=/dev/fd0
#pour un lanceur en partiton boot record qui sera lancé par le lanceur
principal en master boot record
boot=/dev/sda5
root=/dev/sda5
Le premier exemple ne fonctionne plus en Debian/Wheezy, alors qu'il a
fonctionné auraparavant (a priori en Debian/Squeeze).
Je n'ai pas encore eu l'occasion de vérifier le deuxième.
Non, lilo ne va pas écrire dans sda1 (la partition montée, mais dans sda (le device).
Si. lilo va lire/écrire là où on le lui dit. Exemples d'extraits de lilo.conf : #pour une disquette non partitionnée boot=/dev/fd0 root=/dev/fd0
#pour un lanceur en partiton boot record qui sera lancé par le lanceur principal en master boot record boot=/dev/sda5 root=/dev/sda5
Le premier exemple ne fonctionne plus en Debian/Wheezy, alors qu'il a fonctionné auraparavant (a priori en Debian/Squeeze).
Je n'ai pas encore eu l'occasion de vérifier le deuxième.
Cordialement
Dominique
Nicolas George
Dominique MICOLLET , dans le message <52525ac2$0$2043$, a écrit :
lilo utilise dd
Ça m'étonnerait. À part si c'est un script, on voit mal pourquoi un programme irait s'ennuyer à appeler un utilitaire externe pour lire ou écrire dans un fichier ou un périphérique.
Dominique MICOLLET , dans le message
<52525ac2$0$2043$426a74cc@news.free.fr>, a écrit :
lilo utilise dd
Ça m'étonnerait. À part si c'est un script, on voit mal pourquoi un
programme irait s'ennuyer à appeler un utilitaire externe pour lire ou
écrire dans un fichier ou un périphérique.
Dominique MICOLLET , dans le message <52525ac2$0$2043$, a écrit :
lilo utilise dd
Ça m'étonnerait. À part si c'est un script, on voit mal pourquoi un programme irait s'ennuyer à appeler un utilitaire externe pour lire ou écrire dans un fichier ou un périphérique.
Dominique MICOLLET
Bonjour,
Nicolas George wrote:
Ça m'étonnerait.
Je parle d'expérience. Je le prouverai d'ici peu :-)
À part si c'est un script, on voit mal pourquoi un programme irait s'ennuyer à appeler un utilitaire externe pour lire ou écrire dans un fichier ou un périphériquee,
En C, ça prend deux lignes : sprintf(Commande,"dd if=%s of=%s bsQ2 count=1n",fichier_source, peripherique_cible); system (Commande);
Ceci dit, si, comme je le pense, le noyau refuse l'accès à dd parce la partition est montée, un appel system open/write/read risque tout aussi bien d'échouer. Incidemment, je suis curieux de savoir comment est réalisé ce verrouillage, parce que cela permettrait peut-être de le contourner.
Cordialement
Dominique.
Bonjour,
Nicolas George wrote:
Ça m'étonnerait.
Je parle d'expérience. Je le prouverai d'ici peu :-)
À part si c'est un script, on voit mal pourquoi un
programme irait s'ennuyer à appeler un utilitaire externe pour lire ou
écrire dans un fichier ou un périphériquee,
En C, ça prend deux lignes :
sprintf(Commande,"dd if=%s of=%s bsQ2 count=1n",fichier_source,
peripherique_cible);
system (Commande);
Ceci dit, si, comme je le pense, le noyau refuse l'accès à dd parce la
partition est montée, un appel system open/write/read risque tout aussi bien
d'échouer.
Incidemment, je suis curieux de savoir comment est réalisé ce verrouillage,
parce que cela permettrait peut-être de le contourner.
Je parle d'expérience. Je le prouverai d'ici peu :-)
À part si c'est un script, on voit mal pourquoi un programme irait s'ennuyer à appeler un utilitaire externe pour lire ou écrire dans un fichier ou un périphériquee,
En C, ça prend deux lignes : sprintf(Commande,"dd if=%s of=%s bsQ2 count=1n",fichier_source, peripherique_cible); system (Commande);
Ceci dit, si, comme je le pense, le noyau refuse l'accès à dd parce la partition est montée, un appel system open/write/read risque tout aussi bien d'échouer. Incidemment, je suis curieux de savoir comment est réalisé ce verrouillage, parce que cela permettrait peut-être de le contourner.
Cordialement
Dominique.
Nicolas George
Dominique MICOLLET , dans le message <52526e5d$0$2031$, a écrit :
En C, ça prend deux lignes : sprintf(Commande,"dd if=%s of=%s bsQ2 count=1n",fichier_source, peripherique_cible); system (Commande);
Avec la gestion d'erreur, la protection contre les noms de fichiers bizarres, etc., qu'un programme sérieux se doit d'avoir, ça va prendre un peu plus que ça.
Et surtout, il faut avoir créé « fichier_source » préalablement, et c'est exactement aussi compliqué de le créer dans un fichier que de le mettre directement sur le device.
Ceci dit, si, comme je le pense, le noyau refuse l'accès à dd parce la partition est montée, un appel system open/write/read risque tout aussi bien d'échouer.
Oui.
Dominique MICOLLET , dans le message
<52526e5d$0$2031$426a74cc@news.free.fr>, a écrit :
En C, ça prend deux lignes :
sprintf(Commande,"dd if=%s of=%s bsQ2 count=1n",fichier_source,
peripherique_cible);
system (Commande);
Avec la gestion d'erreur, la protection contre les noms de fichiers
bizarres, etc., qu'un programme sérieux se doit d'avoir, ça va prendre un
peu plus que ça.
Et surtout, il faut avoir créé « fichier_source » préalablement, et c'est
exactement aussi compliqué de le créer dans un fichier que de le mettre
directement sur le device.
Ceci dit, si, comme je le pense, le noyau refuse l'accès à dd parce la
partition est montée, un appel system open/write/read risque tout aussi bien
d'échouer.
Dominique MICOLLET , dans le message <52526e5d$0$2031$, a écrit :
En C, ça prend deux lignes : sprintf(Commande,"dd if=%s of=%s bsQ2 count=1n",fichier_source, peripherique_cible); system (Commande);
Avec la gestion d'erreur, la protection contre les noms de fichiers bizarres, etc., qu'un programme sérieux se doit d'avoir, ça va prendre un peu plus que ça.
Et surtout, il faut avoir créé « fichier_source » préalablement, et c'est exactement aussi compliqué de le créer dans un fichier que de le mettre directement sur le device.
Ceci dit, si, comme je le pense, le noyau refuse l'accès à dd parce la partition est montée, un appel system open/write/read risque tout aussi bien d'échouer.
Oui.
Dominique MICOLLET
Bonjour,
Nicolas George wrote:
Avec la gestion d'erreur, la protection contre les noms de fichiers
...
directement sur le device.
La situation est toutefois particulière en ce sens qu'on lit ou écrit un "boot record" : il est à un endroit unique, hors système de fichier, et ce qu'on y écrit est immuable (pour une version de lilo). Je ne suis pas sûr que l'emploi d'open et cie serait plus sûr. En me relisant, je ne suis même pas certain que ce soit possible : open("/dev/sda5",...); est il valide ? lilo offre par ailleurs une option de test qui simule l'opération et permet à l'utilisateur de vérifier la validité du fichier de configuration. De toutes façons, installer un lanceur est une opération potentiellement léthale pour le système.
Cordialement
Dominique.
Bonjour,
Nicolas George wrote:
Avec la gestion d'erreur, la protection contre les noms de fichiers
...
directement sur le device.
La situation est toutefois particulière en ce sens qu'on lit ou écrit un
"boot record" : il est à un endroit unique, hors système de fichier, et ce
qu'on y écrit est immuable (pour une version de lilo).
Je ne suis pas sûr que l'emploi d'open et cie serait plus sûr.
En me relisant, je ne suis même pas certain que ce soit possible :
open("/dev/sda5",...);
est il valide ?
lilo offre par ailleurs une option de test qui simule l'opération et permet
à l'utilisateur de vérifier la validité du fichier de configuration.
De toutes façons, installer un lanceur est une opération potentiellement
léthale pour le système.
Avec la gestion d'erreur, la protection contre les noms de fichiers
...
directement sur le device.
La situation est toutefois particulière en ce sens qu'on lit ou écrit un "boot record" : il est à un endroit unique, hors système de fichier, et ce qu'on y écrit est immuable (pour une version de lilo). Je ne suis pas sûr que l'emploi d'open et cie serait plus sûr. En me relisant, je ne suis même pas certain que ce soit possible : open("/dev/sda5",...); est il valide ? lilo offre par ailleurs une option de test qui simule l'opération et permet à l'utilisateur de vérifier la validité du fichier de configuration. De toutes façons, installer un lanceur est une opération potentiellement léthale pour le système.
Cordialement
Dominique.
Fred
- Lilo s'utilise presque systématiquement sur une partition montée. - Techniquement, un MBR n'est jamais monté, uniquement un PBR. - je viens de tester dd en écriture sur une partition montée, ça marche (slack 13)
As-tu executé lilo ou seulement dd? As-tu tester dd sur autre chose que ta disquette. N'as-tu pas enchainer des commandes vers ta disquette sans attendre que la précédente soit terminée?
- Lilo s'utilise presque systématiquement sur une partition montée.
- Techniquement, un MBR n'est jamais monté, uniquement un PBR.
- je viens de tester dd en écriture sur une partition montée,
ça marche (slack 13)
As-tu executé lilo ou seulement dd?
As-tu tester dd sur autre chose que ta disquette.
N'as-tu pas enchainer des commandes vers ta disquette sans
attendre que la précédente soit terminée?
- Lilo s'utilise presque systématiquement sur une partition montée. - Techniquement, un MBR n'est jamais monté, uniquement un PBR. - je viens de tester dd en écriture sur une partition montée, ça marche (slack 13)
As-tu executé lilo ou seulement dd? As-tu tester dd sur autre chose que ta disquette. N'as-tu pas enchainer des commandes vers ta disquette sans attendre que la précédente soit terminée?
Fred
On 07/10/2013 10:43, Dominique MICOLLET wrote:
En me relisant, je ne suis même pas certain que ce soit possible : open("/dev/sda5",...); est il valide ?
C'est completement valide et c'est justement tout l'interet des péripheriques unix: les voir comme de simples fichiers.
On 07/10/2013 10:43, Dominique MICOLLET wrote:
En me relisant, je ne suis même pas certain que ce soit possible :
open("/dev/sda5",...);
est il valide ?
C'est completement valide et c'est justement tout l'interet des
péripheriques unix: les voir comme de simples fichiers.
