Problems With UNIX Standards

[SoulofDeity]

I still don't understand. If you need the "mount" command to mount other volumes how can you store that command (or a library implementing it as a system call, or an initialization program calling that system call) on a separate volume? I still don't understand the statement that "the only reason anything should be in the root directory is if it can optionally be stored on a separate volume". I just can't make any sense of that statement. Perhaps you could expound on the logic behind it.

When you first turn on the pc, grub pokes its nose around for configuration files. Obviously, it finds the one on /boot first which describes how to load the kernel. The /etc directory is the next thing that gets mounted. Since it contains the configuration data for the kernel it must also be on the same volume as the kernel. The kernel then reads /etc/fstab to determine how and where to mount everything else.

Note: at this point, the mounting is taking place internally, not by calling the 'mount' command. There's a C api for this.

[iansjack]

Well, thank you for the lesson on Unix basics.

A few comments, as I see it:

1. Grub doesn't "poke its nose around for configuration files". What would happen if there were two grub configuration files on separate volumes - which would it choose?

2. /etc does not have to be on the same volume as the kernel - frequently it isn't (the kernel is on the volume mounted on /boot, /etc on the volume mounted as /). But it does, IMO, have to be on the same volume as the root directory.

3. If /etc is not on the same volume as /, but is mounted later, how does the system know which volume to mount on /etc? It can't determine this from /etc/fstab. Note that this problem doesn't apply to / - you told it which volume to mount in the grub configuration file.

4. "Mounting is taking place internally. There's a C api for this." And how do C apis work? By calling functions in the C library, which is located in libc. So can libc be stored on a separate Volume? I'd say it has to be on the same volume as the root directory (or, possibly /boot, but that is not commonly done). Hence we have /lib as well as /usr/lib; /lib also stores the modules, which may need to be loaded early in the boot process. All this needs to be on the root volume.

So I still have a problem with "the only reason anything should be in the root directory is if it can optionally be stored on a separate volume". It is internally inconsistent. If a file or directory cannot optionally be stored on a separate volume then that implies that it has no place in the root directory (i.e. on the same volume as the root directory). So where do you store it? You've said that it has no place in the root directory, and you've said that it cannot optionally be stored on a separate volume. So where on earth are you going to store it?

I begin to wonder if you meant the exact obvious (which would be a sensible, if rather obvious, statement) and are just too stubborn to admit the mistake.

[SoulofDeity]

Well, thank you for the lesson on Unix basics.

A few comments, as I see it:

1. Grub doesn't "poke its nose around for configuration files". What would happen if there were two grub configuration files on separate volumes - which would it choose?

Both. That's how grub works. (DUH)

2. /etc does not have to be on the same volume as the kernel - frequently it isn't (the kernel is on the volume mounted on /boot, /etc on the volume mounted as /). But it does, IMO, have to be on the same volume as the root directory.

Seriously? Do you know why there's often a link to the kernel in the root directory? Because some people place it there and others place it in boot. You just contradicted yourself.

3. If /etc is not on the same volume as /, but is mounted later, how does the system know which volume to mount on /etc? It can't determine this from /etc/fstab. Note that this problem doesn't apply to / - you told it which volume to mount in the grub configuration file.

Because it's on the same volume as the kernel (or in /boot)

4. "Mounting is taking place internally. There's a C api for this." And how do C apis work? By calling functions in the C library, which is located in libc. So can libc be stored on a separate Volume? I'd say it has to be on the same volume as the root directory (or, possibly /boot, but that is not commonly done). Hence we have /lib as well as /usr/lib; /lib also stores the modules, which may need to be loaded early in the boot process. All this needs to be on the root volume.

The C api was testament to the fact you don't need to use the 'mount' command. The kernel controls the vfs, it doesn't need to go through a library to manipulate the filing system.

I begin to wonder if you meant the exact obvious (which would be a sensible, if rather obvious, statement) and are just too stubborn to admit the mistake.

I'm beginning to wonder if you just like to argue. You keep telling me I don't know what I'm talking about when just 2 posts ago, you apparently didn't know you could mount stuff on separate volumes.

[iansjack]

You know, that post is so full of simple errors that I don't know where to start. And really I am getting tired of pointing out the most elementary misunderstandings, so I'll stick with just the first.

1. When you install grub you tell it which volume contains the configuration files. So it doesn't matter if another volume contains grub configuration files. Grub will only look at the one you told it about. The idea that it chooses "both" is preposterous beyond belief. (DUH).

I notice that you still can't come up with an explanation of that statement about what belongs in /. I'm not surprised; but I'll supress my delight in arguing further and leave it at that.

[SoulofDeity]

EDITx2:
I did have further explanation of my answers here, but I'm just gonna drop it. We were talking about how you can mount root things on separate volumes. It doesn't matter how the boot loader works, it's not part of the system.

[iansjack]

Last time I checked, I didn't explicitly tell grub where my Windows partition was

Your grub configuration files are on Windows? That's quite unusual.

By this, I'm saying that you can have grub installed on multiple volumes, but only the grub.cfg on the booting partition will be used.

And how does it know which is the booting partition? (Catch 22) But you now seem to be saying that it uses only one config file, not multiple ones. That is correct; it uses the one it was told to use when you installed grub.

