Adding a second SSD

I just added a second SSD to a Dell M3800 laptop running tumbleweed (20201209) and it now hangs on boot (tumbleweed at the bottom of the screen with the animated circle over it). I can get in recovery mode without a problem and verify that the second SSD gets mounted as setup in the fstab file as follows:

UUID=ce09e9bc-65b7-4143-87e7-fa95c0120170 /mnt/DataBank        xfs        defaults              1 2

Do not know where to start troubleshooting this problem, so any help anybody can offer, it is very much appreciated.

You may have an entry in /etc/fstab, but you do not show that such an UUID even exists on your system.
Please show

lsblk -f

As requested:

~> lsblk -f 
NAME   FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT 
sda                                            
└─sda1                          110.1G     1% /mnt/DataBank 
sdb                                            
├─sdb1                          148.2M     5% /boot/efi 
├─sdb2                                        [SWAP] 
├─sdb3                           19.5G    61% /var/tmp 
└─sdb4                            149G    83% /home

As I mentioned in the original message,the new SSD (sda) gets mounted without a problem.
Now I see that the problem may be that the new SSD is now /dev/sda, while the old SSD is now /dev/sdb. The /boot/efi partition is now in the /dev/sdb1 partition while in the previous configuration it was in the /dev/sda1 partition.
Is there a way to change the bootloader to point at /dev/sdb1, instead of /dev/sda1?
I do not really know if this is the problem but I will investigate in those lines.

hcvv, thank you for your attention to this matter. Any other pointer will be appreciated.

To show the complete information you need to run the command as root:

 > su
Passwort: 
# lsblk -f
NAME                FSTYPE      FSVER LABEL          UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                                      
├─sda1              ext4              DATA  207076e6-6edb-4ed0-ab79-a9f286a52b77  500,1G    29% /mnt/Data


Regards

susejunky

Sorry that I was not clear enough about doing this as root.

And better better use CODE tags then PHP tags. It is the # button, two to the left of the PHP button.

Also, as long as everywhere the UUIDs are used the switching from sda to sdab and v.v. should not matter (and that is done by default on an openSUSE installation).

There remains hope it won’t be necessary …

https://bugzilla.opensuse.org/show_bug.cgi?id=1169006

The information as shown by the OP is certainly not what I would expect from it. I assume that running it as root will provide what we expect. And I see the same on my own 15.2 system: information about file systems is missing when not run as root.

Running as root now… and with the CODE tags. Learning as I go.

~> sudo lsblk -f 
[sudo] password for root:  
NAME   FSTYPE FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINT 
sda                                                                               
└─sda1 xfs          DataBank ce09e9bc-65b7-4143-87e7-fa95c0120170  110.1G     1% /mnt/DataBank 
sdb                                                                               
├─sdb1 vfat                  E4DF-112F                             148.2M     5% /boot/efi 
├─sdb2 swap                  d97d85f8-1ec8-45ed-b0e6-0ef76b342c54                [SWAP] 
├─sdb3 btrfs                 aeee825d-6aef-4b22-ae61-e28858abe0a7   19.5G    61% / 
└─sdb4 xfs                   3d89a4a9-03e8-4479-a6ab-cfe331c66a27    149G    83% /home

Thanks to all pitching in…!!!

OK, we started this lsblk listing because we wanted to know if the UUID used in fstab is correct. And it is.

We also see that everything you need is mounted. Does no look like recovery mode mode.

Thus back to your report. Did you hit Esc during boot to see what happens?
And maybe a more elaborate description on what you see on the screen until it “hangs” may help to start our imagination.

The last five lines shown afer hitting scape during boot are as follows (I do not know how to capture the screen at that point to share it here)

 OK ] Reached target Initrd Root Device.
 OK ] Finished dracut initqueue hook.
 OK ] Reached target Remote File Systems (Pre.).
 OK ] Reached target Remote File Systems.
  *  ] A start job is running for /dev/sda2 (46s / no limit)

It hangs in there with the time counter increasing indefinitely (I’ve let it go up to 5min+) and the asterisk at the beginning of the line moving back and forth.

That is strange because we know there is no sda2.
But there was before when I understand your story above.
Looks as if still somewhere there is sda2 instead of a UUID. And as now sdb2 is used for Swap, It could be that it is “hardcoded” (as sda2) in the bootstring in the resume= parameter. Can you check that? It is in /boot/grub2/grub.cfg.

Addition. You could in any case check if sda2 is mentioned somewhere in /boot/grub2/grub.cfg at all.

The following appears in the grub.cfg multiple times in the lines shown below:


echo    'Loading Linux 5.9.12-1-default ...'
    linuxefi /boot/vmlinuz-5.9.12-1-default root=UUID=aeee825d-6aef-4b22-ae61-e28858abe0a7  ${extra_cmdline} resume=/dev/sda2 splash=silent quiet showopts resume=/dev/sda2 splash=silent quiet showopts
    echo    'Loading initial ramdisk ...'

echo    'Loading Linux 5.9.11-1-default ...'
        linuxefi /boot/vmlinuz-5.9.11-1-default root=UUID=aeee825d-6aef-4b22-ae61-e28858abe0a7  ${extra_cmdline} resume=/dev/sda2 splash=silent quiet showopts resume=/dev/sda2 splash=silent quiet showopts
        echo    'Loading initial ramdisk ...'

Hi
That is correct, when you had only one drive it was sda2 (your swap) press the e key at grub and remove it temporarily, or change it to either;


resume=/dev/sdb2
or
resume=UUID=d97d85f8-1ec8-45ed-b0e6-0ef76b342c54

That solved the problem.
Thanks to everyone involved in this troubleshooting exercise; very much appreciated!!!

You are welcome. Glad I could analyze it until this. Also note that already in post #5 I hinted that UUIDs should be used everywhere. I also say there that a default installation should do that, thus I wonder why in your case it wasn’t like that.

OP need to check whether GPT is used for all disks.
Or he decided to use “sda” naming instead of UUID’s during installation.