28

I've seen a few other posts on this topic. Only one or two were very close to my situation, but there were no clear solutions. I would like to describe my situation specifically because I have some details that are not part of the other posts.

I'm running Ubuntu 22.04.3 LTS. I had a regular SATA HDD as my "system" drive which had 3 partitions:

  • /boot - this is my designated boot partition
  • / - this is my system drive with just about everything else
  • swap

I just cloned my SATA hdd to an SATA sdd keeping all the partitioning identical. But the UUIDs are now different (I changed them since I wanted the possibility of having both drives mounted at some point). I updated /etc/fstab with the new UUIDs and, through some research, changed the /etc/initramfs-tools/conf.d/resume file to not reference the old swap UUID.

After changing to the new SSD, it boots fine but there's a 20-30 second dead quiet pause (no disk activity) early in the boot process. Here's an excerpt of where it occurs:

[    2.498174] scsi 6:0:0:0: Direct-Access     TEAC     USB   HS-CF Card 4.08 PQ: 0 ANSI: 0
[    2.501897] scsi 6:0:0:1: Direct-Access     TEAC     USB   HS-xD/SM   4.08 PQ: 0 ANSI: 0
[    2.505707] scsi 6:0:0:2: Direct-Access     TEAC     USB   HS-MS Card 4.08 PQ: 0 ANSI: 0
[    2.509122] scsi 6:0:0:3: Direct-Access     TEAC     USB   HS-SD Card 4.08 PQ: 0 ANSI: 0
[    2.509357] sd 6:0:0:0: Attached scsi generic sg3 type 0
[    2.509936] sd 6:0:0:1: Attached scsi generic sg4 type 0
[    2.511152] sd 6:0:0:2: Attached scsi generic sg5 type 0
[    2.512435] sd 6:0:0:3: Attached scsi generic sg6 type 0
[    2.514823] sd 6:0:0:0: [sdc] Media removed, stopped polling
[    2.519575] sd 6:0:0:1: [sdd] Media removed, stopped polling
[    2.528168] sd 6:0:0:0: [sdc] Attached SCSI removable disk
[    2.533063] sd 6:0:0:2: [sde] Media removed, stopped polling
[    2.541980] sd 6:0:0:1: [sdd] Attached SCSI removable disk
[    2.550871] sd 6:0:0:2: [sde] Attached SCSI removable disk
[    2.559421] sd 6:0:0:3: [sdf] Media removed, stopped polling
[    2.572356] sd 6:0:0:3: [sdf] Attached SCSI removable disk
[   33.540466] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[   33.703038] systemd[1]: Inserted module 'autofs4'
[   33.718092] systemd[1]: systemd 249.11-0ubuntu3.11 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[   33.731050] systemd[1]: Detected architecture x86-64.
[   33.736943] systemd[1]: Hostname set to <musicman>.
[   33.951287] systemd[1]: Queued start job for default target Graphical Interface.
[   33.953273] systemd[1]: Created slice Slice /system/modprobe.

Note that sdc through sdf show up here. I have an old SD card reader with 4 slots hooked up to my system. That's been there a long time, even when I was using my old HDD. I do not have them automounted in my fstab, shown below:

# <file system>                           <mount point>   <type>  <options>         <dump>  <pass>
# / was on /dev/sda6 during installation
UUID=52de13f0-4bc6-4b65-95b3-ea3144b51cef /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=8c68f915-02a3-417f-8eae-c4f3b135805a /boot           ext2    defaults          0       2
# swap was on /dev/sda5 during installation
UUID=e3355472-3ec2-412c-80fa-42e9af3d900e none            swap    sw                0       0
UUID=d80fae04-3ecd-4e68-87ee-0ea47c89adae /backup         ext4    defaults          1       2

/backup partition is on a different physical drive (/dev/sdb) and isn't changed in the whole migration process.

I can provide more of the log if needed. But you can see the big time gap. I did try systemd-analyze blame but it didn't seem to help me find the answer.

There's something very interesting that I noticed, however. If I attach my old hdd to the system, keeping my ssd as the main boot and system drive, so not even including the old hdd in /etc/fstab or mounting it in any way, the system will suddenly not have the 20-30 second pause at all and it all boots up within just a couple of seconds as expected.

What on earth is taking the 20-30 seconds? I did some searching under /etc to try and find text files that referenced UUIDs but could not find any other than the resume file.

My next experiment was going to just set all the ssd UUIDs to be the same as the UUIDs from the old hdd. It would be just an experiment to determine if there's some hold-over in the system somewhere thinking the an old UUID still applies. But there's got to be some understanding of what's going on with the system.

Thank you for any help

