[arch-general] Re-install of Arch on a larger drive

[Trey Sizemore via arch-general]

Hi all-

I currently have Arch running on a 250GB drive, and I'm going to be
moving to a 500GB drive.

I'm looking for 'best practices' when it comes to the migrating as much
as possible during the re-install.

It appears that I can migrate my installed packages (standard and AUR
repos) via:

pacman -Qqe > pkglist.txt

and then on the new install, I can use the pkglist.txt generated
previously to:

pacman -S - < pkglist.txt

In addition, by backing up and migrating much of my /home partition (to
include 'hidden' config files, anything else I could do to make the
process fast and as close to the current install as possible?

Thanks!

[Dorian C via arch-general]

I'm just curious really, but any particular reason you can't back up your
personal files and do a clean install?

On Sat, Mar 17, 2018 at 5:25 PM, Trey Sizemore via arch-general <

Post by Trey Sizemore via arch-general
Hi all-
I currently have Arch running on a 250GB drive, and I'm going to be
moving to a 500GB drive.
I'm looking for 'best practices' when it comes to the migrating as much
as possible during the re-install.
It appears that I can migrate my installed packages (standard and AUR
pacman -Qqe > pkglist.txt
and then on the new install, I can use the pkglist.txt generated
pacman -S - < pkglist.txt
In addition, by backing up and migrating much of my /home partition (to
include 'hidden' config files, anything else I could do to make the
process fast and as close to the current install as possible?
Thanks!

[Trey Sizemore via arch-general]

Post by Dorian C via arch-general
I'm just curious really, but any particular reason you can't back up your
personal files and do a clean install?

I will be doing a clean install. I want to mirror the same setup as
the current install, just on a bigger hard drive.

[Jens John]

anything else I could do to make the process fast and as close to the
current install as possible?

Yes. Do not reinstall but migrate your file system contents 1:1 to the
new disk using rsync. The advantage is that the file system contents and
therefore system configuration stay the same and you don't have to waste
time putting stuff together afterwards.

I used/recommend a procedure similar to [1]. The principle is basically
the same as a reinstall but instead of bootstrapping from a bare bones
system you substitute your existing file systems. I don't see any
benefit of doing it differently unless your existing install is broken
in some way.

The most time was taken up by copying 512G of file system contents over
a SATA<>USB3 bridge to the new SSD. If you can put both the old and the
new drive on a SATA bus, you'll be done in no time.

[1] https://wiki.archlinux.org/index.php/migrate_installation_to_new_hardware#Top_to_Bottom

[Trey Sizemore via arch-general]

On Sat, Mar 17, 2018 at 05:25:36PM -0400, Trey Sizemore via arch-

anything else I could do to make the process fast and as close to the
current install as possible?

Yes. Do not reinstall but migrate your file system contents 1:1 to the
new disk using rsync. The advantage is that the file system contents and
therefore system configuration stay the same and you don't have to waste
time putting stuff together afterwards.
I used/recommend a procedure similar to [1]. The principle is
basically
the same as a reinstall but instead of bootstrapping from a bare bones
system you substitute your existing file systems. I don't see any
benefit of doing it differently unless your existing install is broken
in some way.
The most time was taken up by copying 512G of file system contents over
a SATA<>USB3 bridge to the new SSD. If you can put both the old and the
new drive on a SATA bus, you'll be done in no time.
[1] https://wiki.archlinux.org/index.php/migrate_installation_to_new_
hardware#Top_to_Bottom

Thanks Jens. But does the fact that I'm going from a 250GB to 500GB
(and different partition sized) complicate this procedure?

[Ralf Mardorf]

Post by Jens John
Do not reinstall but migrate your file system contents 1:1 to the
new disk using rsync.

Why using such an advanced tool for a simple copy?

Run a Linux from a live media and simply do a

sudo cp -a /from/source/mountpoint /to/target/mountpoint

But does the fact that I'm going from a 250GB to 500GB (and different
partition sized) complicate this procedure?

It doesn't matter, don't confuse the copy (or any sync) command, with
something like the dd command.

Since you don't migrate to other hardware, appart from the drive, you
even don't need to fix a graphics driver or something like that, you
only need to reinstall the bootloader after coping all files.

[Ralf Mardorf]

Post by Ralf Mardorf

Post by Jens John
Do not reinstall but migrate your file system contents 1:1 to the
new disk using rsync.

Why using such an advanced tool for a simple copy?
Run a Linux from a live media and simply do a
sudo cp -a /from/source/mountpoint /to/target/mountpoint

But does the fact that I'm going from a 250GB to 500GB (and different
partition sized) complicate this procedure?

It doesn't matter, don't confuse the copy (or any sync) command, with
something like the dd command.
Since you don't migrate to other hardware, appart from the drive, you
even don't need to fix a graphics driver or something like that, you
only need to reinstall the bootloader after coping all files.

Oops, perhaps you need to fix fstab, your bootloader's config and
similar files, assuming you are one of those UUID users. If you tend to
use labels instead of UUIDs, you even don't need to fix those
files. After copying the files just use the same label for the new
partition, you used for the partition on the old drive.

[Florijan Hamzic via arch-general]

I also planning to do that and found this:

https://wiki.archlinux.org/index.php/disk_cloning#Using_e2image

It only copies the used blocks to the new partition

Post by Ralf Mardorf

Post by Ralf Mardorf

Post by Jens John
Do not reinstall but migrate your file system contents 1:1 to the
new disk using rsync.

Why using such an advanced tool for a simple copy?
Run a Linux from a live media and simply do a
sudo cp -a /from/source/mountpoint /to/target/mountpoint

But does the fact that I'm going from a 250GB to 500GB (and different
partition sized) complicate this procedure?

It doesn't matter, don't confuse the copy (or any sync) command, with
something like the dd command.
Since you don't migrate to other hardware, appart from the drive, you
even don't need to fix a graphics driver or something like that, you
only need to reinstall the bootloader after coping all files.

Oops, perhaps you need to fix fstab, your bootloader's config and
similar files, assuming you are one of those UUID users. If you tend to
use labels instead of UUIDs, you even don't need to fix those
files. After copying the files just use the same label for the new
partition, you used for the partition on the old drive.

[l***@tun0.de]

Post by Ralf Mardorf
Oops, perhaps you need to fix fstab, your bootloader's config and
similar files, assuming you are one of those UUID users. If you tend to
use labels instead of UUIDs, you even don't need to fix those
files. After copying the files just use the same label for the new
partition, you used for the partition on the old drive.

Even simpler, when reinstalling the bootloader to MBR or EFI, while
being in the live environment, this can be taken care of with genfstab
[1].

[1] https://wiki.archlinux.org/index.php/installation_guide#Fstab

[l***@tun0.de]

Post by Trey Sizemore via arch-general
Thanks Jens. But does the fact that I'm going from a 250GB to 500GB
(and different partition sized) complicate this procedure?

Absolutely not.

You are going to partition the new drive (and possibly create the LUKS
container, and/or LVM) according to the increased capacity of the new
drive. Then, you'll copy only the contents of the old file systems over
to the new file systems while preserving all attributes (the rsync flags
are important). Thus, the target file systems on the new drive can be
bigger or even smaller, dependent only on the data volume stored on your
existing file systems.

I linked to the wiki page previously because all steps of the procedure
are covered by it, somewhere.

[Fons Adriaensen]

Post by Trey Sizemore via arch-general
pacman -Qqe > pkglist.txt
and then on the new install, I can use the pkglist.txt generated
pacman -S - < pkglist.txt
In addition, by backing up and migrating much of my /home partition (to
include 'hidden' config files, anything else I could do to make the
process fast and as close to the current install as possible?

The trick with pkglist may work, but I never tried it.

If you do a fresh install, you can copy over you /home partition
and any others that only contain user data and nothing related
to the system.

To save some download time, and assuming your current system is
up to date, you can copy /var/cache/pacman/pkg to your new system
after the basic install (just before you do the pacman -Syu and
eventually pacman -S - < pkglist.txt).

Ciao,

[Ricardo Band via arch-general]

On Sat, 2018-03-17 at 17:25 -0400, Trey Sizemore via arch-general

Post by Trey Sizemore via arch-general
Hi all-
I currently have Arch running on a 250GB drive, and I'm going to be
moving to a 500GB drive.

why not just `dd if=/dev/olddrive of=/dev/newdrive` and then grow the
filesystems in it change UUIDs in fstab, done?

- --

Greetings

Ricardo Band

https:// www.ricardo.band
mailto:// ***@ricardo.band

[Ralf Mardorf]

Post by Ricardo Band via arch-general

Post by Trey Sizemore via arch-general
Hi all-
I currently have Arch running on a 250GB drive, and I'm going to be
moving to a 500GB drive.

why not just `dd if=/dev/olddrive of=/dev/newdrive` and then grow the
filesystems in it change UUIDs in fstab, done?

The "dd" command is inappropriate, a "cp -a" is the most reasonable
solution. However, UUIDs are still an issue, the average desktop
computer user should consider to prefer a lable over an UUID.

[Doug Newgard via arch-general]

On Sun, 18 Mar 2018 17:30:27 +0100

Post by Ralf Mardorf

Post by Ricardo Band via arch-general

Post by Trey Sizemore via arch-general
Hi all-
I currently have Arch running on a 250GB drive, and I'm going to be
moving to a 500GB drive.

why not just `dd if=/dev/olddrive of=/dev/newdrive` and then grow the
filesystems in it change UUIDs in fstab, done?

The "dd" command is inappropriate, a "cp -a" is the most reasonable
solution. However, UUIDs are still an issue, the average desktop
computer user should consider to prefer a lable over an UUID.

Why is it inappropriate? It should work fine, and work with no other changes.
Even the UUIDs/Labels would be the same that way.

[Ralf Mardorf]

Post by Doug Newgard via arch-general

Post by Ralf Mardorf
The "dd" command is inappropriate, a "cp -a" is the most reasonable
solution. However, UUIDs are still an issue, the average desktop
computer user should consider to prefer a lable over an UUID.

Why is it inappropriate? It should work fine, and work with no other
changes. Even the UUIDs/Labels would be the same that way.

If so, don't beat around the bush, simply provide the command that does
it all :).

