I'm trying to move my root directory from sda5 to sda3. After running grub2-install and grub2-mkconfig, my machine will not boot. I performed the changes using a F33 live DVD which also fails to boot. After plugging in a USB-connected SD card with Centos 7 on it, the F33 live DVD decided to boot. It is what I am running now. The complaint is UUID 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a not found. While running F33 live DVD I get blkid | grep 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a /dev/loop1: LABEL="Anaconda" UUID="2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a" BLOCK_SIZE="4096" TYPE="ext4" /dev/mapper/live-rw: LABEL="Anaconda" UUID="2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a" BLOCK_SIZE="4096" TYPE="ext4" /dev/mapper/live-base: LABEL="Anaconda" UUID="2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a" BLOCK_SIZE="4096" TYPE="ext4"
I backed up sda5 with rsync -auHAXUUx . I copied from the backup with the same flags. I edited the new etc/fstab to point at sda3, actually LABEL=local3slash .
As root: grupb2-install grub2-mkconfig -o .../local3slash/boot/grub2/grub/cfg
Reboot failed and sent me to grub rewscue mode, about which I know nothing.
From .../local3slash/boot , grep -r -F 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a . ./grub2/grub.cfg: search --no-floppy --fs-uuid --set=root 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a ./grub2/grub.cfg: search --no-floppy --fs-uuid --set=root 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a ./grub2/grub.cfg: search --no-floppy --fs-uuid --set=root 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a ./grub2/grub.cfg: search --no-floppy --fs-uuid --set=root 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a ./grub2/grub.cfg: search --no-floppy --fs-uuid --set=boot 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a ./grub2/grub.cfg: search --no-floppy --fs-uuid --set=boot 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a ./grub2/grub.cfg: set kernelopts="root=UUID=2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a ro "
What is going on and what can I do about it?
On 4/22/21 1:40 PM, Michael Hennebry wrote:
I'm trying to move my root directory from sda5 to sda3. After running grub2-install and grub2-mkconfig, my machine will not boot.
I don't see any mention of your using dracut to rebuild your initramfs after making the changes.
On 4/22/21 4:19 PM, Joe Zeff wrote:
On 4/22/21 1:40 PM, Michael Hennebry wrote:
I'm trying to move my root directory from sda5 to sda3. After running grub2-install and grub2-mkconfig, my machine will not boot.
I don't see any mention of your using dracut to rebuild your initramfs after making the changes.
Also you probably need to edit /etc/fstab to point / to the new root.
On Thu, 22 Apr 2021, Lester M Petrie wrote:
On 4/22/21 4:19 PM, Joe Zeff wrote:
On 4/22/21 1:40 PM, Michael Hennebry wrote:
I'm trying to move my root directory from sda5 to sda3. After running grub2-install and grub2-mkconfig, my machine will not boot.
I don't see any mention of your using dracut to rebuild your initramfs after making the changes.
What is dracut? None of the sites I found in my research mentioned using it. Also, I'm not sure the boot sequence got foar enough for it to matter. I did not destroy sda5. I'd expect to be able to boot from it. That was not an option.
Also you probably need to edit /etc/fstab to point / to the new root.
That I did.
Nothing in dracut cares about what partition it is on, and grub is not finding the initramfs. Grub is failing to find the boot.cfg files and vmlinuz and inittramfs. So either you have the wrong grub being started or the right grub but it cannot find its config files.
Are you trying to move /root or /boot or is your /boot on /root without a separate /boot?
Did you set /dev/sda3 as bootable in whatever program you used to partition? (if not efi).
My general plan would be to set the new partition bootable with the partitioning program (fdisk there are options to find the option to set bootable) (this all assumes you aren't using EFI).
liveboot it. mount the new installs root (/) under /mnt mount the new install boot device under /mnt/boot mount -o bind /dev/ /mnt/dev mount -o bind /dev/pts /mnt/dev/pts mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys this allows the chroot system to access devices and other critical resources to be able to run.
if you are efi then you would need it mounted /dev/sda1 under /mnt/boot/efi
Then chroot /mnt and rerun the grub commands inside the chroot which should look like the system you want to boot.
The grub commands typically rely on finding /boot so if the new boot is not at /boot when you ran those commands then it won't work right.
On a rescue type boot the above mounting/chroot stuff allows the OS to be fixed with the installs tools to be used which is typically best.
if this is efi then efibootmgr and/or the efi menu would have been needed to point to the new /boot.
To further troubleshoot you probably need to provide a lot more details about exactly you were trying and how you were trying it
And what fstab is now and what it looked like before.
On Thu, Apr 22, 2021 at 4:56 PM Joe Zeff joe@zeff.us wrote:
On 4/22/21 3:46 PM, Michael Hennebry wrote:
What is dracut?
Try using man dracut. Man is your friend; trust man. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, 22 Apr 2021, Joe Zeff wrote:
On 4/22/21 3:46 PM, Michael Hennebry wrote:
What is dracut?
Try using man dracut. Man is your friend; trust man.
My kernel version is not changing. Should not dracut recreate the same image for the same kernel? Is the partition of the binary or the working directory an implicit input?
On Thu, 22 Apr 2021, Roger Heflin wrote:
Nothing in dracut cares about what partition it is on, and grub is not finding the initramfs. Grub is failing to find the boot.cfg files and vmlinuz and inittramfs. So either you have the wrong grub being started or the right grub but it cannot find its config files.
Are you trying to move /root or /boot or is your /boot on /root without a separate /boot?
When it was working, / , the root of the tree was on sda5. That partition included everything except /var and /home , which had their own separate partions.
Did you set /dev/sda3 as bootable in whatever program you used to partition? (if not efi).
No. Neither sda5 nor sda3 has ever been set as bootable. I was under the impression that the grubs did not care. I've never changed a bootable flag. sda1 , a Windows 7 partition is the only partition marked bootable.
My general plan would be to set the new partition bootable with the partitioning program (fdisk there are options to find the option to set bootable) (this all assumes you aren't using EFI).
liveboot it.
That means boot a live disk, correct?
mount the new installs root (/) under /mnt
aka sd3 aka local3slash
mount the new install boot device under /mnt/boot
I do not have a separate boot partition, so no need for this?
mount -o bind /dev/ /mnt/dev mount -o bind /dev/pts /mnt/dev/pts mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys this allows the chroot system to access devices and other critical resources to be able to run.
Now what? Run dracut?
On Thu, Apr 22, 2021 at 4:56 PM Joe Zeff joe@zeff.us wrote:
On 4/22/21 3:46 PM, Michael Hennebry wrote:
What is dracut?
Try using man dracut. Man is your friend; trust man.
Then whatever windows is using to boot is pointing to grub, and that needs to be repointed to the new device.
I don't believe grub-install does anything with that.
On Thu, Apr 22, 2021 at 6:03 PM Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Thu, 22 Apr 2021, Roger Heflin wrote:
Nothing in dracut cares about what partition it is on, and grub is not finding the initramfs. Grub is failing to find the boot.cfg files and vmlinuz and inittramfs. So either you have the wrong grub being started or the right grub but it cannot find its config files.
Are you trying to move /root or /boot or is your /boot on /root without a separate /boot?
When it was working, / , the root of the tree was on sda5. That partition included everything except /var and /home , which had their own separate partions.
Did you set /dev/sda3 as bootable in whatever program you used to partition? (if not efi).
No. Neither sda5 nor sda3 has ever been set as bootable. I was under the impression that the grubs did not care. I've never changed a bootable flag. sda1 , a Windows 7 partition is the only partition marked bootable.
My general plan would be to set the new partition bootable with the partitioning program (fdisk there are options to find the option to set bootable) (this all assumes you aren't using EFI).
liveboot it.
That means boot a live disk, correct?
mount the new installs root (/) under /mnt
aka sd3 aka local3slash
mount the new install boot device under /mnt/boot
I do not have a separate boot partition, so no need for this?
mount -o bind /dev/ /mnt/dev mount -o bind /dev/pts /mnt/dev/pts mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys this allows the chroot system to access devices and other critical resources to be able to run.
Now what? Run dracut?
On Thu, Apr 22, 2021 at 4:56 PM Joe Zeff joe@zeff.us wrote:
On 4/22/21 3:46 PM, Michael Hennebry wrote:
What is dracut?
Try using man dracut. Man is your friend; trust man.
-- Michael hennebry@web.cs.ndsu.NoDak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, 22 Apr 2021, Roger Heflin wrote:
Then whatever windows is using to boot is pointing to grub, and that needs to be repointed to the new device.
I'll try changing the bootable flag. There has never been a windows partition in sda5, so something else, possibly the Fedora installer, must have affected what the top bootloader does.
I don't believe grub-install does anything with that.
On Thu, 22 Apr 2021, Michael Hennebry wrote:
On Thu, 22 Apr 2021, Roger Heflin wrote:
My general plan would be to set the new partition bootable with the partitioning program (fdisk there are options to find the option to set bootable) (this all assumes you aren't using EFI).
liveboot it.
That means boot a live disk, correct?
mount the new installs root (/) under /mnt
aka sd3 aka local3slash
mount the new install boot device under /mnt/boot
I do not have a separate boot partition, so no need for this?
mount -o bind /dev/ /mnt/dev mount -o bind /dev/pts /mnt/dev/pts mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys this allows the chroot system to access devices and other critical resources to be able to run.
Did all that. Did a chroot to /mnt . Moved the latest .img file to a .old file. Ran dracut with --kver option. It complained about the lack of /var/tmp . Ran mount without options to mount fstab entries. Ran dracut again. It replaced the .img file. I tried to reboot. Same error message.
'Tis rather obvious by now that reinstalling would have been much simpler. grub2 is just too hard for me. I'd like to understand what is going on, but I'd also like a computer that runs. If I do not have it working tomorrow, I'm going to do just that.
When I ran grub2-install, I used /dev/sda . Should I have used /dev/sda3 ?
I am not sure which it needs. If it did not stop windows from booting then it may have updated the wrong thing.
Try /dev/sda3 it will either work or give you an error in my experience.
What OS does the main boot loader come from and/or is the machine EFI? Something in the main boot loader will be pointing to sda5 still I would guess. I have not had any dual boot machines so I don't know much about how that works.
If it is dropping to the grub shell that is a sign that it did not find the /boot partition or nothing is on the /boot partition and/or the config files and such. So it is finding grub but not /boot, but it is not clear if this is the sda3 grub or the sda5 grub.
if you are using EFI (and not legacy-legacy would have required a bios setting change on any hw build in the last 7+ years) then you probably need to get into the EFI menu and use it to fixit.
Though if you have EFI, livecd boot (and possibly chroot type rescue ) and type efibootmgr if that returns boot info that is where the boot magic is, and you will either need to switch to sda3 there or in the bios/efi cli menu.
man efibootmgr and/or google efibootmgr. And if it is in you should grub-install on sda3.
On Thu, Apr 22, 2021 at 10:41 PM Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
When I ran grub2-install, I used /dev/sda . Should I have used /dev/sda3 ?
-- Michael hennebry@web.cs.ndsu.NoDak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 23/04/2021 00:30, Roger Heflin wrote:
Nothing in dracut cares about what partition it is on,
That is not completely true. The correct file system kernel modules (or what else is needed to access the root partition) have to be included in the intitrd. If the root file system type is changed (e.g. from ext4 to btrfs) the old initrd might not work.
if you are efi then you would need it mounted /dev/sda1 under /mnt/boot/efi
I think you also have to bind mount /sys/firmware/efi/efivars/ in this case.
I have BIOS, not UEFI.
On Fri, 23 Apr 2021, Roger Heflin wrote:
I am not sure which it needs. If it did not stop windows from booting then it may have updated the wrong thing.
Windows will not boot either.
Try /dev/sda3 it will either work or give you an error in my experience.
From what I have read, it will refuse or not depending on whether it gets a --force argument or some such.
What OS does the main boot loader come from and/or is the machine EFI? Something in the main boot loader will be pointing to sda5 still I would guess. I have not had any dual boot machines so I don't know much about how that works.
I believe that before I fiddled with it, the bootloader had come from the F33 install/live disk.
If it is dropping to the grub shell that is a sign that it did not find the /boot partition or nothing is on the /boot partition and/or the config files and such. So it is finding grub but not /boot, but it is not clear if this is the sda3 grub or the sda5 grub.
It complains about not finding UUID 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a . At the moment blklid tells me /dev/loop1: LABEL="Anaconda" UUID="2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a" BLOCK_SIZE="4096" TYPE="ext4" I'm running the F33 live/install disk.
ot@localhost-live liveuser]# mount /dev/sda3 /mnt [root@localhost-live liveuser]# cd /mnt [root@localhost-live mnt]# ls bin etc lib lost+found mnt2 root srv usr boot home lib64 media opt run sys var dev label.txt local3slash.mt mnt proc sbin tmp [root@localhost-live mnt]# grep -n -r -F 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a boot boot/grub2/grub.cfg:67: search --no-floppy --fs-uuid --set=root 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a boot/grub2/grub.cfg:69: search --no-floppy --fs-uuid --set=root 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a boot/grub2/grub.cfg:124: search --no-floppy --fs-uuid --set=root 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a boot/grub2/grub.cfg:126: search --no-floppy --fs-uuid --set=root 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a boot/grub2/grub.cfg:130: search --no-floppy --fs-uuid --set=boot 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a boot/grub2/grub.cfg:132: search --no-floppy --fs-uuid --set=boot 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a boot/grub2/grub.cfg:151: set kernelopts="root=UUID=2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a ro " [root@localhost-live mnt]#
A similar search on sda5 turns up empty.
The first six are all part of the following construct: if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a else search --no-floppy --fs-uuid --set=root 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a fi Except for a blank, the two lines are identical. I suspect this is a result of automation.
On Fri, 23 Apr 2021, Roger Heflin wrote:
I am not sure which it needs. If it did not stop windows from booting then it may have updated the wrong thing.
It did stop windows from booting. No menu. Nuthin.
If you used rsync to copy from one disk to the other then the uuid would have changed on the new fs as compared to the old fs. I typically copy /boot the hard crude way (dd) and copy LVM using the LVM tools (pvmove and friends) and in both cases that maintains the same UUID on the old and new.
You will need to find the new uuid and update grub to be using that anyplace it has the old uuid then reinstall it on sda if grub is going to boot first, or see if a microsoft install cd will fix the windows side of the system, or see below match the new fs to have the old uuid.
Once you get the system fixed to boot one then you need to use the working bootloader to boot the other system. There are instructions on how to boot windows from grub, and I believe also how to boot grub/linux from a windows boot loader, I assume some deviation of said instructions will work. I would probably lean to using grub to boot either as it seems to be better documented and is known to be able to boot a number of different oses. The one that boots first will be whichever bootloader gets installed directly on /dev/sda, then it will have something from the second bootable image that it loads to start the other OS when the other os'es menu option is selected.
grub2-probe looks like it might once bootedup and rescued might let you probe to confirm the new uuid.
I am not sure there is a way to without editing the cfg file to fix it.
It does appear that tune2fs (ext2/3/4) will let you set the uuid on a filesystem so you could set your new device to have the old uuid. if xfs then xfs_admin will let you do the same thing.
What was sda3 before that you could now use it for the system on sda5?
You might detail what the partition layout/usage was before and what you moved it to.
A partition table rework/new boot disk/device setup is never a simple job unless you have a very standard system layout and you have done a lot of testing, or are letting anaconda do it all.
On Fri, Apr 23, 2021 at 12:40 PM Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Fri, 23 Apr 2021, Roger Heflin wrote:
I am not sure which it needs. If it did not stop windows from booting then it may have updated the wrong thing.
It did stop windows from booting. No menu. Nuthin.
-- Michael hennebry@web.cs.ndsu.NoDak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, 23 Apr 2021, Roger Heflin wrote:
If you used rsync to copy from one disk to the other then the uuid would have changed on the new fs as compared to the old fs. I
Yup. Needed to change fstab.
typically copy /boot the hard crude way (dd) and copy LVM using the LVM tools (pvmove and friends) and in both cases that maintains the same UUID on the old and new.
I do not have a /boot partition. /boot is in the root, aka / , partition. I'm allergic to LVM. The first time I encountered it was in the middle of an install, not the time to try something unexpected and new.
You will need to find the new uuid and update grub to be using that anyplace it has the old uuid then reinstall it on sda if grub is going to boot first, or see if a microsoft install cd will fix the windows side of the system, or see below match the new fs to have the old uuid.
I thought I knew how to do that, but apparently not. The issue is not finding the new root IDs, the issue is what to do with it.
I considered directly copying sda5 to sda3 and changing the IDs on sda5. sda3 is more than twice as large as sda3. Whatever else I'd need to do, I'd need to enlarge the filesystem after. Does the enlarger work well for two to one enlargements?
What was sda3 before that you could now use it for the system on sda5?
A Windows 7 partition that I had not used in a long time.
You might detail what the partition layout/usage was before and what you moved it to.
I only changed partitions 2 and 3.
sda before: 1* 100 M Windows 7 boot? 2 28 G Windows 7 3 4.7 G garbage no fs 4 extended 5 9.3 G / 6 4.7 G /var 7 4.7 G swap 8 24.1 G /home
sda now (intended): 1 100 M Windows 7 boot? 2 100 M garbage 3 31.7 G / new 4 extended 5 9.3 G / retired 6 4.7 G swap 7 24.1 G /home
I assume it is still not bootable.
But if the windows system is gone and you don't care about it, then I would set sda3 to be bootable.
rescue it and then grub-install /dev/sda3 but make sure the newuuid is in both fstab (you have done that I think) and matches what is in the /boot/grub2/grub.cfg. if a different value is in the grub.cfg file then you can either make the actual fs uuid match that and update fstab to match, or edit the grub.cfg file that it says do not edit (I would think the grub2-install would fix that but it appears another command might be required for that--see below).
I did a test and it looks like this will update the grub.cfg file and it should use the new uuid, try it and see if it uses the correct uuid and verify the old file did not have the correct uuid.
grub2-mkconfig -o /boot/grub2/grub.cfg <save a copy of it first>
On Fri, Apr 23, 2021 at 2:37 PM Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Fri, 23 Apr 2021, Roger Heflin wrote:
If you used rsync to copy from one disk to the other then the uuid would have changed on the new fs as compared to the old fs. I
Yup. Needed to change fstab.
typically copy /boot the hard crude way (dd) and copy LVM using the LVM tools (pvmove and friends) and in both cases that maintains the same UUID on the old and new.
I do not have a /boot partition. /boot is in the root, aka / , partition. I'm allergic to LVM. The first time I encountered it was in the middle of an install, not the time to try something unexpected and new.
You will need to find the new uuid and update grub to be using that anyplace it has the old uuid then reinstall it on sda if grub is going to boot first, or see if a microsoft install cd will fix the windows side of the system, or see below match the new fs to have the old uuid.
I thought I knew how to do that, but apparently not. The issue is not finding the new root IDs, the issue is what to do with it.
I considered directly copying sda5 to sda3 and changing the IDs on sda5. sda3 is more than twice as large as sda3. Whatever else I'd need to do, I'd need to enlarge the filesystem after. Does the enlarger work well for two to one enlargements?
What was sda3 before that you could now use it for the system on sda5?
A Windows 7 partition that I had not used in a long time.
You might detail what the partition layout/usage was before and what you moved it to.
I only changed partitions 2 and 3.
sda before: 1* 100 M Windows 7 boot? 2 28 G Windows 7 3 4.7 G garbage no fs 4 extended 5 9.3 G / 6 4.7 G /var 7 4.7 G swap 8 24.1 G /home
sda now (intended): 1 100 M Windows 7 boot? 2 100 M garbage 3 31.7 G / new 4 extended 5 9.3 G / retired 6 4.7 G swap 7 24.1 G /home
-- Michael hennebry@web.cs.ndsu.NoDak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, 23 Apr 2021, Roger Heflin wrote:
I assume it is still not bootable.
But if the windows system is gone and you don't care about it, then I would set sda3 to be bootable.
Did that. Forgot to mention it.
rescue it and then grub-install /dev/sda3 but make sure the newuuid is
I've read that I need --force to grub2-install onto a partition. IIRC grub rescue did not find any partitions. Live F33 has no trouble.
in both fstab (you have done that I think) and matches what is in the /boot/grub2/grub.cfg. if a different value is in the grub.cfg file then you can either make the actual fs uuid match that and update fstab to match, or edit the grub.cfg file that it says do not edit (I would think the grub2-install would fix that but it appears another command might be required for that--see below).
The UUID not found is used by the F33 live DVD. Changing sda3's UUID to that seems a bad idea.
I did a test and it looks like this will update the grub.cfg file and it should use the new uuid, try it and see if it uses the correct uuid and verify the old file did not have the correct uuid.
grub2-mkconfig -o /boot/grub2/grub.cfg <save a copy of it first>
if you are doing the grub-install/grub2-mkconfig from inside the chroot then it should find the correct uuid (if it works like it should).
any of the test commands for grub need to be in the chroot otherwise they will think they are the livecd and not do the right thing or show the right thing as they will attempt to setup/look at install for current booted image.
Did you check to see if the uuid listed in /boot/grub2/grub.cfg root uuids (sda3 that contains the /boot directory) matches what tune2fs -l /dev/sda3 's uuid?
Since you are booting from a partition that uuid may also be on the kernel boot line(s) similar to root=<XXXX> and that will also need to be sda3's uuid.
It may also be in grubenv rather than directly on the boot lines.
The biggest change you seem to have made is changing the boot/rootfs'es uuid and grub seems to stick that in multiple places in its config files and on the kernel boot lines (in addition to the the fstab you knew about). And it does not appear that grub expects the uuid to ever change and so nothing outside of the grub2-mkconfig command redoes that, it it still may not rewrite to root= line on the kernelopts line.
On Fri, Apr 23, 2021 at 3:51 PM Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Fri, 23 Apr 2021, Roger Heflin wrote:
I assume it is still not bootable.
But if the windows system is gone and you don't care about it, then I would set sda3 to be bootable.
Did that. Forgot to mention it.
rescue it and then grub-install /dev/sda3 but make sure the newuuid is
I've read that I need --force to grub2-install onto a partition. IIRC grub rescue did not find any partitions. Live F33 has no trouble.
in both fstab (you have done that I think) and matches what is in the /boot/grub2/grub.cfg. if a different value is in the grub.cfg file then you can either make the actual fs uuid match that and update fstab to match, or edit the grub.cfg file that it says do not edit (I would think the grub2-install would fix that but it appears another command might be required for that--see below).
The UUID not found is used by the F33 live DVD. Changing sda3's UUID to that seems a bad idea.
I did a test and it looks like this will update the grub.cfg file and it should use the new uuid, try it and see if it uses the correct uuid and verify the old file did not have the correct uuid.
grub2-mkconfig -o /boot/grub2/grub.cfg <save a copy of it first>
-- Michael hennebry@web.cs.ndsu.NoDak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
The grub rescue mode finds only (hd0), no paritions at all.
On Fri, 23 Apr 2021, Roger Heflin wrote:
if you are doing the grub-install/grub2-mkconfig from inside the chroot then it should find the correct uuid (if it works like it should).
I did stuff in the chroot, but apparently not well.
any of the test commands for grub need to be in the chroot otherwise they will think they are the livecd and not do the right thing or show the right thing as they will attempt to setup/look at install for current booted image.
Did you check to see if the uuid listed in /boot/grub2/grub.cfg root uuids (sda3 that contains the /boot directory) matches what tune2fs -l /dev/sda3 's uuid?
I do not understand grub2 configuration files. sda3/boot/grub2/grub.cfg contains references both to sda3 and to the Anaconda file system from the F33 live DVD. I'm running a live Centos 7 right now.
Since you are booting from a partition that uuid may also be on the kernel boot line(s) similar to root=<XXXX> and that will also need to be sda3's uuid.
It may also be in grubenv rather than directly on the boot lines.
The biggest change you seem to have made is changing the boot/rootfs'es uuid and grub seems to stick that in multiple places in its config files and on the kernel boot lines (in addition to the the fstab you knew about). And it does not appear that grub expects the uuid to ever change and so nothing outside of the grub2-mkconfig command redoes that, it it still may not rewrite to root= line on the kernelopts line.
What is the exact error you are getting?
With the hard disk only does it find grub and does it display a menu or drop you to the grub> prompt?
If it displays a menu and you select one of them what does it then do?
The uuid will also be on the kernelopts line, but if that was the error you would have failure to mounted root after the kernel tried to boot.
all of the commands would need to be run in the chroot setup (after the chroot . and before exiting chroot-mainly the grub2-mkconfig that updates grub.cfg and the grub2-install for /dev/sda.
I would stay away from the centos boot, nothing it can do will be good since you are running a newer grub setup. It is better to use newer livecds than older ones (ie I f27 all of the time to rescue el5/6/7 version and chroot into the actual machine to be fixed environ after mounted it all).
On Fri, Apr 23, 2021 at 4:35 PM Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
The grub rescue mode finds only (hd0), no paritions at all.
On Fri, 23 Apr 2021, Roger Heflin wrote:
if you are doing the grub-install/grub2-mkconfig from inside the chroot then it should find the correct uuid (if it works like it should).
I did stuff in the chroot, but apparently not well.
any of the test commands for grub need to be in the chroot otherwise they will think they are the livecd and not do the right thing or show the right thing as they will attempt to setup/look at install for current booted image.
Did you check to see if the uuid listed in /boot/grub2/grub.cfg root uuids (sda3 that contains the /boot directory) matches what tune2fs -l /dev/sda3 's uuid?
I do not understand grub2 configuration files. sda3/boot/grub2/grub.cfg contains references both to sda3 and to the Anaconda file system from the F33 live DVD. I'm running a live Centos 7 right now.
Since you are booting from a partition that uuid may also be on the kernel boot line(s) similar to root=<XXXX> and that will also need to be sda3's uuid.
It may also be in grubenv rather than directly on the boot lines.
The biggest change you seem to have made is changing the boot/rootfs'es uuid and grub seems to stick that in multiple places in its config files and on the kernel boot lines (in addition to the the fstab you knew about). And it does not appear that grub expects the uuid to ever change and so nothing outside of the grub2-mkconfig command redoes that, it it still may not rewrite to root= line on the kernelopts line.
-- Michael hennebry@web.cs.ndsu.NoDak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, 23 Apr 2021, Roger Heflin wrote:
What is the exact error you are getting?
Something along the lines of UUID 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a not found.
With the hard disk only does it find grub and does it display a menu or drop you to the grub> prompt?
I get the grub prompt.
If it displays a menu and you select one of them what does it then do?
No menu.
The uuid will also be on the kernelopts line, but if that was the error you would have failure to mounted root after the kernel tried to boot.
The offending UUID is listed in the grub.cfg file in seven places. Not sure what that tells you.
Apparently grub can find sda3/boot/grub2/grub/cfg even though grub rescure can find no partitions, just (hd0).
all of the commands would need to be run in the chroot setup (after the chroot . and before exiting chroot-mainly the grub2-mkconfig that updates grub.cfg and the grub2-install for /dev/sda.
I would stay away from the centos boot, nothing it can do will be good since you are running a newer grub setup. It is better to use newer livecds than older ones (ie I f27 all of the time to rescue el5/6/7 version and chroot into the actual machine to be fixed environ after mounted it all).
After chroot I should get the grub stuff from sda3 , correct?
My DVD machine no longer likes my F33 DVD. I'll need to make a new one.
Is there a way to tell grub rescue to reboot without pressing the power button?
From what I can see with mine 7 places would be about right.
Is that uuid the current one for sda3 or the old uuid for sda5? if it is not the one for sda3 that would be an issue. It kind of looks like the *3a uuid is from the bootcd so that would be wrong, if you run the grub2-mkconfig and the grub2-install inside the chroot that should not be happening. but if you ran the command outside they would be using the info from the livecd. so is important to mount everything under /mnt with the commands from prior and then chroot . and then run the commands in that. then when you exit (in the chroot) you will go back to outside the chroot. It is possible that grub2-install/mkconfig does not work quite like the prior version of grub-install. If the root of the livecd is not mounted inside the chroot environment then there should be no way for it to get the other uuid (outside of reading it from either /proc/cmdline, or possibly relying on the symbolic links in sys that have the uuids in them pointing to the iso's root). if if it does not use sda3's uuid then you a manual edit may be required.
I have never used grub rescue so I am not sure. Did you try exit typically that would reboot, and if you exit back to another prompt then try reboot there. Not sure if ctrl-alt-del will work. "echo b > /proc/sysrq-trigger" might work if proc is mounted and sysrq-trigger is enabled.
the grub2-mkconfig will create a new file that you can use to replace the current grub.cfg and if the above uuid is not the uuid for sda3 that would need to happen. That uuid would appear to be telling grub where to find its config files and boot files. if that uuid was wrong in grub.cfg make sure to either update the one in grubenv or make sure the mkconfig does (the man page has an option to not update grubenv so it may do that right). Make sure that the uuid changes to the sda3 one in grub.cfg, if it is not changing you may need to manually edit both of them. I am not sure anyone has a nice set of instructions for changing the uuid/boot device.
The uuid is also probably going to be in grubenv but if you boot far enough that will get you a kernel crash/failure to find root.
On Fri, Apr 23, 2021 at 5:37 PM Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Fri, 23 Apr 2021, Roger Heflin wrote:
What is the exact error you are getting?
Something along the lines of UUID 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a not found.
With the hard disk only does it find grub and does it display a menu or drop you to the grub> prompt?
I get the grub prompt.
If it displays a menu and you select one of them what does it then do?
No menu.
The uuid will also be on the kernelopts line, but if that was the error you would have failure to mounted root after the kernel tried to boot.
The offending UUID is listed in the grub.cfg file in seven places. Not sure what that tells you.
Apparently grub can find sda3/boot/grub2/grub/cfg even though grub rescure can find no partitions, just (hd0).
all of the commands would need to be run in the chroot setup (after the chroot . and before exiting chroot-mainly the grub2-mkconfig that updates grub.cfg and the grub2-install for /dev/sda.
I would stay away from the centos boot, nothing it can do will be good since you are running a newer grub setup. It is better to use newer livecds than older ones (ie I f27 all of the time to rescue el5/6/7 version and chroot into the actual machine to be fixed environ after mounted it all).
After chroot I should get the grub stuff from sda3 , correct?
My DVD machine no longer likes my F33 DVD. I'll need to make a new one.
Is there a way to tell grub rescue to reboot without pressing the power button?
-- Michael hennebry@web.cs.ndsu.NoDak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a virgin." -- someeecards _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Apr 22, 2021 at 1:41 PM Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
I'm trying to move my root directory from sda5 to sda3.
This is much harder to do without LVM or Btrfs. For LVM there's more steps but basically it depends on 'pvmove'. And for Btrfs it's 'btrfs replace' - both are live migrations and so long as /boot is separate, nothing else needs to be changed or updated.
After running grub2-install and grub2-mkconfig,
If the computer has BIOS firmware, then grub2-install to a whole block device is indicated. If it's UEFI firmware, then grub2-install shouldn't be used. Instead use:
sudo dnf reinstall grub-* shim-*
Also note starting with Fedora 34 that UEFI and BIOS have /boot/grub2/grub.cfg now due to feature: https://fedoraproject.org/wiki/Changes/UnifyGrubConfig
my machine will not boot. I performed the changes using a F33 live DVD which also fails to boot. After plugging in a USB-connected SD card with Centos 7 on it, the F33 live DVD decided to boot. It is what I am running now. The complaint is UUID 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a not found. While running F33 live DVD I get blkid | grep 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a /dev/loop1: LABEL="Anaconda" UUID="2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a"
Sounds like /etc/fstab has the wrong UUID.
I backed up sda5 with rsync -auHAXUUx . I copied from the backup with the same flags. I edited the new etc/fstab to point at sda3, actually LABEL=local3slash .
OK but did you label the file system 'local3slash' at mkfs time?
As root: grupb2-install
This is missing a block device.
grub2-mkconfig -o .../local3slash/boot/grub2/grub/cfg
That's probably only going to work in a chroot where everything is properly assembled in advance. The easiest way to get it properly assembled for you is the rescue option in the troubleshooting menu on netinstall media.
And since /boot is a dir in the copied sysroot... yeah dracut.
A neat hint is to search a live install's program.log for 'rsync' to see what command is used for a live install.
08:18:29,672 INF program: Running... rsync -pogAXtlHrDx --exclude /dev/ --exclude /proc/ --exclude /tmp/* --exclude /sys/ --exclude /run/ --exclude /boot/*rescue* --exclude /boot/loader/ --exclude /boot/efi/loader/ --exclude /etc/machine-id /run/install/source/ /mnt/sysroot
A lot of that does translate into -a option.
On Fri, Apr 23, 2021 at 2:51 PM Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
I've read that I need --force to grub2-install onto a partition.
That's sufficiently unreliable that upstream GRUB has recommended against it for almost a decade.
First, what firmware type is this?
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
If this really is a computer with BIOS, it's something like:
grub2-install /dev/sda
And yes that steps on the Windows bootloader in the MBR. But grub2-mkconfig via os-prober should find the Windows bootloader and add a chainloader entry for it.
I'm actually betting dollars to donuts that this is a UEFI system, and grub2-install was used, and now it's looking for grub.cfg in the wrong location.
Fedora 33, UEFI:
sudo dnf reinstall grub2-* shim-* sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Fedora 34, UEFI:
sudo dnf reinstall grub2-* shim-* sudo grub2-mkconfig -o /boot/grub2/grub.cfg
The UUID not found is used by the F33 live DVD. Changing sda3's UUID to that seems a bad idea.
It is. You should use 'sudo blkid' and find out what UUID is on sda3 and put that into fstab for /
On 4/23/21 1:05 PM, Roger Heflin wrote:
But if the windows system is gone and you don't care about it, then I would set sda3 to be bootable.
The bootable flag is not relevant.
rescue it and then grub-install /dev/sda3 but make sure the newuuid is
grub needs to be installed to the raw hard drive (mbr), not a partition.
On 4/23/21 7:39 PM, Chris Murphy wrote:
I'm actually betting dollars to donuts that this is a UEFI system, and grub2-install was used, and now it's looking for grub.cfg in the wrong location.
His partition list has "extended" on sda4, so it looks like he's correct about it being BIOS.
On 4/23/21 3:37 PM, Michael Hennebry wrote:
On Fri, 23 Apr 2021, Roger Heflin wrote:
What is the exact error you are getting?
Something along the lines of UUID 2b82edc2-4eb2-44a0-8b5b-c71da0de9b3a not found.
When are you getting this error? Since you say grub isn't booting from the hard drive, what exact steps are you taking to get that?
With the hard disk only does it find grub and does it display a menu or drop you to the grub> prompt?
I get the grub prompt.
And this is where you can only see (hd0)? That sounds like grub is messed up now and can't find it's modules.
At this point I suggest you use the live boot to backup any config files you think you might need and just do a re-install. It will be a lot easier. Also backup your /home files just in case.
On Fri, Apr 23, 2021 at 11:11 PM Samuel Sieb samuel@sieb.net wrote:
His partition list has "extended" on sda4, so it looks like he's correct about it being BIOS.
Yep, I missed that.
grub2-install --force /dev/sdXY can work, even though it's not recommended upstream. I think it's still some confusion over something in fstab listing something that isn't found during startup.
It might be useful to see the /etc/fstab. Also, booting with rd.timeout=60 would at least get it to a (dracut/initramfs) prompt and from there mount any partition or USB stick, and save out a copy of the journal: journalctl -b > /path/to/rw/mount/journal.log
And then post the journal.log and /etc/fstab somewhere.
On Fri, Apr 23, 2021 at 11:17 PM Samuel Sieb samuel@sieb.net wrote:
On 4/23/21 3:37 PM, Michael Hennebry wrote:
With the hard disk only does it find grub and does it display a menu or drop you to the grub> prompt?
I get the grub prompt.
And this is where you can only see (hd0)? That sounds like grub is messed up now and can't find it's modules.
BIOS GRUB has two kinds of prompts:
grub> grub rescue>
If it is the former, that means it did find modules (well, in particular it found normal.mod at least), but did not find grub.cfg. That's curious given the sequence we know so far.
If it is the latter, then we're in core.img (stage 2) only, and it didn't find either grub.cfg or modules. This means core.img isn't pointing to the proper grub device and path, which is ordinarily baked into the core.img by grub2-mkimage which is part of what grub2-install does. So... yeah it's kinda confusing. But ordinarily a grub2-install /dev/sda will fix that.
But I'm not sure in what environment the commands are being issued. grub2-install can be pointed at an alternate root, but grub2-mkconfig is kinda fussy, and doesn't really do the alternate root routine very well. I've only found it reliable to run in a chroot of a properly assembled system. Netinstall rescue option does this for us, but Live boots don't have that so you have to assemble manually:
mount /dev/root /mnt/sysimage mount /dev/boot /mnt/sysimage/boot # in this case it's skipped because /boot is a dir on sysroot mount -B /dev /mnt/sysimage/dev mount -B /sys /mnt/sysimage/sys mount -B /proc /mnt/sysimage/proc mount -B /run /mnt/sysimage/run chroot
then do grub2-mkconfig -o /boot/grub2/grub.cfg
then reboot
I don't know if all of those are needed. /run probably isn't. But...
At this point I suggest you use the live boot to backup any config files you think you might need and just do a re-install. It will be a lot easier. Also backup your /home files just in case.
I agree. This is probably more grief than it's worth. Backup /home to some other drive entirely. And obliterate /dev/sda with automatic partitioning, using "reclaim space" to also Delete All. Or if allergic to both LVM and Btrfs, use "Custom-Automatic" UI, i.e. choose Custom, pick the Standard partition scheme popup, then the blue text to create partitions automatically. Install.
Two independent backups for anything important.
sda3/etc/fstab : # # /etc/fstab # Created by anaconda on Tue Nov 24 17:36:35 2020 # # Accessible filesystems, by reference, are maintained under '/dev/disk/'. # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info. # # After editing this file, run 'systemctl daemon-reload' to update systemd # units generated from this file. # LABEL=local3slash / ext3 defaults 1 1 UUID=9d52b44c-eb94-4398-9f36-a415d0290e6b /home ext3 defaults 1 2 UUID=0899193d-734b-4b85-9d8d-7c334571e3bb /var ext4 defaults 1 2
Proposed strategy: boot live DVD su mount /dev/sda3 /mnt mount /proc /mnt/proc mount /dev /mnt/dev mount /dev/pts /mnt/dev/pts chroot /mnt
mount # from fstab should do /var and /home
grub2-install /dev/sda3 grub2-mkconfig > /boot/grub2/grub.cfg exit # out of chroot?
reboot
Should work?
On Sat, Apr 24, 2021, 6:18 AM Michael Hennebry < hennebry@web.cs.ndsu.nodak.edu> wrote:
mount /dev/sda3 /mnt mount /proc /mnt/proc mount /dev /mnt/dev mount /dev/pts /mnt/dev/pts
You need to use -B to bind mount the pseudo filesystems, and probably also need to include /sys
grub2-install /dev/sda3 grub2-mkconfig > /boot/grub2/grub.cfg exit # out of chroot?
reboot
Should work?
grub2-install /dev/sda
-- Chris Murphy
On Sat, 24 Apr 2021, Chris Murphy wrote:
You need to use -B to bind mount the pseudo filesystems, and probably also need to include /sys
grub2-install /dev/sda
mount /dev/sda3 /mnt/a3 # already done mount -B /proc /mnt/a3/proc mount -B /dev /mnt/a3/dev mount -B /dev/pts /mnt/a3/dev/pts mount -B /sys /mnt/a3/sys
chroot /mnt/a3
grub2-install /dev/sda mount /var # grub2-mkconfig wants it grub2-mkconfig > /boot/grub2/grub.cfg exit # out of chroot?
reboot
On Sun, Apr 25, 2021, 10:36 AM Michael Hennebry < hennebry@web.cs.ndsu.nodak.edu> wrote:
On Sat, 24 Apr 2021, Chris Murphy wrote:
You need to use -B to bind mount the pseudo filesystems, and probably
also
need to include /sys
grub2-install /dev/sda
mount /dev/sda3 /mnt/a3 # already done mount -B /proc /mnt/a3/proc mount -B /dev /mnt/a3/dev mount -B /dev/pts /mnt/a3/dev/pts mount -B /sys /mnt/a3/sys
chroot /mnt/a3
grub2-install /dev/sda mount /var # grub2-mkconfig wants it grub2-mkconfig > /boot/grub2/grub.cfg exit # out of chroot?
reboot
Yes.
-- Chris Murphy
-
Chris Murphy -
Joe Zeff -
Lester M Petrie -
Lukas Middendorf -
Michael Hennebry -
Roger Heflin -
Samuel Sieb