Forum: >>> Magnum BBS <<<

Adding a new boot disk while keeping old disk

From Charlie Gibbs@21:1/5 to All on Mon Nov 25 03:30:01 2024

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
([email protected]) (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
\ / <[email protected]d> | 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Andrew M.A. Cater@21:1/5 to Charlie Gibbs on Mon Nov 25 08:30:01 2024

On Sun, Nov 24, 2024 at 05:56:25PM -0800, 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.

Fair enough: at 20 years old - that might also explain the flakiness on
boot you mentioned.

Good to hear that you got an operational machine second try :)

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.

No - REALLY don't do that - a reinstall will be quicker, especially since I
see you were using legacy MBR install rather than UEFI (if that's how I interpreted the installation of grub-pc.)

Do an install to the 1TB NVME using AMD64 media. Do it using LVM.
Maybe use the expert install to allow you more flexibility in partitioning.

If what you want to keep from your old /home is small, just copy it across
as a directory called /oldhome and delete it once you're happy. [Dotfiles,
some configs] Don't forget mail from /var or wherever your mail was stored.

On the 4TB spinner, make a mount point called /data and move the music
and video files across to sit under it.
.
Optionally, at some point, repartition the 4TB for everything other
than the music data amd make another LVM volume for use.

Maybe you want to keep a smaller swap partition on the spinning disk rather than swapping onto NVME but that's a choice.

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.

Copying with dd just means that you've copied a chunk - it may not
be aligned.

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.)

