System boots into emergency mode after migration to new disk

English Install/Boot/Login
1

Hi all,

I have just migrated my system from a 240 GB SATA hard drive to a 480 GB SATA SSD. I had pretty vanilla installation with a /swp (type unix sap), a / (type btrfs) and a /home (type xfs) partition, and I had duplicated this with bigger partitions and had already migrated the /swap and the /home to the new SSD, so just had to do the boot partition.

I followed the instructions here: https://www.suse.com/support/kb/doc/?id=7018639 and I used rsync to copy the boot drive data across rather than dd as I had already set up the partition table.

I did make a mistake doing the copy as entered “rsync -zahP /mnt /mnt2” instead of “rsync -zahP /mnt/ /mnt2/” so I ended up with a /mnt2/mnt folder, and rather than redo the rsync which too hours, I just moved everything from /mnt2/mnt to /mnt2 (maybe this is my problem ? ).

Anyhow, after that, I carried on with the procedure and I followed the steps for grub2 although I didn’t bother to change GRUB_CMDLINE_LINUX_DEFAULT as it wasn’t set on the old drive.

The procedure told me I needed to chroot in order to make the grub2 changes and referred me to this: https://www.suse.com/support/kb/doc/?id=7018126

I followed those steps and noticed that when I did mount -a, it threw a load of errors saying that most of my mount points didn’t exist. I aborted the mount -a which had hung on a network drive, and pressed on, and the rest of the procedure seemed to work fine.

After this, I rebooted to from the new SSD, and although it partially boots the system, it doesn’t go all the way, and stops and asks for the root password to go into ‘maintenance mode’.

Looking at the logs, the issue is still the mount points. I get errors like the one below:

