Planning to make an external nvme SSD my backup PC

In regards to this External SSD (with LEAP-15.6 on it) was going to share the additional boot times comparing:

  • Generation-9 Lenovo-X1 Carbon laptop booting to the external SSD, to
  • Generation-9 Lenovo-X1 Carbon laptop booting to its internal SSD, to
  • Generation-4 Lenovo-X1 carbon laptop booting to the external SSD

But it the end I decided not to, as the boot times can (and did) very significantly between different boots, possibly due to the login to the network timing affecting the boot times? < unsure >

What I can say is the boot times of this external SSD when booting from the old Generation-4 Lenovo-X1 carbon laptop (my wife’s backup PC) is competitive to both the desktop and Lenovo Generation-9 laptop when using the external SSD. I think that illustrates the USB-3.1 interface is the main speed limiting factor.

Anyway … on a different aspect, related to the booting of the External SSD - after I press F12 when switching on (or rebooting) the laptop, here are some images, where I marked with a red arrow the boot selection to boot the external SSD to a UEFI boot:

External SSD : F12 boot menu when booting from Desktop PC


In the above image, note I chose “UEFI : Realtek RTL9210B-CG 1.00” to boot to the external SSD to boot to an UEFI mode boot. I also want to point out that selecting instead “Realtek RTL9210B-CG 1.0” also boots to the external SSD MBR/Legacy boot mode.

External SSD : F12 boot menu when booting from Generation-9 Lenovo X1 Carbon laptop
Next I booted the external SSD to my ‘main’ PC, the Generation-9 Lenovo X1 Carbon laptop:

Note I chose “opensuse-secureboot” to boot to the external SSD to boot to an UEFI mode boot. I also want to point out that selecting instead “USB HDD: Realtek RTL9210B-CG” also boots the laptop.

External SSD : F12 boot menu when booting from Generation-4 Lenovo X1 Carbon laptop
Next, I booted the external SSD from my wife’s Generation-4 Lenovo X1 Carbon laptop (this is her (and now mine) backup laptop).
I chose “opensuse” to boot to the external SSD to boot to an UEFI mode boot.

I also want to point out that selecting instead “USB HDD: Realtek RTL9210B-CG” also boots the laptop.

Most important (from my point of view) is the above last image, as most of my use with this external SSD, if it ends up actually being used as a backup, will for the first year or two, will be from this Generation-4 Lenovo X1 Carbon laptop.

MOST important to me is the successful boot and operation from the very old Generation Lenovo X1 Carbon laptop. Booting from this laptop was the main reason for me buying the USB-3.1 external SSD enclosure and the external Samsung SSD.

Perhaps an extra qualifier - ALL of these computers are old. My desktop is the oldest, and I can not recall when I purchased it in Europe, but well over 10 years ago. As for the laptops, Lenovo tend to come out with a new ‘generation’ X1 Carbon laptop every year. So by that logic, given this year the Generation-13 is the latest Lenovo laptop, my ‘new’ backup laptop (the generation-4) is 9-years old, and my main PC (the generation-9 X1 Carbon laptop) is four years old.

I am thinking either next year, or the year after, I will buy a new laptop, and relegate my current main PC (the generation-9 X1 Carbon laptop) to being my backup laptop.

I am not certain then, what I will do with this external SSD, but I will cross that bridge if and when I come to it. At age-71, I am not getting any younger, so who knows what the future holds. Most of my relatives passed away before age-70, but a couple of my relatives lived to their early 90s.
.

1 Like

I note (as evident by the boot menus when booting the external SSD from 3 different computers) that the external chipset of this Orico enclosure, which house the SSD, is an RTL9210B.

With regard to what the “B” in the RTL9210 brings? I read

