2:40 p.m.
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?
--
Michael hennebry(a)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
4:28 p.m.
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.
--
Lester M Petrie
4:46 p.m.
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.
--
Michael hennebry(a)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
5:30 p.m.
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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
6:02 p.m.
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(a)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(a)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
6:44 p.m.
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(a)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(a)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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
8:52 p.m.
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.
--
Michael hennebry(a)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
10:13 p.m.
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.
--
Michael hennebry(a)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
10:41 p.m.
When I ran grub2-install, I used /dev/sda .
Should I have used /dev/sda3 ?
--
Michael hennebry(a)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
10:26 a.m.
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(a)web.cs.ndsu.nodak.edu> wrote:
>
> When I ran grub2-install, I used /dev/sda .
> Should I have used /dev/sda3 ?
>
> --
> Michael hennebry(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
12:37 p.m.
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.
--
Michael hennebry(a)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
12:40 p.m.
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(a)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
1:22 p.m.
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(a)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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
2:37 p.m.
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(a)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
3:05 p.m.
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(a)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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
3:51 p.m.
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(a)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
4:07 p.m.
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(a)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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
4:35 p.m.
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(a)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
4:56 p.m.
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(a)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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
5:37 p.m.
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(a)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
6:26 p.m.
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(a)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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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
12:17 a.m.
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.
12:46 a.m.
On Fri, Apr 23, 2021 at 11:17 PM Samuel Sieb <samuel(a)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.
--
Chris Murphy
7:18 a.m.
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?
--
Michael hennebry(a)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
9:24 a.m.
On Sat, Apr 24, 2021, 6:18 AM Michael Hennebry <
hennebry(a)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
11:36 a.m.
New subject: success Re: machine will not boot after moving root
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
--
Michael hennebry(a)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
6:57 p.m.
New subject: success Re: machine will not boot after moving root
On Sun, Apr 25, 2021, 10:36 AM Michael Hennebry <
hennebry(a)web.cs.ndsu.nodak.edu> wrote:
Yes.
--
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
9:39 p.m.
On Fri, Apr 23, 2021 at 2:51 PM Michael Hennebry
<hennebry(a)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 /
--
Chris Murphy
12:10 a.m.
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.
12:31 a.m.
On Fri, Apr 23, 2021 at 11:11 PM Samuel Sieb <samuel(a)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.
--
Chris Murphy
12:07 a.m.
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.
11:59 a.m.
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.
5:31 p.m.
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?
--
Michael hennebry(a)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
9:31 p.m.
On Thu, Apr 22, 2021 at 1:41 PM Michael Hennebry
<hennebry(a)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.
--
Chris Murphy
1132
days inactive
1135
days old
35 comments
7 participants
participants (7)
-
Chris Murphy -
Joe Zeff -
Lester M Petrie -
Lukas Middendorf -
Michael Hennebry -
Roger Heflin -
Samuel Sieb