I really over-simplified the explanation here.

I can't disagree with that!

I say this from an experience I had once where I had installed Gentoo.

I think that you are getting confused between the location of the configuration files and the locations of the various operating systems that it boots. You're certainly very confused about something.

Edit: Oops! I see that you have now edited that post out of existence.

[cmdrcoriander]

I notice that you still can't come up with an explanation of that statement about what belongs in /. I'm not surprised; but I'll supress my delight in arguing further and leave it at that.

My comment was an opinion; I don't like the idea of making the root directory a mess for no logical reason.

And honestly a pretty reasonable one - I like that convention, not for any real reason other than it feels quite neat to me.

[SoulofDeity]

@ianjack, I changed my post shortly before you had responded. As I said before, I could explain my answers more, but I won't. I hate stretched out arguments and this has nothing to do with the original topic about how you can mount the directories in your root on separate volumes.

The point is that you can do it. It's even recommended. I'm not a GRUB expert, but frankly speaking, it's not part of the system anyhow.

[iansjack]

I hate stretched out arguments and this has nothing to do with the original topic about how you can mount the directories in your root on separate volumes.

For goodness sake! This has nothing to do with that blindingly obvious fact. I am just trying to make sense of a rather peculiar statement that you made:

the only reason anything should be in the root directory is if it can optionally be stored on a separate volume

That still makes no sense to me and you seem to be unwilling to enlighten me. Substitute "cannot" for "can" and I would agree.

[SoulofDeity]

I am just trying to make sense of a rather peculiar statement that you made:

the only reason anything should be in the root directory is if it can optionally be stored on a separate volume

That still makes no sense to me and you seem to be unwilling to enlighten me. Substitute "cannot" for "can" and I would agree.

SERIOUSLY?

The directories under root (/bin, /boot, /home, /usr, etc). Can be mounted on separate volumes, it's recommended. You said you acknowledge that, but still claim you cannot do it! That's stupid, I feel like you're just arguing with yourself at this point.

I stated that in my opinion, no one should put anything in the root directory unless it can be mounted on a separate partition because it's much cleaner, there's nothing more to explain.

[thepowersgang]

May I suggest that everyone in this thread stop for a moment and read the "Filesystem Hierarchy Standard" (http://refspecs.linuxfoundation.org/fhs.shtml), to get a solid idea on what each directory is meant to contain (and what volumes they can be on).

The gist of the original idea (which some distros are moving away from) is that /[bin,lib] contain the core binaries to boot the system into single-user mode (i.e. the admin can now perform maintenance on the system). /usr contains a similar structure to /, but contains code for general operation, and /usr/local contains machine-local (or site-local) installs of software. It makes a lot of sense when working in a networked environment, when / would be on the networked terminal, and /usr would be mounted from a read-only NFS share, and /home from another read-write NFS share.

[iansjack]

Yes. That's how I understand it. And it makes perfect sense.

[Brynet-Inc]

A reoccurring theme in this thread is using Unix and Linux interchangeably. Linux has deviated from Unix, modern Linux distributions have the kernel mount an initial memory filesystem (initramfs) as / which contains modules and utilities necessary for mounting disk partitions. OpenBSD on the other hand has no such concept outside of the installation media. With the GENERIC kernel configuration, the kernel itself handles mounting the root partition and expects /sbin/init to exist, /sbin/init exec(3)'s the /etc/rc shell script, which also expects /sbin/mount to exist. These requirements mean that for at least OpenBSD, /bin, /sbin and /etc must reside within the root partition. In fact, /bin and /sbin contain statically linked binaries.. a concept almost lost on the Linux world, which long ago moved away from them. In contrast, OpenBSD 5.7 will introduce self-relocating static PIE so that they can avoid trying to fit a runtime linker into the single-user environment, or have to deal with the unnecessary problems Linux has confounded users with.

[bluemoon]

Aside from confusion, one reason that I brought up the '/' root path was security. None of the UNIX tools question the actions of the root user, and when you don't make absolute paths explicit, you make it extremely easy to accidently destroy your filesystem by forgetting a single character.

Actually, this solves nothing and potentially could cause new kinds of trouble. Imagine if the root directory must be explicitly specified as ROOT@ and a traditional path like /home/sortie/foo would then be ROOT@home/sortie/foo. Imagine the command that deletes a directory would then be: rm -r ROOT@home/sortie/foo. Okay, so good. But like /, ROOT@ is just a magical prefix. Imagine a script that tries to delete a directory, but the variable was unset. It could then easily end up running rm -r ROOT@ by accident and deleting it all. Or imaging downloading a script, and it got truncated at the wrong location, just after the @ character. Or imaging an administrator that wants to remove ROOT@var/logs/sillyprogram/ but ends up pressing enter prematurely after entering the @. The new magical prefix doesn't solve these issues. It just changes the stuff that must be typed, but there's still a lot of unsolved dangerous cases.

I believe they think the shell (or file manager) is responsible to prevent this issue.
For instant, some shell ask for confirmation if you do rm -rf /.

Other ways to deal with this problem is ACL and sandbox. It has less to do with the name convention itself - problem exists even you have multiple root system like DOS/windows.

[Combuster]

Removing root is certainly a fix for a lot of things.

The user root