Re: [9fans] Install: root file system

["Iruatã Souza" <iru.muzgo@gmail.com>]

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
>