What has to be on the BOOT drive?

[ex-Gooserider]

I have an older desktop PC, an early generation Intel I7, which has been running on Trixie using a SATA SSD hard drive for everything. I got a free 1TB NVMe drive, which I installed using a PCIe adapter card. I figured out w/ help from the forum how to use Clonezilla to copy the entire install onto the new drive, and found that I can't boot off it, as the system can't find it as a boot device. Once the machine is booted up, it does see the drive.

This probably shouldn't have surprised me since the CPU / Mobo was built before NVMe was a thing...

However it appears that the NVMe drive is significantly faster than the SSD, so I'd really like to have it used as much as possible.

What I think will work is if I use the SSD for the minimal boot files needed to get the machine to the point where it can see the NVMe drive, and then have it use that for everything else.

I'm expecting that I would want to have /boot on the SSD, but what about / and the rest of the directories? I've been looking at the FHS, and other docs and haven't been able to find a clear answer. According to https://www.debian.org/releases/stable/ ... 02.en.html, the / dir has to contain /etc, /bin, /sbin, /lib, /dev and /usr, which I understand to be frequently used so it would seem better to have them on the faster drive, but do I need / on the SSD to get the machine to boot?

Thanks
ex-Gooserider

[pbear]

Sounds like you have already cloned the old drive to the new one. If so, you could try putting just the boot loader on the SSD. Frankly, if that doesn't work, I'm skeptical anything else will. For purposes of illustration, I'll assume the SSD is /dev/sda, the new drive is /dev/nvme0n1, and the new system partition is nvme0n1p1. You can confirm their actual IDs by running lsblk -f. Then, boot a live session and run commands in this form:

Code: Select all

sudo mount /dev/nvme0n1p1 /mnt
sudo grub-install /dev/sda --boot-directory=/mnt/boot

If this works, you can put any partitions you like on the SSD. The boot loader goes in the MBR, which is a special space at the head of the drive used only for boot loaders and the partition table.

All this assume you have an old-fashioned BIOS computer. Something similar can be tried If it uses UEFI, but the commands are a little different. In that case, please post the output of lsblk -f.

FYI to others, the prior thread. For future reference, rsync could have handled that problem pretty easily. On the other hand, copy at file level is slower than block copy, so maybe you saved a little time doing the job with Clonezilla.
By the way, I have to ask. Do you have backups? If not, that's several orders of magnitude more important than shaving three seconds off your boot time.

[ex-Gooserider]

Thanks for the answer Pbear,
I agree about backups being important, I have Timeshift running a daily of the entire system to an external drive, and do an extra run any time I'm about to do something major like this...

I believe this machine has a UEFI BIOS since I have the drives partitioned w/ gpt rather than the really old primary / secondary scheme. However Aki pointed at the UEFI entry in the Debian Wiki, and according to that, I seem not to be running in UEFI mode, as I don't have the /sys/firmware/efi directory, and efibootmgr gives a message "EFI variables are not supported on this system".

