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 30358 invoked from network); 28 Jul 2023 03:01:31 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 28 Jul 2023 03:01:31 -0000 Received: from m5.chicago.il.us ([204.248.57.218]) by 9front; Thu Jul 27 22:58:08 -0400 2023 Content-Type: text/plain; charset=iso-8859-1 To: 9front@9front.org Message-Id: <16905130930.52F6E.13899@lsd.chicago.il.us> MIME-Version: 1.0 From: "Jay F. Shachter" Date: Thu, 27 Jul 2023 21:58:13 -0500 (EDT) Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: hypervisor software SSL over YAML hardware NoSQL service grid Subject: [9front] MBR; Boot Arguments Reply-To: 9front@9front.org Precedence: bulk Centuries ago, Nostradamus predicted that Jacob Moody would write on Thu Jul 27 16:53:52 2023: > > 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. > It is an MBR-partitioned disk. I think -- and please correct me if I am wrong -- that the entire concept of a boot flag on a disk slice is inapplicable to GPT-partitioned disks. > > Can you give me an entire explanation of how your disk is > configured? > Windows 10 occupies the first two primary slices (when I got the computer, Windows 10 had colonized all three primary slices, but I liberated the third one). FreeDOS 1.3 resides on the third primary slice because it is practically impossible to get FreeDOS to work anywhere but on a primary slice. Everything else resides on logical slices within the extended slice. The two Linux systems reside on a single logical slice, which constitutes a volume group from which Linux logical volumes can be carved out. The other operating systems each occupies a separate logical slice. 9front is on slice #14. The MBR boots Linux GRUB. There is also a backup copy of the Linux GRUB MBR on slice #10. There is a backup copy of the Solaris GRUB MBR on slice #13. But the question of disk layout -- the entire question of why the 9front bootloader cannot find anything in the 9fat filesystem when primary slice #1 is flagged as bootable -- is now a question only of intellectual, but not practical, interest. I am bypassing the 9front bootloader; GRUB is booting /9pc64 directly. The remaining question, which I hope someone on this mailing list can answer, is: What argument can I pass to /9pc64 that will tell it the bootfile, so that I don't have to type the Enter key whenever I boot 9front to confirm that I want to use local!/dev/sdE0/fs (similar to the user=glenda option that keeps me from having to type Enter to confirm that I am glenda)? 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"