I'm trying to switch a red-hat enterprise box from booting with a ram
disk (initrd) to boot without it. And I got some problems with e2fsck.

I'm booting with lilo, if in lilo.conf I leave the kernel option for
read-only then I can see a few errors (like hwclock) reporting that
files cannot be opened or used, and then at the point that fsck will
check the file system integrity I see a log saying that fsck just
failed and then I'm presented with this sort of interactive recovery
console.

Now, if instead of read-only I change lilo.conf to read-write then the
first errors goes away, but again the fsck section fails. This time
with an error reporting that the file system is already mounted.

Now, if in /etc/rc.d/rc.sysinit I comment out the fsck check (keeping
read-write in lilo) then the system will boot successfully. In
rc.sysinit fsck is program to run as 'fsck -T -a $rootdev $fsckoptions'

Is there some help for booting without an initrd?

thanks,
Rodrigo

On Mon, 11 Sep 2006 06:34:48 -0700, ramestica wrote:

> I'm trying to switch a red-hat enterprise box from booting with a ram
> disk (initrd) to boot without it. And I got some problems with e2fsck.

Why do you want to boot without an initrd? You know, it may be doing
something important, right? One important job of the initrd is to load
kernel modules which are necessary to read filesystems and add other
drivers which aren't compiled directly into the base kernel image. This
may be a good exercise to learn about the kernel/root filesystem startup;
and hopefully, your test system is not being used by anyone else who
will be impacted if you break something while learning.

>
> I'm booting with lilo, if in lilo.conf I leave the kernel option for
> read-only then I can see a few errors (like hwclock) reporting that
> files cannot be opened or used, and then at the point that fsck will
> check the file system integrity I see a log saying that fsck just failed
> and then I'm presented with this sort of interactive recovery console.
>
AFAIK, it is best to boot with the root filesystem mounted RO (unless
there is a good reason to start RW.) The init process (or another startup
script will remount RW when it's ready.

> Now, if instead of read-only I change lilo.conf to read-write then the
> first errors goes away, but again the fsck section fails. This time with
> an error reporting that the file system is already mounted.
>
> Now, if in /etc/rc.d/rc.sysinit I comment out the fsck check (keeping
> read-write in lilo) then the system will boot successfully. In
> rc.sysinit fsck is program to run as 'fsck -T -a $rootdev $fsckoptions'
>
> Is there some help for booting without an initrd?
>
> thanks,
> Rodrigo
>
Note: comments inline.

Apparently, another option which you didn't try will work, too. If you
boot with the line commented out in rc.sysinit, then the state of the
RO/RW root filesystem option will not matter. The filesystem check is a
good idea, and for it to be performed the root filesystem may only be
mounted RO.

Are you sure you are using an ext2 filesystem. A lot of RH systems use
ext3.

--
Douglas Mayne

Hi Douglas, thanks for the reply.

Douglas Mayne wrote:
> Why do you want to boot without an initrd? You know, it may be doing
> something important, right? One important job of the initrd is to load
> kernel modules which are necessary to read filesystems and add other
> drivers which aren't compiled directly into the base kernel image. This
> may be a good exercise to learn about the kernel/root filesystem startup;
> and hopefully, your test system is not being used by anyone else who
> will be impacted if you break something while learning.

The bottom reason is a bit convoluted. I originally used grub, but the
grub gets confused when you use the vmalloc and mem kernel parameters.
Which is something I do need for this machine (custom driver for a very
specific pci data acqusition board). Then I switiched to lilo, with
which vmalloc+mem works just fine and my driver works just necely. Then
a colleague suggested me that the issue with grub could be, perhaps,
resolved by avoiding the initrd, which seems to be the cause of grub
getting 'confused' when vmalloc is specified.

This is not really a general purpose machine, we configure the machines
targeting the very particular needs of the project we work for.

Given that this is the second time I'm being asked, with somehow big
amusement, why is that I'm trying to boot without initrd, then I'm
starting to think that sticking with lilo for this machine is less
hassle than trying to align it to the rest of the grub machines in our
farm.

> AFAIK, it is best to boot with the root filesystem mounted RO (unless
> there is a good reason to start RW.) The init process (or another startup
> script will remount RW when it's ready.

I switched to read-write just because the errors I was seeing before
fsck. No special reason here.

> Note: comments inline.
>
> Apparently, another option which you didn't try will work, too. If you
> boot with the line commented out in rc.sysinit, then the state of the
> RO/RW root filesystem option will not matter. The filesystem check is a
> good idea, and for it to be performed the root filesystem may only be
> mounted RO.
>

What I do not understand is why when booting with the initrd image
(which I understand goes read-only until after fsck) I do not see the
file access errors I see when booting read-only but without initrd.

> Are you sure you are using an ext2 filesystem. A lot of RH systems use
> ext3.

Yes, this is something else I do not understand. My file systems are in
fact ext3. Therefore, I cannot understand why is that fsck in
rc.sysinit actually triggers e2fsck. In my /sbin I can see the
following related files:

/sbin/dosfsck
/sbin/e2fsck
/sbin/fsck
/sbin/fsck.cramfs
/sbin/fsck.ext2
/sbin/fsck.ext3
/sbin/fsck.msdos
/sbin/fsck.vfat

fsck is a binary file, therefore, I guess that it finds out the type of
the file system by looking into some configuration file, like fstab,
where I obviously see ext3.

thanks again,
Rodrigo

ramestica wrote:

> I'm trying to switch a red-hat enterprise box from booting with a ram
> disk (initrd) to boot without it. And I got some problems with e2fsck.

<snip>

> Is there some help for booting without an initrd?

Rebuild the kernel with all required (needed for the system) drivers into
kernel and not as modules.


--
"A personal computer is called a personal computer because it's yours,
Anything that runs on that computer, you should have control over."
Andrew Moss, Microsoft's senior director of technical policy, 2005

Hi Lenard,

>
> Rebuild the kernel with all required (needed for the system) drivers into
> kernel and not as modules.

that's what I did. Before disabling initrd I inspected the initrd file
and found that ext3 and jbd where the only module files in the image,
therefore, I configured them as built in the kernel.

It could be that I'm still missing some module, but the e2fsck problem
I get does not seem to point to that. It also happens that by disabling
the file system check in rc.sysinit allows the machine boot properly
without initrd, and this also tells me that I'm not missing some built
in kernel module. But I can be wrong.

thanks,
Rodrigo

On 11 Sep 2006 08:52:50 -0700, ramestica
<ramestica@yahoo.com> wrote:
>
>> Are you sure you are using an ext2 filesystem. A lot of RH systems use
>> ext3.
>
> Yes, this is something else I do not understand. My file systems are in
> fact ext3. Therefore, I cannot understand why is that fsck in
> rc.sysinit actually triggers e2fsck. In my /sbin I can see the
> following related files:
>
Is ext3 built into the kernel, or is it a module that is loaded by the
initrd? Normally, if the system was not shut down properly, with an
ext3 filesystem the journal is used to recover. Fsck will run after a
certain number of boots or a certain period of time, configured by
running tune2fs.


--
Politics is not the art of the possible. It consists in choosing
between the disastrous and the unpalatable.
-- John Kenneth Galbraith

On Mon, 11 Sep 2006 08:52:50 -0700, ramestica wrote:

> Hi Douglas, thanks for the reply.
>
> Douglas Mayne wrote:
>> Why do you want to boot without an initrd? You know, it may be doing
>> something important, right? One important job of the initrd is to load
>> kernel modules which are necessary to read filesystems and add other
>> drivers which aren't compiled directly into the base kernel image. This
>> may be a good exercise to learn about the kernel/root filesystem startup;
>> and hopefully, your test system is not being used by anyone else who
>> will be impacted if you break something while learning.
>
> The bottom reason is a bit convoluted. I originally used grub, but the
> grub gets confused when you use the vmalloc and mem kernel parameters.
>
I use the grub loader, and I like it better than lilo. For me, the grub
flexibility of grub means I would not switch back to lilo without a very
good reason. Out of curiosity, what error messages did grub give with
this setup? I have never used the vmalloc kernel option, and I don't know
what it is for. I would assume that grub should ignore any parameters
given as arguments on the "kernel" line, and simply feed them directly to
the kernel when control is transferred. Then again, I only have standard
hardware, and using less than the normal maximum amount of RAM for 32-bit
architecture.

Are you using any special disk contollers? I have heard of a case with the
reiserfs where the filesystem module binds to disk the controllers that
are present when the module loads. Maybe, ext3 is similar.


> Which is something I do need for this machine (custom driver for a
> very specific pci data acqusition board).
> Then I switiched to lilo, with
> which vmalloc+mem works just fine and my driver works just necely. Then
> a colleague suggested me that the issue with grub could be, perhaps,
> resolved by avoiding the initrd, which seems to be the cause of grub
> getting 'confused' when vmalloc is specified.
>
> This is not really a general purpose machine, we configure the machines
> targeting the very particular needs of the project we work for.
>
> Given that this is the second time I'm being asked, with somehow big
> amusement, why is that I'm trying to boot without initrd, then I'm
> starting to think that sticking with lilo for this machine is less
> hassle than trying to align it to the rest of the grub machines in our
> farm.
>
>> AFAIK, it is best to boot with the root filesystem mounted RO (unless
>> there is a good reason to start RW.) The init process (or another
>> startup script will remount RW when it's ready.
>
> I switched to read-write just because the errors I was seeing before
> fsck. No special reason here.
>
>> Note: comments inline.
>>
>> Apparently, another option which you didn't try will work, too. If you
>> boot with the line commented out in rc.sysinit, then the state of the
>> RO/RW root filesystem option will not matter. The filesystem check is a
>> good idea, and for it to be performed the root filesystem may only be
>> mounted RO.
>>
>>
> What I do not understand is why when booting with the initrd image
> (which I understand goes read-only until after fsck) I do not see the
> file access errors I see when booting read-only but without initrd.
>
>> Are you sure you are using an ext2 filesystem. A lot of RH systems use
>> ext3.
>
> Yes, this is something else I do not understand. My file systems are in
> fact ext3. Therefore, I cannot understand why is that fsck in rc.sysinit
> actually triggers e2fsck. In my /sbin I can see the following related
> files:
>
ext3 is a journalling layer on top of ext2, and should be backward
compatible (ext2 driver can use ext3 as ext2). I use xfs as my preferred
journalling filesystem.

>
> /sbin/dosfsck
> /sbin/e2fsck
> /sbin/fsck
> /sbin/fsck.cramfs
> /sbin/fsck.ext2
> /sbin/fsck.ext3
> /sbin/fsck.msdos
> /sbin/fsck.vfat
>
> fsck is a binary file, therefore, I guess that it finds out the type of
> the file system by looking into some configuration file, like fstab,
> where I obviously see ext3.
>
> thanks again,
> Rodrigo
>
Note: comments inline.

It sounds like your box is using a lot of RAM? Is that what the
vmalloc option is for? If you give more information about your hardware,
then that might helpful in narrowing the issue.

--
Douglas Mayne

Bill Marcum wrote:
> Is ext3 built into the kernel, or is it a module that is loaded by the
> initrd? Normally, if the system was not shut down properly, with an
> ext3 filesystem the journal is used to recover. Fsck will run after a
> certain number of boots or a certain period of time, configured by
> running tune2fs.

ext3 is built into my kernel. I changed the configuration from 'm' to
'y' (for ext3 and jbd) after finding that those 2 modules were
contained in the ram image I was using to boot the machine before
disabling initrd.

Rodrigo

In comp.os.linux.setup ramestica <ramestica@yahoo.com>:
> Hi Douglas, thanks for the reply.

> Douglas Mayne wrote:
>> Why do you want to boot without an initrd? You know, it may be doing
>> something important, right? One important job of the initrd is to load
>> kernel modules which are necessary to read filesystems and add other
>> drivers which aren't compiled directly into the base kernel image. This
>> may be a good exercise to learn about the kernel/root filesystem startup;
>> and hopefully, your test system is not being used by anyone else who
>> will be impacted if you break something while learning.

> The bottom reason is a bit convoluted. I originally used grub, but the
> grub gets confused when you use the vmalloc and mem kernel parameters.

Then use lilo, it simply rocks! Comes with RHEL, fun thing since
version 4 you can't select lilo while manual installing but it
works just fine via kickstart. I hope this will not change with
RHEL 5!

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 15: temporary routing anomaly

Douglas Mayne wrote:
> I use the grub loader, and I like it better than lilo. For me, the grub
> flexibility of grub means I would not switch back to lilo without a very
> good reason. Out of curiosity, what error messages did grub give with
> this setup? I have never used the vmalloc kernel option, and I don't know
> what it is for. I would assume that grub should ignore any parameters
> given as arguments on the "kernel" line, and simply feed them directly to
> the kernel when control is transferred. Then again, I only have standard
> hardware, and using less than the normal maximum amount of RAM for 32-bit
> architecture.

I do not quite remember the exact error logs I was getting, but while
searching for on-line help somebody at lkml.org kindly pointed me to
the following 2 links:

http://lkml.org/lkml/2005/4/4/283
http://lists.linbit.com/pipermail/dr...il/002890.html

In these links (or at least in one of them) they talk about 'tricking'
the grub with the 'uppermem' parameter. However, that trick did not
work for me. I suppose that it did not work for me due to my specific
hardware configuration. My machine has 2G bytes of ram and I boot with
the following related params:

vmalloc=384M mem=1771M

That is, I'm reserving the top ~256MB for my application, and I have
increased the default size of VmallocTotal from the default 128MB to
128+256=384MB as to not interfere when I do ioremap the top 256MB of
memory.

>
> Are you using any special disk contollers? I have heard of a case with the
> reiserfs where the filesystem module binds to disk the controllers that
> are present when the module loads. Maybe, ext3 is similar.
>

Not really, I have only one disk and it is an ide disk.

>
> It sounds like your box is using a lot of RAM? Is that what the
> vmalloc option is for? If you give more information about your hardware,
> then that might helpful in narrowing the issue.

I guess my comment above should clarify this point.

Rodrigo