Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #248025 > unrolled thread

Copying one drive to a smaller one.

Back to article view | Back to linux.debian.user

Contents

  Copying one drive to a smaller one. <paulf@quillandmouse.com> - 2022-05-09 04:00 +0200
    Re: Copying one drive to a smaller one. Felix Miata <mrmazda@earthlink.net> - 2022-05-09 04:40 +0200
    Re: Copying one drive to a smaller one. David Christensen <dpchrist@holgerdanske.com> - 2022-05-09 21:00 +0200
      Re: Copying one drive to a smaller one. "Andrew M.A. Cater" <amacater@einval.com> - 2022-05-09 21:20 +0200
        Re: Copying one drive to a smaller one. Tixy <tixy@yxit.co.uk> - 2022-05-09 22:10 +0200
        Re: Copying one drive to a smaller one. The Wanderer <wanderer@fastmail.fm> - 2022-05-09 23:00 +0200
      Re: Copying one drive to a smaller one. <paulf@quillandmouse.com> - 2022-05-09 23:10 +0200
        Re: Copying one drive to a smaller one. Michael Stone <mstone@debian.org> - 2022-05-10 00:10 +0200
          Re: Copying one drive to a smaller one. Stefan Monnier <monnier@iro.umontreal.ca> - 2022-05-10 04:40 +0200
      Re: Copying one drive to a smaller one. "stepore@gmail.com" <stepore@gmail.com> - 2022-05-10 07:10 +0200
      Re: Copying one drive to a smaller one. <paulf@quillandmouse.com> - 2022-05-10 14:40 +0200
        Re: Copying one drive to a smaller one. Michael Stone <mstone@debian.org> - 2022-05-10 18:30 +0200
        Re: Copying one drive to a smaller one. Michael Stone <mstone@debian.org> - 2022-05-10 21:20 +0200
        Re: Copying one drive to a smaller one. <paulf@quillandmouse.com> - 2022-05-10 21:30 +0200

#248025 — Copying one drive to a smaller one.

Folks:

Situation: I have a 500G boot drive (root, swap, home) I'd like to copy
to a new 250G drive which must then also be bootable (yes, there's
enough room). This are EFI drives. I can use "dd", but I don't know
the proper parameters, and as I understand it, copying a 500G to a 250G
drive is Bad(tm). I could use "rsync", but I don't think the second
250G drive will boot just because I copied the files over to it. I
suspect I would have an additional step needed to make the drive
bootable.

Can someone outline the proper procedure here?

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

[toc] | [next] | [standalone]

#248030

paulf@quillandmouse.com composed on 2022-05-08 21:54 (UTC-0400):

> Situation: I have a 500G boot drive (root, swap, home) I'd like to copy
> to a new 250G drive which must then also be bootable (yes, there's
> enough room). This are EFI drives. I can use "dd", but I don't know
> the proper parameters, and as I understand it, copying a 500G to a 250G
> drive is Bad(tm). I could use "rsync", but I don't think the second
> 250G drive will boot just because I copied the files over to it. I
> suspect I would have an additional step needed to make the drive
> bootable.

> Can someone outline the proper procedure here?

rsync gets the files, once required partitioning and formatting is done, but
doesn't configure bootloader. You can run efibootmgr to set the new ESP up, or
select the new ESP as priority within EFI BIOS setup (if it works as it should).

dd can be safely used only if target space is equal to or larger than source. If
the old drive is partitioned, you might be able to dd individual partitions that
fit, but your situation is a clear case to prefer rsync.
-- 
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

[toc] | [prev] | [next] | [standalone]

#248047

On 5/8/22 18:54, paulf@quillandmouse.com wrote:
> Folks:
> 
> Situation: I have a 500G boot drive (root, swap, home) I'd like to copy
> to a new 250G drive which must then also be bootable (yes, there's
> enough room). This are EFI drives. I can use "dd", but I don't know
> the proper parameters, and as I understand it, copying a 500G to a 250G
> drive is Bad(tm). I could use "rsync", but I don't think the second
> 250G drive will boot just because I copied the files over to it. I
> suspect I would have an additional step needed to make the drive
> bootable.
> 
> Can someone outline the proper procedure here?


Resizing and moving a Debian instance from a 500 GB drive to a 250 GB 
drive requires a lot of expertise.


