[9fans] Install: root file system

[9fans] Install: root file system

[tlaronde]

Hello,

As explained in a previous message, I try to install Plan9 on a new node
(previous one defunct).

I have tried the usb Bell Labs and 9 atom flavours, and none works on my
node.

The Bell Labs iso works (I mean it boots and the install starts) but
9pcflop doesn't recognize my disks (while 9load lists them correctly).

So I'm back to what I had already done: I sketch a Plan9 partition from
NetBSD, setting a bootable FAT and populate it. 9pcdisk recognizes my
disk but there is the problem of the root file system---an initial one,
so that I can make the install from 9pcdisk and not 9pcflop.

I have populated the 9fat with what is indicated in the proto. But there
are binaries not in the iso image (bargraph, tailfsrv and a few others).

So I have extracted the embedded root.bz2 from 9pcflop (found in
bootdisk.img on the ISO) with the help of grep, od (because there are
nulls to have the correct offset) and dd.

The problem is that this is not only bzip2'ed, but previously bflz'ed. I
can even not add the bflz binary to the FAT, since there is no such
binary on the  ISO.

The questions are the following:

1) Is it possible to specify as bootargs the 9fat as the root
filesystem? If yes, what is the plan9.ini syntax (I tried
local!#S/sdE2/9fat, but this is not it...);

2) Is it possible to give the root.bz2 as a filesystem to a vanilla
kernel (here 9pcdisk)? Does it have the code to load it in memory, or
can I cat 9pcdisk with the root.bz2 (with the sentry "bzfilesystem")
like what is done with 9pcflop?

3) Can such a root file be served, if nothing local work, as a root file
system for a DHCP request?

TIA
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Install: root file system

[erik quanstrom]

i'm not sure what the root cause of your problem is, due to not enough data,
but it does remind me of a limitation that has been bugging me.

to boot from usb cleanly, i added a bit to the boot process that creates a loopback
sd device /dev/sdu0 that points to the usb disk device.  i've been booting my auth
server this way for some time.

it seems to me that i really screwed this up.  what i really want is a sd device
that always points to the boot drive, the one bios refers to as 0x80.
givem this, one can then put something like "bootargs=local!#S/sdB0/fs"
in plan9.ini.  this will allow the 9atom usb install image to run off any bootable
media (for which we have drivers).

so, i'm preparing a patch that will present the boot device as /dev/sdB0 regardless
of what underlying disk driver or protocol is being used.  here's the output from
my test machine.  it's been booted over the network, but even so bios has assigned
a 0x80 drive, and it's been found and configured:

>>	sdB loop #S/sdF0/data
	sdE ahci ahci port 0xfffffe00fb538000 pci 0.17.4: 64a ncq alp led clo pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 4 ghc 80000002 isr 0 pi f 0-3 ver 10300
	sdF ahci ahci port 0xfffffe00fb532000 pci 0.31.2: 64a ncq alp led clo pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 6 ghc 80000002 isr 0 pi 3f 0-5 ver 10300
	sdN nvme port 0xfffffe00fb410000 pci 2.0.0 v1.0 rst 0 ctg 1 ams 0 stride 1 to 20000 fatal 0
	sdO nvme port 0xfffffe00fb300000 pci 4.0.0 v1.1 rst 0 ctg 1 ams 0 stride 1 to 30000 fatal 0

- erik

Re: [9fans] Install: root file system

[tlaronde]

On Sat, Jan 02, 2016 at 04:26:39PM -0800, erik quanstrom wrote:
> i'm not sure what the root cause of your problem is,

I'm now suspecting that the underlying problem is that a 9fat is a dos,
but that is a special dos: part of a plan9 slice, so whether kfs or
fossil supplementary partitions are expected.

I have changed the MBR identifier to big FAT16 (6) and in this case
9load doesn't find a Plan9 slice and ask for a kernel, the
sdE2!dos!9pcdisk.gz is OK (but it panics after since it doesn't ask for
a plan9.ini).

> due to not enough data,
> but it does remind me of a limitation that has been bugging me.
>
> to boot from usb cleanly, i added a bit to the boot process that creates a loopback
> sd device /dev/sdu0 that points to the usb disk device.  i've been booting my auth
> server this way for some time.
>