Purportedly the key issues plaguing the original RTL9210 (non-B) and largely resolved in the RTL9210B were:

  1. Heat and Power Management (The Big One): The initial chip had less sophisticated power states (ASPM and PSP). This led to:
  • Higher idle temperatures: The drive would stay warmer than necessary when not in active use.
  • Excessive heat under load: This could trigger thermal throttling, reducing speeds during large file transfers.
  • Higher power draw: Draining laptop batteries faster.
  • This relates to “stability issues” and “poor performance,” as overheating is a primary cause of both.
  1. Compatibility & Disconnections: Early firmware and hardware on the original chip had more issues with “handshaking” between the USB host, the bridge controller, and the specific NVMe SSD inside the enclosure. This could manifest as:
  • Random disconnections during use, especially with certain SSD brands or models.
  • Failure to be recognized by the OS upon plugging in.
  • Linux Support: Linux support and stability have seen significant improvements through both the hardware revision and subsequent firmware updates for the RTL9210B.

So it reads that I am fortunate that the ORICO M2PV-C3 enclousure has the “B” variant of the RTL9210.

1 Like

duplicate post

This is NOT a help request post. Its just more on this external SSD saga.

Initial problem (subsequently solved)

I went to boot this external SSD drive from my Lenovo laptop and it would not boot ! As it turned out the issue was a partitioning boot flag issue.

Detailed story

Encountering the problem:

I went to boot the external SSD drive from Lenovo laptop, where with the laptop switched OFF, I plugged in the USB external SSD housing (that has the SSD inside), switched on the Laptop (pressing F12) and the BIOS boot menu came up.

I selected the external enclosure’s boot menu item (which is a UEFI boot), and the screen ‘blinked’ and same boot menu showed. No matter how many times I selected the external enclosure’s boot menu item, it simply ‘blinked’ and showed the same thing. I could not boot to the external SSD (from my Lenovo laptop)

However the laptop’s internal SSD booted fine.

Switch to Desktop PC

So I switched the laptop off, and took the external SSD enclosure down to my desktop PC, plugged it in a USB port, switched on the PC, and pressed F12. I obtained the BIOS book menu. I observed both the external enclosures UEFI and MBR boot options in the menu, I selected the UEFI boot, and the external enclosure SSD booted LEAP-15.6 ok from the desktop PC. No problems.

Go Figure !

So I then checked the boot flags with : sudo parted -l

(where I will only here show the SSD) part of that command:

Model: Realtek RTL9210B-CG (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/2048B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  3146kB  2097kB                     bios_grub
 2      3146kB  2151MB  2147MB  fat32              msftdata
 3      2151MB  55.8GB  53.7GB  ext4
 4      55.8GB  1000GB  944GB   ext4

There was no esp flag set for the fat32 which is the /boot/efi partition. There should be an esp !! There used to be such.

So I then ran parted to reset the flag, first sending the ‘print’ command at the (parted) prompt to confirm no flag set:

oldcpu@orico-samsung:~> sudo parted /dev/sdc
GNU Parted 3.2
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Model: Realtek RTL9210B-CG (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/2048B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  3146kB  2097kB                     bios_grub
 2      3146kB  2151MB  2147MB  fat32              msftdata
 3      2151MB  55.8GB  53.7GB  ext4
 4      55.8GB  1000GB  944GB   ext4

Then I set the ‘esp’ flag:

(parted) set 2 esp on                                                     
(parted) set 2 boot on

Then I checked to make certain I did not mess things up (and things were ok):

(parted) print                                                            
Model: Realtek RTL9210B-CG (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/2048B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  3146kB  2097kB                     bios_grub
 2      3146kB  2151MB  2147MB  fat32              boot, esp
 3      2151MB  55.8GB  53.7GB  ext4
 4      55.8GB  1000GB  944GB   ext4

(parted) quit                                                             
Information: You may need to update /etc/fstab.
oldcpu@orico-samsung:~>

The inappropriate “msftdata” was replaced with “boot, esp”.

Test against Lenovo laptop

I switched off the desktop PC and then took the USB external SSD up my Lenovo laptop, plugged it in, switched ON the Laptop, and pressed F12.

At the BIOS boot menu, I selected the UEFI boot drive, and this time on the Lenovo laptop, it worked !!

I am happy it works - albeit a couple of puzzles (which I speculate about).

  1. Why did external SSD not boot in UEFI mode to laptop (where boot flag not set) but it did boot to the desktop in UEFI mode?
    .
    I attribute that to the different BIOS in each motherboard. Both BIOS had UEFI histories, and I speculate initially the Lenovo, when I selected the UEFI boot selection, did a quality check, noted the boot flag was missing, and did not boot. In contrast, the Desktop, if one is booting from a BIOS ‘memory’ selection, does no such boot flag check if the entry is already in BIOS (from previous boots).

  2. Why did this problem happen?
    .
    Originally I had ‘esp’ set correctly as the flag and not ‘msftdata’ … I do not know how the change to msftdata happened, but I suspect it may have been some (unknown exactly what) update where I was not careful afterwards to ensure the ‘esp’ flag was not inappropriately changed to ‘msftdata’.

Anyway, its working again. Hopefully I will figure out what caused this, before I have a repeat of the same problem again.

Here we are 2 months later (my initial post was ~mid-July) and I note I can procure a UGREEN 40Gbps M.2 NVMe PCIe Sata SSD Case Thunderbolt 4 USB 4.0, 3.2 Gen2 with Active Cooling Fan & Tool-Free Installation Model: 15976) for only 2,290 Thai baht (ie ~$72 US$) .

I believe it supports PCI-4.0.

With Thunderbolt 4, the UGREEN enclosure should be much faster than my current ORICO M2PV-C2 M.2 NVMe SSD (USB.3.1 Gen2) enclosure. Having typed that, thou, my ORICO enclosure is already fast enough for how I use it.

Still … new toys are new toys.

I read the UGREEN enclosure has an ASMedia ASM2464PD chipset is generally compatible with GNU/Linux. If I was not leaving in less than a few weeks for over a month of global travel, I would be tempted to purchase this Thunderbolt 4 enclosure here and now.

Likely I could simply swap my Samsung 990 EVO Pro Plus SSD from the USB-3.1 ORICO SSD enclosure to this Thunderbolt 4 enclosure, and it would boot from a Thunderbolt 4 port. I might then need to remove the boot code I have, as I have read the ASMedia ASM2464PD chipset may be superior to the older Realtek chipset in my ORICO enclosure.

I am surprised at how quickly the price has dropped for Thunderbolt 4 enclosures.

Possibly when I return from my travels, I will purchase this UGREEN (or another) Thunderbolt 4 enclosure and either buy a new SSD for it, or move the SSD from my (2 month old) ORICO enclosure to the UGREEN. One downside (I believe - still TBC) is this UGREEN enclosure, being inexpensive, likely it means the firmware of the enclosure is not supported for updates.

Regardless, this booting off of an external SSD has worked well for me, thus far.

I’ve been travelling internationally a lot, and returned and was then ill for a month and only today decided to boot to my external nvme SSD. I plugged it into my Lenovo X1 Gen-4 carbon, switched on laptop (pressing F12 to get BIOS boot menu), selected the external USB device (legacy boot option), and booted to LEAP. I spotted an update available, which I applied, where I note there was included a kernel update.

After the kernel update I rebooted, but when doing so, there was no Legacy boot option, only a couple UEFI options. Neither would boot the old Lenovo X1 Carbon Gen4 laptop. :frowning:

So I switched off the Lenovo X1 Carbon Gen4, and moved the external USB enclosure over to my Lenovo X1 Carbon Gen9. Switched it on, pressed F12 immediately after switch-on, and in the BIOS boot menu, selected the UEFI boot (for the external drive) and it booted fine.

So then I tried to figure out, how do I fix this external SSD (in the external USB enclosure) to get working on the old Lenovo X1 generation 4 laptop (ie boot in legacy mode).

Of course, I could not remember anything of my external SSD setup (a bad memory - product of my now being in my 70s?? ) …

So first thing, check the portioning, when running this external SSD (in UEFI boot mode) from my Lenovo X1 carbon generation 9 laptop:


oldcpu@orico-samsung:~> lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 931.5G  0 disk 
├─sda1        8:1    0     2M  0 part 
├─sda2        8:2    0     2G  0 part /boot/efi
├─sda3        8:3    0    50G  0 part /
└─sda4        8:4    0 879.5G  0 part /home
zram0       254:0    0   7.7G  0 disk [SWAP]
nvme0n1     259:0    0 953.9G  0 disk 
├─nvme0n1p1 259:1    0   260M  0 part 
├─nvme0n1p2 259:2    0    16M  0 part 
├─nvme0n1p3 259:3    0  78.1G  0 part 
├─nvme0n1p4 259:4    0  25.1G  0 part 
├─nvme0n1p5 259:5    0  1000M  0 part 
├─nvme0n1p6 259:6    0  16.4G  0 part 
└─nvme0n1p7 259:7    0   833G  0 part 
oldcpu@orico-samsung:~>

Ok. clearly sdax is the external SSD, and nvme0n1px is the internal SSD on my Lenovo X1 carbon gen9.

My memory started to come back. I had setup sda1 as the legacy grub boot partition, and sda1 (/boot/efi) was for the legacy grub boot.

So to confirm I did the following:

oldcpu@orico-samsung:~> sudo fdisk -l /dev/sda
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: RTL9210B-CG     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 2048 bytes
I/O size (minimum/optimal): 2048 bytes / 2048 bytes
Disklabel type: gpt
Disk identifier: EFD96E5B-4200-4D76-ADBC-CDCB9DFD3B49

Device         Start        End    Sectors   Size Type
/dev/sda1       2048       6143       4096     2M BIOS boot
/dev/sda2       6144    4200447    4194304     2G EFI System
/dev/sda3    4200448  109058047  104857600    50G Linux filesystem
/dev/sda4  109058048 1953525134 1844467087 879.5G Linux filesystem
oldcpu@orico-samsung:~>

Which confirmed ‘functions’ of sda1 and sda2 in my external SSD setup (where RTL9210B-CG is the external SSD).

I decided to double check the boot that I selected:
verify where /boot/efi is mounted:

oldcpu@orico-samsung:~> mount | grep /boot/efi
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
oldcpu@orico-samsung:~>

Where /boot/efi is mounted from /dev/sda2, which is on my external drive. Hence I decided the internal nvme drive will NOT be touched by the following commands that I sent which was to reconfigure GRUB2 for both Legacy BIOS and UEFI :

i.e. I then restored GRUB2 for legacy BIOS boot
sudo grub2-install --target=i386-pc /dev/sda

Then to be certain, I re-installed GRUB2 for UEFI boot (I don’t know if that was necessary as I was already running from a UEFI boot):
sudo grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=opensuse

And finally I regenerated the GRUB configuration
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

But … I asked myself, did it work? Before rebooting for the final test, I decided to send another few commands:

oldcpu@orico-samsung:~> sudo grub2-install --target=i386-pc /dev/sda
[sudo] password for root: 
Installing for i386-pc platform.
Installation finished. No error reported.

oldcpu@orico-samsung:~> sudo grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=opensuse
Installing for x86_64-efi platform.
Installation finished. No error reported.

oldcpu@orico-samsung:~> sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
Found linux image: /boot/vmlinuz-6.4.0-150600.23.78-default
Found initrd image: /boot/initrd-6.4.0-150600.23.78-default
Found linux image: /boot/vmlinuz-6.4.0-150600.23.73-default
Found initrd image: /boot/initrd-6.4.0-150600.23.73-default
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
oldcpu@orico-samsung:~>

Given this is for an external boot USB, I decided I could ignore the warning … (hopefully I was correct).

And then another couple of checks:

oldcpu@orico-samsung:~> sudo dd if=/dev/sda bs=512 count=1 2>/dev/null | strings | grep -i grub
GRUB 
oldcpu@orico-samsung:~>

ok … ‘GRUB’ as output suggests legacy boot is in place.

Then a test of the EFI for UEFI boot:

oldcpu@orico-samsung:~> ls -la /boot/efi/EFI/opensuse/
total 3984
drwxr-xr-x 2 root root    4096 Jul 25 18:54 .
drwxr-xr-x 4 root root    4096 Jul 23 17:03 ..
-rwxr-xr-x 1 root root      58 Dec  8 16:06 boot.csv
-rwxr-xr-x 1 root root     345 Dec  8 16:06 grub.cfg
-rwxr-xr-x 1 root root 2082816 Dec  8 16:06 grub.efi
-rwxr-xr-x 1 root root  155648 Dec  8 16:50 grubx64.efi
-rwxr-xr-x 1 root root  852456 Dec  8 16:06 MokManager.efi
-rwxr-xr-x 1 root root  965672 Dec  8 16:06 shim.efi
oldcpu@orico-samsung:~>

All with todays date, which looked good.

So I then shutdown my Lenovo X1 Carbon generation-9 and moved the external SSD enclosure over to my Lenovo X1 Carbon generation-4, switched on that laptop, pressed F12 at start of boot, and in the BIOS boot menu I spotted the legacy boot option was back ! … I choose that, and the Legacy grub boot of the Lenovo X1 Carbon Generation-4 to the external USB SSD openSUSE version worked !!

Next I switched off the Lenovo X1 Carbon Generation-4, and moved the external USB SSD over to my Lenovo X1 Carbon Generation-9, switched it on (immediately pressing F12) and in the BIOS boot menu selected the UEFI boot for the external SSD. And I successfully was able to boot in UEFI mode as well, from the external SSD.

So all is back to normal, but I am puzzled as to how this problem happened.

I assume that the problem I encountered can occur if:

  1. openSUSE detected UEFI-capable system: The update scripts may have detected that my external drive has a GPT partition table with an EFI partition, assumed I only needed UEFI boot, and only reinstalled the UEFI bootloader ??? and/or
  2. the grub2-install (that perhaps is part of the kernel update) only ran for UEFI, where the kernel update may have explicitly run grub2-install --target=x86_64-efi only as it spotted the EFI partition?

This is speculation by me. …

I think in future, after every kernel update on this external SSD, I should as a good check (before rebooting) verify both bootloaders are still present by::

1. Check for legacy BIOS bootloader
sudo dd if=/dev/sda bs=512 count=1 2>/dev/null | strings | grep -i grub
and
2. Check for UEFI bootloader
ls /boot/efi/EFI/opensuse/grubx64.efi

If either presents an issue, then before rebooting, run the commands I noted earlier in this post, so not to have a subsequent boot issue.

I am not 100% certain I have all of this correct. I am still a bit ‘under the weather’ due to illness, but I am getting better.

I definitely did not have all the above correct. :frowning_face:

While I adequately fixed the USB-external SSD openSUSE boot for both legacy and UEFI boots, I managed to clobber my Lenovo X1 Gen-9 laptop’s nvme boot in the process.

I ended up using the USB-external SSD to boot openSUSE and then repair my laptop’s boot. Fortunately I was successful there :+1: as this is not the first time I messed this up.

With the above in mind, and knowing I would always forget what commands to run after a kernel update, I created a script that if executed (after a kernel update to my USB external SSD (and BEFORE rebooting after the kernel update)), will check if grub2 was installed correctly for the new kernel. If I created the script correctly, it will check content of
(1) the laptops internal nvme grub2 config,
(2) the USB external SSDs UEFI boot/grub2 config and
(3) the USB external SSDs legacy boot config (which was tricky as I needed to have the script mount the small partition on the USB-external SSD in order to check grub).

The script seems to run ok with current kernel, but the ‘proof of the pudding’ (as the saying goes) will happen if I remember to run the script after my next kernel update on the USB external SSD.