Eben King (HE12025-07-31):

I recently got some SSDs, and decided to use one of them (a 256G model) to boot from. I want the change to be undetectable, in that from a user perspective, nothing seems different, just faster.

I currently have a 2T HD, partitioned with GPT but booting by MBR. Yes, that's probably weird. When I installed Debian I was unaware that the installer would only install grub to boot using the method that the
installer booted. My BIOS/firmware will boot using either method, but defaults to MBR if both methods work. You can force it to use UEFI on a one-time basis. I want the SSD to boot using UEFI. Is that possible, and
if so, what's the best method to go about it?

My ideas are:
1. dd / onto the SSD, then modify it to boot UEFI. This sounds hard.
2. Install Debian (the same version I run) onto the SSD, then modify
/etc and whatever else so stuff works. This sounds error-prone.
3. Wait until I upgrade to Trixie, then let the installer hash it out.

The most convenient method depends on what exactly you have right now.
Can you share the output of lsblk and df?

Regards,

--
Nicolas George

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

On 7/31/25 12:41, Eben King wrote:

No idea what sdd is

Might it be an SD card/CF card slot with no media inserted? One of mine
does that.

--

Titus Newswanger
Curtiss WI

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

On 7/31/25 19:18, Eben King wrote:

I recently got some SSDs, and decided to use one of them (a 256G model)
to boot from.  I want the change to be undetectable, in that from a user perspective, nothing seems different, just faster.

I currently have a 2T HD, partitioned with GPT but booting by MBR.  Yes, that's probably weird.  When I installed Debian I was unaware that the installer would only install grub to boot using the method that the
installer booted.  My BIOS/firmware will boot using either method, but defaults to MBR if both methods work.  You can force it to use UEFI on a one-time basis.  I want the SSD to boot using UEFI.  Is that possible,
and if so, what's the best method to go about it?

My ideas are:
1. dd / onto the SSD, then modify it to boot UEFI.  This sounds hard.
2. Install Debian (the same version I run) onto the SSD, then modify
   /etc and whatever else so stuff works.  This sounds error-prone.
3. Wait until I upgrade to Trixie, then let the installer hash it out.

I would go for the first option (dd), then modify grub to boot
from that, then fix the new /etc/fstab to use the correct UUID for /,
and that's it. Why do you want to switch to UEFI?

Detlef

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

Detlef Vollmann (HE12025-07-31):

I would go for the first option (dd)

That will not work. At least not with a lot lot more details. That would
work to copy the whole system to a larger drive. For this setup it is a terrible idea.

Regards,

--
Nicolas George

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

Hi Eben,

[2TB HDD booting MBR to 256G SSD booting UEFI]

On Thu, Jul 31, 2025 at 01:41:19PM -0400, Eben King wrote:

eben@cerberus:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 238.5G 0 disk
└─sda1 8:1 0 238.5G 0 part
sdb 8:16 0 1.8T 0 disk
├─sdb1 8:17 0 953M 0 part /boot
├─sdb2 8:18 0 2G 0 part /
├─sdb3 8:19 0 20G 0 part /usr

To be honest I think I would probably just move some stuff to the SSD
and carry on booting MBR mode.

0. Have backups.

1. From single user mode or a live environment (even the "rescue" mode
from the Debain install medium) rsync the contents of /, /boot and
/usr to the single sda1 partition.

2. grub-install /dev/sda

3. Adjust /etc/fstab to mount / from sda1 and comment out /boot and
/usr.

4. Reboot the computer, making sure that the SSD appears first in the
boot order.

If it doesn't work for some reason, revert step 3 and then boot with
the HDD as first in the boot order to be back where you started.

This moves the majority of your OS to the SSD. It still boots in MBR
mode.

I don't see any advantage to changing a working system from MBR to UEFI
booting unless there is specific need. I'd do that at next reinstall.

├─sdb7 8:23 0 30G 0 part /misc/export
├─sdb8 8:24 0 130G 0 part /misc/media
├─sdb9 8:25 0 165G 0 part /misc/mp3
├─sdb10 8:26 0 74G 0 part /misc/torrent
├─sdb11 8:27 0 9G 0 part /home
├─sdb12 8:28 0 75G 0 part /misc/scratch
└─sdb13 8:29 0 48G 0 part [SWAP]
sdc 8:32 0 238.5G 0 disk
├─sdc1 8:33 0 5.1G 0 part /var/cache
└─sdc2 8:34 0 182.7G 0 part /misc/iso

You may also consider getting this part of /var and also swap onto SSD.

As a side note I would find this amount of partitions to juggle to be
really unwieldy. What do you do when one of them fills up and you can't
easily resize it because of the other partitions before and after it on
the disk?

If separate mount points are truly necessary then I recommend using some
form of volume management so that resizing later is easy.

No idea what sdd is:

"lsblk -o +model,vendor" may give more idea, as may "smartctl -i
/dev/sdd".

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

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

Nicolas George (HE12025-07-31):

That would work to copy the whole system to a larger drive.

Rectification: not even that, as the secondary GPT would not be at the
right place. It works only for an identical drive.

Regards,

--
Nicolas George

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

On 7/31/25 21:27, Nicolas George wrote:

Detlef Vollmann (HE12025-07-31):

I would go for the first option (dd)

That will not work. At least not with a lot lot more details. That would
work to copy the whole system to a larger drive. For this setup it is a terrible idea.

What are you talking about?
It's just copying the root partition from the HD to the SSD.
It will also copy the UUID of the partition, so this needs to be fixed.
The size of the filesystem will be smaller than the partition,
which can be changed afterwards.
And as Eben wrote, it's probably a good idea to copy the /boot partition
as well (which requires to create the target partition first)
and then run grub-install, as Andy suggested.

What would go wrong?

Detlef

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

On 7/31/25 14:53, Andy Smith wrote:

I do not have Andy's mail, so I am relying to this one.

1. From single user mode or a live environment (even the "rescue" mode
from the Debain install medium) rsync the contents of /, /boot and
/usr to the single sda1 partition.

What? Absolutely not, that does not match at all what Eben wants.

Regards,

--
Nicolas George

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

Detlef Vollmann composed on 2025-07-31 20:49 (UTC+0200):

Why do you want to switch to UEFI?

One reason is a form of future-proofing. Increasingly, computers are being made without legacy boot support. If a PC goes poof without taking the storage along down, one used to expect to be able to move the storage to a new PC and keep on going without missing many beats. That won't work with MBR disks moved to a UEFI-only PC. Besides that, UEFI is more robust/evolved, plays nicer with multibooting, and is typically more easily repaired when bootloader trouble manifests.
--
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)

On 7/31/25 10:18, Eben King wrote:

I recently got some SSDs, and decided to use one of them (a 256G model)
to boot from.  I want the change to be undetectable, in that from a user perspective, nothing seems different, just faster.

I currently have a 2T HD, partitioned with GPT but booting by MBR.  Yes, that's probably weird.  When I installed Debian I was unaware that the installer would only install grub to boot using the method that the
installer booted.  My BIOS/firmware will boot using either method, but defaults to MBR if both methods work.  You can force it to use UEFI on a one-time basis.  I want the SSD to boot using UEFI.  Is that possible,
and if so, what's the best method to go about it?

My ideas are:
1. dd / onto the SSD, then modify it to boot UEFI.  This sounds hard.
2. Install Debian (the same version I run) onto the SSD, then modify
   /etc and whatever else so stuff works.  This sounds error-prone.
3. Wait until I upgrade to Trixie, then let the installer hash it out.

On 7/31/25 10:41, Eben King wrote:

eben@cerberus:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 238.5G 0 disk
└─sda1 8:1 0 238.5G 0 part
sdb 8:16 0 1.8T 0 disk
├─sdb1 8:17 0 953M 0 part /boot
├─sdb2 8:18 0 2G 0 part /
├─sdb3 8:19 0 20G 0 part /usr
├─sdb5 8:21 0 953M 0 part
├─sdb6 8:22 0 300G 0 part
├─sdb7 8:23 0 30G 0 part /misc/export
├─sdb8 8:24 0 130G 0 part /misc/media
├─sdb9 8:25 0 165G 0 part /misc/mp3
├─sdb10 8:26 0 74G 0 part /misc/torrent
├─sdb11 8:27 0 9G 0 part /home
├─sdb12 8:28 0 75G 0 part /misc/scratch
└─sdb13 8:29 0 48G 0 part [SWAP]
sdc 8:32 0 238.5G 0 disk
├─sdc1 8:33 0 5.1G 0 part /var/cache
└─sdc2 8:34 0 182.7G 0 part /misc/iso
sdd 8:48 1 0B 0 disk
sr0 11:0 1 7.5G 0 rom
0
eben@cerberus:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 16132328 0 16132328 0% /dev
tmpfs 3229464 1796 3227668 1% /run
/dev/sdb2 2047208 802856 1123116 42% /
/dev/sdb3 20557912 8146532 11439652 42% /usr
tmpfs 16147316 71380 16075936 1% /dev/shm
tmpfs 5120 16 5104 1% /run/lock
/dev/sdc1 5157164 1373336 3501616 29% /var/cache
/dev/sdc2 187459092 79418636 98445320 45% /misc/iso
/dev/sdb7 30786644 19419460 9777988 67% /misc/export /dev/sdb1 941740 132468 744096 16% /boot
/dev/sdb8 133589828 122712680 4045076 97% /misc/media /dev/sdb12 76832012 43023296 29860172 60% /misc/scratch /dev/sdb9 169191044 156127788 4396124 98% /misc/mp3
/dev/sdb10 75799884 46825720 25078052 66% /misc/torrent /dev/sdb11 9278492 7747788 1042472 89% /home
tmpfs 3229460 2484 3226976 1% /run/user/1000 nascent:/nfs/Media 1918708224 774040384 1125174848 41%

/mnt/nascent-Media

0
eben@cerberus:~$

sda is the new SSD. sdb is my HD. sdc is another SSD. nascent is a
NAS. No idea what sdd is:

eben@cerberus:~$ sudo fdisk -l /dev/sdd
fdisk: cannot open /dev/sdd: No medium found

I have a SOHO network with a file server, a backup server, and various
Linux, BSD, Windows, macOS, IOT, etc., clients. I keep the client
images small and self-contained (e.g. one SSD), and put as much data as possible on the file server.


I would:

1. Backup the computer and the NAS.

2. Move as much data as possible from /dev/sdb HDD to the NAS. Leave
home directory login, profile, desktop environment, app configuration/
profile, etc. files local to the HDD. Empty trash, clean caches, remove scratch files, etc..

3. Run zerofree(8) on all of the HDD file systems.

4. Take a compressed image of the HDD.

5. Disconnect HDD and /dev/sdc SSD.

6. Boot computer into Setup and restore settings to factory defaults.

7. Boot manufacturer diagnostic or live Debian instance, and secure
erase /dev/sda SSD.

8. Install Debian on /dev/sda SSD.

9. Reconnect HDD and /dev/sdc SSD. Restore system configuration and
required data.

10. Take an image of /dev/sda SSD.

11. Backup the computer and the NAS.


The HDD and /dev/sdc SSD can be repurposed afterwards. I would secure
erase /dev/sdc SSD and use it for virtual machines, audio/video editor
scratch files, etc.. If you want to partition the space, use a volume management solution -- LVM, BTRFS, ZFS, etc.. I would put the HDD into
an external USB enclosure and use it for images and/or backups, or put
the HDD into the NAS.


David

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

On Thu, 31 Jul 2025 13:18:07 -0400
Eben King <eben@gmx.us> wrote:

I recently got some SSDs, and decided to use one of them (a 256G
model) to boot from. I want the change to be undetectable, in that
from a user perspective, nothing seems different, just faster.

I currently have a 2T HD, partitioned with GPT but booting by MBR.
Yes, that's probably weird. When I installed Debian I was unaware
that the installer would only install grub to boot using the method
that the installer booted. My BIOS/firmware will boot using either
method, but defaults to MBR if both methods work. You can force it
to use UEFI on a one-time basis. I want the SSD to boot using UEFI.
Is that possible, and if so, what's the best method to go about it?

My ideas are:
1. dd / onto the SSD, then modify it to boot UEFI. This sounds hard.
2. Install Debian (the same version I run) onto the SSD, then modify
/etc and whatever else so stuff works. This sounds error-prone.
3. Wait until I upgrade to Trixie, then let the installer hash it out.

I suggest you install trixie, as the Debian installer seems to be more
robust than that for bookworm.

I would try switching to UEFI when you go to boot the installer. That
should give you a system that will boot to UEFI.

I would do a new installion on the SSD. Get that running as you want it.
This may include copying over configuration files from the old /etc, or
diffing them, or similar. Copy over some or all of the old /home.

If you let the installer partition the drive for you, you will get /,
/boot. /boot/efi partitions.

I would then add the rest manually after the installation.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

Hi,

On Thu, Jul 31, 2025 at 02:31:44PM -0700, David Christensen wrote:

I would:

1. Backup the computer and the NAS.

2. Move as much data as possible from /dev/sdb HDD to the NAS. Leave home directory login, profile, desktop environment, app configuration/ profile, etc. files local to the HDD. Empty trash, clean caches, remove scratch files, etc..

3. Run zerofree(8) on all of the HDD file systems.

4. Take a compressed image of the HDD.

5. Disconnect HDD and /dev/sdc SSD.

6. Boot computer into Setup and restore settings to factory defaults.

7. Boot manufacturer diagnostic or live Debian instance, and secure erase /dev/sda SSD.

8. Install Debian on /dev/sda SSD.

9. Reconnect HDD and /dev/sdc SSD. Restore system configuration and required data.

10. Take an image of /dev/sda SSD.

11. Backup the computer and the NAS.

When OP asks how to add a new SSD to their system and move their boot
drive to it, it seems really excessive that you advise moving off
hundreds of gigabytes of data, physically removing two other unrelated
drives and then doing a complete reinstall.

I guess we could all go to OP's home, rip everything out and rebuild it
in our own desired way.

Surely if they are wanting to reinstall Debian they wouldn't need to ask
any of this and could just do it, UEFI boot and all, without needing to
be told to back up and restore?

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

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

On 7/31/25 15:15, Eben King wrote:

On 7/31/25 17:31, David Christensen wrote:

On 7/31/25 10:18, Eben King wrote:

I recently got some SSDs, and decided to use one of them (a 256G
model) to boot from.  I want the change to be undetectable, in that
from a user perspective, nothing seems different, just faster.

I would:
<snip>
9.  ...  Restore system configuration and required data.

That is the bit I'm not sure how to do so the change is mostly
undetectable.

I once heard a speaker who worked as a Linux system administrator on
Wall Street state:

"You should be able to pick any computer at random, throw it out a 7th
story window, and have a replacement in operation within 2 hours".


The key is disaster preparedness and disaster recovery. Expect that
your computer(s) will break, and prepare for it with backups. Verify
your backups by doing recoveries and comparing the source against the
recovery. [1] is dated, but will get you thinking in the right
direction. A related technique is disk imaging. Another is archiving.
Learn them all.


Learn how to write shell scripts (or Perl, Python, etc.), so that you
can automate repetitive tasks and get consistent results.


Do not be afraid to spend money on a spare computer, spare parts, and
bigger HDD's.


Keep records of anything and everything that matters. Use a version
control system.


David


[1] https://www.oreilly.com/library/view/backup-recovery/0596102461/

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

On 7/31/25 15:39, Andy Smith wrote:

Hi,

Hello. :-)

On Thu, Jul 31, 2025 at 02:31:44PM -0700, David Christensen wrote:

<snip>

When OP asks how to add a new SSD to their system and move their boot
drive to it, it seems really excessive that you advise moving off
hundreds of gigabytes of data, physically removing two other unrelated
drives and then doing a complete reinstall.

I guess we could all go to OP's home, rip everything out and rebuild it
in our own desired way.

Surely if they are wanting to reinstall Debian they wouldn't need to ask
any of this and could just do it, UEFI boot and all, without needing to
be told to back up and restore?

Thanks,
Andy