[0;32m OK [0m] Reached target Switch Root.
Starting Switch Root…
[0;1;31mFAILED[0m] Failed to mount /var/lib/mailman.
See ‘systemctl status var-lib-mailman.mount’ for details.
[0;1;33mDEPEND[0m] Dependency failed for Local File Systems.
Starting Restore /run/initramfs on shutdown…

for the following mount points:

/var/lib/mailman
/var/spool
/var/tmp
/opt
/var/lib/named
/var/lib/pgsql
/var/lib/machines
/var/cache
/var/log
/.snapshots
/boot/grub2/i386-pc
/usr/local
/var/lib/libvirt/images
/var/opt
/var/lib/mysql
/var/lib/mariadb
/tmp
/boot/grub2/x86_64-efi
/srv
/var/crash

The fstab from the old disk looks identical to the one on new disk apart from the UUID of the disk (which I have checked and re-checked).

The contents of the disk are basically identical apart from the fstab and boot loader (since I rsynced all of the data across when the system was running in rescue mode).

Can anybody tell me what I am missing here ?

It still boots fine from the old disk, so I am not completely stuck, but it’s got me stumped.

Cheers,

Mark

2

Since you changed partitions are all new UUID set correctly in /etc/fstab???

3

Hi - thanks for replying.

I believe the UUID’s are correct. The old disk is sdb and the new one is sdc. Below are my old fstab, my new fstab and the output of blkid.

One thing that is different is that when I boot from the new drive, it comes up as sda rather than sdc, but I don’t think that matters as I am using UUID to identify the partitions …

Old:
UUID=7fe909f1-2ef0-480d-bb35-09d826dc8ff6 swap swap defaults 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 / btrfs defaults 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /boot/grub2/x86_64-efi btrfs subvol=@/boot/grub2/x86_64-efi 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /opt btrfs subvol=@/opt 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /srv btrfs subvol=@/srv 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /tmp btrfs subvol=@/tmp 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /usr/local btrfs subvol=@/usr/local 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/cache btrfs subvol=@/var/cache 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/crash btrfs subvol=@/var/crash 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/lib/machines btrfs subvol=@/var/lib/machines 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/lib/named btrfs subvol=@/var/lib/named 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/log btrfs subvol=@/var/log 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/opt btrfs subvol=@/var/opt 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/spool btrfs subvol=@/var/spool 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /var/tmp btrfs subvol=@/var/tmp 0 0
UUID=46d3d0cd-1327-448f-b182-127ee8d95594 /.snapshots btrfs subvol=@/.snapshots 0 0
diskstation01.home.lichfield.com:/volume1 /diskstation01 nfs defaults 0 0
UUID=5eab7c75-9f89-41cb-a293-0e25da935b1b /SeagateExternal xfs nofail 1 2
UUID=37046a1c-cd4e-456e-8410-f2ca1fc0bdf4 /home xfs defaults 0 0
UUID=55867bf1-4a66-4916-bf88-1b9d3c4e5a7a /oldhome xfs defaults 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /newroot btrfs defaults 0 0

New:
UUID=7fe909f1-2ef0-480d-bb35-09d826dc8ff6 swap swap defaults 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d / btrfs defaults 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /boot/grub2/x86_64-efi btrfs subvol=@/boot/grub2/x86_64-efi 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /opt btrfs subvol=@/opt 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /srv btrfs subvol=@/srv 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /tmp btrfs subvol=@/tmp 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /usr/local btrfs subvol=@/usr/local 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/cache btrfs subvol=@/var/cache 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/crash btrfs subvol=@/var/crash 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/lib/machines btrfs subvol=@/var/lib/machines 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/lib/named btrfs subvol=@/var/lib/named 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/log btrfs subvol=@/var/log 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/opt btrfs subvol=@/var/opt 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/spool btrfs subvol=@/var/spool 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /var/tmp btrfs subvol=@/var/tmp 0 0
UUID=292695cd-c056-4c97-9385-829b91e84b4d /.snapshots btrfs subvol=@/.snapshots 0 0
diskstation01.home.lichfield.com:/volume1 /diskstation01 nfs defaults 0 0
UUID=5eab7c75-9f89-41cb-a293-0e25da935b1b /SeagateExternal xfs nofail 1 2
UUID=37046a1c-cd4e-456e-8410-f2ca1fc0bdf4 /home xfs defaults 0 0
UUID=55867bf1-4a66-4916-bf88-1b9d3c4e5a7a /oldhome xfs defaults 0 0

blkid:
/dev/sda1: LABEL=“SeagateExt” UUID=“5eab7c75-9f89-41cb-a293-0e25da935b1b” TYPE=“xfs” PARTLABEL=“primary” PARTUUID=“8fc4bad3-4b0c-4a5b-8872-56d1ea0d4529”
/dev/sdb1: UUID=“f0961f3c-286b-43f7-ac81-94011f0c0ad4” TYPE=“swap” PARTUUID=“000aeb25-01”
/dev/sdb2: UUID=“46d3d0cd-1327-448f-b182-127ee8d95594” UUID_SUB=“792175a1-b100-433d-871e-908db27a45a9” TYPE=“btrfs” PTTYPE=“dos” PARTUUID=“000aeb25-02”
/dev/sdb3: UUID=“55867bf1-4a66-4916-bf88-1b9d3c4e5a7a” TYPE=“xfs” PARTUUID=“000aeb25-03”
/dev/sdc1: UUID=“7fe909f1-2ef0-480d-bb35-09d826dc8ff6” TYPE=“swap” PARTUUID=“df723c8d-01”
/dev/sdc2: UUID=“292695cd-c056-4c97-9385-829b91e84b4d” UUID_SUB=“22c3e21d-29f3-496c-87f4-764b7efac9af” TYPE=“btrfs” PARTUUID=“df723c8d-02”
/dev/sdc3: UUID=“37046a1c-cd4e-456e-8410-f2ca1fc0bdf4” TYPE=“xfs” PARTUUID=“df723c8d-03”

4

Looks OK to me. Have you run fsck and smartctrlto check if the file systems are OK and the drives are not broken??

5

Hi

As you can see at the top of that page it is for SLE 11 and SLE 12.
Current SLE version is 15.

SLE 11 doesn’t have Btrfs.
The instructions on that page

that you mentioned should work when migrating from an old drive with partition table type “dos”/“msdos” and / (or root) in e.g. an ext3 partition to a new drive with the same partition table type “dos”/“msdos” and an ext3, ext4 or even xfs partition for / (or root). And I think that that page was written for just that case, as it is further described there how to set the boot flag on the new or target drive for / or the root partition using fdisk (as it has been done for legacy/MBR setups).

Now if you search the internet for “rsync btrfs subvolume” or “rsync btrfs migrate” or “clone btrfs” etc., among other pages you will find the page

From that and other pages it seems to me that dd might work - but read the warning about the UUIDs in this case on that same page and on
https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices
Or you may need a specialised tool if you like those.

As such, that would not have been a reason to not use dd.

In your 2nd posting in this thread from blkid you obtained PTTYPE=“dos” for your root partition on the old drive.
Now if you would have created a partition table of type “gpt” on your new SSD then additional provisions would have been necessary.

As far as I can see these mountpoints correspond to your btrfs subvolumes. Seems that you can mount none of those subvolumes.

If I were in your situation and would want to stick with btrfs I’d probably redo the copying with something else than rsync.

6

Thanks for the reply.

I didn’t use dd as I had a bigger disk and wanted bigger partitions than were on the previous drive.

In the meantime, I had realised my error and found a script called btrfs-clone which was mentioned in a few threads but sadly it didn’t work for my installation, and after a couple of goes, I just gave up and put a fresh install onto the new drive and rebuilt my config.

I didn’t know much about btrfs before this and only had it because the installer put it there when I built the system. I am not sure I am a fan as it seems that although the basic tools are there for day to day operation, there are no reliable tools for a situation like the one I just ended up in.

Anyhow - my system is now running fine (and boots in about 20 seconds from the new ssd!) - thanks for the help!!!

7

Hi again

Yes, of course.
On the other hand, from your output from blkid: Your xfs or /home partition is the last one, and using gparted live or a Leap 15.1 installed on a USB with gparted installed from the openSUSE repos to it, it would have been quite easy to enlarge at least this /home.
Before I would have moved this /home using gparted to enlarge the space for / or btrfs with root I would have probably done some research on the internet …

You have a clean installation now! That can save much time :wink:

Ah yes, the defaults of the installer!
Except perhaps for the first two installations of openSUSE years ago there hasn’t been a single fresh installation during which I didn’t change some defaults.

I still stick with ext4. And if I read a thread like this one
https://forums.opensuse.org/showthread.php/533829-Computer-frozen-by-btrfs-cleaner-amp-btrfs-transacti-using-100-CPU
I am quite happy with that.
But I run Leap 15.0 and Leap 15.1.
When you’re running tumbleweed then the possibility to roll back to previous snapshots (a feature of btrfs) seems to be helpful sometimes.

That sounds great!

In order to extend the lifetime of your SSD a bit by reducing small writes, you should consider to include the parameters “noatime” and “nodiratime” for the mounts in fstab, if you don’t need access times.
For your xfs /home that is straightforward - you can enter those even using partitioner of YaST checking “No access time” in the mount options of your /home and entering nodiratime in the small text box as arbitrary option in the same dialogue, if you don’t want to edit /etc/fstab directly.

For your btrfs … a quick search on the internet gives a bit differing results:
https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#DEPRECATED_MOUNT_OPTIONS
(text search for “atime” on this first page)
https://wiki.archlinux.org/index.php/Btrfs

Finally you could and should check whether fstrim works, entering

# fstrim -v /

and

# fstrim -v /home

as root on the command line.

If for both you get results looking like this

/: 17.8 GiB (19079819264 bytes) trimmed

then fstrim or TRIM works.

You can then check with

# systemctl status fstrim.timer

if the timer for fstrim is activated, and at which time interval.

fstrim is about wear leveling

I’ll stop now …

8

Thanks!

Yes - I should have done some more research before I embarked on this particular upgrade - but it is hard to know in advance what is going to go wrong!

I did do some (e.g. grub vs grub2), but I didn’t know anything about btrfs, and I didn’t pay a lot of attention to the contents of fstab which should have told me something I didn’t understand was going on. I guess getting out of situations like this is what backups are for ;).