That's problematic, I think.

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 ([email protected]) (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?

In some sense, all you have to safeguard is your music and video files.

Hope this helps,

Andy

--
/~\ Charlie Gibbs | We'll go down in history as
\ / <[email protected]d> | 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From George at Clug@21:1/5 to All on Mon Nov 25 08:30:02 2024

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 ([email protected]) (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

<html>
<head>
<style type="text/css">
body,p,td,div,span{
font-size:13px; font-family:Arial, Helvetica, sans-serif;
};
body p{
margin:0px;
}
</style>
</head>
<body>Charlie, 

I think this is what you are looking for (and what I use). 

# nano /etc/default/grub 

<a href="https://wiki.debian.org/Grub" target="_blank" class="normal-link">https://wiki.debian.org/Grub</a> 
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. 
 <div>
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. </

<div> </div><div>In /etc/fstab add entry something like, depending on what ext or other format your drive is: </div><div>UUID=ecbf69dd-e238-42f4-9ee9-043044cc0953 /home/[username]/videos/HD ext4    defaults,noatime  &

nbsp;     0       2 </div><div>I hope the "nano /etc/default/grub" info helps? </div><div> </div><div>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 ! </div><div> </div><div>George. </div>

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 
> ([email protected]) (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 
> \ /  <[email protected]d>      |  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 
> 
></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Frank Guthausen@21:1/5 to Charlie Gibbs on Mon Nov 25 10:20:01 2024

On Sun, 24 Nov 2024 17:56:25 -0800
Charlie Gibbs <[email protected]> wrote:

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.[...]

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 seen this problem recently on an amd64 architechture machine.

You do not have to edit this file. Since your HDD is large, your system
is likely to boot UEFI. Check whether there is an EFI partition - the 1M partitions are a good candidate. Check your grub package to support
this:

grub-efi-amd64

The package grub-pc will be removed, when you install that one.

Inside a chroot install grub with a mounted EFI partition
(e.g. to /boot/efi relative to the chroot environment) with
something like:

grub-install --target=x86_64-efi --efi-directory=/boot/efi

The classic GRUB package and install will write to disk,
but the UEFI firmware might not be able to boot that. BTST
HTH

kind regards
Frank

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From [email protected]@21:1/5 to George at Clug on Mon Nov 25 16:10:02 2024

On 11/25/24 02:26, George at Clug wrote:

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.

I find PARTLABELs to be a lot more human-friendly than UUIDs.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Felix Miata@21:1/5 to All on Mon Nov 25 16:40:01 2024

David Wright composed on 2024-11-25 09:21 (UTC-0600):

On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote:

George at Clug wrote:

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.

I find PARTLABELs to be a lot more human-friendly than UUIDs.

Can you put PARTLABELs on an MBR disk?

(I'm not condoning such a disk. I'd take the opportunity to
switch to UEFI booting from a GPT SSD if that's possible.
Some explanation of the partitioning would be useful, rather
that slavishly copying them.)

I have to think eben wasn't conscious of the difference between PARTLABEL and LABEL when composing.

All manual configuration I do involving Linux native filesystems is done using LABELs, swapspace too. I favor lsblk -f over blkid most of the time.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From David Wright@21:1/5 to eben on Mon Nov 25 16:30:01 2024

On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote:

On 11/25/24 02:26, George at Clug wrote:

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.

I find PARTLABELs to be a lot more human-friendly than UUIDs.

Can you put PARTLABELs on an MBR disk?

(I'm not condoning such a disk. I'd take the opportunity to
switch to UEFI booting from a GPT SSD if that's possible.
Some explanation of the partitioning would be useful, rather
that slavishly copying them.)

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From [email protected]@21:1/5 to [email protected] on Mon Nov 25 18:00:02 2024

On Mon, Nov 25, 2024 at 10:07:35AM -0500, [email protected] wrote:

On 11/25/24 02:26, George at Clug wrote:

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.

I find PARTLABELs to be a lot more human-friendly than UUIDs.

As Felix pointed out in this thread, you're possibly talking about
(file system) LABELS. The idea of UUIDs is that they are "unique",
so you can run two OS installs automatically without the disk IDs
colliding. We leave the collision probability of UUIDs as an exercise
for the reader. Suffice it to say that the probability of /very
weird/ things happening (let alone an alpha particle flipping a few
bits in your RAM) is higher than a UUID collision.

A label is something you come up to slap onto something. So using
the same label is most of the time intended.

Of course, this UUID uniqueness thing starts looking ever more
flimsy once you start bit-copying file systems (people do this!
I know I do!).

Civilised file systems have a slot for each, so you can use both
of them, at the same time, for different purposes.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0Ss6AAKCRAFyCz1etHa Rg5GAJ9rzjZZkbjdy+URiKdzMWYvJNZn5QCfUcg19Y5o+0nBSBLvkW66h91x/+I=
=djUM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From [email protected]@21:1/5 to Default User on Mon Nov 25 19:00:01 2024

On Mon, Nov 25, 2024 at 12:36:55PM -0500, Default User wrote:

[...]

Thomas, would you mind elaborating on, or give a link to an
explanation of:

"Of course, this UUID uniqueness thing starts looking ever more
flimsy once you start bit-copying file systems . . . "

I'm not sure I understand what bit-copying of file systems is,
and why it would be flimsy.

It's more trivial than it seems. If you copy a whole file system
bit-for-bit (e.g. with dd or similar), since the UUID is "in there",
it travels along. Now you have two identical file systems with the
same UUID.

If you now, for example, mount one and write things to it, you have
two different file systems with the same UUID.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0S64wAKCRAFyCz1etHa RlvkAJ9Cf8bvHaKG0gFeqOdNETz84wi9oQCeOiKeekq/7TKMjM91dPfHngAMMwk=
=dEKW
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From [email protected]@21:1/5 to David Wright on Mon Nov 25 18:30:01 2024

On 11/25/24 10:21, David Wright wrote:

On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote:

On 11/25/24 02:26, George at Clug wrote:

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.

I find PARTLABELs to be a lot more human-friendly than UUIDs.

Can you put PARTLABELs on an MBR disk?

Ah, apparently you have to use LABEL, but otherwise yes, at least in fstab:

eben@cerberus:~$ sudo fdisk -l /dev/sdc | grep label
Disklabel type: dos

eben@cerberus:~$ sudo blkid /dev/sdc1
/dev/sdc1: LABEL="Partition_1" UUID="ab7e9bee-27f4-4f4f-94c4-5d19d8413074" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b1604273-01"

eben@cerberus:~$ grep Partition_1 /etc/fstab
LABEL=Partition_1 /mnt/temp2 ext4 defaults,noauto 0 0

eben@cerberus:~$ mount | grep temp2

eben@cerberus:~$ sudo mount /mnt/temp2

eben@cerberus:~$ mount | grep temp2
/dev/sdc1 on /mnt/temp2 type ext4 (rw,relatime,stripe=8191)

(I'm not condoning such a disk. I'd take the opportunity to
switch to UEFI booting from a GPT SSD if that's possible.
Some explanation of the partitioning would be useful, rather
that slavishly copying them.)

I repartitioned in GPT because the 4 partition limit in MBR without jumping through hoops made them hard to deal with. My motherboard doesn't boot in UEFI, but still.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Hans@21:1/5 to All on Mon Nov 25 21:00:01 2024

I am not sure, what you are intend to do.

If you want a new bootable harddrive, I suggest, to clone the old (maybe smaller one) to the new one using clonezilla.

After it you can resize the partitions of new one to your needs and then mount the old one to any folder you want (maybe "/space" or "/data", whatever)

Or just format it.

If you then want it automatically mounted, I suggest, to enter the device
(like "/dev/sdc1") into /etc/fstab, but the UUID.

If you are using the devicename, it may happen when several harrdtrives, the BIOS will not recognize the correct order. So /dev/sdc1 is /dev/sdd1 suddenly. (I have 4 harddrives in my computer and ran in this issue)

Using UUID will avoid this.

An entry in /etc/fstab would then look like this:

UUID=XXXXX-XXXX-XXXX-XXXX-XXXXXXXXX /home ext4 defaults 0

Just an example.

Dunno, if it is that, what you want. If not, just ignore my mail.

Best

Hans

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From [email protected]@21:1/5 to Default User on Mon Nov 25 23:40:01 2024

On 11/25/24 12:36, Default User wrote:

Thomas, would you mind elaborating on, or give a link to an
explanation of:

"Of course, this UUID uniqueness thing starts looking ever more
flimsy once you start bit-copying file systems . . . "

I'm not sure I understand what bit-copying of file systems is,
and why it would be flimsy.

I'm not Thomas, but here you go. If you do

dd if=/dev/sda1 of=/dev/sdb1

to copy sda1 to sdb1, they get the same UUID. Which makes one question the Uniqueness part. I ran into that, and my solution was to use the actual
device names everywhere, something of the sdXY format. Which worked great until I installed Debian, and something in the boot process makes the names switch randomly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Greg Wooledge@21:1/5 to [email protected] on Tue Nov 26 00:00:01 2024

On Mon, Nov 25, 2024 at 17:37:28 -0500, [email protected] wrote:

I'm not Thomas, but here you go. If you do

dd if=/dev/sda1 of=/dev/sdb1

to copy sda1 to sdb1, they get the same UUID. Which makes one question the Uniqueness part. I ran into that, and my solution was to use the actual device names everywhere, something of the sdXY format. Which worked great until I installed Debian, and something in the boot process makes the names switch randomly.

Using "sda1" in fstab is a bad idea, for exactly the reasons you
discovered the hard way. The names will not necessarily be assigned
to the same devices each time you boot.

Given that you dd-copied a file system, you might consider changing
the UUID of the new copy. Assuming this is an ext4 file system,
tune2fs(8) has a -U option that looks like it should do the job.
Specifically, "-U random" looks promising, though I haven't tested it.

If it's not ext4, then consult your documentation for whichever type
of file system this is.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Felix Miata@21:1/5 to All on Tue Nov 26 00:30:01 2024

Greg Wooledge composed on 2024-11-25 17:50 (UTC-0500):

Given that you dd-copied a file system, you might consider changing
the UUID of the new copy. Assuming this is an ext4 file system,
tune2fs(8) has a -U option that looks like it should do the job. Specifically, "-U random" looks promising, though I haven't tested it.

Well tested here:
# grep U .bash_history | head -1
tune2fs -U random -L p20deb12 /dev/sda20
# grep U .bash_history | wc -l
42
#

Another PC:
# grep U .bash_history | wc -l
34
# grep U .bash_history | head -1
tune2fs -U random -L p13trixie /dev/sda13
#

I've been getting rid of 128 byte inode filesystems lately in long term prep for
2038 32bit time rollover.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From George at Clug@21:1/5 to All on Tue Nov 26 01:50:01 2024

On Tuesday, 26-11-2024 at 02:33 Felix Miata wrote:

David Wright composed on 2024-11-25 09:21 (UTC-0600):

On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote:

George at Clug wrote:

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.

I find PARTLABELs to be a lot more human-friendly than UUIDs.

Can you put PARTLABELs on an MBR disk?

(I'm not condoning such a disk. I'd take the opportunity to
switch to UEFI booting from a GPT SSD if that's possible.
Some explanation of the partitioning would be useful, rather
that slavishly copying them.)

I have to think eben wasn't conscious of the difference between PARTLABEL and LABEL when composing.

All manual configuration I do involving Linux native filesystems is done using
LABELs, swapspace too. I favor lsblk -f over blkid most of the time.

"$ lsblk -f" output is very nice ! Thanks.

George.

--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From David Christensen@21:1/5 to Charlie Gibbs on Tue Nov 26 03:20:01 2024

On 11/24/24 17: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.

You have not mentioned backups or archives. Please do so, if you have
not already.

A key decision you must make is whether to have one computer
(all-in-one) or to have two computers (workstation and file server).
Each approach has its advantages and disadvantages. My SOHO
installation has a file server, a backup server, many client devices,
Gigabit Ethernet, and 802.11ac Wi-Fi. I have an 8-port KVM switch at my primary work area.

A newer used video card could make that old motherboard/ CPU/ memory
useful again. I would put the new parts in a new case, put the old
parts in the old case, buy a KVM switch, and have two working computers.
This gives you more options.

I recently rebuilt my file server and my backup server using Fractal
Design cases and power supplies. I have been very impressed with the
quietness and cooling:

https://www.fractal-design.com/products/cases/define/define-r5/black/

https://www.fractal-design.com/products/power-supplies/ion/ion-2-platinum-660w/black/

https://www.fractal-design.com/products/fans/venturi/venturi-hf-14/white/

The box was getting flaky on boot anyway,

How so?

so I figured it was time to spring for a new motherboard,

Make and model?

complete with an AMD Ryzen 5 processor,

Model?

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.

Make and model?

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

Make and mode?

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 ([email protected]) (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?

Every time I tried multi-boot, I found it to be brittle. Similarly so
for multiple bootable drives in the same computer. My solution was hard
drive mobile racks, extra drives, and one OS instance per drive.
Throwing money at the problem lowers the knowledge and skill
requirements, simplifies system administration, and prevents service interruptions:

https://www.startech.com/en-us/hdd/drw150satbk

https://www.startech.com/en-us/hdd/hsb220sat25b

https://www.startech.com/en-us/hdd/s25slotr

Given the various high-quality "free" virtualization solutions that are
now available, I use virtual machines whenever they make sense.

I suggest that you disconnect all drives except optical and the NVMe
SSD, configure the new motherboard firmware for UEFI, boot the Debian Installer, go to a rescue shell, zero-fill or secure erase the NVMe SSD,
reboot the Debian Installer, and do a fresh install of Debian onto the
NVMe SSD. I do not use LVM. I keep the boot, swap, and root partitions
small, to facilitate imaging, disaster preparedness, and disaster
recovery (1 GB, 1 GB, and 13 GB, respectively). If the SSD has spare
empty space, I create a partition and file system for scratch files,
virtual machines, etc..

For the all-in-one approach, then reconnect the 4 TB HDD, disable the
bootable flag on the appropriate partition, and mount the data
partitions(s)/ file system(s).

For the workstation and server approach, then share the 4 TB HDD data
file system(s) on the server and mount them on the workstation.

In both cases, think about getting another 4 TB HDD and implementing
RAID1 (mirror). HDD sectors become unreadable over time, and your
files, directories, file systems, and/or partition tables will become
corrupt if you do not have RAID. Automatic repair by RAID is far easier
than restoring from backups/ archives or than forensic disk drive data recovery. Your motherboard firmware may provide hardware RAID, or you
can buy a hardware RAID card. Linux offers several choices of software
RAID.

David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Charlie Gibbs@21:1/5 to All on Tue Nov 26 07:30:01 2024

Many thanks to all of you who have replied to my questions.
It seems that I've been creating trouble for myself by trying
to kludge something together from the old installation.
The only reason I tried this was the age-old problem I
have whenever I start from a fresh install: I lose all my
customizations and added packages that went into /usr, /var,
/etc, etc. :-) It takes a while to put all this stuff back;
for a month or so after a fresh install I'm discovering (and
re-installing) missing things. I was hoping I could avoid
this, but it seems that the time I'm spending on my jury-rigged
"solution" more than offsets any savings I might realize.

I bit the bullet and downloaded the Debian 12.8 installer to a
thumb drive. To be safe, I unplugged the original hard drive
to keep it out of harm's way (and to avoid any possible confusion
for the installer). Then I deleted all the partitions I was
experimenting with on the SSD, and did a fresh install. WOW!
Was that ever fast! A complete install in 5 minutes or less!
And booting is also lightning-fast.

But, as I expected, all my stuff is gone. Well, sort of.
I plugged the hard drive back in, and all my files are
there. But there are no icons left on the desktop - no
more Portal, and none of the utilities I downloaded were
on my $PATH.

How do the rest of you deal with all the user-added stuff
that vanishes when you do a fresh install? Are there some
tricks I can use, rather than painstakingly re-installing
all my utilities one by one? I assume you can just copy
the old /home over to the new drive (although in my case
I'll be leaving the big music and video directories on the
spinning rust, to be accessed at a new mount point that I'll
add to /etc/fstab). But that does nothing about all the
nifty utilities that were in (e.g.) /usr/bin (even though
the configuration files are probably in /home).

For now, though, the box is sort of running. And man, is it
a speed demon. Once again, thanks for the assistance.

--
/~\ Charlie Gibbs | Life is perverse.
\ / <[email protected]d> | It can be beautiful -
X I'm really at ac.dekanfrus | but it won't.
/ \ if you read it the right way. | -- Lily Tomlin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From George at Clug@21:1/5 to All on Tue Nov 26 08:30:01 2024

On Tuesday, 26-11-2024 at 17:03 Charlie Gibbs wrote:

Many thanks to all of you who have replied to my questions.
It seems that I've been creating trouble for myself by trying
to kludge something together from the old installation.
The only reason I tried this was the age-old problem I
have whenever I start from a fresh install: I lose all my
customizations and added packages that went into /usr, /var,
/etc, etc. :-) It takes a while to put all this stuff back;
for a month or so after a fresh install I'm discovering (and
re-installing) missing things. I was hoping I could avoid
this, but it seems that the time I'm spending on my jury-rigged
"solution" more than offsets any savings I might realize.

