On 3/18/20 11:50 PM, Robert McBroom via users wrote:
On 3/18/20 1:00 PM, Tom Horsley wrote:
On Wed, 18 Mar 2020 11:09:23 -0400
Robert McBroom via users wrote:
/etc/grub2.cfg
That's usually a link to the "real" file, and some
editors don't do well with links. Might want to check
the actual file down under /boot somewhere (location
varies for old dos versus uefi installs).
I use emacs which has yet to have any problem with links. Also looked
at /boot/grub2/grub.cfg as well.
This is a legacy system but the recent changes in grub2 for "Boot
Loader Specification" have added many quirks. I had missed that the
grub menu entries come from the *.conf files in /boot/loader/entries.
I'm not even using uefi, yet for some reason I have
both these links:
/etc/grub2.cfg -> ../boot/grub2/grub.cfg
/etc/grub2-efi.cfg -> ../boot/efi/EFI/fedora/grub.cfg
True, the empty dummy entries are put in place holders in /boot and
/boot/grub2 even though they are not used.
There are also references to things like "hd0,msdos2"
in grub.cfg which may need fixing as well. Possibly
there is a device.map file that needs fixing as well?
Tracked the entries for a DOS partitioned disk remembering that the
disk count starts from 0 and the partition count starts from1, Simple
since there is only one 1T disk. Likewise for device.map the entry is
(hd0) /dev/sda
I do this all the time to install a new fedora where I want
it by installing in a virtual machine then using guestmount
and rsync to put it on a "real" disk and boot it from
a stand alone grub partition using the "configfile" option.
Haven't tackled "virtual machine", what is your host?
I've never seen a uuid make it's way into an initramfs
file before, but if you can get booted by hook or
by crook, "dracut -f" forces a rebuild.
The message from dracut about initramfs was a red herring.
Fixing the *.conf entries in /boot/loader/entries gets the UUID
problem solved and I get to the login screen but my logins are not
accepted. Copied the original to usb disk from the source with a
Knoppix live disk so there was nothing being executed by the file
system. Then from the usb disk to a the partition on the target system
again with Knoppix. The /boot was on a separate partition on the
source and to a separate partition on the target system.
What is the login process looking for that is missing?
_______________________________________________
The problems was selinux. Used the chroot process to edit
/etc/selinus/config and disable selinux. Cloning is successful.
Recap
Knoppix DVD used to copy working Fedora 31 /boot and / to a usbdisk with
rsync. If separate, /home and /var also
Using gparted on Knoppix on the new system make space for /boot and /,
etc. where desired.
Copy /boot and /, etc. to the new locations with rsync.
Using a Fedora Workstation live USB drive, boot and logoff to get out of
graphics mode. Ctrl-alt f3 to a texmode and login with liveuser.
su - to root
From the documentation
https://docs.fedoraproject.org/en-US/Fedora/22/html/Multiboot_Guide/common_operations_appendix.html
structure the file system on the target and do the chroot.
Fix the UUID entries in /etc/fstab, /boot/grub2.cfg,
/boot/grub2/grubenv, /grub/loader/*.conf
edit /etc/selinux/config to disable selinux
system 1 cloned to system 2
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
