From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18111 invoked from network); 27 Jul 2023 21:41:09 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 27 Jul 2023 21:41:09 -0000 Received: from m5.chicago.il.us ([204.248.57.218]) by 9front; Thu Jul 27 17:37:25 -0400 2023 Content-Type: text/plain; charset=iso-8859-1 To: 9front@9front.org Message-Id: <16904938490.a94c1A.9077@lsd.chicago.il.us> MIME-Version: 1.0 From: "Jay F. Shachter" Date: Thu, 27 Jul 2023 16:37:29 -0500 (EDT) Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: extensible engine CMS SOAP over SVG general-purpose high-performance database Subject: [9front] Re: 9front Boots Into "No Config" -- The Most Bizarre Error; Bypassing The Bootloader Reply-To: 9front@9front.org Precedence: bulk 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"