I would take the KISS approach -- backup the system configuration files 
and data, remove the 500 GB drive, install the 250 GB drive, do a fresh 
install onto the 250 GB drive, and reconfigure/ restore.


David

[toc] | [prev] | [next] | [standalone]

#248049

On Mon, May 09, 2022 at 11:54:16AM -0700, David Christensen wrote:
> On 5/8/22 18:54, paulf@quillandmouse.com wrote:
> > Folks:
> > 
> > Situation: I have a 500G boot drive (root, swap, home) I'd like to copy
> > to a new 250G drive which must then also be bootable (yes, there's
> > enough room). This are EFI drives. I can use "dd", but I don't know
> > the proper parameters, and as I understand it, copying a 500G to a 250G
> > drive is Bad(tm). I could use "rsync", but I don't think the second
> > 250G drive will boot just because I copied the files over to it. I
> > suspect I would have an additional step needed to make the drive
> > bootable.
> > 
> > Can someone outline the proper procedure here?
> 
> 
> Resizing and moving a Debian instance from a 500 GB drive to a 250 GB drive
> requires a lot of expertise.
> 
> 
> I would take the KISS approach -- backup the system configuration files and
> data, remove the 500 GB drive, install the 250 GB drive, do a fresh install
> onto the 250 GB drive, and reconfigure/ restore.
> 
> 
> David
>

I also agree: then all you have to do is copy across data you wish to retain.

Alternatively, you can plug in the new drive and do a minimal install on it.
Use 

dpkg --get-selections > somefilename 

to get a list of packages installed on one system and write it into somefile.

dpkg --set-selections < somefilename

will write that list for Debian's most basic package manager.

apt update ; apt dist-upgrade

 will then use that information to isntall the same package list onto the
second machine as exists on the first machine - but that's complex.

With every good wish, as ever,

Andy Cater 

[toc] | [prev] | [next] | [standalone]

#248051

On Mon, 2022-05-09 at 19:18 +0000, Andrew M.A. Cater wrote:
[...]
> Alternatively, you can plug in the new drive and do a minimal install on it.
> Use 
> 
> dpkg --get-selections > somefilename 
> 
> to get a list of packages installed on one system and write it into somefile.
> 
> dpkg --set-selections < somefilename
> 
> will write that list for Debian's most basic package manager.
> 
> apt update ; apt dist-upgrade
> 
>  will then use that information to isntall the same package list onto the
> second machine as exists on the first machine - but that's complex.

Won't that process set all those packages as manually installed, so
should you later uninstall a top level package it's dependedncied won't
be automatically removed?

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#248052

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

On 2022-05-09 at 15:18, Andrew M.A. Cater wrote:

> On Mon, May 09, 2022 at 11:54:16AM -0700, David Christensen wrote:

>> I would take the KISS approach -- backup the system configuration
>> files and data, remove the 500 GB drive, install the 250 GB drive,
>> do a fresh install onto the 250 GB drive, and reconfigure/
>> restore.
> 
> I also agree: then all you have to do is copy across data you wish to
> retain.
> 
> Alternatively, you can plug in the new drive and do a minimal install
> on it. Use
> 
> dpkg --get-selections > somefilename
> 
> to get a list of packages installed on one system and write it into
> somefile.
> 
> dpkg --set-selections < somefilename
> 
> will write that list for Debian's most basic package manager.

I've found that this doesn't always produce the desired result in some
cases. The most obvious one is when the names of the available packages
have changed between the two steps (e.g. a new kernel package), but
there are other times that issues can arise.

What I've found to be the method that produces the best results is use
the output of apt-mark instead:

oldmachine:~$ apt-mark showmanual > somefilename

newmachine:~# apt-get update

newmachine:~# apt-get install $(cat somefilename)

(I've tried various methods to get the install to work without the
subshell and the cat, but none of them seemed to put the package names
on the actual command line where apt-get could see them.)

That both installs the packages, and marks *only* the specified list of
packages as manually installed.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#248054

On Mon, 9 May 2022 11:54:16 -0700
David Christensen <dpchrist@holgerdanske.com> wrote:

> On 5/8/22 18:54, paulf@quillandmouse.com wrote:
> > Folks:
> > 
> > Situation: I have a 500G boot drive (root, swap, home) I'd like to
> > copy to a new 250G drive which must then also be bootable (yes,
> > there's enough room). This are EFI drives. I can use "dd", but I
> > don't know the proper parameters, and as I understand it, copying a
> > 500G to a 250G drive is Bad(tm). I could use "rsync", but I don't
> > think the second 250G drive will boot just because I copied the
> > files over to it. I suspect I would have an additional step needed
> > to make the drive bootable.
> > 
> > Can someone outline the proper procedure here?
> 
> 
> Resizing and moving a Debian instance from a 500 GB drive to a 250 GB 
> drive requires a lot of expertise.
> 
> 
> I would take the KISS approach -- backup the system configuration
> files and data, remove the 500 GB drive, install the 250 GB drive, do
> a fresh install onto the 250 GB drive, and reconfigure/ restore.
> 

Unfortunately, this is precisely what I was trying to avoid. For
example, to accommodate the graphics on my CPU, I had to use a later
kernel from backports. That's one of many wrinkles. Under other
circumstances, I probably would do as you advise, but I'm limited on
time and was trying to find a shortcut.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

[toc] | [prev] | [next] | [standalone]

#248056

On Mon, May 09, 2022 at 04:47:44PM -0400, paulf@quillandmouse.com wrote:
>Unfortunately, this is precisely what I was trying to avoid. For
>example, to accommodate the graphics on my CPU, I had to use a later
>kernel from backports. That's one of many wrinkles. Under other
>circumstances, I probably would do as you advise, but I'm limited on
>time and was trying to find a shortcut.

With a modern EFI system with UUIDs in the fstab it's actually not that 
hard. Boot off an rescue disk or somesuch. Create partitions on the new 
disk that mirror those of the old disk (except of course that the 
largest one should be smaller; do not make any of the others smaller). 
If you're lucky you've just got an EFI partition and a root partition. 
Assuming you're using ext4, use resize2fs to shrink the large volume to 
something smaller than the destination partition. (For example, if the 
new partition is 128G, shrink it to 120G.) Assuming your original drive 
is sda and the new one is sdb, copy each partition with something like 
cp /dev/sda1 /dev/sdb1. That's basically it for copying the data. Now 
this part's important: you don't want to boot from either of these disks 
while the other is in the system, because the UUIDs on the filesystems 
are the same. Pull the old one out before booting up. You may need to 
reconfigure the BIOS to boot of the new disk, depending on how it was 
configured--if you do, there should be some kind of "add new boot 
device" option that will let you browse the EFI partition and select 
"EFI/debian/grubx64.efi". I may be missing something as I type this off 
the top of my head, but whatever comes up should be fixable as long as 
you don't copy the new disk onto the old one. :)  I think all the 
current versions of fdisk will show you the disk model when using "fdisk 
-l" in addition to the partition information, which should help to 
double check which drive is which. 

With an old-style PC BIOS boot you'd need additional steps to install 
grub to the boot sector of the new disk, reconfigure grub's 
understanding of which linux device corresponds to which bios device, 
and tell the grub package where to install new bootloaders in the 
future.

There are also other ways to do this, for example by creating new 
filesystems, then using cp or rsync to copy the files (but this does 
require specific flags, and can have issues in [somewhat rare] 
circumstances) or using filesystem-specific tools like xfs_copy. In this 
case you'd need to use blkid to determine the UUIDs of the new 
partitions and update fstab on the new disk to match the new UUIDs.

[toc] | [prev] | [next] | [standalone]

#248062

> With a modern EFI system with UUIDs in the fstab it's actually not that
> hard. Boot off an rescue disk or somesuch. Create partitions on the new disk
> that mirror those of the old disk (except of course that the largest one
> should be smaller; do not make any of the others smaller). If you're lucky

A similar option is to use (g)parted on the source disk to shrink the
partitions enough to fit on the destination disk, move them to the
beginning of the disk and then `dd` the whole disk to the destination:
the `dd` will fail when it reaches the end of the destination disk but
if you've shrunk*resized properly it will have copied all the relevant
info.  You'll just need to run `parted` on the destination disk (to fix
the secondary GPT partition table which is a copy normally placed at
the end and which `dd` couldn't copy for you).


        Stefan

[toc] | [prev] | [next] | [standalone]

#248064

On 5/9/22 11:54, David Christensen wrote:
> Resizing and moving a Debian instance from a 500 GB drive to a 250 GB
> drive requires a lot of expertise.

Maybe I'm misremembering. But doesn't clonezilla or using partclone 
<https://partclone.org/> directly accomplish this? i'm sure i've used it 
to do exactly this. But it was years ago.

[toc] | [prev] | [next] | [standalone]

#248070

On Tue, 10 May 2022 07:28:02 +0200
DdB <debianlist@potentially-spam.de-bruyn.de> wrote:

> Hi,
> 
> Am 09.05.2022 um 20:54 schrieb David Christensen:
> > Resizing and moving a Debian instance from a 500 GB drive to a 250
> > GB drive requires a lot of expertise.
> 
> I fully agree. And i am missing some information from the OP:
> 
> Was the 500 GB drive UEFI already?

Yes.

> Will both drives live on the same computer ever?

No.

The original problem is this: The 500G drive has too small a root
partition and also has the home partition on the same drive. I want to
expand the root partition, and separate the home partition off to
another drive. I don't need much for root-- 250G is more than enough
(actually 64G would be plenty, but it's hard to find SSDs that small).

> 
> If the answers would be yes to 1 and no to second, that would allow
> reusing the UUID's, which can be manipulated (on the new disk) with
> sgdisk. But of course, since that involves some kind of "hacking", i
> recommend to create some understanding along the disk format
> necessities for UEFI booting first, like from
> https://www.rodsbooks.com/ pages.
> 
> My goal would be to manipulate the target to come very close to the
> source, except for the partitioning/fs layout, in order to prepare
> for a successful rsync for ALL (except swap, but including ESP)
> partitions. mkswap has a -U switch too. :-)
> 

For all but the boot mechanism, copying files from source to
destination via rsync should work. For ext4, files are files. It's the
boot mechanism that can get tricky. That's what I'm unsure about.

The plan is/was to partition the new 250G drive exactly as I want it,
and then copy the individual pieces (root, /boot, swap) to the drive.
Then figure out/work out the boot process so I can stick it in and boot
from that drive.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

[toc] | [prev] | [next] | [standalone]

#248075

On Tue, May 10, 2022 at 08:31:12AM -0400, paulf@quillandmouse.com wrote:
>For all but the boot mechanism, copying files from source to
>destination via rsync should work. For ext4, files are files.

Except when they have ACLs or extended attributes, hard links are messy 
to rsync, etc. Most of time this isn't an issue, but be aware that it's 
possible.

>It's the
>boot mechanism that can get tricky. That's what I'm unsure about.

The UEFI boot mechanism is actually one of the easiest parts of this: 
unlike the old PC boot sector which was very limited in size and 
required jumps into hard-coded blocks elsewhere on the disk, UEFI is 
just files on a FAT fs with a special partition type that is read by the 
BIOS. Copy the files, tell the BIOS to use those files, and you're good 
to go.

If you want to change the UUID of the root partition, then you need to 
change three configuration files: /etc/fstab, /boot/grub/grub.cfg, and 
/boot/efi/EFI/debian/grub.cfg. If you have a separate /boot then you'd 
need to account for that as well. Once you're in the new system future 
calls to update-grub will base the UUID on the running filesystem; the 
manual updating is a one-time job.

[toc] | [prev] | [next] | [standalone]

#248078

On Tue, May 10, 2022 at 07:13:55PM +0200, DdB wrote:
>Proper entry in NVRAM (Can be read and changed with efibootmgr)

I've never seen a BIOS where this is hard--you just browse to the 
appropriate file in the EFI partition (EFI/debian/grubx64.efi). Using a 
program from within linux is helpful for the installer, which is trying 
to automate the process, but I wouldn't bother for manually 
reconfiguring a drive.

[toc] | [prev] | [next] | [standalone]

#248079

On Tue, 10 May 2022 19:13:55 +0200
DdB <debianlist@potentially-spam.de-bruyn.de> wrote:

> Booting UEFI requires different things: (detailed descriptions on
> rodsbook site)
> Proper subdir/entry in ESP (could be reused from old disk)
> Proper entry in NVRAM (Can be read and changed with efibootmgr)
> If i were you, i would prepare for emergency rescuing the system in
> case of havoc. For example the refind iso is capable of booting a
> system without a proper NVRAM entry, in order to rescue, i recommend
> preparing such an iso.
> 

My plan was to start over with the original disk in the machine, if the
new one won't boot. I'll be keeping the original disk unaltered in a
safe place for a while in case of problems.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web