If I am doing my math correctly, the OP's 2 TB HDD has ~404 GB of
content. I know of no easy way to make that fit onto a 256 GB SSD:

2025-07-31 23:31:20 dpchrist@laalaa ~
$ perl -e 'print 802856+8146532+19419460+132468+122712680+43023296+156127788+46825720+7747788, $/'
404938588


Taking a step back, putting the OS and the data on the same disk is a
mistake. Once the OS is on its own disk and the data is on other disks, performance, system administration, maintenance, disaster preparedness/ recovery, etc., are all improved. The OP is at an opportune moment to
do so with their computer, so I recommended it.


I had some Unix/ BSD/ Linux internals knowledge in the past, but today I
simply *use* Debian. My strategy for success is to *keep it simple*.
Perhaps a Debian expert could accomplish the feats of partitioning,
bootloader, initramfs, grub, etc., surgery, transformation, and
migration the OP seeks, but I am not that expert. So, I offered an
alternative that is within the confines of my knowledge.


David

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

David Christensen (HE12025-08-01):

I once heard a speaker who worked as a Linux system administrator on Wall Street state:

Maybe do not give advice tailored for somebody who is in charge of
dozens computers, with plenty of spare disks at hand, to somebody who apparently is just an individual who wants to upgrade their computer
cleanly but without too much work?

Regards,

--
Nicolas George

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

On 8/1/25 01:52, Nicolas George wrote:

David Christensen (HE12025-08-01):

I once heard a speaker who worked as a Linux system administrator on Wall
Street state:

"You should be able to pick any computer at random, throw it out a 7th
story window, and have a replacement in operation within 2 hours".

Maybe do not give advice tailored for somebody who is in charge of
dozens computers, with plenty of spare disks at hand, to somebody who apparently is just an individual who wants to upgrade their computer
cleanly but without too much work?

Regards,

I think the principle (expect and prepare for computer disasters)
applies at any scale (including one computer), but the tools and
techniques change. I started with two computers and tar(1), gzip(1),
and rsync(1). As my knowledge, skills, and needs grew, I added more
tools and starting writing scripts. TIMTOWTDI.


David

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

On Thursday 31 July 2025 03:25:23 pm Nicolas George wrote:

On the other hand, /var on the same filesystem as the rest of / is not a
good idea.

Why?

--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

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

On 8/1/25 07:22, Eben King wrote:

On 8/1/25 04:08, David Christensen wrote:

The key is disaster preparedness and disaster recovery.
<snip>

I do back up my entire drive weekly.  NAS too.  However, I recently
looked around for another 2T drive to implement two-level backups and
didn't have one.  Can't afford one right now either.

Yet another reason to free up the 2 TB /dev/sdb HDD.

Learn how to write shell scripts (or Perl, Python, etc.), so that you
can automate repetitive tasks and get consistent results.

I write shell scripts (sh, occasionally bash) for that purpose.

Good. :-)

Do not be afraid to spend money on a spare computer, spare parts, and
bigger HDD's.

It's not that I'm afraid, it's that I'd rather keep the car, keep us
fed, etc. than do that. Not everyone has enough disposable income to do things the recommended way.

I have bought several older model, new or open box, 3.5" SATA HDD's on
eBay. In terms of price-per-byte, the sweet spot is around 13 US$/TB
for 3 TB or 4 TB disks. SAS HDD's are cheaper, but require an SAS HBA
or dock.

Keep records of anything and everything that matters.

I have a log file where I note important stuff.

Good. :-)


David

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

Charles Curley (HE12025-08-01):

Do you want to mount /root r-o? /etc? I think not.

Separating the things that move a lot and the things that are stable is
still a good idea.

For what the OP is up to, mounting the old file systems (on the HD)
until he is satisfied he has everything working right is probably a
good idea.

No, it is an excellent occasion to rework the partitioning, wasting is
not a good idea.

Also, the partitions will probably not fit the new disk exactly, leaving
a useless clump with an awkward at the end.

It is a much better idea to create new partitions, choosing the
repartition and the sizes in the light of past uses of the system, mount
them with their intended structure and copy the contents, letting Linux
worry about the split.

