Bug#320091: kernel-image-2.6.8-2-386: Boot fails with a syntax error in /scripts/ext3-add-journal.sh
On Tue, Jul 26, 2005 at 11:48:20PM -0700, Dustin wrote:
> On Wed, 27 Jul 2005, Horms wrote:
>
> > On Tue, Jul 26, 2005 at 03:23:57PM -0700, Dustin Laurence wrote:
>
> > > Not finding it on the system, I mounted the initrd files and found a
> > > script named ext3-add-journal.sh, which I presume is the problem. They
>
> Something that should have hit me earlier: I have an ext3 partition, but
> the root filesystem is reiser. If root isn't mounted yet why does it want
> to mess with ext3? So one guess is perhaps it is attempting to treat a
> reiserfs partition as an ext3 partition.
If you poke around in sbin/init on the initrd image you will see that
it sources all *.sh in scripts/. So the ext3-add-journal.sh script will
be sourced, regardless of weather you are using reiser or not, and
it should have enough logic to skip a reiser partition. From a cursoary
glance that is the case and I suspec that the error you are seeing
is infact being generated inside the call to get_device() in
ext3-add-journal.sh (get_device() is defined in sbin/init.
This call takes place before the check to make sure root is
an ext3 partition (which it isn't).
However, thats just a guess, and the reiser factor may be a problem.
And I do wonder if this script should be on the initrd image at all.
Could you poke around for difference between your working initrd
image for kernel-image-2.6.8-1-386 and the broken one for
kernel-image-2.6.8-2-386?
For reference the script is here
-- begin scripts/initrd.ext3-add-journal ---
#!/bin/sh
#
# /usr/share/e2fsprogs/initrd.ext3-add-journal
#
cd /
mount -nt proc proc proc
rootdev=$(cat proc/sys/kernel/real-root-dev)
cmdline=$(cat /proc/cmdline)
umount -n proc
if [ $rootdev != 256 ]; then
mount -nt tmpfs tmpfs /dev2
get_device
roottype=`/bin/e2initrd_helper -r /dev2/root2`
if test -n "$roottype" ; then
mount -nt tmpfs tmpfs /etc
echo >> /etc/fstab
echo >> /etc/mtab
if test "$roottype" = "ext3" ; then
/sbin/tune2fs -O has_journal /dev2/root2 > /dev/null 2>&1
else
/sbin/tune2fs -O ^has_journal /dev2/root2 > /dev/null 2>&1
fi
umount -n /etc
fi
umount -n /dev2
umount -n /proc > /dev/null 2>&1
fi
-- end scripts/initrd.ext3-add-journal --
>
> > This sounds like you are seeing two problems.
>
> <nod>
>
> > Could you take a look at what modules are needed to access your root
> > partition using kernel-image-2.6.8-1-386? You should be able to
> > work this out using dmsg and lsmod. Then compare this to the modules
> > that are included in your initrd image and its /loadmodules script.
>
> If I understand what you're asking, the first hard disk module it loads is
> sata_sil and its dependencies, which from lsmod looks like just libata and
> scsi_mod.
>
> I know sata_sil is right in any case because I've built kernels by hand
> for this machine. Root is on an SATA drive.
>
> Looking at the loadmodules scripts, it is quite short in 2.6.8-1:
>
> -----------------------------------------------------------------------
> modprobe -k vesafb > /dev/null 2>&1
> modprobe -k fbcon 2> /dev/null
> modprobe -k unix 2> /dev/null
> modprobe -k sata_sil
> modprobe -k usb-storage
> modprobe -k sd_mod
> modprobe -k sr_mod
> -----------------------------------------------------------------------
>
> while it's much, much longer in 2.6.8-2:
>
> -----------------------------------------------------------------------
> modprobe -k vesafb > /dev/null 2>&1
> modprobe -k fbcon 2> /dev/null
> modprobe -k unix 2> /dev/null
> modprobe -k sata_sil
> modprobe -k usb-storage
> modprobe -k vesafb
> modprobe -k font
> modprobe -k sd_mod
> modprobe -k sr_mod
> modprobe -k ide-cd
> modprobe -k ide-generic
> modprobe -k sbp2
> modprobe -k radeon
> modprobe -k forcedeth
> modprobe -k sk98lin
> modprobe -k raw1394
> modprobe -k dv1394
> modprobe -k dm-mod
> modprobe -k ohci-hcd
> modprobe -k ehci-hcd
> modprobe -k pwc
> modprobe -k nvidia-agp
> modprobe -k usblp
> modprobe -k shpchp
> modprobe -k pciehp
> modprobe -k amd74xx
> modprobe -k rtc
> modprobe -k pcspkr
> modprobe -k evdev
> modprobe -k psmouse
> modprobe -k tsdev
> modprobe -k mousedev
> modprobe -k floppy
> modprobe -k parport_pc
> modprobe -k ide-disk
> modprobe -k lp
> modprobe -k serverworks > /dev/null 2>&1
> modprobe -k via82cxxx > /dev/null 2>&1
> modprobe -k sis5513 > /dev/null 2>&1
> modprobe -k amd74xx > /dev/null 2>&1
> modprobe -k cy82c693 > /dev/null 2>&1
> modprobe -k ns87415 > /dev/null 2>&1
> modprobe -k opti621 > /dev/null 2>&1
> modprobe -k pdc202xx_new > /dev/null 2>&1
> modprobe -k pdc202xx_old > /dev/null 2>&1
> modprobe -k atiixp > /dev/null 2>&1
> modprobe -k triflex > /dev/null 2>&1
> modprobe -k sc1200 > /dev/null 2>&1
> modprobe -k cs5520 > /dev/null 2>&1
> modprobe -k cs5530 > /dev/null 2>&1
> modprobe -k generic > /dev/null 2>&1
> modprobe -k slc90e66 > /dev/null 2>&1
> modprobe -k rz1000 > /dev/null 2>&1
> modprobe -k piix > /dev/null 2>&1
> modprobe -k cmd64x > /dev/null 2>&1
> modprobe -k hpt366 > /dev/null 2>&1
> modprobe -k hpt34x > /dev/null 2>&1
> modprobe -k alim15x3 > /dev/null 2>&1
> modprobe -k trm290 > /dev/null 2>&1
> modprobe -k aec62xx > /dev/null 2>&1
> modprobe -k siimage > /dev/null 2>&1
> -----------------------------------------------------------------------
>
> I guess this script is generated during the install (I didn't mess with
> initrd and just built in the root device drivers)? One thing that bothers
> me is that it attempts to modprobe both sata_sil and siimage (the ATA
> subsystem driver for this chipset, I know it all too well). I have vague
> memories that these two never played well together in my own kernels and I
> always had to dump one or the other (I converted a Gentoo system from ide
> and siimage to libata and sata_sil, and I once had the silly idea I could
> build a kernel that could boot either way). Maybe I just didn't know how
> to do it, but that's another random possibility.
This script is generated when your run mkinitrd image. I suspect that
your concerns about siimage are correct (I have no first hand experience
here) and that is indeed the cause of your problem. Also, almost
eveything on the longer list seems bogus - though harmless. So the
problem would seem to be mkinitrd, which is hardly a surprise - we know
that code is problematic and we are working on replacing it for etch.
Now, what to do about this?
I have two ideas.
1. try playing with /etc/mkinitrd/modules and
/etc/mkinitrd/mkinitrd.conf - the MODULES setting in particular.
Actually, just changing MODULES from most to dep might work.
2. Mount the image, copy it to a fresh directory,
trim down loadmodules, and make a fresh initrd image
using mkcramfs.
--
Horms
Reply to: