| View previous topic :: View next topic |
| Author |
Message |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
 Posted: Wed Jul 14, 2021 4:18 am Post subject: How to identify the on disk grub installation? |
 |
|
I'm migrating to a new disk, and this is the last step.
In what I can only guess was intended to be a flexible installation, my old setup included: | Code: | /dev/sda1 2048 6143 4096 2M BIOS boot
/dev/sda2 6144 268287 262144 128M EFI System |
The system is from around the time when EFI may or may not have been hardware supported, so it was either due to that or planning for an eventual migration to an EFI system that I most likely went with both partitions.
Never mind the EFI partition type as it is being used as ext4: | Code: | % mount |grep sda2
/dev/sda2 on /mnt/sda2 type ext4 (rw,relatime,data=ordered) |
The file system includes what you'd expect from a /boot file system with grub files.
Is there a way to verify where grub-install put data? I'm probably just confused about how the BIOS boot partition would be used, as my guess is that it was never used.
Installation guide instructions indicate installation to the device (not partition): | Quote: | When using BIOS:
| Code: | | root #grub-install /dev/sda |
|
I'm not sure if this is useful, but I suppose it might be the answer even if it isn't clear: | Code: | % grub-probe -d /dev/sda
grub-probe: error: unknown filesystem.
% grub-probe -d /dev/sda1
grub-probe: error: unknown filesystem.
% grub-probe -d /dev/sda2
ext2 |
grub-probe with verbose doesn't add much that appears helpful.
I can presume that it is safe to use the /dev/sdb for the new drive, but it would still be nice to demonstrate what exists rather than guess.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
 |