And even better to do it with LVM volumes rather than partitions.

--
Nicolas George

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

On Fri, 1 Aug 2025 13:21:06 -0400
Jeffrey Walton <noloader@gmail.com> wrote:

You typically want to mount / as read-only; while you want to mount
/var as read-write. Or some people want to mount the filesystem
read-only.

Do you want to mount /root r-o? /etc? I think not.

For what the OP is up to, mounting the old file systems (on the HD)
until he is satisfied he has everything working right is probably a
good idea. But that's a different can of politicians.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

On Sat, 2 Aug 2025 00:02:31 +0200
Nicolas George <george@nsup.org> wrote:

Charles Curley (HE12025-08-01):

Do you want to mount /root r-o? /etc? I think not.

Separating the things that move a lot and the things that are stable
is still a good idea.

Right. With /root r-o, you never get your shell history saved. And
things do change from time to time under /etc.

For what the OP is up to, mounting the old file systems (on the HD)
until he is satisfied he has everything working right is probably a
good idea.

No, it is an excellent occasion to rework the partitioning, wasting is
not a good idea.

Agree. I don't think the ideas are mutually exclusive. And wasting
one's time is also not a good idea.

Also, the partitions will probably not fit the new disk exactly,
leaving a useless clump with an awkward at the end.

Right. Which is why he should copy over only what he must and leave the
rest. To give the appearance of having copied everything over, he can
use symlinks.

It is a much better idea to create new partitions, choosing the
repartition and the sizes in the light of past uses of the system,
mount them with their intended structure and copy the contents,
letting Linux worry about the split.

Agree, except I'm not sure what you mean by "letting Linux worry about
the split".

And even better to do it with LVM volumes rather than partitions.

Again, agree. OP didn't indicate that any of his partitions were LVs,
so I didn't suggest it.

Anyway, I just wanted to understand your thinking on the r-o business.
Thanks.


--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

Charles Curley (HE12025-08-01):

Separating the things that move a lot and the things that are stable
is still a good idea.

^^^^^

Right. With /root r-o, you never get your shell history saved. And
things do change from time to time under /etc.

Elementary language clarification: “still” over there means “even if you do not do it”, with “it” being “mounting / read-only”.

But still, every write to a filesystem is a tiny risk of damage: maybe
thermal noise did flip a bit on the bus at the wrong time, maybe there
was a bug in the specific version of the kernel we were running right
now.

And every write to a filesystem costs in the incremental backups.

Two of the reasons to want to keep subtrees that move a lot and
subtrees that do not separate.

Also, if you save your history, especially as root, odds are there have
been some confidential information in there at some point in time.

No, it is an excellent occasion to rework the partitioning, wasting is
not a good idea.

Agree. I don't think the ideas are mutually exclusive.

Sorry, I had not read what you wrote carefully enough. Forget that part:
yes, doing the migration in steps, keeping working with the existing
system during the transition is a good idea.

To give the appearance of having copied everything over, he can
use symlinks.

No need for symlinks when it can be just mounted in place.

Agree, except I'm not sure what you mean by "letting Linux worry about
the split".

Let us assume he booted a live system to make things simple. He mounted
the hard drive in /mnt/src, getting a tree like that:

│
├── mnt
sdb2 └── src
sdb3 ├── usr
└── var

Then he will create a new set of volumes and mount them in /mnt/dst:

│
└── mnt
sdb2 ├── src
sdb3 │ ├── usr
│ └── var
mapper/ssd-root └── dst
mapper/ssd-var └── var

Now he copies the contents:

cp -a /mnt/src/. /mnt/dst/

(or rsync). cp is a simple userland program, it does not care about
mount points, they are just directories. So, it sees src/usr but no
dst/usr: it creates dst/usr, not caring that src/usr was a mount point.
And it sees src/var, it sees dst/var is already there, so it does not
create it, it just copies the permissions.

On the other hand, Linux, the kernel, does not care we are copying a
whole tree, it just sees files being opened and directories being
created, and its normal virtual filesystem operations will direct these
open() and mkdir() to the right underlying device.

