Imaged to 2nd disk, login fails on new one

[mathog]

I had a copy of Ubuntu on sda and CentOS 8 on sdb and wanted to make a bootable copy of the latter on the first disk.

Used gparted to make the same partitions on sda as on sdb.

Used tar (with one file system switch) to copy / (root), /boot, and /home from sdbX to sdaX.

Modified /etc/fstab on the sda copy so that the blkids matched for the partitions on that disk.

Made a new /boot/grub2/grub.cfg with grub2-mkconfig. It saw the sda copy of CentOS and added it to the menu.

Reboot, select the sdb version, it comes up and works normally.

Reboot, select the sda version, it comes up with a just a couple of warnings (which flew by too quickly to read) and put up the usual login prompt. This is text mode, no X11 involved.

Here's where things stop working. Tried logging in as "root". After entering the password it goes right back to the text login prompt, as if the credentials were bad.

So, what did I do wrong?

This is a standalone machine, no NFS, ldap, NIS, etc.

Thanks.

[chemal]

Unless specified, tar doesn't include extended attributes (capabilities, acls, selinux contexts, ...). The author of star says, GNU tar doesn't get it right anyway.

[mathog]

Unless specified, tar doesn't include extended attributes (capabilities, acls, selinux contexts, ...). The author of star says, GNU tar doesn't get it right anyway.

Yeah, I didn't have the extended attributes flag set on tar. That could be it. "dd" isn't an option here because the disks are different sizes so the partitions are not precisely 1:1 in space allocated. These are all xfs partitions. If "tar" does not cut it what would? xfsdump? I recall using "star" once, about 20 years ago.

[MartinR]

From man xfsdump:

To copy the contents of a filesystem to another directory (see xfsrestore(8)):
# xfsdump -J - / | xfsrestore -J - /new

[mathog]

The xfsdump/xfsrestore was run on the /boot, /, and /home partitions.

/etc/fstab was modified (again) with the correct blkid values

Grub was generated again with:

Code: Select all

grub2-mkconfig --output=/boot/grub2/grub.cfg

Reboot, it shows the /sda CentOS 8 and after it boots logins work.

However...

It is not an exact copy!

1. The graphics come up differently (different resolution both during boot process and once X11 starts).
This probably relates to kernel parameters being set differntly.

2. Some things do not start and it isn't even the same kernel! Example:

Code: Select all

grep -i rpc /var/log/messages
Jan 14 12:36:52 poweredge systemd[1]: Mounting RPC Pipe File System...
Jan 14 12:36:52 poweredge mount[863]: mount: /var/lib/nfs/rpc_pipefs: unknown filesystem type 'rpc_pipefs'.
Jan 14 12:36:52 poweredge systemd[1]: Starting RPC Bind...
Jan 14 12:36:52 poweredge systemd[1]: var-lib-nfs-rpc_pipefs.mount: Mount process exited, code=exited status=32
Jan 14 12:36:52 poweredge systemd[1]: var-lib-nfs-rpc_pipefs.mount: Failed with result 'exit-code'.
Jan 14 12:36:52 poweredge systemd[1]: Failed to mount RPC Pipe File System.
Jan 14 12:36:52 poweredge systemd[1]: Dependency failed for rpc_pipefs.target.
Jan 14 12:36:52 poweredge systemd[1]: Dependency failed for RPC security service for NFS client and server.
Jan 14 12:36:52 poweredge systemd[1]: rpc-gssd.service: Job rpc-gssd.service/start failed with result 'dependency'.
Jan 14 12:36:52 poweredge systemd[1]: rpc_pipefs.target: Job rpc_pipefs.target/start failed with result 'dependency'.
Jan 14 12:36:53 poweredge systemd[1]: Started RPC Bind.
grep -i iptables /var/log/messages
Jan 14 12:36:54 poweredge systemd[1]: Starting IPv4 firewall with iptables...
Jan 14 12:36:56 poweredge iptables.init[903]: iptables: Applying firewall rules: iptables-restore/1.8.4 Failed to initialize nft: Protocol not supported
Jan 14 12:36:56 poweredge iptables.init[903]: [FAILED]
Jan 14 12:36:57 poweredge systemd[1]: iptables.service: Main process exited, code=exited, status=1/FAILURE
Jan 14 12:36:57 poweredge systemd[1]: iptables.service: Failed with result 'exit-code'.
Jan 14 12:36:57 poweredge systemd[1]: Failed to start IPv4 firewall with iptables.
/var/log/messages | tail -1
Jan 14 12:36:53 poweredge smartd[890]: smartd 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-147.5.1.el8_1.x86_64] (local build)


mount /dev/sdb3 /mnt/foo
grep -i rpc /mnt/foo/var/log/messages
Jan 14 12:34:56 poweredge systemd[1]: Mounting RPC Pipe File System...
Jan 14 12:34:56 poweredge systemd[1]: Starting RPC Bind...
Jan 14 12:34:56 poweredge kernel: RPC: Registered named UNIX socket transport module.
Jan 14 12:34:56 poweredge kernel: RPC: Registered udp transport module.
Jan 14 12:34:56 poweredge kernel: RPC: Registered tcp transport module.
Jan 14 12:34:56 poweredge kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
Jan 14 12:34:56 poweredge systemd[1]: Mounted RPC Pipe File System.
Jan 14 12:34:56 poweredge systemd[1]: Reached target rpc_pipefs.target.
Jan 14 12:34:56 poweredge systemd[1]: Started RPC Bind.
grep -i iptables /mnt/foo/var/log/messages
Jan 14 12:34:57 poweredge systemd[1]: Starting IPv4 firewall with iptables...
Jan 14 12:35:00 poweredge iptables.init[733]: iptables: Applying firewall rules: [  OK  ]
Jan 14 12:35:01 poweredge systemd[1]: Started IPv4 firewall with iptables.
grep 4.18 /mnt/foo/var/log/messages | tail -1
Jan 14 12:34:58 poweredge smartd[731]: smartd 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-193.19.1.el8_2.x86_64] (local build)

So why did grub2-mkconfig use an older kernel when it set things up for sda??? Note, here are the relevant files from /boot

Code: Select all

ls -tal /boot/initramfs*
-rw-------. 1 root root 17203889 Oct 13 09:24 /boot/initramfs-4.18.0-193.19.1.el8_2.x86_64kdump.img
-rw-------. 1 root root 25178467 Oct 12 10:57 /boot/initramfs-4.18.0-193.19.1.el8_2.x86_64.img
-rw-------. 1 root root 25180850 Sep 21 14:11 /boot/initramfs-4.18.0-193.6.3.el8_2.x86_64.img
-rw-------. 1 root root 25180787 Sep 21 14:11 /boot/initramfs-4.18.0-193.14.2.el8_2.x86_64.img
-rw-------. 1 root root 17549273 Aug 31 09:46 /boot/initramfs-4.18.0-193.14.2.el8_2.x86_64kdump.img
-rw-------. 1 root root 17531150 Jul 15  2020 /boot/initramfs-4.18.0-193.6.3.el8_2.x86_64kdump.img
-rw-------. 1 root root 17517234 Jul 14  2020 /boot/initramfs-4.18.0-147.5.1.el8_1.x86_64kdump.img
-rw-------. 1 root root 62457790 Mar 19  2020 /boot/initramfs-0-rescue-e22ad4d30b7a49d19af7fb42c14e2107.img
ls -tal /boot/vmlin*
-rwxr-xr-x. 1 root root 8920200 Sep 14 07:45 /boot/vmlinuz-4.18.0-193.19.1.el8_2.x86_64
-rwxr-xr-x. 1 root root 8920200 Jul 25 21:02 /boot/vmlinuz-4.18.0-193.14.2.el8_2.x86_64
-rwxr-xr-x. 1 root root 8913656 Jun 10  2020 /boot/vmlinuz-4.18.0-193.6.3.el8_2.x86_64
-rwxr-xr-x. 1 root root 8106744 Mar 19  2020 /boot/vmlinuz-0-rescue-e22ad4d30b7a49d19af7fb42c14e2107

When the older kernels were purged it apparently left the older initramfs files, and grub2-mkconfig chose to use the oldest of these for the other disk.

[lightman47]

Clonezilla? It seems to only require the target drive to be >= the size of the source drive.

[mathog]

The boot menu it created has the newer kernels for the sda disk, they are in a submenu under the last entry. They all have exactly the same name though and the only way to tell which kernel is used is to "e" on each one. This is all very odd because the kernels found on sdb are all shown by kernel name, and neatly ordered newest to oldest. The grub2-mkconfig seems to be using very different rules for adding entries found on other disks, even though in this case the ones found are exactly the same as those found on the current system disk. Maybe that is the problem - it is avoiding a naming collision? (And ends up creating a different one!)

The entries for sda3 look like (edited down from the grub.cfg)

Code: Select all

CentOS Linux 8 (Core) (on /dev/sda3)
Advanced options for CentOS Linux 8 (Core) (on /dev/sda3)
  CentOS Linux 8 (Core) (on /dev/sda3)
  CentOS Linux 8 (Core) (on /dev/sda3)
  CentOS Linux 8 (Core) (on /dev/sda3)
  CentOS Linux 8 (Core) (on /dev/sda3)

and the corresponding kernels for the last 4 are

Code: Select all

vmlinuz-0-rescue
vmlinuz-4.18.0-193.14.2.el8_2.x86_64
vmlinuz-4.18.0-193.19.1.el8_2.x86_64
vmlinuz-4.18.0-193.6.3.el8_2.x86_64

[mathog]

Edited the grub.cfg file so that those sda3 entries showed rescue or kernel number, which helped.
Reboot, when it gets to grub (from the MBR on sdb) select the most recent sda3 kernel, it comes up normally.
Once there did:

Code: Select all

grub2-mkconfig --output=/boot/grub2/grub.cfg

To set up its boot.cfg so that grub2 on sda MBR can boot OS on either disk. Reboot and change boot disk to sda in the BIOS. That dropped into grub rescue, either because the grub2 in the MBR on sda, which was from Ubuntu, was not expecting however CentOS 8 set things up, or the device.map on sda was wrong. To fix those issues:

Code: Select all

#boot normally from sdb, the original disk
mount /dev/sda3 /mnt/foo #root partition
mount /dev/sda1 /mnt/foo/boot #boot partition
export ROOTDIR=/mnt/foo
mount -o bind /sys  $ROOTDIR/sys #for network
mount -o bind /proc $ROOTDIR/proc #for network
mount -o bind /dev $ROOTDIR/dev  #or it cannot see /dev/sda to write it
chroot $ROOTDIR
# as copied both hd0 and hd1 map to /dev/sdb, but need to set this up
# so that it can boot either from sda MBR
cat >/boot/grub2/device.map <<'EOD'
# this device map was generated by anaconda
(hd0)      /dev/sda
(hd1)      /dev/sda
EOD
umount $ROOTDIR/sys 
umount $ROOTDIR/proc
umount $ROOTDIR/dev
reboot
#in BIOS select disk corresponding to sda as boot device, grub menu comes up, let it default,
#it comes up properly on sda3 using the MBR from sda
reboot
#in BIOS select disk corresponding to sda as boot device, grub menu comes up, find the option for sdb3 with current kernel, boot.
#it comes up properly on sdb3 using the MBR from sda

So all is good now, either disk's MBR can boot CentOS 8 on either disk.