I bit the bullet and downloaded the Debian 12.8 installer to a
thumb drive. To be safe, I unplugged the original hard drive
to keep it out of harm's way (and to avoid any possible confusion
for the installer). Then I deleted all the partitions I was
experimenting with on the SSD, and did a fresh install. WOW!
Was that ever fast! A complete install in 5 minutes or less!
And booting is also lightning-fast.

But, as I expected, all my stuff is gone. Well, sort of.
I plugged the hard drive back in, and all my files are
there. But there are no icons left on the desktop - no
more Portal, and none of the utilities I downloaded were
on my $PATH.

Linux's libraries and dependencies from your old installs of your "utilities" are likely to be very different to your new Linux environment.

I recommend finding current Debian (i.e. Bookworm?) packaged versions, and if they are not in Debian packages, then downloading the Utilities from their respective web sites (if they offer installation instructions for the Debian environment. If these
too were not possible, I personally would give up using the "utilities", and where possible finding something that kind of does what they did. Not knowing what your utilities are that you used to run, I can only make broad suggestions, and sorry if some
of those "utilities" are very important to you. For me, I give up and move on quicker that some, even if I really miss them. All the best in your efforts, I hope you succeed !

How do the rest of you deal with all the user-added stuff
that vanishes when you do a fresh install? Are there some
tricks I can use, rather than painstakingly re-installing
all my utilities one by one? I assume you can just copy
the old /home over to the new drive (although in my case
I'll be leaving the big music and video directories on the
spinning rust, to be accessed at a new mount point that I'll
add to /etc/fstab).

If you had spare space, I would be tempted to put a copy of the videos/music that I liked, to the new NVMe. Speed and ease of use. I would keep the HD as a backup.

BTW: I still think HDs have less chance of dying and/or loosing data that SDD (inc NVMe SSDs).

But that does nothing about all the
nifty utilities that were in (e.g.) /usr/bin (even though

the configuration files are probably in /home).

I would not recommend copying over hidden folder config files unless they were for a specific "utility" that you used to use. I have found conflicts between new installations with configuration files of older installations due to programs changing the
way they store their own configurations/data.

Even if it means setting things up again, and the waste of time that takes, I prefer to have a stable environment as my first priority. Stability even triumphs over my laziness.

For now, though, the box is sort of running. And man, is it
a speed demon. Once again, thanks for the assistance.

I hope for a nice stable, fast, and reliable Debian system for you (with programs that do what you used to do, whether that be the same utilities you used to use, or some kind of replacement program.

George.

--
/~\ Charlie Gibbs | Life is perverse.
\ / <[email protected]d> | It can be beautiful -
X I'm really at ac.dekanfrus | but it won't.
/ \ if you read it the right way. | -- Lily Tomlin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Karl Vogel@21:1/5 to All on Tue Nov 26 11:50:01 2024

On Tue 26 Nov 2024 at 01:21:31 (-0500), Charlie Gibbs wrote:

How do the rest of you deal with all the user-added stuff that vanishes
when you do a fresh install? Are there some tricks I can use, rather
than painstakingly re-installing all my utilities one by one?

I use a filesystem "/dist" to keep various installations I've done:

/dist
| +--i386-pc-solaris2.11
| +--sparc-sun-solaris2.10
| +--x86_64-centos5-linux
| +--x86_64-centos6-linux
| +--x86_64-freebsd-10.4-rel
| +--x86_64-freebsd-11.3-rel
| +--x86_64-oracle6.9-linux
| +--x86_64-oracle6.10-linux
| +--x86_64-oracle7.9-linux

Each system directory (named by architecture and OS-release) contains
a tree like this:

/dist
| +--x86_64-whatever
| | +--bin # original /bin
| | +--boot # original /boot
| | +--etc.orig # original /etc
| | +--etc # /etc with all my changes
| | +--home # interesting parts of $HOME like dotfiles
| | +--lib # original /lib
| | +--libexec # original /libexec, if present
| | +--root # anything I added to root home directory
| | +--sbin # original /sbin
| | +--STIG # STIG software and check results, if any
| | +--usr
| | | +--bin # original /usr/bin
| | | +--lib # original /usr/lib
| | | +--local # anything I installed
| | +--var
| | | +--cron
| | | | +--tabs # scheduled jobs for me, root, etc.
| | | +--log # any /var/log files I created --
# placeholders with owner and permissions

I create this tree when I have a server/workstation I'm happy with,
and I update it when I'm about to retire the system.

The biggest {time,error}-saver was doing this immediately after getting
a bootable system so I can recover from a bad change to an /etc file:

root# mkdir /etc.orig
root# cd /etc
root# find . -print | cpio -pdum /etc.orig

HTH.

--
Karl Vogel I don't speak for anyone but myself

CEO assistant: "please reset CEO's password, he's too drunk to remember it."
--Reddit "unusual IT support tickets", 5 Nov 2024

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Chris Green@21:1/5 to All on Tue Nov 26 13:20:01 2024

On Tue 26 Nov 2024 at 01:21:31 (-0500), Charlie Gibbs wrote:

How do the rest of you deal with all the user-added stuff that vanishes
when you do a fresh install? Are there some tricks I can use, rather
than painstakingly re-installing all my utilities one by one?

I do two things:-

1 - Keep a simple text list of packages I have added to the system
using 'apt install' (or aptitude, or synaptic, or whatever). Then
when I do a clean install I can simply add all the extra packages, I
suppose I could automate it even but I don't bother doing that.

2 - I have a mercurial repository in /etc, it has an ignore file that,
by default, ignores every file in /etc. Then, when I modify something,
I first do an 'hg add <file>' and then do the change and commit it to
the repository. I thus have a history (and diffs) of all the changes
I have done in /etc. With a new install I make a backup copy of the
old /etc and refer to it to make similar changes to the new system.

--
Chris Green
·

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Anssi Saari@21:1/5 to Charlie Gibbs on Tue Nov 26 15:20:01 2024

Charlie Gibbs <[email protected]> writes:

How do the rest of you deal with all the user-added stuff
that vanishes when you do a fresh install?

I don't do fresh installs as a rule, not when changing hardware or
shuffling files around like in your case, or when I wanted to switch
from MBR partition table to GPT or when otherwise shuffling partitions
around.

In fact, I find it weird to see people advocate the Windows way of "if
in doubt, reinstall". Linux installations are robust and long lived. In
fact, Windows is pretty good too, these days.

However, my little pizza box kicked the bucket recently so I got an
identical replacement. My backups include the output of dpkg
--get-selections "*" as recommended in the Debian release notes so
putting all the same packages on the replacement box needed just some
apt work. I also save the partition table but in the case of a small
system it's not an issue. The system specific stuff in /etc and /home I
pulled from backups as well.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From David Christensen@21:1/5 to Charlie Gibbs on Tue Nov 26 23:00:01 2024

On 11/25/24 22:03, Charlie Gibbs wrote:

Many thanks to all of you who have replied to my questions.

YW. :-)

It seems that I've been creating trouble for myself by trying
to kludge something together from the old installation.
The only reason I tried this was the age-old problem I
have whenever I start from a fresh install: I lose all my
customizations and added packages that went into /usr, /var,
/etc, etc. :-) It takes a while to put all this stuff back;
for a month or so after a fresh install I'm discovering (and
re-installing) missing things. I was hoping I could avoid
this, but it seems that the time I'm spending on my jury-rigged
"solution" more than offsets any savings I might realize.

