[SOLVED] grub2 partition install on new install.

[Tony0945]

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?

Code: Select all

default 3
timeout 10
splashimage=(hd1,0)/boot/grub/splash.xpm.gz

title=LAX ACPI (5.4.80-gentoo-r1) 
root (hd1,0)
kernel /vmlinuz-5.4.80-gentoo-r1 vga=0x346 rootfstype=ext4 root=/dev/sdb3 net.ifnames=0 mitigations=off acpi_enforce_resources=lax

title=Gentoo Latest (5.4.80-gentoo-r1) 
root (hd1,0)
kernel /vmlinuz-5.4.80-gentoo-r1 vga=0x346 rootfstype=ext4 root=/dev/sdb3 net.ifnames=0 mitigations=off

title=Gentoo Next Latest (5.4.72-gentoo) 
root (hd1,0)
kernel /vmlinuz-5.4.72-gentoo vga=0x346 rootfstype=ext4 root=/dev/sdb3 net.ifnames=0 mitigations=off

title=Gentoo (4.17.19-gentoo) 
root (hd1,0)
kernel /vmlinuz-4.17.19-gentoo vga=0x346 rootfstype=ext4 root=/dev/sdb3 net.ifnames=0 mitigations=off

title=F12 Boot
root (hd0,0)
kernel /vmlinuz-5.4.72-gentoo vga=0x346 rootfstype=ext4 root=/dev/sda3 net.ifnames=0 mitigations=off

#
title=Windows
root (hd0,0)
chainloader +1

title=32bit
root (hd1,4)
chainloader +1

title=Ubuntu
root (hd1,5)
chainloader +1

title=RESCUE GENTOO
root (hd1,6)
chainloader +1

I don't have a CD drive on this system and my working USB sysrecuecd doesn't boot on this Gigabyte board. This seems to be a Gigabyte problem based on google results.

I really want to remove the (damaged) Windows drive and replace it with an SSD, but I do need a rescue medium.

[halcon]

I rebooted and chose this partition from the main grub (legacy) install...

Code: Select all

title=Gentoo (4.17.19-gentoo) 
root (hd1,0)
kernel /vmlinuz-4.17.19-gentoo vga=0x346 rootfstype=ext4 root=/dev/sdb3 net.ifnames=0 mitigations=off

AFAIK, GRUB-legacy does not support ext4 (without patching). In any case, all my GRUB-legacy installs are with ext3...

[Hu]

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]

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]

Partition table:

Code: Select all

 $ fdisk -l /dev/sdb
Disk /dev/sdb: 465.78 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WDC WD5000HHTZ-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x0008d19b

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1  *           63   2008124   2008062 980.5M 83 Linux
/dev/sdb2         2008125   6024374   4016250   1.9G 82 Linux swap / Solaris
/dev/sdb3         6024375 461290409 455266035 217.1G 83 Linux
/dev/sdb4       461291520 976773119 515481600 245.8G  5 Extended
/dev/sdb5       461293568 595802111 134508544  64.1G 83 Linux
/dev/sdb6       595804160 672143359  76339200  36.4G 83 Linux
/dev/sdb7       672145408 976773119 304627712 145.3G 83 Linux

Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.

Partition 1 boot partition providing /boot for main gentoo installation
Partition 2 swap partition
Partition 3 root partition of main Gentoo install
Partition 4 extended partition containing the next three partitions
Partition 5 32-bit Gentoo used as a build box for an external k6-3 computer
Partition 6 Ubuntu
Partition 7 The new Gentoo partition, that i can chroot into but not boot directly. I want to boot directly.

[halcon]

So, your scheme is similar to the one described there? I never tried it, can't say nothing.

[Tony0945]

So, your scheme is similar to the one described there? I never tried it, can't say nothing.

\

Yes. But that post is from 2011. The Ubuntu that I'm chainloading is (I'm pretty sure) newer than that. And it seems the OP in that post switched to trying to load the Ubuntu kernel directly from grub legacy directly. I'm supposing that I will have to install grub-legacy in the new install. I don't think you can do a partition install of SYSLINUX.