[Doug Newgard via arch-general]

On Sun, 18 Mar 2018 17:46:21 +0100

Post by Ralf Mardorf

Post by Doug Newgard via arch-general

Post by Ralf Mardorf
The "dd" command is inappropriate, a "cp -a" is the most reasonable
solution. However, UUIDs are still an issue, the average desktop
computer user should consider to prefer a lable over an UUID.

Why is it inappropriate? It should work fine, and work with no other
changes. Even the UUIDs/Labels would be the same that way.

If so, don't beat around the bush, simply provide the command that does
it all :).

If you need more than what Ricardo Band already posted, you're beyond help.

[Paul Gideon Dann via arch-general]

I've moved or cloned my general-use Arch system between disks more times
than I can count. This is what LVM is for. If you're not using LVM (or
BTRFS), I recommend you start, but in the meantime, the simplest solution
when moving between systems is to dd the contents of each partition from
the source disk to the destination disk, and then expand filesystems as
necessary:

sudo dd if=/dev/sdx1 of=/dev/sdy1 bs=1M oflag=direct
sudo fsck -f /dev/sdy1
sudo resize2fs /dev/sdy1

Paul

On 18 March 2018 at 17:08, Doug Newgard via arch-general <

Post by Doug Newgard via arch-general
On Sun, 18 Mar 2018 17:46:21 +0100

Post by Ralf Mardorf

Post by Doug Newgard via arch-general

Post by Ralf Mardorf
The "dd" command is inappropriate, a "cp -a" is the most reasonable
solution. However, UUIDs are still an issue, the average desktop
computer user should consider to prefer a lable over an UUID.

Why is it inappropriate? It should work fine, and work with no other
changes. Even the UUIDs/Labels would be the same that way.

If so, don't beat around the bush, simply provide the command that does
it all :).

If you need more than what Ricardo Band already posted, you're beyond help.

[Trey Sizemore via arch-general]

On Mon, 19 Mar 2018 09:17:02 +0000

Post by Paul Gideon Dann via arch-general
I've moved or cloned my general-use Arch system between disks more
times than I can count. This is what LVM is for. If you're not using
LVM (or BTRFS), I recommend you start, but in the meantime, the
simplest solution when moving between systems is to dd the contents
of each partition from the source disk to the destination disk, and
sudo dd if=/dev/sdx1 of=/dev/sdy1 bs=1M oflag=direct
sudo fsck -f /dev/sdy1
sudo resize2fs /dev/sdy1
Paul

Thanks. I'll give it a try and also go back to using LVM.
--
Cheers,
Trey
----

There is an innocence in admiration; it is found in those to whom
it has not yet occurred that they, too, might be admired some day.
--Friedrich Nietzsche

Linux mint-desktop 4.10.0-38-generic x86_64
06:43:24 up 17:12, 1 user, load average: 0.10, 0.32, 0.75

[Carsten Mattner via arch-general]

On 3/19/18, Paul Gideon Dann via arch-general

Post by Paul Gideon Dann via arch-general
I've moved or cloned my general-use Arch system between disks more times
than I can count. This is what LVM is for. If you're not using LVM (or
BTRFS), I recommend you start

Which aspect is easier/improved with LVM?

[Jens John]

Post by Carsten Mattner via arch-general
On 3/19/18, Paul Gideon Dann via arch-general

Post by Paul Gideon Dann via arch-general
I've moved or cloned my general-use Arch system between disks more times
than I can count. This is what LVM is for. If you're not using LVM (or
BTRFS), I recommend you start

Which aspect is easier/improved with LVM?