I bit the bullet and downloaded the Debian 12.8 installer to a
thumb drive. To be safe, I unplugged the original hard drive
to keep it out of harm's way (and to avoid any possible confusion
for the installer). Then I deleted all the partitions I was
experimenting with on the SSD, and did a fresh install. WOW!
Was that ever fast! A complete install in 5 minutes or less!
And booting is also lightning-fast.

But, as I expected, all my stuff is gone. Well, sort of.
I plugged the hard drive back in, and all my files are
there. But there are no icons left on the desktop - no
more Portal, and none of the utilities I downloaded were
on my $PATH.

How do the rest of you deal with all the user-added stuff
that vanishes when you do a fresh install?

Similar to other readers, I use a version control system (CVS) to help
me with system administration -- checking in system configuration files
I modify or create, keeping a plain text log file of my notes and
console sessions, keeping a plain text file containing the names of
packages I have installed, checking in various shell and Perl scripts I
have written over the years, checking in app configuration and data
files, etc.. Then when I do a fresh install, I check out a CVS working directory for the previous incarnation of that machine, or something
similar, and use those files to help me configure the new system.

AIUI the "top shelf" solution is configuration management systems, such
as Puppet, Ansible, etc.. I expect they are necessities in large
organization IT environments.

Are there some
tricks I can use, rather than painstakingly re-installing
all my utilities one by one?