wwdev16
n00b
Joined: 29 Aug 2018
Posts: 52
|
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2014
|
| Posted: Wed Jul 14, 2021 8:43 am Post subject: |
|
|
pjp,
I assume you're using non-EFI boot. Well, you can't be using EFI, the EFI partition is wrong...
So, assuming your BIOS is normal, you're booting via the MBR on sda, which is lurking in the "BIOS boot" sda1 partition. AFAIK, the instructions that lead you to reserve 2MB at the front of the disk were so that grub-install wouldn't overwrite something important - hence the label "BIOS boot" - I assume this partition isn't formatted ext4, vfat or anything else, it's just reserved space over which grub-install will have trampled.
<edit>To clarify, GRUB BIOS install writes the boot loader plus all the grub modules it thinks you need to the start of the device specified in grub-install. In legacy GRUB, that all fitted in the MBR, In GRUB2, there's too much, so they tell you to reserve the first 2M of disk for GRUB's use</edit>
Put all that together, I'm pretty sure you're booting from the MBR on sda, and your grub should be using that.
According to the "info grub" page on troubleshooting, grub starts with its "prefix" set from a value hard-coded into the grub executable. Ergo, reboot, when the grub menu appears, hit C to enter the command line, and execute "set" to see the environment and shell variables. "prefix" tells you where grub believes whence it was loaded. Something like | Code: | | (hd0,msdos1)/boot/grub |
Of course, if you've been really clever, that might be a lie... You should also see "platform" or "grub_platform" which should say "PC", not "EFI".
ASIDE: anyone reading this migrated their system to grub 2.06? I mean not just upgrading the package 'cos emerge does that, but then running grub-install to update the system. I've not had the nerve yet....
_________________
Greybeard |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2014
|
| Posted: Wed Jul 14, 2021 8:49 am Post subject: |
|
|
Afterthought: check your grub.cfg doesn't change "prefix". Otherwise you'll get what your cfg says, not what's hard coded.
_________________
Greybeard |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1549
Location: South America
|
| Posted: Wed Jul 14, 2021 1:35 pm Post subject: |
|
|
| pjp wrote: | In what I can only guess was intended to be a flexible installation, my old setup included: | Code: | /dev/sda1 2048 6143 4096 2M BIOS boot
/dev/sda2 6144 268287 262144 128M EFI System |
|
The partition types shown here suggest that /dev/sda has a GPT. Nevertheless, I agree with Goverp, this machine probably doesn't have UEFI support, and GRUB boots in legacy BIOS mode. In that case, part of GRUB would be in the (protective) MBR, and the rest of it would be in /dev/sda1, which doesn't have a filesystem indeed. grub-install just writes to it. Modules and other support files are in the grub/ directory of /dev/sda2.
| pjp wrote: | Never mind the EFI partition type as it is being used as ext4: | Code: | % mount |grep sda2
/dev/sda2 on /mnt/sda2 type ext4 (rw,relatime,data=ordered) |
The file system includes what you'd expect from a /boot file system with grub files.
Is there a way to verify where grub-install put data? |
I don't know if you can 'prove' that GRUB data is there, since /dev/sda1 does not have a filesystem, and the MBR would contain machine code, but I believe that grub-install for target x86_64-efi refuses to install the bootloader's EFI executable to a filesystem that is not FAT, you likely don't have a /boot/EFI/gentoo/grubx64.efi file, and the subdirectory of /boot/grub that contains the modules is likely named i386-pc.
| Goverp wrote: | | AFAIK, the instructions that lead you to reserve 2MB at the front of the disk were so that grub-install wouldn't overwrite something important - hence the label "BIOS boot" |
Those instructions are for a MS-DOS partition table. There is no BIOS boot partition in that case, and GRUB installs itself in the space after the MBR, so what grub-install should not overwrite are the first sectors of the first partition.
If there's a GPT, I believe it immediately follows the protective MBR.
| Goverp wrote: | "prefix" tells you where grub believes whence it was loaded. Something like | Code: | | (hd0,msdos1)/boot/grub |
|
It would be (hd<some number>,gpt1)/boot/grub for a disk with a GPT.
| Goverp wrote: | | ASIDE: anyone reading this migrated their system to grub 2.06? |
Works on VirtualBox at least, both in UEFI and legacy BIOS emulation. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Wed Jul 14, 2021 3:55 pm Post subject: |
|
|
Thanks.
I know it is not currently using EFI, I just don't know if the hardware can support it.
The disk is using GPT. Entries in grub.cfg refer to set root="hd0,gpt2".
I guess I'll have to settle for deduction on what it isn't to accept what it probably is :).
It seems like there could be a utility that could check for a signature where it would write one, but perhaps the signature isn't consistent?
I'm also recalling that this was likely the first time using GPT disks, so I haven't completely absorbed the new GPT way of doing things. The drive would have been powered on for 9 years this December, and I don't think I've dealt with GPT booting since its initial setup.
The Grub2 wiki page does help clarify what's going on, but I don't see anything about verification. I haven't followed any of the links. Either that or maybe a forum post is probably how I settled on 2M (now I'm wondering if I should use 4M or more given the law of code expansion over time).
I'll update for confirmation after I've installed grub to the new drive and confirm that it boots, or at least tries to. I've never done a system migration with rsync, so I'm still anxious about how well that went.
Thanks again!
EDIT:
This adds some visual clarity and provides some search terms ({boot,core}.img):
https://en.wikipedia.org/wiki/BIOS_boot_partition#Overview
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54320
Location: 56N 3W
|
| Posted: Wed Jul 14, 2021 4:27 pm Post subject: |
|
|
pjp,
If the EFI system partition is formatted ext4, it can't possibly be using EFI.
EFI firmware can only read vfat, so with your setup, grub would never be loaded. You would notice that :)
The BIOS boot partition is is used by grub2 when you BIOS boot a drive with a GPT, as there is no free space before the first partition for grub to use.
The gory detail is in that link.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Thu Jul 15, 2021 5:52 am Post subject: |
|
|
Thanks, I'll read the gory details soon.
EFI was never really a question here and I was only trying to describe that oddity of the appearance of my configuration. It Seemed Like A Good Idea At The Time to use the EFI partition type such that I would know it could be used for it in a future scenario.
Anyway, booting only partially works.
Grub loads from the new (sdb) drive. I had to add a visual identifier to know that was happening. I also had to modify set root= from "hd0" to "hd1". I based that on sda working as hd0 and: | Code: | % grub-probe -d /dev/sdb2 -t compatibility_hint
hd1,gpt2 |
After that, the system appears to boot to the old, sda drive.
I hadn't yet changed /etc/fstab on the new drive, so I changed the UUIDs for /boot and / to refer to sdb. However, it still loads sda.
My current guess is that the initrd must have a reference to the old drive and loads it when it does the pivot_root.
A better solution would probably be swapping positions / connections for sda and sdb. I'll try that tomorrow.
EDIT:
<narrator>But it was not a better solution.</narrator>
Or at least I wasn't paying attention to the rest of the story. Specifically the kernel boot line that has root=UUID=<...> which points to... the old drive.
EDIT 2:
Changing the UUID for the kernel boot entry solved the problem.
With that part of the migration complete, now I can do the data management I tried to start many moons ago.
Thanks again!
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