A short version of ls-blk -f (I left out some drives that aren't relevant...)

Code: Select all

NAME        FSTYPE FSVER LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
├─sda2      ext2   1.0   boot         1bc3c6bf-4447-4783-8fa1-e8b7acf18f64  406.4M    14% /boot
├─sda3      ext4   1.0   root         d3b429b6-37a0-4c8a-bfdb-1bc92ae8137e   14.2G    57% /
├─sda4      ext4   1.0   temp         ff743e54-1374-4529-9c7a-0741ee02170d
├─sda5      ext4   1.0   var          e10121da-10c2-419e-9941-ae2b50e6362c
├─sda6      ext4   1.0   SSD-HOME     c65b8967-ed09-423a-b6cc-9775dfc85828  226.2G    59% /home
└─sda7      ext4   1.0   usr-local    5741f56e-9757-407b-a98a-566ea0b282b1    8.3G     5% /usr/local
sdb
├─sdb1      ntfs         Win10        54CFFDF62E1AE6AC
└─sdb2      swap   1                  02e01e53-5ace-4592-9600-c8674b27cf9b                [SWAP]
sr0
nvme0n1
├─nvme0n1p1
├─nvme0n1p2 ext2   1.0   boot         1bc3c6bf-4447-4783-8fa1-e8b7acf18f64
├─nvme0n1p3 ext4   1.0   root         d3b429b6-37a0-4c8a-bfdb-1bc92ae8137e
├─nvme0n1p4 ext4   1.0   temp         ff743e54-1374-4529-9c7a-0741ee02170d    9.3G     0% /tmp
├─nvme0n1p5 ext4   1.0   var          e10121da-10c2-419e-9941-ae2b50e6362c    2.9G    39% /var
├─nvme0n1p6 ext4   1.0   SSD-HOME     c65b8967-ed09-423a-b6cc-9775dfc85828
└─nvme0n1p7 ext4   1.0   usr-local    5741f56e-9757-407b-a98a-566ea0b282b1

This is after rebooting with both drives installed, it seems to have somewhat randomly picked which drive it got each directory from, since /temp and /var seem to be on the NVMe drive, and the rest on the SSD... I also notice that both drives seem to have the same UUID, which sort of makes sense given that I cloned the SSD, but at the same time I thought UUID's were supposed to be unique?

At any rate I will try the commands you suggested, and see if that works...

[ex-Gooserider]

Well, the suggested fix didn't work, and left me non-bootable.

I sort of fixed it by booting off a Bookworm install CD into graphical rescue mode. I told it to use nvme0n1p3 as the root directory and to install the bootloader to /dev/sda. This let me boot again, but now lsblk -f shows all the directories pointing at /dev/sda...

I'm wondering what would happen if I edited /etc/fstab to explicitly point at the NVME drive directories?

ex-Gooserider

[pbear]

Don't know where you got that partition table, but not an allocation I would recommend. Anyhoo, does look like BIOS on GPT, which is fine.
So, sda1 looks to be a BIOS boot partition, which stands in for the MBR. OTOH, as you have a boot partition (why?), the commands I gave need modification.

Code: Select all

sudo mount /dev/nvme0n1p3 /mnt
sudo mount /dev/nvme0n1p2 /mnt/boot
sudo grub-install /dev/sda --boot-directory=/mnt/boot

Don't think the duplicate UUIDs will prevent boot, but you'll have to do something about that before you can mount both disks at the same time.

Glad to hear you have a backup drive. You shouldn't use Timeshift to backup data files, though. Use a different app, e.g., Back In Time.

[ex-Gooserider]

Thanks Pbear, unfortunately it didn't work I apparently need to get further into the boot process before it sees the NVMe drive...

Since the UUID's needed to be different, I started out today's adventures by looking up how to fix that, and found it is fairly simple, using tune2fs -U random </dev/[partition]> So I did this with all the partitions on the NVMe drive, so my lsblk -f is now:

Code: Select all

lsblk -f
NAME        FSTYPE FSVER LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
├─sda2      ext2   1.0   boot         1bc3c6bf-4447-4783-8fa1-e8b7acf18f64  406.4M    14% /boot
├─sda3      ext4   1.0   root         d3b429b6-37a0-4c8a-bfdb-1bc92ae8137e   14.2G    57% /
├─sda4      ext4   1.0   temp         ff743e54-1374-4529-9c7a-0741ee02170d    9.3G     0% /tmp
├─sda5      ext4   1.0   var          e10121da-10c2-419e-9941-ae2b50e6362c    2.9G    39% /var
├─sda6      ext4   1.0   SSD-HOME     c65b8967-ed09-423a-b6cc-9775dfc85828  226.2G    59% /home
└─sda7      ext4   1.0   usr-local    5741f56e-9757-407b-a98a-566ea0b282b1    8.3G     5% /usr/local
sdb
└─sdb1      ext4   1.0   /dev/sde     e800cb22-d170-4868-a332-cc044df93202
sdc
└─sdc1      ext4   1.0   music        898a5610-cbe3-4ee3-a7ba-2d475353cf4f
sdd
├─sdd1      ntfs         Win10        54CFFDF62E1AE6AC
└─sdd2      swap   1                  02e01e53-5ace-4592-9600-c8674b27cf9b                [SWAP]
sde
├─sde1      ext2   1.0   old-BOOT     8e660124-c9f7-4a7f-b23d-3c1329d2c09b
├─sde3      ext4   1.0   old-ROOT     1f996152-b19e-49ab-9614-2fd81d5f289d
├─sde4      ext4   1.0   old-VAR      fb1851c6-feac-46fd-977a-d3c6ef582629
├─sde5      ext4   1.0   old-VAR-MAIL 7e88d9b1-eba3-4bd3-bf4e-92c9871a8946
├─sde6      ext4   1.0   old-TMP      c33a5cb7-dda4-4807-bb3d-dc56acb68864
└─sde7      ext4   1.0   old-HOME     733320af-925c-4226-ad57-a74b29f589c0
sdf
└─sdf1      ext4   1.0   backups      1ea01a8f-c1be-4056-84e2-519448b41891
sdg
sdh
sdi
sdj
sr0
nvme0n1
├─nvme0n1p1
├─nvme0n1p2 ext2   1.0   boot         ccd68510-252e-4f38-b3cd-5b8a0378a0ec
├─nvme0n1p3 ext4   1.0   root         41e382ca-bdd5-447d-b716-03323c13d44e
├─nvme0n1p4 ext4   1.0   temp         9a3b2e91-ace0-4a91-a761-1dffde4ef7b4
├─nvme0n1p5 ext4   1.0   var          d2636e2a-f119-43d1-bc28-639f12f27388
├─nvme0n1p6 ext4   1.0   SSD-HOME     b800c322-1156-492e-b270-2a6096291121
└─nvme0n1p7 ext4   1.0   usr-local    db44152e-9c5a-46b5-8d0c-4b5b61a35058

I then edited /etc/fstab only on the NVMe drive to reflect the new UUID's....

After that I followed your suggested commands, using an older copy of SystemRescueCD. I noticed it said it was installing an I386 grub - is that normal? When I rebooted I came up at the Grubrescue prompt, after an error saying it couldn't find the NVMe boot directory UUID. I again was able to get it back to booting off the SSD by using rescue mode of a Bookworm install DVD...

As I mentioned in the other thread, this does seem like a bit of an odd BIOS as when I checked it, the boot setting was to attempt a UEFI boot and fall back to legacy if it failed, but at least once the Bookworm DVD came up with the UEFI grub menu, although it has usually come up in the Legacy BIOS menu....

For what it's worth, the mobo is an Intel DX79SR with a Sandy Bridge-E (Core i7 3rd Generation X-Series) CPU - i7-3930K – 3.2 GHz/3.8 GHz Turbo Boost, 6 cores, 12 MB L3 cache so circa 2011 vintage...

I mostly got the partition scheme from the Debian install manual, which is why I don't break /usr out as it's own partition, and a few others (It used to be suggested to use a lot of partitions way back when (I think I started using Linux around late kernel 2 or early 3) the separate /boot was suggested as offering some (minor) protection against rootkits... What would you suggest?

Similarly, why do you think Timeshift is a bad program for backing up data files? I believe it's just a front end for rsync?

My two thoughts about things to try next...

1. Switch the BIOS to always use the legacy boot since it seems to be using that most of the time anyway, and I don't have any drives over 1TB....

2. Tell the system to use /dev/sda as the boot drive, with /etc/fstab on /dev/sda pointing at the NVMe drive for everything.

Does this make sense?

ex-Gooserider

[pbear]

fstab isn't a boot file and doesn't point at anything. It's a config file which tells the system where to mount partitions. Indeed, that it's not read until several milliseconds into boot might be why cross-boot didn't work.

Anyhoo, I didn't suggest trying to install Grub from a older copy of SystemRescueCD. Not going to try to figure out why it went sideways. What I suggested is that you boot a live session. I'm sure you're aware Debian is available in that format. Testing, I notice you have to install grub-pc before the command will go through, but you would have been told that anyway. There's a way to do this with the standard installer, setting up a chroot as I recall, but I've never learned the details because it seems to me a silly way to go about maintaining a computer. A live ISO is readily available, easier to use, and can do much more.

Alternatively, as the computer can boot in UEFI, you probably could get the nvme to boot with rEFInd. Would require an EFI partition, of course, and entail a bit of reworking things unless you're okay with booting from a flash drive all the time. Reason this strategy should work is that rEFInd can boot the nvme's kernel images, bypassing Grub entirely. Easy to test (with flash drive) before making any changes to the installed system.

As for Timeshift and data files, read the manual.

[pbear]

Thinking this over, it occurred to me the solution might be simple (and right in front of our noses). Use the boot partition on sda, instead of the one on the nvme. I don't have a convenient way to test this theory - and generally don't recommend things I can't test - but was able to run a sort-of-similar test, modifying an LVM+LUKS test box (a VM) to comment out the boot partition mount. Lo, the system rebooted fine anyway. Which says the system can find the initramfs without fstab. Where it might fall down here is that sda2's initramfs points to sda3. I think we can fix that by updating it in chroot, but not sure (and, as I said, no convenient way to test).

If you're game for an adventure, boot a live session of Debian, set up an internet connection, and run:

Code: Select all

sudo mount /dev/nvme0n1p3 /mnt
sudo mount /dev/sda2 /mnt/boot
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
update-initramfs -u
grub-install /dev/sda
exit
sudo umount /mnt/boot
sudo umount -R /mnt

If successful, you would add sda2 to fstab, as the mount is used for other things, especially updating kernel images. Obviously you would keep that partition (and sda1), but could use the rest of sda for other things.

Note: Edited from what I originally posted. On testing, I realize there's no need to install grub-pc in chroot, as the installed system already has it.

[ex-Gooserider]

I started by downloading the live install, debian-live-12.5.0-amd64-kde.iso, and making a USB boot stick. I then tried your suggested adventure... I was doing this just before you made the edit, and had errors with the install grub pc step, but every thing else went without problems. However when I rebooted, lsblk still showed everything on the SSD....

I should point out that I'm only aware of the system doing a UEFI boot ONCE while doing this entire process... The other times when I was aware of how it booted it came up in Legacy mode. This may be due to the UEFI firmware being buggy, which seems possible given the age of the board (I am running the latest firmware I can find, but it's about the same age) Even though I have the boot order set to 1. DVD drive, 2. USB, 3. Hard drive, I find I have to use the POST 'manual boot menu' AND get the timing of when I put the DVD in the drive just right... This is why I was thinking about switching the BIOS to just use the Legacy boot since it seems to end up doing that anyway.

At any rate, as an experiment, I just tried editing the /etc/fstab on the SSD to point at the NVME drive for everything but the /boot and root partitions, and after rebooting, I got the following lsblocks

Code: Select all

lsblk -f
NAME        FSTYPE FSVER LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
├─sda2      ext2   1.0   boot         1bc3c6bf-4447-4783-8fa1-e8b7acf18f64  406.2M    14% /boot
├─sda3      ext4   1.0   root         d3b429b6-37a0-4c8a-bfdb-1bc92ae8137e   14.2G    57% /
├─sda4      ext4   1.0   temp         ff743e54-1374-4529-9c7a-0741ee02170d
├─sda5      ext4   1.0   var          e10121da-10c2-419e-9941-ae2b50e6362c
├─sda6      ext4   1.0   SSD-HOME     c65b8967-ed09-423a-b6cc-9775dfc85828
└─sda7      ext4   1.0   usr-local    5741f56e-9757-407b-a98a-566ea0b282b1
sdb
├─sdb1      ntfs         Win10        54CFFDF62E1AE6AC
└─sdb2      swap   1                  02e01e53-5ace-4592-9600-c8674b27cf9b                [SWAP]
sdc
└─sdc1      ext4   1.0   music        898a5610-cbe3-4ee3-a7ba-2d475353cf4f
sdd
├─sdd1      ext2   1.0   old-BOOT     8e660124-c9f7-4a7f-b23d-3c1329d2c09b
├─sdd3      ext4   1.0   old-ROOT     1f996152-b19e-49ab-9614-2fd81d5f289d
├─sdd4      ext4   1.0   old-VAR      fb1851c6-feac-46fd-977a-d3c6ef582629
├─sdd5      ext4   1.0   old-VAR-MAIL 7e88d9b1-eba3-4bd3-bf4e-92c9871a8946
├─sdd6      ext4   1.0   old-TMP      c33a5cb7-dda4-4807-bb3d-dc56acb68864
└─sdd7      ext4   1.0   old-HOME     733320af-925c-4226-ad57-a74b29f589c0
sde
└─sde1      ext4   1.0   /dev/sde     e800cb22-d170-4868-a332-cc044df93202
sdf
└─sdf1      ext4   1.0   backups      1ea01a8f-c1be-4056-84e2-519448b41891
sdg
sdh
sdi
sdj
sr0
nvme0n1
├─nvme0n1p1
├─nvme0n1p2 ext2   1.0   boot         ccd68510-252e-4f38-b3cd-5b8a0378a0ec
├─nvme0n1p3 ext4   1.0   root         41e382ca-bdd5-447d-b716-03323c13d44e
├─nvme0n1p4 ext4   1.0   temp         9a3b2e91-ace0-4a91-a761-1dffde4ef7b4    9.3G     0% /tmp
├─nvme0n1p5 ext4   1.0   var          d2636e2a-f119-43d1-bc28-639f12f27388    2.9G    39% /var
├─nvme0n1p6 ext4   1.0   SSD-HOME     b800c322-1156-492e-b270-2a6096291121    441G    43% /home
└─nvme0n1p7 ext4   1.0   usr-local    db44152e-9c5a-46b5-8d0c-4b5b61a35058    8.3G     5% /usr/local

This seems like the most progress I've made so far, so I think my next effort will be to change the root directory.... If that works, I will try changing /boot....

ex-Gooserider

[ex-Gooserider]

With fstab pointing at the NVME drive for root, it boots still comes up with the same lsblk list, so / is still on the SSD. Will try also moving /boot next...

ex-Gooserider

[ex-Gooserider]

With fstab on the SSD giving the NVME UUID's for all but swap, it boots, and comes up with lsblk showing root on the SSD, (which is now sdb3 if that makes any difference) and everything else on the NVMe drive...

Code: Select all

lsblk -f
NAME        FSTYPE FSVER LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1      ntfs         Win10        54CFFDF62E1AE6AC
└─sda2      swap   1                  02e01e53-5ace-4592-9600-c8674b27cf9b                [SWAP]
sdb
├─sdb1
├─sdb2      ext2   1.0   boot         1bc3c6bf-4447-4783-8fa1-e8b7acf18f64
├─sdb3      ext4   1.0   root         d3b429b6-37a0-4c8a-bfdb-1bc92ae8137e   14.2G    57% /
├─sdb4      ext4   1.0   temp         ff743e54-1374-4529-9c7a-0741ee02170d
├─sdb5      ext4   1.0   var          e10121da-10c2-419e-9941-ae2b50e6362c
├─sdb6      ext4   1.0   SSD-HOME     c65b8967-ed09-423a-b6cc-9775dfc85828
└─sdb7      ext4   1.0   usr-local    5741f56e-9757-407b-a98a-566ea0b282b1
sdc
└─sdc1      ext4   1.0   music        898a5610-cbe3-4ee3-a7ba-2d475353cf4f
sdd
├─sdd1      ext2   1.0   old-BOOT     8e660124-c9f7-4a7f-b23d-3c1329d2c09b
├─sdd3      ext4   1.0   old-ROOT     1f996152-b19e-49ab-9614-2fd81d5f289d
├─sdd4      ext4   1.0   old-VAR      fb1851c6-feac-46fd-977a-d3c6ef582629
├─sdd5      ext4   1.0   old-VAR-MAIL 7e88d9b1-eba3-4bd3-bf4e-92c9871a8946
├─sdd6      ext4   1.0   old-TMP      c33a5cb7-dda4-4807-bb3d-dc56acb68864
└─sdd7      ext4   1.0   old-HOME     733320af-925c-4226-ad57-a74b29f589c0
sde
└─sde1      ext4   1.0   /dev/sde     e800cb22-d170-4868-a332-cc044df93202
sdf
└─sdf1      ext4   1.0   backups      1ea01a8f-c1be-4056-84e2-519448b41891
sdg
sdh
sdi
sdj
sr0
nvme0n1
├─nvme0n1p1
├─nvme0n1p2 ext2   1.0   boot         ccd68510-252e-4f38-b3cd-5b8a0378a0ec  404.2M    15% /boot
├─nvme0n1p3 ext4   1.0   root         41e382ca-bdd5-447d-b716-03323c13d44e
├─nvme0n1p4 ext4   1.0   temp         9a3b2e91-ace0-4a91-a761-1dffde4ef7b4    9.3G     0% /tmp
├─nvme0n1p5 ext4   1.0   var          d2636e2a-f119-43d1-bc28-639f12f27388    2.9G    39% /var
├─nvme0n1p6 ext4   1.0   SSD-HOME     b800c322-1156-492e-b270-2a6096291121  441.2G    43% /home
└─nvme0n1p7 ext4   1.0   usr-local    db44152e-9c5a-46b5-8d0c-4b5b61a35058    8.3G     5% /usr/local

Booted in legacy bios mode...

ex-Gooserider

[pbear]

Don't have time to digest that right now (headed to work); will look at again later. Based on a quick read, though, having only the boot loader on the SATA SSD should be sufficient (as I originally suggested).

[pbear]

Try as I might, I can't think of a reason the firmware would tolerate moving the boot partition to the nvme but not the root partition. The boot partition has the initramfs and is accessed first.

You're updating initramfs after editing fstab, right?

[ex-Gooserider]

Try as I might, I can't think of a reason the firmware would tolerate moving the boot partition to the nvme but not the root partition. The boot partition has the initramfs and is accessed first.

You're updating initramfs after editing fstab, right?

I hadn't been, but I have tried doing that, and it didn't seem to make any difference...

Is there any difference in a hard drive that has been GPT partitioned under a legacy boot as opposed to one GPT partitioned under a UEFI boot? I'm all but certain that all the drives were partitioned and the OS installed under legacy boot.... It does seem like I'm missing some of the things needed in a UEFI boot and that might be part of the problem...

I'm looking at https://wiki.debian.org/GrubEFIReinstall thinking that following the steps there to get the UEFI stuff onto the SSD (and maybe the NVMe drive?) might get the system booting in UEFI and doing the right thing, otherwise I will look at switching the BIOS to only do legacy and fixing it from a legacy standpoint...

Thank you very much for all the help you have given me so far, it's at least hopefully gotten me looking at the right stuff....

ex-Gooserider

[pbear]

Is there any difference in a hard drive that has been GPT partitioned under a legacy boot as opposed to one GPT partitioned under a UEFI boot?

I'm quite certain the answer is no. What can be an issue (very rarely) is how legacy mode handles GPT (it's a compatibility mode, not true BIOS).

It does seem like I'm missing some of the things needed in a UEFI boot and that might be part of the problem...

Missing what? There's not much to it. Anyhoo, if you're willing to consider UEFI boot, look again at my earlier suggestion about using a rEFInd flash drive.

[sunrat]

You will need an EFI System Partition (ESP) for UEFI boot for starters. You don't seem to have one.

[pbear]

You will need an EFI System Partition (ESP) for UEFI boot for starters.

Yes, and I mentioned that earlier. A rEFInd flash drive has its own EFI partition, though, so works without one on the main drive.

Indeed, the usual use of a rEFInd flash drive is system rescue in the scenario where the main EFI partition has stopped working (e.g., due to Grub or NVRAM error).

[ex-Gooserider]

I've been doing a lot of poking and prodding the system over the last few days, and I think I found part of the problem and why the previous efforts haven't worked... At least I hope I'm seeing the end of the process...

The initial Debian install was done in BIOS mode, and as a result none of the UEFI information / drive partitions were on the SSD, so it would always come up in BIOS mode, and because the drive didn't have the right partition setup, it wouldn't allow the steps you suggested to put the UEFI information on the drive and fix the GRUB install... I made a rEFInd USB stick - and it wouldn't boot of that. Then I tried a rEFInd CD, and it would boot, but didn't seem able to solve the drive problem.

