mountpoint not existent, droping to single user mode

[Polytropon]

On Sat, 21 Aug 2010 23:12:03 +0200, claudiu vasadi <claudiu.vasadi at gmail.com> wrote:
> What happened when a "secondary" hdd cannot be mounted at boot ? From
> experience I know the OS drops to single user mode, which I find incredibly
> stupid because a "non-OS" hdd should not stop the OS from booting up
> (imagine the hdd has a malfunction and then you get lucky enough to get a
> power surge - the OS won't come up because of a darn non-OS-important hdd).

The OS does not know about how you are intending to use a hard disk.
It just knows that /etc/fstab retuires (!) the mounting of a certain
partition at boot time. If this fails, the boot process will NOT
go on.

An example: Let's say you have a mountpoint /foo on the / partition.
This partition has 200 MB free space. The mountpoint /foo will usually
be used for the /dev/da0 disk. After boot, a program will periodically
output data to /foo, and will soon produce several GB of data within
short time. Now assume the system comes up, /dev/da0 not present, okay,
don't mind. Result: Soon / will be full. Problem.

A similar situation happens if a mountpoint that /etc/fstab requires (!)
to be present is NOT present. To the OS, this is a problematic situation
as it requires operator decision.



> TEST scenario:
> 2 hdd's. The system is installed on the first one, and the second one has
> "/mnt/2" as mountpoin. The 2nd disk was labeled and a new ufs partition was
> created. I added the corresponding fstab entries and then I deliberately
> removed the "/mnt/2" folder.

Directory. :-)



> FYI: this "secondary" hdd has no data on it whatsoever.

The OS does not know that.



> Then I rebooted and of course the system went in single user mode. And now
> my question: "WHY????" (I know that "rc" finishes abnormally)

A solution would be to code "noauto" for this mount in /etc/fstab,
and then add a custom mount call in /etc/rc.local which can check
both the existance of the device and the mountpoint. You could also
just ignore the errors, because (as far as I remember) a failing
operation in rc.local won't stop the system to fully come up.



> The hdd has no relevant data on it, the OS has no files on it ... basically
> it does not get in the way of anything (except the perfect execution of the
> "rc" framework).

Then mount manually after boot.



> Anyway, it seems to me that "secondary" hdd's mount failure should be
> "ignored" and an OS should be able to come up if one mountpoint does not
> exist or if an entry in fstab is wrong (again, I am talking about non-OS
> related hdd/mountpoints).

I'm not sure how the OS should be able to decide about that, what's
an "OS mount" and what's a "non-OS mount".



> To make things worst, I tested a RHEL5 and the system booted without any
> problems even if the "secondary" hdd's mp was missing.

I won't elaborate on why Linux behaviour is not a reference point for
different operating systems. :-)



> Can someone explain this "weird?" behavior ?

Intended behaviour - PREDICTABLE and SECURE.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...