I take images of my OS disks using dd(1) on a regular basis. So, if I
finger fumble and scramble an OS instance, recovery consists of pulling
the OS SSD, restoring the last image onto a spare SSD, booting, updating Debian, checking out the appropriate CVS working directories, and
merging changes made since the image was taken.

I assume you can just copy
the old /home over to the new drive (although in my case
I'll be leaving the big music and video directories on the
spinning rust, to be accessed at a new mount point that I'll
add to /etc/fstab). But that does nothing about all the
nifty utilities that were in (e.g.) /usr/bin (even though
the configuration files are probably in /home).

I treat the home tree as part of the OS instance. So, it is
incorporated into my image backup/ restore process (above). My home
directory contains CVS working directories and whatever files and/or directories Debian and the various apps put there.

It is up to us and/or the various app developers to figure out
migration, disaster preparedness, disaster recovery, etc., for the
various apps we use. I have configured Thunderbird to copy incoming
mail to a spare directory on the IMAP server, I have configured
Thunderbird to send a BCC of outgoing mail to a spare e-mail account,
and I backup the Thunderbird profile directory daily. I use the Firefox
"Sync" feature to deal with that app's configuration and data. I have
put various app files into CVS projects.

For now, though, the box is sort of running. And man, is it
a speed demon. Once again, thanks for the assistance.

