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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18710 invoked from network); 27 Jul 2023 21:57:03 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 27 Jul 2023 21:57:03 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Thu Jul 27 17:53:54 -0400 2023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1690495032; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5YrVbeJFtEgAlKPAfSMqjl0SmdmVJ3W8yUAuO3Mvjnc=; b=ileayI0FfsFBIFjINBXwU774exmFeKh/vgwcQaAo/ff53mEU3MnPTUYxlanoRc9rIVuy+n JZyhy1cA4jTGSNv0bwmsYBPI/2WKLLOp9ia6plY4uUDp61Z/MkS2l1836TsCVIREVMdJi7 eyV1mWEqB34f1h7BeeUVWUiD/6+Xb0s= Received: from [192.168.168.123] ( [207.45.82.38]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id cdd786f6 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Thu, 27 Jul 2023 16:57:12 -0500 (CDT) Message-ID: <53a35916-d74c-ea3c-08eb-50fcfcbbfba6@posixcafe.org> Date: Thu, 27 Jul 2023 16:53:52 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: 9front@9front.org References: <16904938490.a94c1A.9077@lsd.chicago.il.us> From: Jacob Moody In-Reply-To: <16904938490.a94c1A.9077@lsd.chicago.il.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: advanced rails-aware manager Subject: Re: [9front] Re: 9front Boots Into "No Config" -- The Most Bizarre Error; Bypassing The Bootloader Reply-To: 9front@9front.org Precedence: bulk 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