The idea is interesting.

Another idea/question appeared to me: could it be possible to add a
device identifier #<some_code_point> to the booting device or publish it
in the name space under /boot?

Corollary: when an embedded bzfilesystem ships with the kernel, is there
an device identifier that allows to access it? (From a cursory look at
the proto, it seems that the file is published under /boot, but since
the 9pcflop has no the sdiahci drivers, I try to simply catenate the
9pccd---or 9pcdisk FWIW---with the root.bz2 extracted, guessing that
this is 9load task to arrange the loading, but I didn't find a way to
access it directly from kernel hierarchy, since it is not visible in
namespace).

> it seems to me that i really screwed this up.  what i really want is a sd device
> that always points to the boot drive, the one bios refers to as 0x80.
> givem this, one can then put something like "bootargs=local!#S/sdB0/fs"
> in plan9.ini.  this will allow the 9atom usb install image to run off any bootable
> media (for which we have drivers).
>

:-) This has always been the "pleasure" of the bootstrapping procedure
in the PC world. If I understand correctly, it is normal on other
architectures to pass through the bios to access some hardware. With the
PC, there is the limitation of the interface and, essentially, the real
mode problem.

But it is indeed a bit frustating to see devices accessed at booting
(hurrah! my hardware is recognized!) and suddenly not recognized (when
the BIOS is not used anymore and the kernel is on is own without the
drivers)...