Enjoy. :-)

David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From David Wright@21:1/5 to Charlie Gibbs on Wed Nov 27 06:30:01 2024

On Mon 25 Nov 2024 at 22:03:33 (-0800), Charlie Gibbs wrote:

But, as I expected, all my stuff is gone. Well, sort of.
I plugged the hard drive back in, and all my files are
there. But there are no icons left on the desktop - no
more Portal, and none of the utilities I downloaded were
on my $PATH.

How do the rest of you deal with all the user-added stuff
that vanishes when you do a fresh install? Are there some
tricks I can use, rather than painstakingly re-installing
all my utilities one by one? I assume you can just copy
the old /home over to the new drive (although in my case
I'll be leaving the big music and video directories on the
spinning rust, to be accessed at a new mount point that I'll
add to /etc/fstab). But that does nothing about all the
nifty utilities that were in (e.g.) /usr/bin (even though
the configuration files are probably in /home).

You have the perfect opportunity not to repeat the mistake of
scattering these nifty utilities about, whatever they are,
or comingling them with the Debian system. Knowing nothing
about where you got them, and in what form, you could either
repeat installing them, or just copy the binaries across,
but keep them separate from Debian by placing them in any of
/opt, /usr/local/bin, ~/.local/bin or ~/bin as appropriate.
/usr/local/ will already have other subdirectories besides
bin/, and you can create similar ones under ~/.local/bin/.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From [email protected]@21:1/5 to Charlie Gibbs on Wed Nov 27 23:50:01 2024

On 11/26/24 01:03, Charlie Gibbs wrote:

But there are no icons left on the desktop - no more Portal, and none of
the utilities I downloaded were on my $PATH.

How do the rest of you deal with all the user-added stuff that vanishes
when you do a fresh install? Are there some tricks I can use, rather
than painstakingly re-installing all my utilities one by one?

If they were installed through a package manager, you probably shouldn't do that.

I assume you can just copy the old /home over to the new drive

Mind the dotfiles. Apps might behave strangely when you run them with an
old config file.

But that does nothing about all the nifty utilities that
were in (e.g.) /usr/bin (even though the configuration files are probably
in /home).