Unfortunately in the process of doing this I wiped out the first couple partitions on both the SSD and the NVMe drive, and didn't seem able to get them back nicely. So I ended up getting the Live system USB stick to do a re-install, in UEFI mode, on just the SSD. The system now comes up in UEFI mode, and here is the new lsblk output - note that it now has a /boot/efi partition on sda1.

Code: Select all

[ -d /sys/firmware/efi ] && echo "EFI boot on HDD" || echo "Legacy boot on HDD"
EFI boot on HDD
lsblk -f
NAME        FSTYPE FSVER LABEL          UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1      vfat   FAT32                D102-EF8B                             493.1M     1% /boot/efi
├─sda2      ext2   1.0                  12b619f8-905e-423a-94f9-60275e79a662  362.7M    23% /boot
├─sda3      ext4   1.0                  41fd5d38-d92d-42aa-8397-6b799fd2c8a5   30.3G    15% /
├─sda4      ext4   1.0                  21965877-d556-4549-881f-2e7376ad7fad    9.3G     0% /tmp
├─sda5      ext4   1.0                  d1907436-29c1-4492-af5c-dce0e406b537    4.5G     9% /var
├─sda6      ext4   1.0   SSD-HOME       c65b8967-ed09-423a-b6cc-9775dfc85828    223G    59% /home
└─sda7      ext4   1.0                  844be5ea-cabd-428d-9e17-4b999eccd917      9G     0% /usr/local
sdb
├─sdb1      ntfs         Win10          54CFFDF62E1AE6AC
└─sdb2      swap   1                    ae87123a-5ed7-4b58-880c-e6ac7778456d                [SWAP]
sdc
├─sdc1      ext2   1.0   old-BOOT       8e660124-c9f7-4a7f-b23d-3c1329d2c09b
├─sdc3      ext4   1.0   old-ROOT       1f996152-b19e-49ab-9614-2fd81d5f289d
├─sdc4      ext4   1.0   old-VAR        fb1851c6-feac-46fd-977a-d3c6ef582629
├─sdc5      ext4   1.0   old-VAR-MAIL   7e88d9b1-eba3-4bd3-bf4e-92c9871a8946
├─sdc6      ext4   1.0   old-TMP        c33a5cb7-dda4-4807-bb3d-dc56acb68864
└─sdc7      ext4   1.0   old-HOME       733320af-925c-4226-ad57-a74b29f589c0
sdd
└─sdd1      ext4   1.0   music          898a5610-cbe3-4ee3-a7ba-2d475353cf4f
sde
└─sde1      ext4   1.0   /dev/sde       e800cb22-d170-4868-a332-cc044df93202
sdf
sdg
sdh
sdi
sr0
nvme0n1
├─nvme0n1p3 ext4   1.0   nvme-root      41e382ca-bdd5-447d-b716-03323c13d44e
├─nvme0n1p4 ext4   1.0   nvme-temp      9a3b2e91-ace0-4a91-a761-1dffde4ef7b4
├─nvme0n1p5 ext4   1.0   nvme-var       d2636e2a-f119-43d1-bc28-639f12f27388
├─nvme0n1p6 ext4   1.0   nvme-HOME      b800c322-1156-492e-b270-2a6096291121
└─nvme0n1p7 ext4   1.0   nvme-usr-local db44152e-9c5a-46b5-8d0c-4b5b61a35058