[Tony0945]

Finally got it. The Installion guide says:

When using BIOS:

root #grub-install /dev/sda

So i ran "grub-install /dev/sdb7" and got a lot of warnings. I hadn't realized that the command didn't execute!
So when chain loading I got the "grub >" prompt. Because there was no grub.cfg!

What was needed was an option on the command. "grub-install /dev/sdb7 --force". Now it chainloads nicely and I have a rescue partition that is straight Gentoo latest amd64, with kernel and all built to "march=k8" so it should run all my amd boxes. So now I am free to experiment with my other main partition that doesn't have all the Fedora goo installed on it. If it breaks bad enough to not boot, I can boot into the rescue partition and chroot into the main partition.

[figueroa]

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.

[Tony0945]

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

[GDH-gentoo]

What was needed was an option on the command. "grub-install /dev/sdb7 --force"

I've had no issues recently with "grub-install /dev/sdb1" or /dev/sdb2, both being ext4 [...]

Don't you get warnings about "embedding" not being possible and about using "unreliable" blocklists? The usual way to do this is specifying a whole disk (i.e. no partition number), and having GRUB install itself in the space between the MBR and the first partition...

[Tony0945]

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]

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]

...

...

I was WRONG about not needing to use force. The only explanation is my faulty memory.

On this PC, I had my chainload setup on just /dev/sdb.

However, since I've regularly and recently done grub-install to a partition on Gentoo and Debian-based distributions on my testing/backup server, I did an experiment.

I chrooted into my /dev/sdb1, which is a restoration of my primary desktop system as it was on 23 November 2018.
Then Did:

Code: Select all

(chroot) bethel / # grub-install /dev/sdb1
Installing for i386-pc platform.
grub-install: warning: File system `ext2' doesn't support embedding.
grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.

RATS! I DID have to use --force after all. I still got the errors, but the last line confirmed that grub was installed at /dev/sdb1.

Then, back our of the chroot, I added the following to the end of my /boot/grub/grub.cfg

Code: Select all

menuentry "Chainload Grub on /dev/sdb1" {
set root=('hd1,msdos1')
chainloader +1
}

Upon rebooting and selecting the "Chainload Grub on /dev/sdb1" menu item I got my full grub boot menu from /dev/sdb1 as normal.

No other explanation. Mea culpa.

ADDED: legacy BIOS booting, even on my newer machine. In my opinion, UEFI is for the birds.

[figueroa]

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.

[GDH-gentoo]

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

4 Installation
4.4 BIOS installation
MBR
With this partition table format, there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition [...], or the core image can be installed in a file system and a list of the blocks that make it up can be stored in the first sector of that partition.

Each of these has different problems. [...] On the other hand, installing to a filesystem means that GRUB is vulnerable to its blocks being moved around by filesystem features such as tail packing, or even by aggressive fsck implementations, so this approach is quite fragile; and this approach can only be used if the /boot filesystem is on the same disk that the BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive numbers.

That bug report is from 2012-2013, so error messages might have changed, and it is about GRUB failing even with the --force option. There is one case that is definitely unsupported, and that is the higlighted part in the manual: installing to a partion in a disk that is not the disk that contains /boot/grub. Looking at the attachment, and the final comment in that bug report, that seems to be the case: an attempt was made to install GRUB to /dev/sdb1, but /boot/grub was in /dev/sda2, different disk:

3. The core.img was on another disk than the partition installed to. Just storing sector numbers was thus insufficient - it also needed to be able to find the other disk ... and that is pretty hard (impossible) that early in the boot process.

This does not appear to be your case or Tony0945's. If I understood correctly both of you have the corresponding /boot/grub in the same disk (/dev/sdb) as the partition you want to install to. So --force does not fail, although you have to specify it to coerce GRUB into installing itself. The method, however, is still considered unreliable, according to the manual.

[Tony0945]

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.