I hate losing stuff and drastic changes like that, so what I've done in
the past when I used Ubuntu was:

* do a complete backup
* clean-install the latest *-LTS version
* restore /home, being careful not to overwrite existing dotfiles
* restore any other filesystems that aren't part of the base install
* modify /etc/profile.d/* to change $PATH as appropriate
* keep the installation as long as possible.

The last time I went through this I made a list of installed packages (apt
list --installed) so I could re-install (some of) them on the new OS.

This probably is not the recommended procedure. Since I switched to Debian
the issue hasn't come up, so I haven't yet been forced into a decision as to how to deal with it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From John Hasler@21:1/5 to Charlie Gibbs on Tue Dec 10 01:10:02 2024

Charlie Gibbs writes:

But many binaries have been installed in places like /usr/bin; their configuration files may or may not be in /home, but I'd rather not
lose them wherever they are.

Do you mean that you have placed stuff not under control of the package management system in /usr/bin?
--
John Hasler
[email protected]
Elmwood, WI USA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Charlie Gibbs@21:1/5 to All on Tue Dec 10 00:40:02 2024

Some of you may recall my account of trying to install a new disk (in
my case a 1TB NVMe stick) for use as a boot device. There has been
another thread or two from other people dealing with the same issue,
so it seems to be a hot topic.

I'm still unwilling to give up all my installed packages and
customizations and rebuild the system from scratch, when all I want
to do is copy existing directories to a new boot drive. My own data
files all live in /home, a separate partition - no problem there.
But many binaries have been installed in places like /usr/bin; their configuration files may or may not be in /home, but I'd rather not
lose them wherever they are.

Here's the process I've been trying so far:

1. Do a network install on the new drive; to be really belt-and-
suspenders, make sure everything is completely updated:
sudo apt update
sudo apt upgrade

2. Re-boot from the original drive and update everything:
sudo apt update
sudo apt upgrade
At this point the old and new systems' root partitions should be
as alike as possible, aside from my own customizations.

3. Mount the new drive's root partition somewhere that I can access
from the original drive:
sudo mount /dev/nvme0n1p2 /mnt/backup

4. Save the new system's /etc/fstab:
sudo cp -p /mnt/backup/etc/fstab ~

5. Copy directories from the original drive to the new drive:
sudo rsync -av /bin /mnt/backup
sudo rsync -av /etc /mnt/backup
sudo rsync -av /lib /mnt/backup
sudo rsync -av /lib64 /mnt/backup
sudo rsync -av /opt /mnt/backup
sudo rsync -av /sbin /mnt/backup
sudo rsync -av /usr /mnt/backup
sudo rsync -av /var /mnt/backup
sudo rsync -av /home /mnt/backup

6. Restore the new drive's /etc/fstab:
sudo cp -p ~/etc/fstab /mnt/backup/etc

7. Re-boot from the new drive and cross your fingers.

The system comes up with an xfce login window, but I can't log in
using my regular user ID. Sometimes the screen just goes black,
then after a couple of seconds re-displays a blank login screen.
Lately, though, I've been getting a window with the message:
Xsession: warning: unable to write to /tmp;
X session may exit with an error.
Clicking on "okay" makes the screen goes black; after a
couple of seconds it then returns to an empty login screen.
However, I can log in as root, which suggests some sort
of permissions issue, but it doesn't seem to be with /tmp:

drwxrwxrwt 12 root root 4096 Dec 9 11:58 tmp

To further muddy the waters, I can SSH in from another machine
using my regular user ID.

I'd like to resolve this, but if not I can always fall back to the
original drive. Anybody wanna buy a lightly used 1TB NVMe SSD?

--
/~\ Charlie Gibbs | "Some of you may die,
\ / <[email protected]d> | but it's a sacrifice
X I'm really at ac.dekanfrus | I'm willing to make."
/ \ if you read it the right way. | -- Lord Farquaad (Shrek)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Charlie Gibbs@21:1/5 to [email protected] on Tue Dec 10 03:00:01 2024

On Mon Dec 9 17:25:55 2024 John Hasler <[email protected]> wrote:

Charlie Gibbs writes:

But many binaries have been installed in places like /usr/bin; their
configuration files may or may not be in /home, but I'd rather not
lose them wherever they are.

Do you mean that you have placed stuff not under control of the
package management system in /usr/bin?

No, I've been good about installing things the approved way, e.g.

apt install zip

Yes, not even zip is present after an installation from scratch -
and apt puts it into /usr/bin.

--
[email protected] (Charlie Gibbs)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From John Hasler@21:1/5 to Charlie Gibbs on Tue Dec 10 03:20:01 2024

Charlie Gibbs writes:

No, I've been good about installing things the approved way, e.g.
apt install zip

Then what files do you think you will lose?

Yes, not even zip is present after an installation from scratch -

zip is priority: optional. It won't be installed unless you ask for it.
--
John Hasler
[email protected]
Elmwood, WI USA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From David Wright@21:1/5 to Charlie Gibbs on Tue Dec 10 03:50:01 2024

On Mon 09 Dec 2024 at 15:23:18 (-0800), Charlie Gibbs wrote:

Some of you may recall my account of trying to install a new disk (in
my case a 1TB NVMe stick) for use as a boot device. There has been
another thread or two from other people dealing with the same issue,
so it seems to be a hot topic.

I'm still unwilling to give up all my installed packages and
customizations and rebuild the system from scratch, when all I want
to do is copy existing directories to a new boot drive. My own data
files all live in /home, a separate partition - no problem there.
But many binaries have been installed in places like /usr/bin; their configuration files may or may not be in /home, but I'd rather not
lose them wherever they are.

Why "But …"? Aren't most binaries (those that users run, anyway)
installed in /usr/bin/.

Here's the process I've been trying so far:

1. Do a network install on the new drive; to be really belt-and-
suspenders, make sure everything is completely updated:
sudo apt update
sudo apt upgrade

2. Re-boot from the original drive and update everything:
sudo apt update
sudo apt upgrade
At this point the old and new systems' root partitions should be
as alike as possible, aside from my own customizations.

At that point, I would compare sorted versions of /etc/passwd
and /etc/group from both machines to make sure that they have
matching lists of user/group names. (The numeric IDs can be
different.) Otherwise rsync could mistranslate ownerships.

3. Mount the new drive's root partition somewhere that I can access
from the original drive:
sudo mount /dev/nvme0n1p2 /mnt/backup

4. Save the new system's /etc/fstab:
sudo cp -p /mnt/backup/etc/fstab ~

5. Copy directories from the original drive to the new drive:
sudo rsync -av /bin /mnt/backup
sudo rsync -av /etc /mnt/backup
sudo rsync -av /lib /mnt/backup
sudo rsync -av /lib64 /mnt/backup
sudo rsync -av /opt /mnt/backup
sudo rsync -av /sbin /mnt/backup
sudo rsync -av /usr /mnt/backup
sudo rsync -av /var /mnt/backup
sudo rsync -av /home /mnt/backup

6. Restore the new drive's /etc/fstab:
sudo cp -p ~/etc/fstab /mnt/backup/etc

↑↑↑↑↑↑↑↑↑
Where did that file come from? Not step 4.

7. Re-boot from the new drive and cross your fingers.

The system comes up with an xfce login window, but I can't log in
using my regular user ID. Sometimes the screen just goes black,
then after a couple of seconds re-displays a blank login screen.
Lately, though, I've been getting a window with the message:
Xsession: warning: unable to write to /tmp;
X session may exit with an error.
Clicking on "okay" makes the screen goes black; after a
couple of seconds it then returns to an empty login screen.
However, I can log in as root, which suggests some sort
of permissions issue, but it doesn't seem to be with /tmp:

drwxrwxrwt 12 root root 4096 Dec 9 11:58 tmp

To further muddy the waters, I can SSH in from another machine
using my regular user ID.

I'd like to resolve this, but if not I can always fall back to the
original drive. Anybody wanna buy a lightly used 1TB NVMe SSD?

I've never used DMs and DEs. Do they squirrel away anything
with ownerships attached (either by name or number) that might
be mistranslated, seeing as your two disks likely have different
ideas on the matter.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Anssi Saari@21:1/5 to Charlie Gibbs on Tue Dec 10 14:30:01 2024

Charlie Gibbs <[email protected]> writes:

5. Copy directories from the original drive to the new drive:
sudo rsync -av /bin /mnt/backup
sudo rsync -av /etc /mnt/backup
sudo rsync -av /lib /mnt/backup
sudo rsync -av /lib64 /mnt/backup
sudo rsync -av /opt /mnt/backup
sudo rsync -av /sbin /mnt/backup
sudo rsync -av /usr /mnt/backup
sudo rsync -av /var /mnt/backup
sudo rsync -av /home /mnt/backup

It seems to me there are that things that are not be handled by rsync
-a, namely acls and extended attributes and SELINUX context too. At
least.

From a little googling it seems GDM at least changes ACLs of some things

so maybe that's the problem? Some use of getfacl might show differences
in ACLs. I don't really understand the /tmp writing issue though.

Anyways, I usually image when cloning drives. Either partition by
partition with partclone or whole disk with dd, possibly doing file
checksums before and checking after to make sure.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Who's Online
Recent Visitors
- Furryboy
  Sun Jun 7 13:40:29 2026
  from Romania, Galati via SSH
- Krenn
  Sun Jun 7 10:02:33 2026
  from Sydney, Nsw via Telnet
- Spearb0y
  Sun Jun 7 07:41:05 2026
  from Massachusetts via SSH
- Krenn
  Sun Jun 7 03:07:26 2026
  from Sydney, Nsw via Telnet
- Krenn
  Sun Jun 7 01:30:12 2026
  from Sydney, Nsw via Telnet
- Centurion
  Sat Jun 6 23:27:30 2026
  from Berea, Ohio via Telnet
- Ab Cadd
  Sat Jun 6 15:42:53 2026
  from Sheboygan, Wi via Telnet
- Centurion
  Sat Jun 6 15:32:28 2026
  from Berea, Ohio via Telnet

System Info

Sysop:	Keyop
Location:	Huddersfield, West Yorkshire, UK
Users:	715
Nodes:	16 (2 / 14)
Uptime:	00:31:27
Calls:	12,097
Calls today:	5
Files:	15,003
Messages:	6,517,858

Adding a new boot disk while keeping old disk

Who's Online

Recent Visitors

System Info