Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/home #23

Open
neilconway opened this issue Dec 16, 2015 · 7 comments
Open

/home #23

neilconway opened this issue Dec 16, 2015 · 7 comments

Comments

@neilconway
Copy link

Not really a bug, but why is /home a separate, smaller filesystem? If I'd like to make use of the entire 10GB default storage allocation, this configuration makes things more difficult.

@neilconway
Copy link
Author

Ping :)

The Arch box would be a lot easier to use (at least to me) if (a) there was a single filesystem, not an arbitrary split between / and /home (b) the default HDD was larger -- say 40GB, dynamically allocated.

@terrywang
Copy link
Owner

@neilconway Apology for the late response ;-D Have been busy with stuff.

A sweet /home on separate partition or block device is just a long time best practice as a desktop user.

The current Arch Linux vagrant base box has a small 10GB ONLY virtual disk, which is too small for most use cases nowadays.

NOTE: When the base box (VirtualBox) VM was initially created, I just wanted to make it a reusable minimum install with pretty much all tools I needed to do the daily job, if more storage is needed personally I'll add more Virtual HDDs and add them to existing LVM (VG) or create a separate file system and mount it.

Later on I made it a vagrant base box when learning Vagrant. I didn't expect the Arch Linux base box to be this popular ;-D

I have 2 options:

  1. resize the current 10GB virtual hard disk to 40GB while still keep / (30GB) and /home (10GB) separate
  2. resize the current 10GB virtual hard disk to 40GB and create a single / file system on the block device

I prefer option 1 at this stage, let me know your thoughts.

@neilconway
Copy link
Author

@terrywang Thanks for the response!

My personal opinion is that a separate partition for /home made sense in the past (especially for multi-user Unix installations -- e.g., make it harder for a rogue user to use up all disk-space on the root partition), but is less sensible now, since many/most Vagrant boxes are single-user. I think option 2 is the best default -- of course people can reconfigure it as needed, but it mean the most flexibility for how users want to allocate disk space.

@terrywang
Copy link
Owner

@neilconway Already tried option 2 and the process is pretty straightforward.

Will make the change in the next update and document process in this issue (later on move to a wiki page) for the curious cats ;-D

@neilconway
Copy link
Author

@terrywang Awesome!! Thank you.

@terrywang
Copy link
Owner

Steps to move to a single / file system and increase the VDI size from 10GB to 40GB.

NOTE: Before proceeding, copy entire /home over to a temporary directory, e.g. using my personal favourite tool rsync -> rsync -axHAX --progress --stats /home /mnt.

  1. Unmount /home -> umount -l /home
  2. rm -rf/home; mv /mnt/home / ;-D
  3. Use parted to remove second partition, in this case /dev/sda2, number 2 -> rm 2
  4. Boot with System Rescue CD ISO
  5. Resize the first partition, in this case grow it using all available free space resizepart 1 100%
  6. Quit parted
  7. Run fsck against the resized / -> e2fsck -f /dev/sda1
  8. Grow the ext4 file system (as the underlying block device size changed) -> resize2fs -Fp /dev/sda1
  9. Remove /dev/sda2 entry from /etc/fstab, otherwise systemd will get stuck on boot
  10. Now we can resize the VDI using VirtualBox's lovely and powerful CLI -> VBoxManage modifyhd --resize 40960 /path/to/arch.vdi
  11. Boot with system rescue CD ISO again
  12. Repeat step 4,5,6,7,8
  13. Done

@marco-m
Copy link

marco-m commented Jun 28, 2017

Looks like this can be closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants