Re: Adding a new boot disk while keeping old disk

From	George at Clug <Clug@goproject.info>
Newsgroups	linux.debian.user
Subject	Re: Adding a new boot disk while keeping old disk
Date	2024-11-25 08:30 +0100
Message-ID	<JMBHI-bpPl-9@gated-at.bofh.it> (permalink)
Organization	linux.* mail to news gateway

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

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-kernel@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
> 
>

Back to linux.debian.user | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: Adding a new boot disk while keeping old disk George at Clug <Clug@goproject.info> - 2024-11-25 08:30 +0100
  Re: Adding a new boot disk while keeping old disk eben@gmx.us - 2024-11-25 16:10 +0100
    Re: Adding a new boot disk while keeping old disk David Wright <deblis@lionunicorn.co.uk> - 2024-11-25 16:30 +0100
      Re: Adding a new boot disk while keeping old disk Felix Miata <mrmazda@stanis.net> - 2024-11-25 16:40 +0100
        Re: Adding a new boot disk while keeping old disk George at Clug <Clug@goproject.info> - 2024-11-26 01:50 +0100
          The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 09:00 +0100
            Re: The "uniqueness" of UUIDs Nicolas George <george@nsup.org> - 2024-11-26 09:10 +0100
              Re: The "uniqueness" of UUIDs Nicolas George <george@nsup.org> - 2024-11-26 09:40 +0100
              Re: The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 09:50 +0100
            Re: The "uniqueness" of UUIDs Felix Miata <mrmazda@stanis.net> - 2024-11-26 09:30 +0100
              Re: The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 10:00 +0100
                Re: The "uniqueness" of UUIDs Nicolas George <george@nsup.org> - 2024-11-26 10:10 +0100
                Re: The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 12:20 +0100
                Re: The "uniqueness" of UUIDs <tomas@tuxteam.de> - 2024-11-26 12:40 +0100
                Re: The "uniqueness" of UUIDs Nicolas George <george@nsup.org> - 2024-11-26 12:40 +0100
                Re: The "uniqueness" of UUIDs <tomas@tuxteam.de> - 2024-11-26 10:30 +0100
                Re: The "uniqueness" of UUIDs Nicolas George <george@nsup.org> - 2024-11-26 11:00 +0100
                Re: The "uniqueness" of UUIDs Felix Miata <mrmazda@stanis.net> - 2024-11-26 15:00 +0100
                Re: The "uniqueness" of UUIDs <tomas@tuxteam.de> - 2024-11-26 16:00 +0100
                Re: The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 16:40 +0100
                Re: The "uniqueness" of UUIDs <tomas@tuxteam.de> - 2024-11-26 18:50 +0100
                Re: The "uniqueness" of UUIDs Michael Stone <mstone@debian.org> - 2024-11-27 18:00 +0100
                Re: The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 16:00 +0100
            Re: The "uniqueness" of UUIDs Arno Lehmann <al@its-lehmann.de> - 2024-11-26 09:30 +0100
              Re: The "uniqueness" of UUIDs Arno Lehmann <al@its-lehmann.de> - 2024-11-26 10:50 +0100
            Re: The "uniqueness" of UUIDs <tomas@tuxteam.de> - 2024-11-26 09:50 +0100
            Re: The "uniqueness" of UUIDs pocket@homemail.com - 2024-11-26 13:20 +0100
      Re: Adding a new boot disk while keeping old disk eben@gmx.us - 2024-11-25 18:30 +0100
        Re: Adding a new boot disk while keeping old disk Hans <hans.ullrich@loop.de> - 2024-11-25 21:00 +0100
    Re: Adding a new boot disk while keeping old disk <tomas@tuxteam.de> - 2024-11-25 18:00 +0100
      Re: Adding a new boot disk while keeping old disk Default User <hunguponcontent@gmail.com> - 2024-11-25 18:40 +0100
        Re: Adding a new boot disk while keeping old disk <tomas@tuxteam.de> - 2024-11-25 19:00 +0100
          Re: Adding a new boot disk while keeping old disk Default User <hunguponcontent@gmail.com> - 2024-11-25 20:10 +0100
        Re: Adding a new boot disk while keeping old disk eben@gmx.us - 2024-11-25 23:40 +0100
          Re: Adding a new boot disk while keeping old disk Greg Wooledge <greg@wooledge.org> - 2024-11-26 00:00 +0100
            Re: Adding a new boot disk while keeping old disk Felix Miata <mrmazda@stanis.net> - 2024-11-26 00:30 +0100
      Re: Adding a new boot disk while keeping old disk Max Nikulin <manikulin@gmail.com> - 2024-11-26 03:40 +0100

csiph-web