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

older
[arch-general] Update to 4.15.8 on...

Trey Sizemore

17 Mar 2018 17 Mar '18

9:25 p.m.

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!

Show replies by date

Dorian C

17 Mar 17 Mar

9:59 p.m.

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 < arch-general@archlinux.org> wrote:

...

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!

Trey Sizemore

10:19 p.m.

On Sat, 2018-03-17 at 17:59 -0400, Dorian C via arch-general wrote:

...

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

10:24 p.m.

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

...

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#To...

Trey Sizemore

10:40 p.m.

On Sat, 2018-03-17 at 23:24 +0100, Jens John wrote:

...

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

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

18 Mar 18 Mar

3:03 a.m.

On Sat, 17 Mar 2018 18:40:33 -0400, Trey Sizemore wrote:

...

On Sat, 2018-03-17 at 23:24 +0100, Jens John wrote:

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

3:13 a.m.

On Sun, 18 Mar 2018 04:03:41 +0100, Ralf Mardorf wrote:

...

On Sat, 17 Mar 2018 18:40:33 -0400, Trey Sizemore wrote:

...
On Sat, 2018-03-17 at 23:24 +0100, Jens John wrote:

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

8:45 a.m.

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 Ralf Mardorf schrieb am So., 18. März 2018, 04:14:

...

On Sun, 18 Mar 2018 04:03:41 +0100, Ralf Mardorf wrote:

...
On Sat, 17 Mar 2018 18:40:33 -0400, Trey Sizemore wrote:

...
On Sat, 2018-03-17 at 23:24 +0100, Jens John wrote:

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

lists＠tun0.de

10:24 a.m.

On Sun, Mar 18, 2018 at 04:13:55AM +0100, Ralf Mardorf wrote:

...

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

lists＠tun0.de

10:20 a.m.

On Sat, Mar 17, 2018 at 06:40:33PM -0400, Trey Sizemore via arch-general wrote:

...

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

12:09 a.m.

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

...

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?

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, -- FA

Ricardo Band

3:51 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sat, 2018-03-17 at 17:25 -0400, Trey Sizemore via arch-general wrote:

...

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:// email@ricardo.band -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEhyzgFNiV8yZuI1T5Gp1lfQa1gg4FAlquixkACgkQGp1lfQa1 gg4AWQ/+IQ/5CUDxv5xrGfGSKt30R+noI5QCUuvSY9TkL8b8JgvcTBBh3ZIks/Rm NSuaxZtFP9rTDOJ4st/JkMT83r/I+2X2uPudlajYmGyjTLBNQvqmbwQXdP2sKGfI 2M6tjD8KGIU5HFZQqu7M0fjAoWSQqzkmyVn6DYZE8542Ga/imR5Xb90SIzDH1AyB 17Ecu44w2DB+ubw5cgpW05w4dAoPffWy/xLA4iyHKXk1ZjrUQ+mtkH3LZHMtF7DK vukv8RyPPJBiqGERN07DmVRGJP+842Sco4rojcIIJjjKN3PX6EoxhG+1uWWVwLe8 od2f2QohJEzExiBstEBLZ9uAGmEVRdg+XqrzF69GWiFcWxOw8B6LMi0wj3aVPcVi ZsfjshOqs0KaKn7QNNS+SFbFyx8I4DrRwC/NJ2YXzieyraP7r08CFIwv1rNQjxrN ZEug8Y0EZ2D8byOqlVdz3Jxg6UIU2RI3LDW8QA776NIVFE6TeonfidZCMW4xuYE1 Z+9Y5IsfSNkzPXoRbnD8cgBHuaXwEhKQ3Xs5aP7cMwY6IcleKRM9svuc0RzVbiDu czkgabMKOeHWN6GdWOAu0s42ZxG46r7vv/uMJp6nScc5eOy4FyC/YKV3C1FMNhmn BPyVLVm6BG5Lt12QqfKxSnEWPVHYrTphfXnMQ0CNwAnNpcUcouY= =Wp0S -----END PGP SIGNATURE-----

Ralf Mardorf

4:30 p.m.

On Sun, 18 Mar 2018 16:51:53 +0100, Ricardo Band via arch-general wrote:

...

On Sat, 2018-03-17 at 17:25 -0400, Trey Sizemore wrote:

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

4:33 p.m.

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

...

On Sun, 18 Mar 2018 16:51:53 +0100, Ricardo Band via arch-general wrote:

...
On Sat, 2018-03-17 at 17:25 -0400, Trey Sizemore wrote:

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

4:46 p.m.

On Sun, 18 Mar 2018 11:33:19 -0500, Doug Newgard via arch-general wrote:

...

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

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

5:08 p.m.

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

...

On Sun, 18 Mar 2018 11:33:19 -0500, Doug Newgard via arch-general wrote:

...
On Sun, 18 Mar 2018 17:30:27 +0100 Ralf Mardorf wrote:

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

19 Mar 19 Mar

9:17 a.m.

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 < arch-general@archlinux.org> wrote:

...

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

...
On Sun, 18 Mar 2018 11:33:19 -0500, Doug Newgard via arch-general wrote:

...
On Sun, 18 Mar 2018 17:30:27 +0100 Ralf Mardorf wrote:

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

10:44 a.m.

On Mon, 19 Mar 2018 09:17:02 +0000 Paul Gideon Dann via arch-general wrote:

...

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

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

1:46 p.m.

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

...

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

2:29 p.m.

On Mon, 19 Mar 2018, at 14:46, Carsten Mattner via arch-general wrote:

...

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

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

2:40 p.m.

On 19/03/18 14:29, Jens John wrote:

...

On Mon, 19 Mar 2018, at 14:46, Carsten Mattner via arch-general wrote:

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

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

2:41 p.m.

You can go with the rsync solution if you create your new filesystems with the old uuids. On 19 Mar 2018 3:30 pm, "Jens John" wrote:

...

On Mon, 19 Mar 2018, at 14:46, Carsten Mattner via arch-general wrote:

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

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

Eli Schwartz

3:11 p.m.

On 03/18/2018 01:08 PM, Doug Newgard via arch-general wrote:

...

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

...
On Sun, 18 Mar 2018 11:33:19 -0500, Doug Newgard via arch-general wrote:

...
On Sun, 18 Mar 2018 17:30:27 +0100 Ralf Mardorf wrote:

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

Joan Aymà

4:14 p.m.

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" < arch-general@archlinux.org> wrote:

...

On 03/18/2018 01:08 PM, Doug Newgard via arch-general wrote:

...
On Sun, 18 Mar 2018 17:46:21 +0100 Ralf Mardorf wrote:

...
On Sun, 18 Mar 2018 11:33:19 -0500, Doug Newgard via arch-general wrote:

...
On Sun, 18 Mar 2018 17:30:27 +0100 Ralf Mardorf wrote:

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

18 Mar 18 Mar

4:34 p.m.

BTW. what colour do you like?

2240

Age (days ago)

2242

Last active (days ago)

List overview

Download

24 comments

15 participants

participants (15)

Carsten Mattner
Dan Haworth
Dorian C
Doug Newgard
Eli Schwartz
Florijan Hamzic
Fons Adriaensen
Jens John
Jens John
Joan Aymà
lists＠tun0.de
Paul Gideon Dann
Ralf Mardorf
Ricardo Band
Trey Sizemore