To see if the block size could be a problem, I have installed 9front on a HDD connected via USB.
I created a GPT with the first partition an EFI one (esp for 9 front) and a second partition for 9front. At first, I selected to use the EFI as 9fat. This didn't work, so I secondly let the 9fat be at the very beginning of the Plan9 partition. Testing on a PC with both legacy/UEFI support: the UEFI cdrom install doesn't work; booting with UEFI a 9front installed on an USB disk, doesn't work. But running the UEFI shell and then executing, from the UEFI shell the 9front efi/boot/bootx64.efi succeeded (Note: on the PC, not the AM08Pro ACEMAGICIAN target). So I try on the AM08Pro. UEFI doesn't work; launching the UEFI Shell and executing efi/boot/bootx64.efi goes a little farer (with a filesystem with 512 bytes blocks) but fails: Same result, but it goes a little further that the USB thumb (with an ISO9660 filesystem): --8<-- *acpi=0x93209014 *bootscreen=1600x900x32 x8r8g8b8 0x7fe0000000 bootfile=9pc64 bootargs=local!/dev/sdU1affc/fscache mouseport=ps2 monitor=vesa vgasize=1024x768x16 tiltscreen=none i/o error -->8-- => There is one difference between the "classic" PC and the AM08Pro: on the PC, I have 9front installed on one internal disk. So, perhaps, the booting procedure, supposed to be launched from the USB connected disk, reaches a file (the kernel or the plan9.ini) not from the USB but from the internal disk and this is why it succeeds. On the AM08Pro, since there is not 9front installed, perhaps one of the files is not found. Another attempt: I made an USB key with NetBSD install image. It boots correctly under UEFI. I shrinked the Windows partition on the NVMe disk installed on the AM08Pro and then created, from the "classic" PC, on the USB connected disk, a 9front install with a slice of the same size. Then, booting the AM08Pro from the NetBSD USB thumb, I dd'ed the 9front slice (in the USB connected disk) in the NVMe slot created. I then rebooted the AM08Pro and run the UEFI shell that I have installed. >From the shell, I executed the 9front efi/boot/bootx64.efi The kernel boots, but then an infinite loop of messages appear, with addresses varying but with this pattern: usbxhci dc[0-5]0000: need recover USBSTD=4 er stopped=0 I will look for this in the sources tomorrow (Monday). But if someone has already clues about what is happening... On Sun, Feb 16, 2025 at 06:45:48PM +0100, Gorka Guardiola wrote: > 9front is probably using a completely diferent loading chain, but 2048 > could be correct if they use a similar or related approach. > > On Sun, Feb 16, 2025, 18:44 Gorka Guardiola <pau...@gmail.com> wrote: > > > I haven't used native plan 9 for a long time, but, in case it helps, 2048 > > used to be the blocksize in USB booting (from CDROMs, this was all using El > > Torito standard when I wrote the bootloader ages ago). I think USB didn't > > care but CDROMs did. > > > > On Sun, Feb 16, 2025, 16:51 <tlaro...@kergis.com> wrote: > > > >> As indicated in another message, I'm trying to install Plan9 (9front) > >> on an AM08Pro, that is a ACEMAGICIAN with an AMD Ryzen 9 8cores, 16 Gb > >> of memory, and a 512Gb NVMe disk (M.2). > >> > >> Before attempting to PXE boot (that should work) I'm trying to > >> understant why an USB thumb does not work. > >> > >> I have installed an UEFI Shell (that has to be called Shellx64.efi > >> despite the "Shell.efi" mentionned in the BIOS menu) in the Windows > >> EFI system partition. From the BIOS menu, I can select "try to run an > >> UEFI shell found in one of the filesystems" to explore the board. > >> > >> Concerning USB, there are 3.0, 3.1 and 3.1 USB-C ports (even Windows > >> fail to recognize some USB devices depending on where they are put, > >> and it seems that connecting a keyboard+touchpad combo, that uses one > >> connector, but two instances, invalidates the next USB connector; so > >> the whole USB stuff looks suspiciously fragile). > >> > >> Nonetheless, an USB thumb (as well as a CDROM connected via an USB > >> connector) is recognized as CDROM(0x1). > >> > >> I think this may be the problem: the firmware is using 2048 blocks > >> (ISO9660 FS) while the information in the MBR table relates to 512 > >> blocks. With BIOS allowing legacy compatibility, this may perhaps work > >> (MBR make the booting switch to 512 bytes blocks), but this will not > >> if the block size is fixed as 2048? > >> > >> I haven't look at the UEFI code, but does this ring a bell for someone? > >> -- > >> Thierry Laronde <tlaronde +AT+ kergis +dot+ com> > >> http://www.kergis.com/ > >> http://kertex.kergis.com/ > >> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- Thierry Laronde <tlaronde +AT+ kergis +dot+ com> http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te2a9c6fe778e83f5-Mc2c0094f32c96fab5792c012 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
