[9front] Re: 9front Boots Into "No Config" -- The Most Bizarre Error; Bypassing The Bootloader

[9front] Re: 9front Boots Into "No Config" -- The Most Bizarre Error; Bypassing The Bootloader

[Jay F. Shachter]

Centuries ago, Nostradamus predicted that Jacob Moody would write on Wed Jul 26 19:55:07 2023:

> 
> "no config" is the boot loader telling you that it can not find the
> plan9.ini file on the 9fat partition. You must have some old
> (corrupted?) 9fat partition sitting around.
> 

I do not have an old 9fat partition sitting around.  I did, however,
figure out how to get the 9front bootloader to work.  And then I found
another way to boot 9front which is even better, but not perfect, and
I will be asking the readers of this mailing list for help in making it
perfect.

There is a small FAT filesystem, about 100 megabytes in size, at the
beginning of the 9front disk slice (which is slice #14).  And this
small FAT filesystem did, indeed, have a file on it named plan9.ini.
The 9front bootloader couldn't find it.  The 9front bootloader
couldn't find anything on that filesystem.  If, in response to the >
prompt, you told it "bootfile=/9pc64" and then "boot", it couldn't
find it.

The way I made the bootloader able to find things on the 9fat
filesystem was by removing the bootable flag on primary slice #1.
This is totally bizarre and makes absolutely no sense, but it was the
thing that worked.  9front is on slice #14, and is nowhere near
primary slice #1, and the invocation of the 9front bootloeader did not
travel thru, or near, primary slice #1, but when I cleared its
bootable flag, the 9front bootloader was able to boot 9front.  What
makes this even more bizarre is that the 9front bootloader had worked
in the past when the boot flag on primary slice #1 had been turned
on.  But now it needed to be turned off.

This was not, however, a satisfactory solution, because turning off
the boot flag of primary slice #1 rendered my ReactOS system
unbootable.  ReactOS, which occupies slice #15, is booted thru a
program called freeldr.sys that must occupy a primary slice with the
boot flag turned on.  Don't ask me why it does this.  After ReactOS
installed itself on slice #15, it also installed freeldr.sys and its
configuration file, freeldr.ini, on slice #1.  Freeldr.sys refuses to
work unless it is on a primary slice marked as bootable, so turning
off the bootable flag on slice #1 -- which is what the 9front
bootloader required me to do -- made it impossible to boot ReactOS.
It's possible that I could put something in freeldr.ini that would
enable freeldr.sys to boot /9pc64 directly, bypassing the bootloader,
and that would solve my problem.

I didn't have to solve my problem that way, though, because /9pc64
complies with the multiboot specification (I don't know if that was
true before I moved to the hjfs filesystem, I didn't test it), and so
does GRUB, so I am able to use GRUB to bypass the non-working 9front
bootloader, and to execute /9pc64 directly.  All I had to do was
introduce a 2-line menuitem into my GRUB configuration file:

  set root=(hd0,14)
  multiboot /9pc64 bootargs=local!/dev/sdE0/fs user=glenda mouseport=ps2

I actually like bypassing the bootloader better than going thru it.
When you bypass the bootloader you see the graphical user interface
immediately, before the startup messages and before you are asked to
state or confirm the bootargs.  I think that looks nicer.

The one thing I have not yet been able to do is eliminate the bootargs
prompt.  I want to invoke /9pc64 in such a way that it is told
everything it needs to know in advance, and doesn't have to ask me
anything.  As you can tell from the kernel arguments in my GRUB
menuitem, I tried to do that with the bootargs= argument, but it's
not working, it still asks me to tell it the bootargs.  How do I
eliminate the bootargs prompt when I boot 9front?  Thank you in
advance for any and all replies.

                        Jay F. Shachter
                        6424 North Whipple Street
                        Chicago IL  60645-4111
                                (1-773)7613784   landline
                                (1-410)9964737   GoogleVoice
                                jay@m5.chicago.il.us
                                http://m5.chicago.il.us

                        "Quidquid latine dictum sit, altum videtur"

Re: [9front] Re: 9front Boots Into "No Config" -- The Most Bizarre Error; Bypassing The Bootloader

[Jacob Moody]

On 7/27/23 16:37, Jay F. Shachter wrote:
> 
> Centuries ago, Nostradamus predicted that Jacob Moody would write on Wed Jul 26 19:55:07 2023:
> 
>>
>> "no config" is the boot loader telling you that it can not find the
>> plan9.ini file on the 9fat partition. You must have some old
>> (corrupted?) 9fat partition sitting around.
>>
> 
> I do not have an old 9fat partition sitting around.  I did, however,
> figure out how to get the 9front bootloader to work.  And then I found
> another way to boot 9front which is even better, but not perfect, and
> I will be asking the readers of this mailing list for help in making it
> perfect.
> 
> There is a small FAT filesystem, about 100 megabytes in size, at the
> beginning of the 9front disk slice (which is slice #14).  And this
> small FAT filesystem did, indeed, have a file on it named plan9.ini.
> The 9front bootloader couldn't find it.  The 9front bootloader
> couldn't find anything on that filesystem.  If, in response to the >
> prompt, you told it "bootfile=/9pc64" and then "boot", it couldn't
> find it.
> 
> The way I made the bootloader able to find things on the 9fat
> filesystem was by removing the bootable flag on primary slice #1.
> This is totally bizarre and makes absolutely no sense, but it was the
> thing that worked.  9front is on slice #14, and is nowhere near
> primary slice #1, and the invocation of the 9front bootloeader did not
> travel thru, or near, primary slice #1, but when I cleared its
> bootable flag, the 9front bootloader was able to boot 9front.  What
> makes this even more bizarre is that the 9front bootloader had worked
> in the past when the boot flag on primary slice #1 had been turned
> on.  But now it needed to be turned off.
> 
> This was not, however, a satisfactory solution, because turning off
> the boot flag of primary slice #1 rendered my ReactOS system
> unbootable.  ReactOS, which occupies slice #15, is booted thru a
> program called freeldr.sys that must occupy a primary slice with the
> boot flag turned on.  Don't ask me why it does this.  After ReactOS
> installed itself on slice #15, it also installed freeldr.sys and its
> configuration file, freeldr.ini, on slice #1.  Freeldr.sys refuses to
> work unless it is on a primary slice marked as bootable, so turning
> off the bootable flag on slice #1 -- which is what the 9front
> bootloader required me to do -- made it impossible to boot ReactOS.
> It's possible that I could put something in freeldr.ini that would
> enable freeldr.sys to boot /9pc64 directly, bypassing the bootloader,
> and that would solve my problem.
> 
> I didn't have to solve my problem that way, though, because /9pc64
> complies with the multiboot specification (I don't know if that was
> true before I moved to the hjfs filesystem, I didn't test it), and so
> does GRUB, so I am able to use GRUB to bypass the non-working 9front
> bootloader, and to execute /9pc64 directly.  All I had to do was
> introduce a 2-line menuitem into my GRUB configuration file:
> 
>   set root=(hd0,14)
>   multiboot /9pc64 bootargs=local!/dev/sdE0/fs user=glenda mouseport=ps2
> 
> I actually like bypassing the bootloader better than going thru it.
> When you bypass the bootloader you see the graphical user interface
> immediately, before the startup messages and before you are asked to
> state or confirm the bootargs.  I think that looks nicer.
> 
> The one thing I have not yet been able to do is eliminate the bootargs
> prompt.  I want to invoke /9pc64 in such a way that it is told
> everything it needs to know in advance, and doesn't have to ask me
> anything.  As you can tell from the kernel arguments in my GRUB
> menuitem, I tried to do that with the bootargs= argument, but it's
> not working, it still asks me to tell it the bootargs.  How do I
> eliminate the bootargs prompt when I boot 9front?  Thank you in
> advance for any and all replies.
> 
>                         Jay F. Shachter
>                         6424 North Whipple Street
>                         Chicago IL  60645-4111
>                                 (1-773)7613784   landline
>                                 (1-410)9964737   GoogleVoice
>                                 jay@m5.chicago.il.us
>                                 http://m5.chicago.il.us
> 
>                         "Quidquid latine dictum sit, altum videtur"
> 

I believe something is terribly wrong with your disk for 9boot to
not be able to locate the fat partition.

Are you using an EFI partition table or an MBR? I assume you must
be using EFI if you are dealing in more then 4 partitions on a disk.
But in your previous mails you mentioned installing 9front in MBR mode.

Can you give me an entire explanation of how your disk is configured?

Also again, I will suggest and ask that you attempt to reproduce these
pathological issues on a drive that you're not sharing with 13+
other operating systems.

Thank you,
moody

Re: [9front] Re: 9front Boots Into "No Config" -- The Most Bizarre Error; Bypassing The Bootloader

[B. Atticus Grobe]

On 7/27/23 16:37, Jay F. Shachter wrote:
...
> The one thing I have not yet been able to do is eliminate the bootargs
> prompt.  I want to invoke /9pc64 in such a way that it is told
> everything it needs to know in advance, and doesn't have to ask me
> anything.  As you can tell from the kernel arguments in my GRUB
> menuitem, I tried to do that with the bootargs= argument, but it's
> not working, it still asks me to tell it the bootargs.  How do I
> eliminate the bootargs prompt when I boot 9front?  Thank you in
> advance for any and all replies.

man plan9.ini

as moody said, try this on a drive that isn't filled with stuff.
or run it in a vm. minus a (now patched) issue with hjfs in the 
installer that has already been mentioned, the installer does the right 
thing for a "supported" installation.

all these other hoops you're failing to jump through are of your own 
invention. there is a reason no one does single-drive multiboot like 
this, because it is not actually a supported configuration for any OS, 
just one of those things that can _sometimes_ be made to work.

on the other hand, 9front and most modern operating systems run just 
fine under qemu, virtualbox, vmware, vmd, and probably even hyperv and 
don't require all of this ridiculous crap. 15 (or more?) 
partitions/slices? this is just stupid. do stupid things, get stupid 
results.