Again, agree. OP didn't indicate that any of his partitions were LVs,
so I didn't suggest it.

Somebody who sees a sda13 and a good occasion and does not suggest to
use it to switch to LVM is not giving good advice.

Regards,

--
Nicolas George

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

Eben King (HE12025-08-02):

None are currently. If volume management becomes a big deal, I will implement it immediately after a backup. Currently I do not have enough resizing of partitions to make it worthwhile.

Resizing volumes is not the only benefit of LVM.

The fact that the volumes are named rather than numbered, and that the
naming is stable is quite useful. Granted, you can get that with
partlabels.

If your system had been using LVM already, you could have copied your
data without rebooting it. (You still would have needed to reboot to
enable UEFI.)

Regards,

--
Nicolas George

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

Eben King (HE12025-08-02):

I have made these partitions:

Device Start End Sectors Size Type
/dev/sda1 2048 1953792 1951745 953M Linux filesystem
/dev/sda2 1955840 6150144 4194305 2G Linux filesystem
/dev/sda3 6152192 48095232 41943041 20G Linux filesystem
/dev/sda4 48097280 48195583 98304 48M Linux swap
/dev/sda5 48195584 67069952 18874369 9G Linux filesystem
/dev/sda6 67072000 69023744 1951745 953M BIOS boot

Did you not say you wanted to switch to UEFI? You did not.

And of course, you are wasting the excellent occasion to switch to LVM.

Grub installs without error on that drive, but drops me into grub's command line when I boot from it. Then when I do

boot (hd0,gptN)

Well, yes, that is not how the boot command works. You need something
like:

set root=(hd1,gpt1)
configfile /grub/grub.cfg

(could be other than hd1, UEFI might not see the disks in the same order
as Linux; check with ls) to have it use the config file of the existing bootloader and start your system as it used to.

And once you are finished migrating, you need to run update-grub to
rebuild a configuration taking into account the location of the new root
and boot filesystems, and possibly re-run grub-install to make sure it
uses it.

Regards,

--
Nicolas George

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

Eben King composed on 2025-08-02 16:25 (UTC-0400):

I have made these partitions:

Device Start End Sectors Size Type
/dev/sda1 2048 1953792 1951745 953M Linux filesystem
/dev/sda2 1955840 6150144 4194305 2G Linux filesystem
/dev/sda3 6152192 48095232 41943041 20G Linux filesystem
/dev/sda4 48097280 48195583 98304 48M Linux swap
/dev/sda5 48195584 67069952 18874369 9G Linux filesystem
/dev/sda6 67072000 69023744 1951745 953M BIOS boot

/dev/sda6 is approximately 953X as large as it has any need to be. A BIOS boot on
a GPT disk takes the place of an MBR disk's MBR track, so only needs roughly 60 or
fewer sectors.

