is there a way to add custom mount points at installation point?
And if there is would you say /usr should/could go onto a separate partition?
many thanks, L.
5 thoughts on - Mount Points @install Time
there was a time (sunos 1990’s for example) where mounting /usr on a separate partition was normal.
this might have been because disks at the time were too small to install the whole operating system on one, so usr could be located on another partition.
this is also why we sometimes have a /usr/sbin and /sbin for example. so theres the binaries needed for start up in /sbin, which would mount first.
anyway i digress for reasons of providing some background.
most people dont do this any more as they see it as unnecessary.
the only benefit to lots of separate partitions is to reduce the chances of data loss should a filesystem on that partition get corrupted.
on much older filesystems corruption was more common, another reason why it was done, today there filesystems/hardware are much more robust.
its also a way of restricting fragmentation to the disks that change alot, again almost certainly unnecessary today.
so while its mostly unnecessary, if you do custom partitioning during installation where you select what sizes , filesystem types , and mount points are created at install, you can do it there.
alternatively if using kickstart you can specify it in the kickstart.cfg file as another partition.
regards peter
lejeczek wrote:
Modify /etc/fstab .
peter.winterflood wrote:
To further digress, it also meant /usr could be mounted (read-only) and shared between multiple clients over NFS … thus saving precious hard disk space … (those were the days!)
James Pearson
Yes: tell the installer that you want to do manual partitioning. Then you can create whatever partitioning scheme you like.
A complete CentOS installation is in the single-digit gigs, which is smaller than even most removable media these days. Even small embedded systems can get a useful Linux installation onto a single flash IC or whatever it is they use for mass storage.
When installing to a single volume, the only partitions I make these days are to provide storage space isolation, as a cheap alternative to setting up quotas, log rotation, etc.:
* /var if you expect large log files, large MySQL DBs, large /var/www trees, etc.
* /home if you want to prevent problems with the root disk if normal users end up filling that partition with files they create.
* Network file shares for the same reason.
With filesystems featuring pooled/shared storage (ZFS, btrfs, APFS…) I tend to create only one partition, then rely on the filesystem’s quota feature if necessary to avoid such problems.
Even on single-volume systems without pooled storage, you can usually get away with a minimal partition scheme:
* Small /boot (plus maybe /boot/efi and/or /biosboot)
* swap partition
* root for everything else
This is because modern Unix-type filesystems will will typically reserve the last 5% of the space for root only, so that normal users simply cannot fill a filesystem, so that the OS won’t crash due to system daemons being unable to write to the disk.
Also in the systemd world you create a .mount unit.
5 thoughts on - Mount Points @install Time
there was a time (sunos 1990’s for example) where mounting /usr on a separate partition was normal.
this might have been because disks at the time were too small to install the whole operating system on one, so usr could be located on another partition.
this is also why we sometimes have a /usr/sbin and /sbin for example. so theres the binaries needed for start up in /sbin, which would mount first.
anyway i digress for reasons of providing some background.
most people dont do this any more as they see it as unnecessary.
the only benefit to lots of separate partitions is to reduce the chances of data loss should a filesystem on that partition get corrupted.
on much older filesystems corruption was more common, another reason why it was done, today there filesystems/hardware are much more robust.
its also a way of restricting fragmentation to the disks that change alot, again almost certainly unnecessary today.
so while its mostly unnecessary, if you do custom partitioning during installation where you select what sizes , filesystem types , and mount points are created at install, you can do it there.
alternatively if using kickstart you can specify it in the kickstart.cfg file as another partition.
regards peter
lejeczek wrote:
Modify /etc/fstab .
peter.winterflood wrote:
To further digress, it also meant /usr could be mounted (read-only) and shared between multiple clients over NFS … thus saving precious hard disk space … (those were the days!)
James Pearson
Yes: tell the installer that you want to do manual partitioning. Then you can create whatever partitioning scheme you like.
Once upon a time, yes, but not any more:
https://unix.stackexchange.com/a/4194/138
A complete CentOS installation is in the single-digit gigs, which is smaller than even most removable media these days. Even small embedded systems can get a useful Linux installation onto a single flash IC or whatever it is they use for mass storage.
When installing to a single volume, the only partitions I make these days are to provide storage space isolation, as a cheap alternative to setting up quotas, log rotation, etc.:
* /var if you expect large log files, large MySQL DBs, large /var/www trees, etc.
* /home if you want to prevent problems with the root disk if normal users end up filling that partition with files they create.
* Network file shares for the same reason.
With filesystems featuring pooled/shared storage (ZFS, btrfs, APFS…) I tend to create only one partition, then rely on the filesystem’s quota feature if necessary to avoid such problems.
Even on single-volume systems without pooled storage, you can usually get away with a minimal partition scheme:
* Small /boot (plus maybe /boot/efi and/or /biosboot)
* swap partition
* root for everything else
This is because modern Unix-type filesystems will will typically reserve the last 5% of the space for root only, so that normal users simply cannot fill a filesystem, so that the OS won’t crash due to system daemons being unable to write to the disk.
Also in the systemd world you create a .mount unit.