Charlie, I think this is what you are looking for (and what I use).
# nano /etc/default/grub https://wiki.debian.org/Grub The configuration file is /boot/grub/grub.cfg, but you shouldn't edit it directly. This file is generated by grub v2's update-grub(8)... To configure grub "v2", you should edit /etc/default/grub, then run update-grub. You are far more adventurous than myself. I would have unpluged the HD, install an nice clean, fresh Debian Linux to the nice new NVMe, then after the installation worked well, plugged in the HD and mounted it through the GUI. If I got frustrated mounting the drive frequently, I would create a folder into which to mount the HD's relevant partition, then used "blkid" to find the UUID and manually added a mount point to "/etc/fstab". The resulting paths may be a bit ugly, but I am lazy. In /etc/fstab add entry something like, depending on what ext or other format your drive is: UUID=ecbf69dd-e238-42f4-9ee9-043044cc0953 /home/[username]/videos/HD ext4 defaults,noatime 0 2 I hope the "nano /etc/default/grub" info helps? As far as changing the UUIDs in "/etc/default/grub", that is not something I bother to do, so I am not much help in that regard. Good luck on your efforts ! George. On Monday, 25-11-2024 at 12:56 Charlie Gibbs wrote: > I have a 20-year-old box which was nonetheless enough to run Debian > Bookworm (12.5) - but the video card, equipped with an Nvidia GeForce > 610 GPU, was too old. I was getting messages on boot saying that it > was only supported by drivers up to version 390, while Bookworm doesn't > support drivers that old. > > The box was getting flaky on boot anyway, so I figured it was time to > spring for a new motherboard, complete with an AMD Ryzen 5 processor, > 32GB of RAM, and GeForce 1030 video card. > > I was getting nothing on the screen when I first fired it up, but a > friend and I eventually tracked it down to a RAM module that wasn't > properly seated. Once we corrected that, the machine happily came up, > found the existing hard drive and everything on it, and was fully > operational. Things really have progressed since the bad old days. > > But here's the catch. Since I was laying out the bucks for lots of new > hardware anyway, the salesman talked me into throwing in a 1TB NVMe SSD. > What the heck, might as well really speed things up. However, I want > to keep my existing hard drive; it's a fairly new 4TB unit and /home > contains large archives of music and video files. What I'd like to > do is move everything to the SSD - including the /home partition but > without the music and video files, which I'd leave on the spinning rust > in a renamed set of directories mounted elsewhere. > > Rather than doing a full re-install and copying massive amounts of data > back and forth, I'm trying to take a shortcut - which may or may not be > a good idea, but I'll let you guys judge. > > Here's the output of lsblk: > > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > sda 8:0 0 3.6T 0 disk > ├─sda1 8:1 0 1M 0 part > ├─sda2 8:2 0 27.9G 0 part / > ├─sda3 8:3 0 7.5G 0 part [SWAP] > └─sda4 8:4 0 3.6T 0 part /home > sdb 8:16 1 0B 0 disk > sdc 8:32 1 0B 0 disk > sdd 8:48 1 0B 0 disk > sde 8:64 1 0B 0 disk > sr0 11:0 1 1024M 0 rom > nvme0n1 259:0 0 931.5G 0 disk > ├─nvme0n1p1 259:5 0 1M 0 part > ├─nvme0n1p2 259:6 0 30G 0 part > ├─nvme0n1p3 259:7 0 8G 0 part > └─nvme0n1p4 259:8 0 893.5G 0 part > > As you can see, I've duplicated the partitions on the SSD. I also > copied the 30GB / partition to the SSD with dd, and changed the > UUID of the copy to avoid conflicts due to the cloning. I mounted > /dev/nvme0n1p2 (which I hope to make the new / partition) and > changed the UUIDs in its copy of /etc/fstab to point to the > partitions on the SSD. > > I think my problem is getting GRUB to go to the SSD. I tried the > following: > > sudo grub-install /dev/nvme0n1 > > The following messages came out (with a delay of several seconds between > them): > > Installing for i386-pc platform. > Installation finished. No error reported. > > (Is that first message correct? That sounds like old hardware.) > > When re-booting, I went into the BIOS screen, and saw that the SSD was > first in the boot order. However, this probably doesn't mean much if > I didn't get it set up properly. The machine boots, but apparently > falls back to the hard drive. The first two lines of dmesg are: > > [ 0.000000] Linux version 6.1.0-23-amd64 > (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU > ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian > 6.1.99-1 (2024-07-15) > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-23-amd64 > root=UUID=fb2c9cb9-1737-4bbf-b3e8-c5e88b40877e ro quiet > > According to blkid, that UUID corresponds to /dev/sda2, i.e. the / > partition on the hard drive. I'm obviously missing an incantation > to make the machine go to the SSD instead. In /boot/grub/grub.cfg > I find all sorts of references to the UUID of /dev/sda2, but the > file starts with a big scary "DO NOT EDIT THIS FILE" message. > > I've been looking up GRUB documentation, but my eyes are starting to > glaze over. I get the feeling that I'm close, but don't quite have > the GRUB fu. Could someone provide some pointers? > > -- > /~\ Charlie Gibbs | We'll go down in history as > \ / | the first society that wouldn't > X I'm really at ac.dekanfrus | save itself because it wasn't > / \ if you read it the right way. | cost-effective. -- Kurt Vonnegut > >
