I’m trying to make more room for rootfs since, with every growing system requirements, it is now too small. I booted to live image and made two copies of current rootfs on two spare partitions. Once with dd the other with cp -a . This system did not have separate /boot so all three have a complete bootable image. I also made clone of /boot on a small 4GB partition since I would prefer to separate it anyway.
The dd clone had a identical UUID so I changes one of them to avoid confusion.
I’m having difficulty getting to boot to either of the new fs partitions.
One of key config lines in /boot/grub2/grub.cfg it setting grub’s “root”. This means it already has to know which partition has the required /boot/grub2/grub.cfg
By deduction I’m guessing that this is set by grub2-install and must be hard coded into the bootloader in the MBR ( this is a BIOS system not effing EFI ) . Presumably it just assumes that you want to carry on with the same installed fs so it just comes back to the old rootfs.
man grub2-install does not seem to provide any means of setting a new “root” for grub.
How can I get it to look at the new boot partition ( /dev/sda2 ) where I can then set it to use the new rootfs ?
In this configuration, I would let grub2-mkconfig do it’s job, it should find the two other installations.
Boot as usual, and type “grub2-mkconfig -o /boot/grub2/grub.cfg”
Mount /dev/sda2 as /mnt/sda2 and check that /mnt/sda2/etc/fstab points to the correct locations.
Reboot and boot the kernel on /dev/sda2, and type “grub2-mkconfig -o /boot/grub2/grub.cfg” and “grub2-install /dev/sda” from there. From that moment on, the /boot on sda2 should be the active one.
Thanks, sadly grub2-mkconfig does NOT pick up the clones. I just get the old boot , memtest86 and the original windows boot.
I’m guessing that it does not make duplicate entries for the same kernel. If it was a different OS or an earlier Fedora it would get a separate entry.
It now boots to the dd clone which still has the space problem since it has not been resized to fill its new partition and since it is now rootfs, I can’t resize it. I think it now boots there since the UUID got cloned too, and it was a lower numbered partition which was the first match to that UUID.
I would like to boot from a live image but this is a remote system, so that is not really feasible.
I would still like to know the answer to the original question: how is the partition where grub.cfg is initially read from determined and how can I change it?
That’s a problem. May be the new BLS system interferes where boot entries are stored in /boot/loader/entries. Those are cloned. You can disable it and try the grub2-mkconfig again.
“You can disableBLS support by setting GRUB_ENABLE_BLSCFG=false in /etc/default/grub”
There exists also a method described in using the rescue system. You are not able to use a rescue system, but you start from a running system. If you mount your desired partition as e.g. /mnt/sda3, you have to mount dev, sys, proc into /mnt/sda3/dev and so on.
Then chroot into /mnt/sda3 and do the grub2-mkconfig and grub2-install from there.
I do not know how to change the boot partition in another way.
It might be possible to install grub in /dev/sda3 and add a chainloader to it in the original grub.cfg, but I never tried this.
Or take a kernel and modify the root option, so take the kernel from sda1 and the root from sda3.
Equally named lvm’s might be another source of problems…
Yes, that sounds like a way out. I was wondering about chroot solution and that is why I need to know how and this initial choice of where grub.cfg lies is made. It would seem this has to be done by grub2-intstall and I would expect a parameter to allow this to be set explicitly but I can’t find one in the man page.
Equally named lvm’s might be another source of problems…
Good point , but I don’t use LVM, EFI and don’t want to deal with BLS, I don’t need yet more levels of indirection and virtualisation making thing ever more complicated and difficult to administer in case of problems.
I know I can set BLS off in /env/default but I was told by a dev not to do that on Fed29 since it does not have BLS by default.
Where can I find explicit instructions on how to do that right?
TIA.
Instructions how to do the chroot: https://www.centos.org/forums/viewtopic.php?t=16052
In order to grub-install to work, you have to transfer the dev, sys and proc filesystem to the chroot by mounting it into there.
I looked into grub-install: this starts with grub-mkimage to create a grub runtime based on the currently running system. Finally, it writes a boot block in the bootsector referring to this runtime. So as far I know, grub always gets its information from the /boot/grub2/grub.cfg of the last grub-install, I’ve seen no possibility to change this too, you can specify the /boot location but only within the running system.
Finally, it could be possible to boot anything from the grub shell, with e.g.
linux16 (hd0,2)/boot/vmlinux… root=/dev/sda2
initrd (hd0,2)/boot/initramfs…
boot
but that’s not easy and prone to typos. At least you do not have the risk to mess up the grub.cfg by editing it manually. And of course you should have access to the remote console…