On Fri, 07 Jul 2006 15:23:54 +0000, dave frost wrote:

> Douglas Mayne wrote:
>> On Tue, 04 Jul 2006 10:37:32 +0000, dave frost wrote:
>>
>>> Hi all,
>>>
>>> Ive just made myself anew installation. I formatted hdb, putting my
>>> kernelse and grub etc onto hdb1, a 100Meg partition. I then put my root
>>> filesystem on hdb2, swap hdb3.
>>>
>>> The plan being to mount hdb1 under /boot
>>>
>>> my grub startup looks like
>>>
>>> kernel /linux-2.6.16 rw root=/dev/hdb2
>> -----------------------^^
>> kernel /linux-2.6.16 ro root=/dev/hdb2
>>
>>> i also used rdev to change the root device to hdb2 in the kernel.
>>
>> IME: not necessary if "arguments" are given along with the kernel, i.e.
>> root=/dev/hdb2
>>
>>> Everyhting seems to work fine until the boot scripts come to remount /
>>> read only for a filesystem check, then i get an error saying
>>>
>>> mount / : device or resource busy
>>>
>>> I assume this means a process is running ?
>>>
>>> If i ignore the error everything seems to work just fine. any ideas
>>> what the problem could be.
>>>
>>> cheers
>>> Dave
>>>
>> Note: comments inline.
>>
>> Usually, the kernel is mounted readonly until the filesystem, which allows
>> for filesystem checks to be run if necessary. What is your reason for
>> mounting read-write from the loader?

First, let me correct my mis-statement above:
Usually, the root filesystem is mounted readonly, until the kernel is
ready.

>>
> So this means that the boot scripts in i.e. /etc/rc.d must not need to
> write to the filesystem ? These ones appear to do things like
>
> for i in ls -l****** 2>/dev/null
>
> which causes problems with a read only filesystem i think, does this
> make sense ?
>
> Im planning to write my own boot scripts anyway, so basicaly first mount
> the root filesystem ro, then a e2fsck can be run on it etc, then remount
> it rw.
>
> Wouldnt it cause problems trying to mount for example /proc on a read
> only root fs ?

Apparently, /proc is an exception to the readonly rule. The mount
command for /proc is successful, I guess, because proc is a
pseudo-filesystem which indicates the state of the kernel. The state of
the kernel is dynamic. BTW, for the mount command to be successful, the
mount point /proc must exist. For example, this command fails on a
readonly filesystem:

mkdir /proc

But, this command is successful (if /proc already exists):

mount -n proc /proc -t proc

>
> cheers
>
> Dave
>
Note: comments inline.

Startup scripts are distribution dependant. The SYSV startup scripts
that are used by most distributions are complex. I don't envy your
task of reinventing all of the startup scripts. Probably, the starting
point is a thorough understanding of the jobs performed by the existing
scripts before attempting to change or replace them. Without proper
startup, your system may lack the functionality that you'd expect. One
way to visualize this is to boot using only the kernel and root
filesystem by performing a simple exercise. Try this: specify the
kernel's init process as the bash shell. (Note: init=/bin/bash can be
specified as a kernel argurment.) Once booted in that environment you'll
be able to see what a minimal system looks like. This shows what the
kernel looks like without runlevels which are managed by the standard
"init" in combination with the startup scripts. You'll see a lot is missing.

More Info
There are two "schools" of startup scripts: SYSV and BSD-style. For me, it
is easier to understand and decipher the BSD-style scripts provided by the
Slackware distribution. IME, before changing the SYSV startup scripts,
you'll need to get a "secret decoder ring"- they're too complex. So,
before jumping right in and rewriting the scripts yourself, study both
styles. Perhaps, the other "school" will be more to your liking. In
any case, the concept of an "init" process and "runlevels" are fundamental
to a unix-like OS. If you stray too far, you might end up with something
else.

--
Douglas Mayne