Related question (for whoever has an answer): unfortunately my node has
only a PS2 combo, so that I could, theoretically, have whether a PS2
mouse xor a PS2 keyboard. In fact, when the mouse and keyboard are both
connected via USB, 9pcflop has no problem: I have keyboard and mouse
(BIOS emulating PS2 interfaces). If I use 9pccd or 9pcdisk, I loose the
keyboard (and don't have the mouse if it is connected to USB).

So it seems I could have a running Plan9 (it works for mouse and
keyboard attached via usb with 9pcflop, but 9pcflop doesn't recognize
the SATA/AHCI disks; 9pccd or 9pcdisk recognize the sdiahci, but don't
recognize the usb mouse and keyboard; I hope a synthesis is possible
with the "best" of all worlds)? But what does the usb attachment work
with 9pcflop for mouse and keyboard and doesn't work for the
others---perhaps because 9pcflop doesn't recognize usb and hence fall
back to a PS2 BIOS provided interface?

> so, i'm preparing a patch that will present the boot device as /dev/sdB0 regardless
> of what underlying disk driver or protocol is being used.  here's the output from
> my test machine.  it's been booted over the network, but even so bios has assigned
> a 0x80 drive, and it's been found and configured:
>
> >>	sdB loop #S/sdF0/data
> 	sdE ahci ahci port 0xfffffe00fb538000 pci 0.17.4: 64a ncq alp led clo pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 4 ghc 80000002 isr 0 pi f 0-3 ver 10300
> 	sdF ahci ahci port 0xfffffe00fb532000 pci 0.31.2: 64a ncq alp led clo pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 6 ghc 80000002 isr 0 pi 3f 0-5 ver 10300
> 	sdN nvme port 0xfffffe00fb410000 pci 2.0.0 v1.0 rst 0 ctg 1 ams 0 stride 1 to 20000 fatal 0
> 	sdO nvme port 0xfffffe00fb300000 pci 4.0.0 v1.1 rst 0 ctg 1 ams 0 stride 1 to 30000 fatal 0
>

That's interesting!

For the mean time, I guess I will have to put an unix to serve 9P for a
locally loaded kernel---but I will have to adapt the inst/ scripts since
some programs are in the image embedded for the installation but are not
present on the CDROM.

And I will have to find a way to be able to use both mouse and keyboard,
or it will be a no-go.
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Install: root file system

[Iruatã Souza]

Never tried it, but you could try installing 9front, then your
distribution of choice atop of that.

On Sun, Jan 3, 2016 at 8:06 AM,  <tlaronde@polynum.com> wrote:
> On Sat, Jan 02, 2016 at 04:26:39PM -0800, erik quanstrom wrote:
>> i'm not sure what the root cause of your problem is,
>
> I'm now suspecting that the underlying problem is that a 9fat is a dos,
> but that is a special dos: part of a plan9 slice, so whether kfs or
> fossil supplementary partitions are expected.
>
> I have changed the MBR identifier to big FAT16 (6) and in this case
> 9load doesn't find a Plan9 slice and ask for a kernel, the
> sdE2!dos!9pcdisk.gz is OK (but it panics after since it doesn't ask for
> a plan9.ini).
>
>> due to not enough data,
>> but it does remind me of a limitation that has been bugging me.
>>
>> to boot from usb cleanly, i added a bit to the boot process that creates a loopback
>> sd device /dev/sdu0 that points to the usb disk device.  i've been booting my auth
>> server this way for some time.
>>
>
> The idea is interesting.
>
> Another idea/question appeared to me: could it be possible to add a
> device identifier #<some_code_point> to the booting device or publish it
> in the name space under /boot?
>
> Corollary: when an embedded bzfilesystem ships with the kernel, is there
> an device identifier that allows to access it? (From a cursory look at
> the proto, it seems that the file is published under /boot, but since
> the 9pcflop has no the sdiahci drivers, I try to simply catenate the
> 9pccd---or 9pcdisk FWIW---with the root.bz2 extracted, guessing that
> this is 9load task to arrange the loading, but I didn't find a way to
> access it directly from kernel hierarchy, since it is not visible in
> namespace).
>
>> it seems to me that i really screwed this up.  what i really want is a sd device
>> that always points to the boot drive, the one bios refers to as 0x80.
>> givem this, one can then put something like "bootargs=local!#S/sdB0/fs"
>> in plan9.ini.  this will allow the 9atom usb install image to run off any bootable
>> media (for which we have drivers).
>>
>
> :-) This has always been the "pleasure" of the bootstrapping procedure
> in the PC world. If I understand correctly, it is normal on other
> architectures to pass through the bios to access some hardware. With the
> PC, there is the limitation of the interface and, essentially, the real
> mode problem.
>
> But it is indeed a bit frustating to see devices accessed at booting
> (hurrah! my hardware is recognized!) and suddenly not recognized (when
> the BIOS is not used anymore and the kernel is on is own without the
> drivers)...
>
> Related question (for whoever has an answer): unfortunately my node has
> only a PS2 combo, so that I could, theoretically, have whether a PS2
> mouse xor a PS2 keyboard. In fact, when the mouse and keyboard are both
> connected via USB, 9pcflop has no problem: I have keyboard and mouse
> (BIOS emulating PS2 interfaces). If I use 9pccd or 9pcdisk, I loose the
> keyboard (and don't have the mouse if it is connected to USB).
>
> So it seems I could have a running Plan9 (it works for mouse and
> keyboard attached via usb with 9pcflop, but 9pcflop doesn't recognize
> the SATA/AHCI disks; 9pccd or 9pcdisk recognize the sdiahci, but don't
> recognize the usb mouse and keyboard; I hope a synthesis is possible
> with the "best" of all worlds)? But what does the usb attachment work
> with 9pcflop for mouse and keyboard and doesn't work for the
> others---perhaps because 9pcflop doesn't recognize usb and hence fall
> back to a PS2 BIOS provided interface?
>
>> so, i'm preparing a patch that will present the boot device as /dev/sdB0 regardless
>> of what underlying disk driver or protocol is being used.  here's the output from
>> my test machine.  it's been booted over the network, but even so bios has assigned
>> a 0x80 drive, and it's been found and configured:
>>
>> >>    sdB loop #S/sdF0/data
>>       sdE ahci ahci port 0xfffffe00fb538000 pci 0.17.4: 64a ncq alp led clo pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 4 ghc 80000002 isr 0 pi f 0-3 ver 10300
>>       sdF ahci ahci port 0xfffffe00fb532000 pci 0.31.2: 64a ncq alp led clo pmb slum pslum ems apts alhd xonly smb elmt iss 3 ncs 31 np 6 ghc 80000002 isr 0 pi 3f 0-5 ver 10300
>>       sdN nvme port 0xfffffe00fb410000 pci 2.0.0 v1.0 rst 0 ctg 1 ams 0 stride 1 to 20000 fatal 0
>>       sdO nvme port 0xfffffe00fb300000 pci 4.0.0 v1.1 rst 0 ctg 1 ams 0 stride 1 to 30000 fatal 0
>>
>
> That's interesting!
>
> For the mean time, I guess I will have to put an unix to serve 9P for a
> locally loaded kernel---but I will have to adapt the inst/ scripts since
> some programs are in the image embedded for the installation but are not
> present on the CDROM.
>
> And I will have to find a way to be able to use both mouse and keyboard,
> or it will be a no-go.
> --
>         Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
>                      http://www.kergis.com/
>                      http://www.arts-po.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>

Re: [9fans] Install: root file system

[tlaronde]

On Mon, Jan 11, 2016 at 06:06:57PM -0200, Iruatã Souza wrote:
> Never tried it, but you could try installing 9front, then your
> distribution of choice atop of that.

If nothing else works, I will fall back to a kernel loaded locally from
the sketched "by hand" plan9 partition (indeed the 9FAT at the very
beginning) but accessing a network root filesystem served by a NetBSD
node serving 9P.

But I investigate other tracks---see below.

> 
> On Sun, Jan 3, 2016 at 8:06 AM,  <tlaronde@polynum.com> wrote:
> > On Sat, Jan 02, 2016 at 04:26:39PM -0800, erik quanstrom wrote:
> >> i'm not sure what the root cause of your problem is,
> >
> > I'm now suspecting that the underlying problem is that a 9fat is a dos,
> > but that is a special dos: part of a plan9 slice, so whether kfs or
> > fossil supplementary partitions are expected.

If I'm not mistaken, the man page about kfs is misleading. It says that
indeed what is not fossil is treated as "kfs", but that "kfs" handles 
cd9660 or dos too.

If I understand correctly, this is not true. This is 9660srv or dossrv
or bzfl programs that are copied as "kfs" in the special installation
kernel root according to the type of the root filesystem to read.

And since in the installation kernels there is no kernel with a dossrv
masquerading as "kfs", it fails (the 9pcflop doesn't support sdiahci,
and this is _the_ problem; so I can't use the embedded bzfl root image
since only 9pcflop has the "kfs" to read it; 9pccd supports sdiahci
but it expects an ISO filesystem---and the "live" cd is not very
alive; I don't know if this is via emulation, but everything is
incredibly slow even to try to bootstrap the installation by entering
commands in the CD live plan9.

Note to others: I have only a PS2 keyboard/mouse combo, and other
serials are all USB. Disabling via plan9.ini the USB, even if attached
as USB devices, the mouse and keyboard appear (I guess by some BIOS
emulation). If USB is on, I have no mouse and no keyboard, or only one
of the twoi: the one connected to the PS2 combo.

For root filesystem experiments, I have even tried to create a
"kfs" partition in the plan9 slice, embedding in my case a cd9660
filesystem hoping that giving this as the rootfilesystem the 9660srv
masquerading as kfs in the 9pccd will be able to read it. But boot
fails with a "/ incorrect format" that I'm unable to understand at
the moment (but can be caused by the specification given as bootargs
in plan9.ini; I will try to investigate a little further if I have
some time).
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Install: root file system

[erik quanstrom]

> If I'm not mistaken, the man page about kfs is misleading. It says that
> indeed what is not fossil is treated as "kfs", but that "kfs" handles
> cd9660 or dos too.
>
> If I understand correctly, this is not true. This is 9660srv or dossrv
> or bzfl programs that are copied as "kfs" in the special installation
> kernel root according to the type of the root filesystem to read.

yes, this is correct.  these programs masquerade as "kfs" to make the boot
process happy.

> Note to others: I have only a PS2 keyboard/mouse combo, and other
> serials are all USB. Disabling via plan9.ini the USB, even if attached
> as USB devices, the mouse and keyboard appear (I guess by some BIOS
> emulation). If USB is on, I have no mouse and no keyboard, or only one
> of the twoi: the one connected to the PS2 combo.

on many motherboards, ps/2 keyboard and mouse are emulated by bios.
when usb is turned on, then the the bootloader or os (perhaps via bios calls)
needs to deal with usb.

i think that the distribution usb is not working for some ehci chipsets, especially
those that need explicit bios handoff, and those with multiple ehci controllers.

- erik