SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi there, this is my first post and like to thank you all ahead of time for the years of help I've had on previous accounts :P and just the linux guru's in general. So here I am using slackware 14 and I want to have /usr on a seperate partition and it is so far but I read that to have this work properly you need to add some "hooks" and I'm wondering if this is still true in 14 or not cause when I got a guide on these hooks wehre I found it the directory for the program used no longer is in there. so did they rid this nasty configuration feature and detect it it's self or did they use another program to configure this or even yet did the files move? I doubt the files moved as this tutorial is on the website of the program said to be used. Maybe it was never implemented into slackware either I don't even know. Thank you though! I don't see any kind of errors that stand out to /usr as a directory alone but some for directorys within
The main issue with partitioning directories residing on / is the mounting timing on startup. The files on any partition are only available after the file system found on that partition is mounted. The startup sequence requires access to some files before other file systems are mounted. Those required files must be available when the / file system is mounted by itself.
If the files are needed in the startup sequence before they are mounted then the startup sequence will fail.
For example putting /bin, /sbin, or /etc directories in their own partition is NOT good idea.
I believe that generally any files needed in the /usr directory on Slack only happen after the file systems are all mounted, so there shouldn't be any problems. But it's been years since I've done this. Others can confirm or refute.
There have been other threads in this forum at LQ discussing the benefits of separate partitions for various file directories. This typically involves /usr /var /opt directories. There are arguments made on both sides of the issue.
Usually the simplest way to find out is to try it. Install Slack on a system with a separate /usr partition and see what happens with Slack configured the way you want it. Everyone should have a spare computer or at least a spare hard drive or two around to experiment with.
The reason I did this is because the guy that made the slackware site put that he uses it that way didn't say it needed extra configuration but I just happen to come across this. So I guess I'll maybe while i"m going through reading some things try it out I guess it can't be any harm I mean i guess the biggest reason was that he said it was for upgrading compatibility you can keep all programs but I guess from here I should refer to these post you have refered me to since I think I'll find my answers there to see what fits me
thank you
It's not safe to have /usr on a separate partition. It might work, but I've never managed to make it work. You can put /usr/local and /opt on a separate partition.
I've always had /usr, /var, and /tmp on their own partitions for the past few years with Slackware and way back when (early mid nineties) I was using Novell/SCO Unixware. Zero issues.
I have three systems right now running with separate /usr partitions.
The basic process:
* Create an empty partition of adequate size. Use cfdisk, gparted, etc., whatever is most comfortable.
* When installing Slackware, be sure to assign /usr to that partition location. For example, if the primary (root) partition is /dev/sda1 and the new empty partition is located at /dev/sd2, then when running the install script assign /dev/sda2 to /usr.
* The Slackware install script will create a respective /etc/fstab entry for /usr.
The biggest caveat is typing errors. While the install script helps select the partition through a list, the assignment is manually typed. So be sure to type /usr and not something like /user.
Creating a separate /usr after installing Slackware is similar.
I decided to make a choice on this earlier cuase I had to decide on something. I decided to throw out /usr on it's own partition and make it /usr/local on it's on which I haven't gotten any errors that i was getting before so I guess this works and any of my own programs i'll just throw in there I have many other questions for this forum (A whole list of things i need help with alot that I plan to try and figure out on my own but others that I know I'm gonna need help on after i do a little bit of research). So you guys will be seeing alot from me. Thank you!
I use a separate /usr/local on all of my systems. I store all of scripts there, as well as custome fonts, sounds, non system config files, etc. As a separate file system I don't worry about installations or reinstallations clobbering those files because during such events the installer doesn't "know" about the file system. I add the mount point manually after the installation. Plus, by being a separate partition the entire file system becomes portable across a multi-boot system.
Trying to rip /usr and /usr/local, and even /tmp and /var down to their own partitions can be problematic over time with log files and other buildup that occurs. I find it useless to have anything past the main 2 or 3 partitions most commonly used and just a headache to maintain.
I've had as a partition layout (spread over 2 physical disks) for several years, at least 4 if I recall correct. When I did a clean install, I would leave /home and /opt (games were stored) intact and possibly /usr/local also. I can't really say it was any more responsive than having 1 or 2 partitions but I don't recall any flaws either.
I also use a separate /usr/local, I don't see much value in a separate /usr. I don't really want to dedicate another partition for /opt , so have often wondered if just sym linking /opt to /usr/local would be wise...?
I also use a separate /usr/local, I don't see much value in a separate /usr. I don't really want to dedicate another partition for /opt , so have often wondered if just sym linking /opt to /usr/local would be wise...?
It's certainly one option. I don't bother with a separate /usr/local or /opt. I just tar them up before I do an upgrade or reinstall and put them back afterwards. They're usually not large enough for this approach to be a problem.
I've got my root on one partition and /var on another partition, but I've also linked /home to /var/home and /tmp to /var/tmp.
My reasoning is that /var (/home and /tmp) are most likely to need more space and have to be shifted around or expanded. Whereas everything else (/usr, and /opt mainly) are not going to grow much after the initial installation of the system and software.
Moving /tmp to another partition has only been a minor issue on the occasion when I have to boot from the install DVD to fix something I broke, then if I mount my / partition and chroot to it I've got no /tmp until I mount my /var partition. As I said, minor - very minor - issue.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.