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, <tlaro...@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 >
