Quelqu'un a-t-il deja essaye de faire tourner un BSD sur un stick usb
en read-only ?
En fait j'aimerais bien faire un systeme minimal qui tiendrait sur 64
ou 128 mo et qui permettrait de faire des diagnostiques reseau, voire
des demos de pf dans le cas d'openbsd. Bien sur tout ceci utiliserait
la memoire vive pour les partitions en ecriture.
On Wed, 19 May 2004 18:06:35 +0200 (Emmanuel Dreyfus) wrote:
En revanche je m'interroge sur la façon dont le bootloader d'open (un brin psychorigide) peut encaisser l'amorçage sur clef usb. Avec syslinux+ memdisk j'arrive à amorcer (sur ce media) linux + freebsd (en dual boot!), mais pas moyen de lancer un open (même avec l'amorçeur dernier cri de 3.5). Bref je saisi l'occasion pour demander conseil sur le sujet. Si quelqu'un à une idée sur la façon de faire coopérer syslinux/memdisk et open (et netb aussi) j'adorerai en savoir plus.
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un MBR et tout le toutim, on est dans les sentiers battus...
C'est vu comme un disque scsi :
umass0 at uhub1 port 1 configuration 1 interface 0 umass0: TTI-MSA USB 2.0 Mobile Disk, rev 1.10/1.00, addr 2 umass0: using SCSI over Bulk-Only scsibus2 at umass0: 2 targets sd0 at scsibus2 targ 1 lun 0: <USB 2.0, Mobile Disk, > SCSI2 0/direct removable sd0: 246MB, 246 cyl, 64 head, 32 sec, 512 bytes/sec, 503808 sec total
mips
On Wed, 19 May 2004 18:06:35 +0200
manu@netbsd.org (Emmanuel Dreyfus) wrote:
En revanche je m'interroge sur la façon dont le bootloader d'open
(un brin psychorigide) peut encaisser l'amorçage sur clef usb.
Avec syslinux+ memdisk j'arrive à amorcer (sur ce media) linux +
freebsd (en dual boot!), mais pas moyen de lancer un open (même
avec l'amorçeur dernier cri de 3.5). Bref je saisi l'occasion pour
demander conseil sur le sujet. Si quelqu'un à une idée sur la
façon de faire coopérer syslinux/memdisk et open (et netb aussi)
j'adorerai en savoir plus.
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un
MBR et tout le toutim, on est dans les sentiers battus...
C'est vu comme un disque scsi :
umass0 at uhub1 port 1 configuration 1 interface 0
umass0: TTI-MSA USB 2.0 Mobile Disk, rev 1.10/1.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets
sd0 at scsibus2 targ 1 lun 0: <USB 2.0, Mobile Disk, > SCSI2 0/direct removable
sd0: 246MB, 246 cyl, 64 head, 32 sec, 512 bytes/sec, 503808 sec total
On Wed, 19 May 2004 18:06:35 +0200 (Emmanuel Dreyfus) wrote:
En revanche je m'interroge sur la façon dont le bootloader d'open (un brin psychorigide) peut encaisser l'amorçage sur clef usb. Avec syslinux+ memdisk j'arrive à amorcer (sur ce media) linux + freebsd (en dual boot!), mais pas moyen de lancer un open (même avec l'amorçeur dernier cri de 3.5). Bref je saisi l'occasion pour demander conseil sur le sujet. Si quelqu'un à une idée sur la façon de faire coopérer syslinux/memdisk et open (et netb aussi) j'adorerai en savoir plus.
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un MBR et tout le toutim, on est dans les sentiers battus...
C'est vu comme un disque scsi :
umass0 at uhub1 port 1 configuration 1 interface 0 umass0: TTI-MSA USB 2.0 Mobile Disk, rev 1.10/1.00, addr 2 umass0: using SCSI over Bulk-Only scsibus2 at umass0: 2 targets sd0 at scsibus2 targ 1 lun 0: <USB 2.0, Mobile Disk, > SCSI2 0/direct removable sd0: 246MB, 246 cyl, 64 head, 32 sec, 512 bytes/sec, 503808 sec total
mips
manu
Miod Vallat wrote:
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un MBR et tout le toutim, on est dans les sentiers battus... C'est vu comme un disque scsi :
Ça tombe bien, ATAPI c'est grosso modo SCSI-over-ATA ...
Voila, je n'enfonce pas le clou plus loin: il ne depasse déjà plus de la table.
-- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Miod Vallat <miod@online.fr> wrote:
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un
MBR et tout le toutim, on est dans les sentiers battus...
C'est vu comme un disque scsi :
Ça tombe bien, ATAPI c'est grosso modo SCSI-over-ATA ...
Voila, je n'enfonce pas le clou plus loin: il ne depasse déjà plus de la
table.
--
Emmanuel Dreyfus
A lire: 240 pages en français sur l'administration UNIX avec BSD
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un MBR et tout le toutim, on est dans les sentiers battus... C'est vu comme un disque scsi :
Ça tombe bien, ATAPI c'est grosso modo SCSI-over-ATA ...
Voila, je n'enfonce pas le clou plus loin: il ne depasse déjà plus de la table.
-- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Benjamin Pineau
Le Wed, 19 May 2004 18:06:35 +0200, Emmanuel Dreyfus écrivais:
Ben en fait le problème ne se pose que sur OpenBSD: Sous FreeBSD il y a
Et FreeBSD < 5 j'imagine...
un devfs, et sous NetBSD, si /dev/console est absent, init créé un ramdisk avec les devices dedans, monté sur /dev
Joli !
Par contre j'ai essayé avec un mount_union (qui aurait été à priori plus propre), c'est instable. Sans doute ai-je oublié quelque chose ?
Ben ecoute, chez moi ca marche très bien (NetBSD 1.6.2)
Joli (encore) !
cri de 3.5). Bref je saisi l'occasion pour demander conseil sur le sujet. Si quelqu'un à une idée sur la façon de faire coopérer syslinux/memdisk et open (et netb aussi) j'adorerai en savoir plus.
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un MBR et tout le toutim, on est dans les sentiers battus...
Ok j'avoue je n'ai pas essayé de l'amorcer directement et j'ai voulu discretement profiter de l'occasion pour demander un coup de main sur syslinux->memdisk->{open,net}bsd. Pfff vous étes trop attentifs ;)
Le Wed, 19 May 2004 18:06:35 +0200,
Emmanuel Dreyfus <manu@netbsd.org> écrivais:
Ben en fait le problème ne se pose que sur OpenBSD: Sous FreeBSD il y a
Et FreeBSD < 5 j'imagine...
un devfs, et sous NetBSD, si /dev/console est absent, init créé un
ramdisk avec les devices dedans, monté sur /dev
Joli !
Par contre j'ai essayé avec un mount_union (qui aurait été à priori plus
propre), c'est instable. Sans doute ai-je oublié quelque chose ?
Ben ecoute, chez moi ca marche très bien (NetBSD 1.6.2)
Joli (encore) !
cri de 3.5). Bref je saisi l'occasion pour demander conseil sur le sujet.
Si quelqu'un à une idée sur la façon de faire coopérer syslinux/memdisk et
open (et netb aussi) j'adorerai en savoir plus.
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un MBR
et tout le toutim, on est dans les sentiers battus...
Ok j'avoue je n'ai pas essayé de l'amorcer directement et j'ai voulu
discretement profiter de l'occasion pour demander un coup de main sur
syslinux->memdisk->{open,net}bsd. Pfff vous étes trop attentifs ;)
Le Wed, 19 May 2004 18:06:35 +0200, Emmanuel Dreyfus écrivais:
Ben en fait le problème ne se pose que sur OpenBSD: Sous FreeBSD il y a
Et FreeBSD < 5 j'imagine...
un devfs, et sous NetBSD, si /dev/console est absent, init créé un ramdisk avec les devices dedans, monté sur /dev
Joli !
Par contre j'ai essayé avec un mount_union (qui aurait été à priori plus propre), c'est instable. Sans doute ai-je oublié quelque chose ?
Ben ecoute, chez moi ca marche très bien (NetBSD 1.6.2)
Joli (encore) !
cri de 3.5). Bref je saisi l'occasion pour demander conseil sur le sujet. Si quelqu'un à une idée sur la façon de faire coopérer syslinux/memdisk et open (et netb aussi) j'adorerai en savoir plus.
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un MBR et tout le toutim, on est dans les sentiers battus...
Ok j'avoue je n'ai pas essayé de l'amorcer directement et j'ai voulu discretement profiter de l'occasion pour demander un coup de main sur syslinux->memdisk->{open,net}bsd. Pfff vous étes trop attentifs ;)
Arnaud Launay
Le Wed, 19 May 2004 22:39:10 +0200, mips écrivit:
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un> MBR et tout le toutim, on est dans les sentiers battus...
C'est vu comme un disque scsi : Ça tombe bien, ATAPI c'est grosso modo SCSI-over-ATA ...
L'usb passe par l'interface ATA ?
Je vais peut-etre dire une connerie, mais il me semble bien que le protocole utilise par les clefs usb faisant storage, c'est de l'ata.
Arnaud.
Le Wed, 19 May 2004 22:39:10 +0200, mips écrivit:
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec
un> MBR et tout le toutim, on est dans les sentiers battus...
C'est vu comme un disque scsi :
Ça tombe bien, ATAPI c'est grosso modo SCSI-over-ATA ...
L'usb passe par l'interface ATA ?
Je vais peut-etre dire une connerie, mais il me semble bien que
le protocole utilise par les clefs usb faisant storage, c'est de l'ata.
Ben une clé USB, c'est vu comme un disque ATAPI, non? Donc avec un> MBR et tout le toutim, on est dans les sentiers battus...
C'est vu comme un disque scsi :
Ça tombe bien, ATAPI c'est grosso modo SCSI-over-ATA ...
L'usb passe par l'interface ATA ?
Non, mais en relisant lentement, tu y verra mieux (indice : ATA est un protocole).
Thierry Boudet
On 2004-05-19, Miod Vallat wrote:
A l'heure actuelle, on peut raisonnablement considérer qu'un unionfs dont un seul des systèmes de fichiers considérés est monté avec accès en écriture, est stable.
Donc, monter un union par dessus un cdrom, modifier quelques
fichiers, et refaire l'image ISO de l'union peut fonctionner? J'essayerais ça entre deux glandages IRC, alors...
-- Bien plus zen que le Contrat Social, et ouvert à tous: http://tth.vaboofer.com/Cette/cafe_social.html
On 2004-05-19, Miod Vallat <miod@online.fr> wrote:
A l'heure actuelle, on peut raisonnablement considérer qu'un unionfs
dont un seul des systèmes de fichiers considérés est monté avec accès en
écriture, est stable.
Donc, monter un union par dessus un cdrom, modifier quelques
fichiers, et refaire l'image ISO de l'union peut fonctionner?
J'essayerais ça entre deux glandages IRC, alors...
--
Bien plus zen que le Contrat Social, et ouvert à tous:
http://tth.vaboofer.com/Cette/cafe_social.html
A l'heure actuelle, on peut raisonnablement considérer qu'un unionfs dont un seul des systèmes de fichiers considérés est monté avec accès en écriture, est stable.
Donc, monter un union par dessus un cdrom, modifier quelques
fichiers, et refaire l'image ISO de l'union peut fonctionner? J'essayerais ça entre deux glandages IRC, alors...
-- Bien plus zen que le Contrat Social, et ouvert à tous: http://tth.vaboofer.com/Cette/cafe_social.html
Miod Vallat
Donc, monter un union par dessus un cdrom, modifier quelques fichiers, et refaire l'image ISO de l'union peut fonctionner? J'essayerais ça entre deux glandages IRC, alors...
Attention à ne pas dépasser 650MB non plus (-:
Donc, monter un union par dessus un cdrom, modifier quelques
fichiers, et refaire l'image ISO de l'union peut fonctionner?
J'essayerais ça entre deux glandages IRC, alors...
Donc, monter un union par dessus un cdrom, modifier quelques fichiers, et refaire l'image ISO de l'union peut fonctionner? J'essayerais ça entre deux glandages IRC, alors...
Attention à ne pas dépasser 650MB non plus (-:
Nicolas Le Scouarnec
A l'heure actuelle, on peut raisonnablement considérer qu'un unionfs dont un seul des systèmes de fichiers considérés est monté avec accès en écriture, est stable.
Mouais, enfin, je pouvais juste y écrire par ailleurs ;-) mais a la base, il est ro la couche du dessus a l'intérieur d'une prison... Donc, je comprends que je peux, pour le moment abandonner l'espoir de mon feuilleté au fromage^W^Wà l'ognion, et me rabattre sur une bonne pate brisée, ca va etre plus lourd...
Le seul exemple de montage de type union vraiment stable, à ma connaissance, est le TVFS d'OS/2, qui en plus du système d'union dispose également de la notion de priorité des montages, afin de mieux répartir les opérations d'écriture. Malheureusement, le code n'est pas public ;
Hum ? La, j'ai:
----------> RW --------| /jail/usr/ports | | avec au dessous |-> RO ----------> RW /usr/ports
Donc je ne peux qu'écrire via un chemin sur un FS, j'ai a priori pas de probleme de priorité d'écritures, non ?
-- Nicolas Le Scouarnec
A l'heure actuelle, on peut raisonnablement considérer qu'un unionfs
dont un seul des systèmes de fichiers considérés est monté avec accès en
écriture, est stable.
Mouais, enfin, je pouvais juste y écrire par ailleurs ;-) mais a la base, il
est ro la couche du dessus a l'intérieur d'une prison... Donc, je
comprends que je peux, pour le moment abandonner l'espoir de mon
feuilleté au fromage^W^Wà l'ognion, et me rabattre sur une bonne pate
brisée, ca va etre plus lourd...
Le seul exemple de montage de type union vraiment stable, à ma
connaissance, est le TVFS d'OS/2, qui en plus du système d'union dispose
également de la notion de priorité des montages, afin de mieux répartir
les opérations d'écriture. Malheureusement, le code n'est pas public ;
Hum ? La, j'ai:
----------> RW
--------| /jail/usr/ports
|
| avec au dessous
|-> RO
----------> RW /usr/ports
Donc je ne peux qu'écrire via un chemin sur un FS, j'ai a priori pas de
probleme de priorité d'écritures, non ?
A l'heure actuelle, on peut raisonnablement considérer qu'un unionfs dont un seul des systèmes de fichiers considérés est monté avec accès en écriture, est stable.
Mouais, enfin, je pouvais juste y écrire par ailleurs ;-) mais a la base, il est ro la couche du dessus a l'intérieur d'une prison... Donc, je comprends que je peux, pour le moment abandonner l'espoir de mon feuilleté au fromage^W^Wà l'ognion, et me rabattre sur une bonne pate brisée, ca va etre plus lourd...
Le seul exemple de montage de type union vraiment stable, à ma connaissance, est le TVFS d'OS/2, qui en plus du système d'union dispose également de la notion de priorité des montages, afin de mieux répartir les opérations d'écriture. Malheureusement, le code n'est pas public ;
Hum ? La, j'ai:
----------> RW --------| /jail/usr/ports | | avec au dessous |-> RO ----------> RW /usr/ports
Donc je ne peux qu'écrire via un chemin sur un FS, j'ai a priori pas de probleme de priorité d'écritures, non ?