Generally speaking, it decouples the sizes of your file systems from disk geometry (partitions). So you can resize whichever logical volume up or down without having to care about if there's space in front or after it.

What 's not so neat about OPs dd solution when compared to rsync is that if you have a 100G file system 50% full , you'll copy ~100G of data instead of ~50G. Depending on transfer speeds, that can be a lot of extra time. Also, you'll get free defragmentation when starting with fresh file systems. If you want to change file system block sizes, you also need to start fresh.

[Dan Haworth]

Post by Jens John

Post by Carsten Mattner via arch-general
On 3/19/18, Paul Gideon Dann via arch-general

Post by Paul Gideon Dann via arch-general
I've moved or cloned my general-use Arch system between disks more times
than I can count. This is what LVM is for. If you're not using LVM (or
BTRFS), I recommend you start

Which aspect is easier/improved with LVM?

Generally speaking, it decouples the sizes of your file systems from disk geometry (partitions). So you can resize whichever logical volume up or down without having to care about if there's space in front or after it.
What 's not so neat about OPs dd solution when compared to rsync is that if you have a 100G file system 50% full , you'll copy ~100G of data instead of ~50G. Depending on transfer speeds, that can be a lot of extra time. Also, you'll get free defragmentation when starting with fresh file systems. If you want to change file system block sizes, you also need to start fresh.

To add to this, with LVM you can move your PV's between devices (for
example, to a new bigger hard disk) really simply with the pvmove
command. It literally is as simple (to a point, still have to deal with
the bootloader) as install new hard disk, move pv, remove old hard disk.

--dan

[Joan Aymà via arch-general]

You can go with the rsync solution if you create your new filesystems with
the old uuids.

Post by Jens John

Post by Carsten Mattner via arch-general
On 3/19/18, Paul Gideon Dann via arch-general

Post by Paul Gideon Dann via arch-general
I've moved or cloned my general-use Arch system between disks more

times

Post by Carsten Mattner via arch-general

Post by Paul Gideon Dann via arch-general
than I can count. This is what LVM is for. If you're not using LVM (or
BTRFS), I recommend you start

Which aspect is easier/improved with LVM?

Generally speaking, it decouples the sizes of your file systems from disk
geometry (partitions). So you can resize whichever logical volume up or
down without having to care about if there's space in front or after it.
What 's not so neat about OPs dd solution when compared to rsync is that
if you have a 100G file system 50% full , you'll copy ~100G of data instead
of ~50G. Depending on transfer speeds, that can be a lot of extra time.
Also, you'll get free defragmentation when starting with fresh file
systems. If you want to change file system block sizes, you also need to
start fresh.

[Eli Schwartz via arch-general]

Post by Doug Newgard via arch-general
On Sun, 18 Mar 2018 17:46:21 +0100

Post by Ralf Mardorf

Post by Doug Newgard via arch-general

Post by Ralf Mardorf
The "dd" command is inappropriate, a "cp -a" is the most reasonable
solution. However, UUIDs are still an issue, the average desktop
computer user should consider to prefer a lable over an UUID.

Why is it inappropriate? It should work fine, and work with no other
changes. Even the UUIDs/Labels would be the same that way.

If so, don't beat around the bush, simply provide the command that does
it all :).

If you need more than what Ricardo Band already posted, you're beyond help.

Known issue, just stick with the second half of your sentence. :p

[Joan Aymà via arch-general]

You can makefs with an arbitrary uuid, or, as been said, switch to labels:
From `man mkfs.ext4`:
*-L** new-volume-label*Set the volume label for the filesystem to
*new-volume-label*. The maximum length of the volume label is 16 bytes.
*-U** UUID*Create the filesystem with the specified UUID

Regards.

On 19 Mar 2018 4:10 pm, "Eli Schwartz via arch-general" <

Post by Eli Schwartz via arch-general

Post by Doug Newgard via arch-general
On Sun, 18 Mar 2018 17:46:21 +0100

Post by Ralf Mardorf

Post by Doug Newgard via arch-general

Post by Ralf Mardorf
The "dd" command is inappropriate, a "cp -a" is the most reasonable
solution. However, UUIDs are still an issue, the average desktop
computer user should consider to prefer a lable over an UUID.

Why is it inappropriate? It should work fine, and work with no other
changes. Even the UUIDs/Labels would be the same that way.

If so, don't beat around the bush, simply provide the command that does
it all :).

If you need more than what Ricardo Band already posted, you're beyond

help.
Known issue, just stick with the second half of your sentence. :p
--
Eli Schwartz
Bug Wrangler and Trusted User

[Ralf Mardorf]

BTW. what colour do you like?