I recently migrated a fresh F33 install from a single drive installation to Raid-1.  My eyes
and fingers that did the initial install is over 1,000 miles away.

The initial install:
/     /dev/sda3
/boot /dev/sda2
/swap /dev/sda1

The following is the process I used to migrate the OS to /dev/sdb.  Note I'm not using
a separate /boot partition and this is a legacy BIOS:
Device     Boot    Start        End    Sectors   Size Id Type
/dev/sdb1           2048   67110911   67108864    32G 82 Linux swap / Solaris
/dev/sdb2  *    67110912 1953525167 1886414256 899.5G fd Linux raid autodetect

mdadm -C /dev/md12 --homehost=yoda.example.com -n 2 -l 1 -e 1.2 -b internal /dev/sdb2 missing
mdadm --detail /dev/md12
#edit mdadm.conf add new array

mkdir /mnt/newroot
mount /dev/md12 /mnt/newroot
rsync -axAX --delete --info=progress2 /      /mnt/newroot/
rsync -axAX --delete --info=progress2 /boot/ /mnt/newroot/boot/
rsync -axAX --delete --info=progress2 /dev/  /mnt/newroot/dev/


mount -t proc proc /mnt/newroot/proc
mount -t sysfs sys /mnt/newroot/sys
#mount -o bind /dev /mnt/newroot/dev  not needed

chroot /mnt/newroot

## -- chroot'ed --
#grubby --info=ALL
##kernel command line rd.md.uuid= only assembles these Raid devices
##grubby --args="rd.md.uuid=1630fa68-5cea-44be-8808-9cca3dd46a15" --update-kernel=ALL
grubby --args=rd.auto --update-kernel /boot/vmlinuz-5.11.15-200.fc33.x86_64
dracut -f -v /boot/initramfs-5.11.15-200.fc33.x86_64.img 5.11.15-200.fc33.x86_64
lsinitrd /boot/initramfs-5.11.15-200.fc33.x86_64.img | less


blkid
edit fstab with UUID changes
#edit grub with UUID changes
# legacy BIOS
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sdb
# EFI
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

#dracut --regenerate-all --force
## -- chroot'ed end --


# EFI not chroot'ed
efibootmgr -c -d /dev/sda -p 3 -L "Fedora (new)" -l "\EFI\FEDORA\SHIMX64.EFI"

Booting (from 2nd drive) failed using a degraded array /dev/md12.  That's when I removed rd.md.uuid=
from the kernel command line.  No joy.  Then I added rd.auto to the command line and
removed AUTO +imsm +1.x -all from mdadm.conf and re-generated the initramfs and
re-ran:
grub2-install /dev/sdb

Note in the mdadm.conf man page that everything after AUTO is ignored.  After sucessfully
booting onto the new Raid-1 array, I fdisk'ed /dev/sda and added it to the array.  Also note
the use of rsync instead of tar.

Hope this helps,
Bill

On 4/25/2021 7:09 PM, Robert McBroom via users wrote:
On 4/25/21 5:34 PM, George N. White III wrote:
On Sun, 25 Apr 2021 at 17:04, Robert McBroom via users <users@lists.fedoraproject.org> wrote:
New drive has the same msdos partition structure as the old. Legacy
system with boot partition on a separate drive and from the root
partition. System boots in mode 3 as specified but entering id and
password flashes some text and returns to the login. Edited the grub
entry to try a graphical boot but still get textmode.

What can be done to get access to f33?

Were any original directories encrypted?   Can you boot in rescue mode? 
If not, then you may have to arrange an alternate bootable drive (Live distro?). 

Once you are booted in linux you can mount the root directory and do some
basic sanity checks for proper permissions, missing home directories, etc.  

More details of the command used to create the tar archive might be useful.  
You may be better off installing a fresh system and restoring just the home
directories and other changes outside the purview of distro (/opt, /usr/local, etc).

The drive was pulled out of the system to a usb external drive adapter on another system, mounted and entered from a terminal window.

in the mounted root of the partition the command used was

tar -czf /mnt/stor/system.gz *

to put the tarball on a NAS.

I can get to the F33 from an f31 install on the same computer, mounted on /mnt/sysimage and doing the binds to /dev, /proc, and /sys followed by

chroot gets me in to look at everything. Everything I look into looks correct. Short of ideas


_______________________________________________
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