You are not logged in.
I am new to Arch Linux. I wanted to get some clarity with regard to creating or not creating separate /usr partition. As opposed to at least a couple of other Linux distros, and as opposed to the recommendations over at http://tldp.org/LDP/lame/LAME/linux-adm … oning.html, Arch Linux/ers do not seem to encourage separate /usr partition, even though separate /usr partition is indeed supported on Arch Linux.
thank you for your time .
newbie Arch Linux user -- comparatively newbie Linux user with semblance of semblance of command-line literacy (don't ask, let's leave it at that)
P.S. Below average intelligence -- ooh almost foggot dat won
more about me here - https://bbs.archlinux.org/viewtopic.php … 5#p1258325
Offline
See https://wiki.archlinux.org/index.php/Mk … _partition
You might want to share your thinking for why you want to do this. If you are new to Arch (and Linux in general), then this may just introduce a level of complexity that will yield more frustration that any (perceived) benefit...
Offline
That page was correct 15 years ago. Today, not so much.
Offline
@jasonwryan
See https://wiki.archlinux.org/index.php/Mk … _partition
You might want to share your thinking for why you want to do this. If you are new to Arch (and Linux in general), then this may just introduce a level of complexity that will yield more frustration that any (perceived) benefit...
As a matter of fact I am new to Arch and with respect to Linux, well, I guess, I thought, I had already made that clear in the more about me link in my signature. Well, that's okay, here i go again
Hello everyone,
I am a newbie linuxer and now a newbie Arch Linuxer. I have used (to the best of my newbie ability that is) Linux Mint, Debian, LMDE, Slitaz, Ubuntu, FreeBSD, PCBsd, OpenBSD, and Fedora, et cetera -- maybe I am what is called a distro hopper, the thing is though i have used all these distros to the best of my limited newbie ability, I have not let go of any of them (well, maybe Ubuntu... maybe), and maybe i have learned some bits and pieces from the experience. And now i want to check out Arch Linux and here I am.
Thank you for your time.
I had already been to the https://wiki.archlinux.org/index.php/Mk … _partition link yesterday and the day before, and yes, i was frustrated, i was busting my head on my keyboard, and then i just gave up the idea of a separate /usr partition (at least for the time being and went ahead with the arch install.
But that is not the reason for this posting. If I was vague let me clarify, I do not seek any instruction with regard to creating of separate /usr partition, rather I was looking for information on "why" separate /usr partition way has been dropped, if you will, even though it is supported as per the link you provided me with. I was curious about the matter, especially since http://tldp.org/LDP/lame/LAME/linux-adm … oning.html encourages creation of a separate /usr partition -- maybe the tldp documentation is outdated.
The benefits (perceived) and/or reason for my being after the separate /usr partition is http://tldp.org/LDP/lame/LAME/linux-adm … oning.html.
thank you for your time .
newbie Arch Linux user -- comparatively newbie Linux user with semblance of semblance of command-line literacy (don't ask, let's leave it at that)
P.S. Below average intelligence -- ooh almost foggot dat won
more about me here - https://bbs.archlinux.org/viewtopic.php … 5#p1258325
Offline
As already mentioned, these tldp.org docs that seem to be so important to you are very old, and can no longer be regarded as authoritative in any way.
Have a look here instead: http://freedesktop.org/wiki/Software/sy … -is-broken .
Offline
I use a separate /usr and try to make sure it works. So to that extent I guess it is supported in Arch.
My aim is to be able to run with /usr read-only even if /etc (and hence the real root) is not, and that's why I'm testing it. This still has issues, so unless you want to help with that effort I don't know if it is much point. Another aim would be to share /usr between machines, but that also won't work until pacman stop installing files elsewhere (/etc, /var, /boot).
At any rate, to get a separate /usr working you just need to add an entry for it in your fstab and then add the 'usr' hook to your /etc/mkinitcpio.conf.
This means that /usr will be mounted from your initramfs before switching to the real root. Mounting /usr later, from the real root, is not supported, so you really need to be using an initramfs (which you anyway need to be doing if you are using the standard Arch kernel).
Offline
I use a separate /usr and try to make sure it works. So to that extent I guess it is supported in Arch.
My aim is to be able to run with /usr read-only even if /etc (and hence the real root) is not, and that's why I'm testing it. This still has issues, so unless you want to help with that effort I don't know if it is much point. Another aim would be to share /usr between machines, but that also won't work until pacman stop installing files elsewhere (/etc, /var, /boot).
At any rate, to get a separate /usr working you just need to add an entry for it in your fstab and then add the 'usr' hook to your /etc/mkinitcpio.conf.
This means that /usr will be mounted from your initramfs before switching to the real root. Mounting /usr later, from the real root, is not supported, so you really need to be using an initramfs (which you anyway need to be doing if you are using the standard Arch kernel).
You need usr, fsck, and shutdown in /etc/mkinitcpio.conf.
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
I would imagine the requirement of the fsck hook is not strictly necessary considering that there are a couple filesystems out there that are not intended to be fsck'ed regularly (ie. btrfs). But the shutdown hook does seem like a logical necessaity so that it can switch back to the initramfs on shutdown, thereby enabling the clean unmouting of /usr.
Offline
I use a separate /usr and try to make sure it works. So to that extent I guess it is supported in Arch.
My aim is to be able to run with /usr read-only even if /etc (and hence the real root) is not, and that's why I'm testing it. This still has issues, so unless you want to help with that effort I don't know if it is much point. Another aim would be to share /usr between machines, but that also won't work until pacman stop installing files elsewhere (/etc, /var, /boot).
Since I'm also planning on running /usr and /usr/local as read-only (security reasons), I was wondering, what kind of issues are You referring to? Is the system trying to read/wrtie something other then during package mgmt operations?
Offline
tomegun wrote:I use a separate /usr and try to make sure it works. So to that extent I guess it is supported in Arch.
My aim is to be able to run with /usr read-only even if /etc (and hence the real root) is not, and that's why I'm testing it. This still has issues, so unless you want to help with that effort I don't know if it is much point. Another aim would be to share /usr between machines, but that also won't work until pacman stop installing files elsewhere (/etc, /var, /boot).
Since I'm also planning on running /usr and /usr/local as read-only (security reasons), I was wondering, what kind of issues are You referring to? Is the system trying to read/wrtie something other then during package mgmt operations?
I was seeing this in the past, yes. The situation might have improved, it has been a long time since I looked at it (so forgot the details). If it is still the case, I think it should be considered bugs and be fixed where possible...
Offline
b1tH1de0 wrote:tomegun wrote:I use a separate /usr and try to make sure it works. So to that extent I guess it is supported in Arch.
My aim is to be able to run with /usr read-only even if /etc (and hence the real root) is not, and that's why I'm testing it. This still has issues, so unless you want to help with that effort I don't know if it is much point. Another aim would be to share /usr between machines, but that also won't work until pacman stop installing files elsewhere (/etc, /var, /boot).
Since I'm also planning on running /usr and /usr/local as read-only (security reasons), I was wondering, what kind of issues are You referring to? Is the system trying to read/wrtie something other then during package mgmt operations?
I was seeing this in the past, yes. The situation might have improved, it has been a long time since I looked at it (so forgot the details). If it is still the case, I think it should be considered bugs and be fixed where possible...
OK then.. when I get there, I will try to perform some tests on day-to-day usage and, If any case emerges, I will report it.
Offline
As I understand it, the "separate /usr" recommendation is an artifact from the days when Linux was aimed predominantly at server use, before desktop use became common. It's intended to slightly increase security in a multi-user environment in which network traffic isn't frequently monitored. You can probably stick this advice in the same class as "make a swap partition that's 150% the size of your total available RAM:" If you're using an older machine, and four other people are using that machine simultaneously, this would be sound advice; nowadays, it's obsolete. It will still work, but there's no need for it, and any security benefits would be minuscule compare to those garnered from encryption/firewalls/port forwarding.
If you're using a personal machine that you frequently monitor (as opposed to a server connected to a network that you don't constantly pay attention to), and are the only user, then having a separate /usr partition probably won't bring any benefits that I can see.
Offline
As I understand it, the "separate /usr" recommendation is an artifact from the days when Linux was aimed predominantly at server use, before desktop use became common. It's intended to slightly increase security in a multi-user environment in which network traffic isn't frequently monitored. You can probably stick this advice in the same class as "make a swap partition that's 150% the size of your total available RAM:" If you're using an older machine, and four other people are using that machine simultaneously, this would be sound advice; nowadays, it's obsolete. It will still work, but there's no need for it, and any security benefits would be minuscule compare to those garnered from encryption/firewalls/port forwarding.
If you're using a personal machine that you frequently monitor (as opposed to a server connected to a network that you don't constantly pay attention to), and are the only user, then having a separate /usr partition probably won't bring any benefits that I can see.
There are valid reasons to want a separate /usr partition (but I agree that security is not one of them).
-t
Offline
Like @anoknusa said, I have had a hard time understanding purpose of separate partitions on a personal computer. I am planning a btrfs automatic rollback installation with / for easy restore, /var to keep pacman archive separate and /home as it contains data. Modern computers, specially personal ones, seldom crash and as long as you have your data backed up you are fine. Reinstalling might be easier for average user than to recover a major crash.
Offline
@donniezazen, instead of keeping all of /var on a separate partition, I just keep /var/cache/pacman/pkg separate. From my experience with btrfs, it is just way easier to have the rootfs attached to /var in the case of rollbacks, since the state of /var can sometimes need to be in sync with the state of everything else for the system to be fully happy. So matching a dated /var snapshot to a dated rootfs snapshot just seems like an unnecessary PITA. The real reason I used to make /var a separate partition was so that I could use a different filesystem. But if everything is on btrfs, who cares?
Offline
@WonderWoofy That makes sense. So, you have a subvolume mounted as /var/cache/pacman/pkg? I don't have any partitions except swap and I could snapshot everything but I would not prefer to rollback my home folder. I suppose you could rollback individual folders in btrfs.
Offline
"Rollback" is a relative term, as it is not quite as sophisticated as ZFS in this regard. You can certainly choose to mount and use a different subvolume with subvol= mount flag.
Yes I have a /var/cache/pacman/pkg subvolume. I see no reason to have the snapshotted, as it is a large and contantly changing directory, so it would make the CoW functionality pretty inefficient.
I also have a /home subvolume. I do not just just create a subvolume at /home though I actually created a /rootfs subvol, and then I have a /homedir that is mounted at /rootfs/home (well, it is just /home when the system comes up). By doing this, you can effectively choose which subvolume you wish to mount at that point.
So my subvolume directory would look like this:
/
/rootfs
/homedir
/paccache
/snaps/<snapshots-here>
Where the /snaps is just a directory that resides in subvolid=0 but everything else is a subvolume. I also make things that I don't want to get snapshotted as subvolumes as well. So things like /var/abs and my build chroot are subvolumes that are actually located in the directory structure of /rootfs. I do this because my only motivation here is to not have thos included in the snapshot of the rootfs.
Offline
I had tried most of the partition schemes out there. For a desktop workstation I never felt any difference on new computers honestly. Systems are too fast to care about this nowadays (for normal taks).
Some people even recommend against a swap, but IMHO that's really not a good idea yet Just keep a swap file and set swapiness really low.
Offline
I think that we have effectively derailed this thread. But MilenKid, I don't know what kind of difference you expected to feel in having a multi-partitioned system. As menetioned above, it is historically for security reasons, which have mostly been mode obsolete by modern tools. But I think the separation of /home from rootfs is still obvious, as that is certainly still a divider worth having. The only time I think that you will "feel any difference" is if you piece up your system, but onto separate disks. Otherwise, having a bunch of partitions on the same disk has the possibility of simply leading to increased movement of the write head.
I would just like to point out as well, whatever you do, do not use a swap file with btrfs. It is said to cause severe filesystem corruption. However, if you for some reason really really need swap space on the fly with btrfs and are not willing to shrink the filesystem and partition, then you can use a swap file if done through a loop. Though this apparently comes with a significant performance hit.
Offline
Back in the days one of /usr purposes (and one of the ideas behind it) was to serve as a common filesystem to other network-attached machines for easier management. Mounting it on a host as ro was simply a way of keeping all systems parallel and a precaution to kept it safe from modifications performed on remote hosts.
As for today, most users do not need separate /usr, because most user do not use multiple machines with common filesystems, but..
I for example like to keep my system clean and simple, which in this case means, that, if the system is suppose to perform mod's to /usr during updates ONLY, it does not need /usr mounted as rw for the rest of the time. If it did perform some other mod's during day-to-day usage, this would simply mean, it's doing something I'm not aware of (Ubuntu used to "scream" when /usr was mounted as ro.. and that was one of the reasons I left it behind).
This solution adds a little extra overhead (re-mounting /usr before and after system update), but in the end You are more aware of what is happening "beneath the hood".
Offline
on modern day linux systems setting up seperate partitions for every directory is not neccary and adds to complexity. Same with a seperate /var. with modern kernels and ext4, there is no benefit from running rieserfs on /var and has not been in a long time. Its also not maintained and legacy so don't do it.
Also, the suggestion that the largest parition be /usr, is from 15 years ago, when the biggest things you'd have where programs. This is not the case anymore. If you run a linux desktop, most files will be things you download in /home.
In a MODERN linux system, with a modern large hard disk, a good partition scheme is
/boot - 200mb - combined with the right mkinitcptio hooks, you can fsck / unmounted.
/ - 100GB- your root parition. binary files are not big in today's world of TB+ size HD. 100GB is more than you'd ever need for binaries and systemfiles
SWAP - depends on how much ram you have/use. If you have more than ~8GB of ram, don't bother for general desktop use, you don't need it, using swap will just slow down your computer because HD access is slower than RAM. If you REALLY need swap, try using a swap file instead of a partition.
/home - the rest of your HD. - the advantage of a seperate /home is that installing, formating, or otherwise crashing the rest of the disk won't disrupt your user data, pictures of cats, pr0n, etc.... In fact you can install any distro you want, and expect your files and settings to still be there. In fact its even better if /home is on a completely seperate disk, such as a spinning magnetic disk, while your OS runs on an SSD
Offline
I disagree with having such an unnecessarily big root. With a spinning disk, the further out from the center of the disk you go, the worse the performance. So if you make a 100GB rootfs, you are probably going to be leaving >80GB of the faster part of the drive unused, pushing all your /home data out to the slower outer rungs. Ideally, you should have some idea of how much space your / is going to potentially take. I have never had my / go over ~12GB, so I just feel like 100GB is just waste.
Edit: Of course, this whole coversation is just silly because partition layout is a highly personal decision that varies from user to user. But I think that guiding some new-ish Linux user to make a 100GB / is doing a disservice to them.
Last edited by WonderWoofy (2013-06-20 22:09:42)
Offline