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,   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 
 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

Re: [9fans] 9front ISO image

[V. M. (Mark) Haas]

Thanks for you help.
-- Mark

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,   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 # 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 0xfe00fb538000 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 8002 
>> isr 0 pi f 0-3 ver 10300
>>   sdF ahci ahci port 0xfe00fb532000 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 8002 
>> isr 0 pi 3f 0-5 ver 10300
>>   sdN nvme port 0xfe00fb41 pci 2.0.0 v1.0 rst 0 ctg 1 ams 0 
>> stride 1 to 2 fatal 0
>>   sdO nvme port 0xfe00fb30 pci 4.0.0 v1.1 rst 0 ctg 1 ams 0 
>> stride 1 to 3 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 
>