# parted -l
Model: ATA KINGSTON RBU-SNS (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 263MB 262MB k256p01 DOS C: reservation msftdata 250 MiB
2 263MB 599MB 336MB k256p02 reserved for ESP msftdata 320 MiB
3 599MB 1018MB 419MB ext2 k256p03 res legacy_boot 400 MiB
4 1018MB 1019MB 1049kB k256p04 BIOS Boot (noEFI) bios_grub 1 MiB
5 1019MB 1020MB 1049kB k256p05 DOS dummy msftdata 1 MiB
6 1020MB 1285MB 264MB k256p06 DOS E: reservation msftdata 252 MiB
7 1285MB 4402MB 3117MB linux-swap(v1) k256p07 swapper swap 2973 MiB
8 4402MB 11.1GB 6711MB ext4 k256p08 suse 131 6400 MiB
9 11.1GB 15.7GB 4614MB ext4 k256p09 /home 4400 MiB
10 15.7GB 22.4GB 6711MB ext4 k256p10 suse 423 6400 MiB
...
13 47.6GB 54.3GB 6711MB ext4 k256p13 trixie 6400 MiB
...
24 121GB 128GB 6711MB ext4 k256p24 bookworm 6400 MiB
25 128GB 135GB 6711MB ext4 k256p25 bullseye 6400 MiB
...
42 250GB 256GB 5872MB ext4 k256 mageia 4 6400 MiB

Grub installs without error on that drive, but drops me into grub's
command line when I boot from it. Then when I do

Installs how exactly? Where?

boot (hd0,gptN)

for N in 1 or 2 (/boot or /root) it tells me that I have to pick a
kernel first.

That happens when Grub hasn't been correctly installed and/or configured.

I have these files:
eben@cerberus:~$ sudo mount -o ro /dev/sda2 /mnt/temp
eben@cerberus:~$ sudo mount -o ro /dev/sda1 /mnt/temp/boot
eben@cerberus:~$ ls -l /mnt/temp/vm*
0 lrwxrwxrwx 1 root root 27 May 25 13:01 /mnt/temp/vmlinuz -> boot/vmlinuz-6.1.0-37-amd64
0 lrwxrwxrwx 1 root root 27 May 25 13:01 /mnt/temp/vmlinuz.old -> boot/vmlinuz-6.1.0-35-amd64
eben@cerberus:~$ ls -l /mnt/temp/boot/v*
7.9M -rw-r--r-- 1 root root 7.9M Apr 10 15:32 /mnt/temp/boot/vmlinuz-6.1.0-33-amd64
7.9M -rw-r--r-- 1 root root 7.9M Apr 25 15:51 /mnt/temp/boot/vmlinuz-6.1.0-34-amd64
7.9M -rw-r--r-- 1 root root 7.9M May 7 11:10 /mnt/temp/boot/vmlinuz-6.1.0-35-amd64
7.9M -rw-r--r-- 1 root root 7.9M May 22 14:32 /mnt/temp/boot/vmlinuz-6.1.0-37-amd64

# ls -rtgG initrd.* | egrep -v 'cur|prv' && ls -rtgG vmlinuz-* | egrep -v 'cur|prv'
-rw-r--r-- 1 10720523 May 27 2024 initrd.img-6.1.0-21-amd64
-rw-r--r-- 1 10200492 Jul 3 2024 initrd.img-6.1.0-22-amd64
-rw-r--r-- 2 10729999 Nov 19 2024 initrd.img-6.1.0-27-amd64
-rw-r--r-- 1 9325720 Mar 23 15:45 initrd.img-6.1.0-32-amd64
-rw-r--r-- 1 9325720 Mar 23 15:47 initrd.img-6.1.0-25-amd64
-rw-r--r-- 1 9324144 Apr 28 15:20 initrd.img-6.1.0-34-amd64
-rw-r--r-- 1 9326878 Aug 2 17:31 initrd.img-6.1.0-37-amd64
-rw-r--r-- 1 8169408 May 3 2024 vmlinuz-6.1.0-21-amd64
-rw-r--r-- 1 8173504 Jun 20 2024 vmlinuz-6.1.0-22-amd64
-rw-r--r-- 1 8177600 Aug 26 2024 vmlinuz-6.1.0-25-amd64
-rw-r--r-- 1 8189888 Nov 1 2024 vmlinuz-6.1.0-27-amd64
-rw-r--r-- 1 8193984 Mar 6 01:21 vmlinuz-6.1.0-32-amd64
-rw-r--r-- 1 8193984 Apr 25 15:51 vmlinuz-6.1.0-34-amd64
-rw-r--r-- 1 8193984 May 22 14:32 vmlinuz-6.1.0-37-amd64
#

What does it want from me?

Perhaps show us /mnt/tmp/boot/grub/grub.cfg using pastebinit?

The HD (currently sdc) boots fine. The BIOS (or whatever) doesn't offer
it as a boot device, but I can do F12 at POST = "select boot device",
pick it, and it works.

When was the machine new? What is its BIOS date? Is a BIOS update available?
--
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)

None are currently. If volume management becomes a big deal, I will implement it immediately after a backup. Currently I do not have enough resizing of partitions to make it worthwhile.

I have only (mostly single-user) desktops, laptops, and small
home-server machines, so I don't resize partitions often either, but
I find LVM to be just easier than setting up partitions. I don't claim
it *is* simpler, but it's definitely simple enough that I don't need any "justification" to use LVM.


Stefan

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