lurker
  • 791
  • Verify with "blkid " that the uuid's in fstab are correct. – Soren A Jan 01 '24 at 13:51
  • @SorenA yes I did that already. I did finally figure out the issue though, and posted an answer. – lurker Jan 01 '24 at 14:06
  • 1
    "But the UUIDs are now different." - How did you clone the drive? Because for a simple direct image (e.g. cat /dev/sdX > /dev/sdY) the UUIDs remain identical. That may also be a useful tip for next time. – marcelm Jan 01 '24 at 17:26
  • 2
    @marceim since the new drive was a little smaller, I first used gparted to adjust he size of the original main partition, then used dd to clone. I then changed the UUIDs. as I thought that was the right thing to do since I had both the old and new drive connected for a time. This topic isn't really discussed much in articles or feeds I've read on the topic. It's not clear to me that the issue was just the UUID since, in my tests, I had changed the original drive's swap UUID back to it's original, but the pause did not go away. – lurker Jan 01 '24 at 18:26
  • 1
    Ah yes, the simple copy I proposed won't work when the new drive is smaller (though it can be made to work by resizing filesystems and partitions beforehand). And yes, you are correct, if you want both drives connected simultaneously you want different UUIDs so the system can distinguish between them! – marcelm Jan 02 '24 at 09:49
  • @marcelm I actually did try the simple copy after I had adjusted the partition sizes. However, even running as root, I got a permission denied response. So I just used dd which worked fine of course, plus I liked having the status=progress option. I didn't investigate why the permission error occurred. – lurker Jan 02 '24 at 11:28
  • Perhaps because in something like sudo cat foo > bar, the redirection (> bar) is still running as the unprivileged user. – marcelm Jan 02 '24 at 11:32
  • @marcelm that may have been it. I don't recall if I used sudo or whether I had su - into root at the time. I might have done either. :) – lurker Jan 02 '24 at 13:57

2 Answers2

42

I finally figured out what's going on.

As I mentioned, if my old HDD was connected (not mounted), the system boot up very fast on the SSD.

I ran some additional tests and found that if I altered the old swap partition on the HDD (changed its type and it's UUID, and then changed it back to swap format), it no longer boot up quickly and exhibited the same pause as when the HDD wasn't connected. Note that this partition is not the system's active swap file.

I went back and did a lot of searching of the various little articles on how to properly migrate Ubuntu to a new drive specifically looking for how to handle the swap partition. Very few of them even mention dealing with swap, or even in general what needs to be done if your UUIDs change, other than making sure the /etc/fstab is updated.

Out of the plethora of such articles and discussions, I finally ran across one message thread that mentioned the need to reinitialize the ramfs files after the file system had been migrated:

update-initramfs -u -k all

This updates the initrd.img file for all kernel versions in the /boot directory. If you don't specify -k all (or -k <version>) then it only updates for the latest kernel.

I had not thought about this when I did my initial migration. So I did this update and now everything works as expected.

lurker
  • 791
  • 3
    Well done both in completing your task and documenting it clearly in a way that could help others, good job. – deep64blue Jan 03 '24 at 12:43
  • But... was it booting from such initramfs? A "malformed" initrd.img (even a corrupt one) would not matter unless it tried to use it during boot. – Ángel Jan 03 '24 at 15:15
  • 1
    My guess is that the old initramfs tried to locate the old swap partition to see if it needed to "resume from hibernation", before timing out and going on to normal boot. – Peter Green Jan 03 '24 at 17:57
  • @PeterGreen I think that's a very good guess. :) – lurker Jan 04 '24 at 00:10
1

You seem to have /dev/sdc, through /dev/sdf in your /etc/fstab with the auto option (which causes them to be mounted at boot), AND there is no actual device there. The system tries to read from each disk, gets no response, and times out. That's where the time goes. Read man mount fstab, and remove the auto option.

waltinator
  • 1
  • 2
    Actually, I do not have sdc through sdf in my fstab. I do, however, have an old SD Card reader hooked up to my system that has 4 reader slots. The system seems to be identifying these. But they are not mounted. Also, these are still there when I hook up my old HDD and with that hooked up there is no pause at all. I've added my fstab to my original question to make this clear. – lurker Jan 01 '24 at 12:38
  • According to the dmesg output I showed, the operation that seems to have taken all the time, for some reason, is this: EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. Or... there's something going on between the identification of the SD Card readers and the mounting of sda5 that is taking the time but isn't identified in the output. – lurker Jan 01 '24 at 12:44
  • 1
    Just to be sure, I disconnected the SD card reader from the system and I get the identical pause in the boot at the sda5 mount line but no messages before it about sdc through sdf. All I do is re-attach my old SATA hdd without adding it to fstab and, boom, the pause completely goes away. – lurker Jan 01 '24 at 13:05
  • @lurker : maybe something (swap file?) is still listed as being on that hdd and it waits for it to be available to check it? (hence when it's plugged: it quickly checks and sees it is (or isn't) available, but if unplugged it has a wait time to see it be mounted?) – Olivier Dulac Jan 03 '24 at 13:49