Re: [9fans] Install: root file system
> 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] Install: root file system
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
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 > http://www.kergis.com/ >
Re: [9fans] Install: root file system
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 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
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 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 - erik
[9fans] Install: root file system
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 http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C