From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 3 Jan 2016 11:06:26 +0100 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20160103100625.GA66@polynum.com> References: <20160102115515.GA498@polynum.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [9fans] Install: root file system Topicbox-Message-UUID: 7d643f48-ead9-11e9-9d60-3106f5b1d025 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 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 http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C