Now that I have gotten the UEFI boot problem solved, I plan to try some of your earlier suggestions again, to get the system to use the NVME drive after the initial boot. Thanks again for all your help and advice.

ex-Gooserider

[ex-Gooserider]

After several days of frustration, I finally have mixed success... I tried a bunch of different ways to make the drive switch from Legacy boot to EUFI boot, and nothing seemed to work... I tried doing new installs from both a Live-USB stick and from an install DVD, saying to not format any directories but the /boot and /boot/efi and got failures on the installing system step I finally gave up and tried doing a fresh install of everything but /home, with the intent of then running a restore of my Timeshifft snapshots - I got a system that would boot, but then the Timeshift restore made it unbootable again It appears that it overwrote the /boot/efi and /boot directories sort of making them back into legacy boot.

So I did yet another install from scratch, except for /home, putting the /boot/efi and /boot directories on the SSD, and everything else on the NVMe drive. This boots, and I get the lsblk list that is about what I'm after, with everything except the boot files on the NVME drive....

Code: Select all

sda
├─sda1      vfat   FAT32           B6A5-1BB4                              66.2M    15% /boot/efi
├─sda2      ext2   1.0   ssd-boot  07a9abd8-9c6d-4dcf-8524-9f366ea0ca2d  817.1M     6% /boot
├─sda3      ext4   1.0   ssd-root  f75046e4-bae7-4939-a801-399667819a37
├─sda4      ext4   1.0   ssd-temp  409ff2a4-743f-423c-9672-6ee2e74ea7fa
├─sda5      ext4   1.0   ssd-var   554aff4a-ee35-4abd-b757-f7da6030f6a8
└─sda6      ext4   1.0   SSD-HOME  c65b8967-ed09-423a-b6cc-9775dfc85828
sdb
└─sdb1      ext4   1.0   music     898a5610-cbe3-4ee3-a7ba-2d475353cf4f
sdc
├─sdc2      ext4   1.0             f9f9716e-829c-4f08-9a30-d8ae3af9cd20
├─sdc3      ext4   1.0             e8d689c0-8ef0-446d-b8c7-f02408726654
├─sdc4      swap   1               0da192a7-ef22-45f9-9913-f686d98848e8                [SWAP]
├─sdc5      ext4   1.0             4794c09b-279c-4069-9eca-5d48a114655e
└─sdc6      ext4   1.0             1addfad8-4b1a-4d3a-97bc-2a018f5a9c40
sdd
└─sdd1      ext4   1.0   /dev/sde  e800cb22-d170-4868-a332-cc044df93202
sde
sdf
sdg
sdh
sdi        
sr0
nvme0n1
├─nvme0n1p2 ext2   1.0   nvme-boot 7606a27d-3ad3-4ac6-904d-7a07895ff838
├─nvme0n1p3 ext4   1.0   nvme-root e42c36eb-ad60-483c-baa6-fee190b45ae5   29.6G    17% /
├─nvme0n1p4 ext4   1.0   nvme-tmp  c26d6ecc-75e1-49e8-8062-44e23253a8d6    9.3G     0% /tmp
├─nvme0n1p5 ext4   1.0   nvme-var  a444786f-58ba-453c-92b8-4d26c5523e75    4.5G     9% /var
└─nvme0n1p6 ext4   1.0   nvme-HOME b800c322-1156-492e-b270-2a6096291121    441G    43% /home

The downside is that I had a LOT of other stuff on the system, both programs I'd added from the repository, and some that I'd had to compile from source as they either weren't in the repository at all, or only with (much) older versions.... I'd really like to do a selective restore from my Timeshift snapshots, but it seems not obvious how to do it without breaking things AGAIN... Since it is off-topic for this thread, I will be starting a new one about this.

Again, many thanks for the help you've given me!

ex-Gooserider

[pbear]

... Timeshift restore made it unbootable again

When looking at the Restore box, notice button for Bootloader Options (Advanced). Click button. Untick both boxes. You should be fine. Be aware, there's no such thing as a selective Timeshift restore.

FWIW, I think Timeshift got this point backwards. Reinstall and/or update of Grub should be an option, but not the default. Anyhoo, it is what it is.

By the way, I agree alternative-to-Timeshift warrants its own thread, so let's keep discussion of that topic over there.