[SOLVED] grub2 partition install on new install.

Tony0945 · Last edited by Tony0945 on Sun Dec 06, 2020 5:41 pm; edited 1 time in total

Well, I installed Gentoo from scratch for the first time in 16 years. I installed into a free partition that was used for ntfs storage. The storage was redundant so I blew away the ntfs and installed ext4.

I was distressed that only profile 17.0 was not available except for 17.0 dev. So I chose the default 17.1.

Since I hadn't done this in so long, I read the manual carefully and went slowly. That took an hour, including the manual. It then took two hours to resolve blockers. Then when emerge world could run, llvm was building for four hours. It was still building and I went to bed. What a monstrosity! Why isn't llvm-bin available?
In the morning all had finished. I then attempted to install grub as a partition install. I rebooted and chose this partition from the main grub (legacy) install. I already chainload Ubuntu with grub2 on a different partition, but I just get a grub prompt from my new Gentoo install boot.

Grub complained when I installed and I've read that you can't partition install grub anymore. This is BIOS boot on 16 year old hardware. Do I need to install grub-legacy to get the partition boot?

halcon · Guru Joined: 15 Dec 2019 Posts: 391

Hu · Moderator Joined: 06 Mar 2007 Posts: 16468

If you want to avoid grub2, you could use syslinux/extlinux. I've been quite happy with it. Its configuration is simple and easily parsed by a human.

Tony0945 · Posted: Sun Dec 06, 2020 12:40 am Post subject:

Halcon, Hu,

I'm not having trouble with grub-legacy. it is working fine and chainloading grub2 on Ubuntu.

I'm having trouble setting up grub2 on Gentoo, Dec 4 download, so that it can be chainloaded by anything.
I actually get to grub2 by chainloading from Windows XP. The XP is broken, but the loader is simple and it works.
I do want to get away from the XP chain load and want to have a "standard" Gentoo to boot intoo for recovery.

Tony0945 · Posted: Sun Dec 06, 2020 12:48 am Post subject:

Partition table:

halcon · Guru Joined: 15 Dec 2019 Posts: 391

So, your scheme is similar to the one described there? I never tried it, can't say nothing.
_________________
A wife asks her husband, a programmer:
- Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?
He comes back with 6 cartons of milk.
- Why did you buy 6 cartons of milk?
- They had eggs.

Tony0945 · Posted: Sun Dec 06, 2020 3:08 pm Post subject:

Tony0945 · Posted: Sun Dec 06, 2020 5:41 pm Post subject:

Finally got it. The Installion guide says:

figueroa · Posted: Sun Dec 06, 2020 10:00 pm Post subject:

With up-to-date grub2, amd64 stable, I've had no issues recently with "grub-install /dev/sdb1" or /dev/sdb2, both being ext4, without errors or needing --force. These partitions chainload without issue.

Those partitions were mounted and running as / during the grub-install, after which grub.cfg has to be created, usually with grub-mkconfig.
_________________
Andy Figueroa
andy@andyfigueroa.net Working with Unix since 1983.
Automate and Test Your Backups

Tony0945 · Posted: Sun Dec 06, 2020 11:13 pm Post subject:

This was a new install with the stage3 downloaded on Dec 4.

GDH-gentoo · Posted: Mon Dec 07, 2020 3:06 pm Post subject:

Tony0945 · Posted: Mon Dec 07, 2020 3:43 pm Post subject:

GDH-Gentoo,

Yes but this is not a main boot. This is only for rescue if the main partition becomes unbootable. Or for comparison as is the Ubuntu partition that is also chain loaded. There are four installations on this disk, three of them Gentoo:

Gentoo #1, my everyday install that I'm on today. Customized to my liking. This is booted from the MBR grub-legacy
Gentoo #2, a 32 bit install used as a package build box for another k6 computer. This is chainloaded from the MBR grub-legacy.
Gentoo #3, the new plain Jane install used as a rescue boot if the main install fails. Standard stage3 plus default Mate installation.

GDH-gentoo · Posted: Mon Dec 07, 2020 4:59 pm Post subject:

Sure. I asked out of curiosity, it's the first time I see chainloading to another GRUB, on a BIOS install, using the block list syntax ("chainloader +1"), and wondered what GRUB was doing. Based on you mentioning of --force, I looked at the part of the code that acts on that option, and it seemed that it should output a lot of warnings, even if GRUB ends up doing the install anyway.

How figueroa doesn't get warnings is still a mystery for me.

figueroa · Posted: Mon Dec 07, 2020 5:41 pm Post subject:

figueroa · Posted: Tue Dec 08, 2020 3:44 am Post subject:

I was following up on this with some Internet searches (DuckDuckGo) and found:
https://bugzilla.redhat.com/show_bug.cgi?id=861192
See the last post in this thead where it reads: "When installing to partitions then grub2 can be forced to use blocklists. Blocklists means that grub2-install generates a core.img file, stores it in the filesystem in /boot/grub2, and stores the sector numbers for core.img in the first sectors of the partition. For 'simple' filesystems that means that the early boot loader can bootstrap itself by reading sectors, without implementing file systems."

It absolutely did that. Installing grub to my old /dev/sdb1 filesystem, what I did this morning, wrote a new /boot/grub/i386-pc with updated content including the noted core.img. I'm flabbergasted.

Both of my internal drives are 1 GB Hitachi spinners set up with MBR, which explains why it didn't absolutely fail, but as that post concluded, "It is just unsupported functionality that is unsupported." Bottom line, I shouldn't have done that and I need to discontinue the practice. Of course, it means I can't have multiple grub boot systems installed on a single drive. Bummer.
_________________
Andy Figueroa
andy@andyfigueroa.net Working with Unix since 1983.
Automate and Test Your Backups

GDH-gentoo · Posted: Tue Dec 08, 2020 4:50 pm Post subject:

I believe that this part of the GRUB manual (also available with info grub) describes these cases:

Tony0945 · Posted: Tue Dec 08, 2020 5:53 pm Post subject:

GDH-gentoo, it's even worse. My linux disk is /dev/sdb. /dev/sda is a broken Windows XP disk. Not only is the XP broken (won't boot) but there are disk errors. Nevertheless, XP comes up enough to chain load grub-legacy on the second disk. That in turn presents the menu that includes the chain loading of grub2 on the seventh partition. That last step is noticeably slower than the others. Progress? Slower booting and an incomprehensible parameter syntax is not my idea of progress.

I don't recall all the file names, I'd have to do a google search. Years ago, as a learning excercize I dissambled the MBR and the XP commands to see how it all worked. There were interesting differences in MBR's based on which version of Windows created them, but they boiled down to trying the latest BIOS calls and trying the old calls if the new ones failed.

1. BIOS loads your MBR code is loaded into address XXX (a standard x86 boot location) and control transfers there.
2. The MBR code searches for the bootable partition in the partition table.
3. The MBR code loads the first 512 bytes of the bootable partition into memory and jumps into it.
4. The partition boot code on a Windows disk, looks for the ASCII letters FAT at a certain location and sets certain parameters based on whether it did or did not find them. Apparently NTFS is assumed if FAT not found.
5. Using the parameters from step 4, the code looks for a file named <I forget, maybe boot.cmd> This is a command file, a straight machine language file with no header information. Loads it into memory and jumps to the beginning.
6. Now with a code segment much longer than 512 bytes, the code searches the root file table, a linear listing with constant entry size (different for FAT and NTFS), for the text file, BOOT.INI.
7. The Command code now presents boot.ini to the operator with a timeout and a default choice found in boot.ini. Usually it's some weird looking thing that leads into Windows proper. However, at least at XP, they retained the ability to chain load DOS or pre-NT Windows from a 512 byte file, specified in boot.ini. If this choice is selected or defaulted, it is read into memory and jumped into, just like in step 1. Effectively a chain load.

In my installation that step 7 file is called boot.lnx and it's either a copy of the second disk's MBR or a partition first sector. I'm not sure which. If I boot the second disk directly from the BIOS I just get a string messages something like "Grub stage 1.5 not found" endlessly. If I had a separate boot medium, I'd take the first drive out entirely. But my bootable USB sticks are not seen by the 16 year old Gigabyte BIOS (web search reveals this is a generic Gigabyte problem) and I dont have a CD drive and the floppy drive died long ago.