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(a)lists.fedoraproject.org <mailto: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(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