Ubuntu

Boot failure: FATAL: Module unknown not found (EOL)

Reported by Francisco Javier F. Serrador on 2005-09-15
32
This bug affects 2 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
High
Unassigned

Bug Description

This bug has been discovered chainloading from grub to ubuntu main partition,
which has lilo installed.

The result is that init sequence is aborted and you are droped to initrd busybox.

The sequence that appears on the screen is the following:

FATAL: Module unknown not found
mount: Mounting /dev/root on /root failed: No such device

begin: Runing /scripts/log-bottom
Done
Done
Begin: Running scripts/init-bottom
Done
mount: Mounting /root/dev on /dev/.static/dev failed: no such file or directory
mount: Mounting /dev on /root/dev
Target filesystem doesnt have /sbin/init
Busybox
/bin/sh: cant access tty
#

Created an attachment (id=3825)
Lilo configuration

This is our current lilo config.

Created an attachment (id=3826)
lspci -v information

Jeff Bailey (jbailey) wrote :

Can you try this on a fully upgraded breezy system with initramfs-tools 0.27? A
recent update makes sure that ide-generic is always loaded even if you don't
have a chipset driver, and I think that might be the problem here.

Tks,
Jeff Bailey

Probed with initramfs-tools 0.28 and the problem persists.
How can I provide you more information?

Jeff Bailey (jbailey) wrote :

Do you have time to hop onto IRC to troubleshoot this interactively with me? It
would help if you could connect from a different machine than the one with the
problems.

If yes, I'm jbailey on irc.freenode.net

Updated to linux-2.6.12-9-k7

Now I cannot see anything. All I obtain is a blank screen.

The earlier error was because lilo.conf was not properly updated. Manually
correct it and again it stops with missing modules message, returning on busybox.

Dan Stovall (dbstovall) wrote :

I am having the same problem without the chainloading from grub to lilo.
Instead I have some funky hard drive assignment problems. After running through
the install on the cd it prompts me to reboot. When grub comes up and it tries
to boot into linux I get an error that it can't find the kernel.

I have the following partition table on my HD:
NTFS (Windows XP Pro) - 9GB
JFS (Linux Root) - 4 GB
Linux Swap - 512 MB
JFS (Linux Home) - 6 GB

My hard drive is the master on my Promise UDMA100 controller. My CDROM drive is
the master on my standard ide controller. During the install from the CD grub
is installed to the MBR on hd0. However, everything in /boot/grub/menu.lst is
set for root (hd1,1). But, when I reboot my system to continue the installation
the HD on the UDMA controller is assigned hd0. I have to reboot to the CD,
mount everything and edit menu.lst and sent everything to root (hd0,1). There
is also a problem with /boot/grub/device.map. I change it from:
/dev/hde (hd1)
/dev/hdc (hd0)

to:
/dev/hde (hd0)
/dev/hdc (hd1)

When I make those changes I am able to boot to linux. But I get the same error
that has already been described.

It seems that is is unable to recognize the filesystem on my root partition.
As part of the mountroot function in that is run as part of the init script it
runs the following command:
eval $(fstype < /${root})

the fstype for root (/dev/hde2) returns:
filesytem:unknown
file size:0

later in the mount root function it tries:
modprobe $(FSTYPE}

This is when it gets the error:
FATAL: Module unknown not found

After that is unable to mount root. This is using the breezy preview.

Dan Stovall (dbstovall) wrote :

It looks like my problem may be related to these bugs 16472 and 1870.

Luca Castelluzzo (lucacastle) wrote :

I have the same problem after breezy installation on hdb5.
Is there a workaround?
Can I manually set the FS type of my root?

ThomasSpringer (sparky62366) wrote :

I've had Breezy fully installed for just a week. And now I have this same "Boot failure".

I'm using GRUB and NOT lilo.

HD Specifics -- 2 of them:
   /dev/hda1 vfat (Win Recovery)
   /dev/hda2 ntfs (Win XP)
   /dev/hdb1 ext3 Ubuntu (60 gig)
   /dev/hdb2 swap (20 gig)

I guess there's no workaround -- I could use LiveCD and attempt to save files -- but I've only had it loaded for a week. I've lost only configuration and application upgrades.

I like Ubuntu. Will this be fixed in Dapper, you think?

Marcello Foschi (xiaoma) wrote :

I have exactly the same problem booting Ubuntu.
I have Fedora GRUB on MBR and installed Ubuntu with LILO on hdb5 like Adam Conrad.

I was never able to boot Ubuntu, just installed it 2 times thinking it was a failed install first time. If solution is to upgrade the system... how can I upgrade the system if it is never booting?

I tried Kubuntu live CD and it works (but it is unusable... 5 minutes to boot a live CD is like going back to 1980...) so I don't think it is a compatibility problem with Ubuntu. Maybe the reason is Debian's vengeance against me, because I'm a YUM supporter? :-)

Any suggestion? I can access the partition from Fedora, so I can send you any configuration file if needed. Hope I will be able to try Ubuntu on my PC someday... it is the only distro I don't know...

Changed in initramfs-tools:
status: Unconfirmed → Needs Info
Marcello Foschi (xiaoma) on 2006-03-02
Changed in initramfs-tools:
status: Needs Info → Unconfirmed
tarski (guy-laffitte) wrote :

I found something nasty in file "/usr/share/initramfs-tools/scripts/functions", and a way to correct it.

1. At the end, in function "parse_numeric", replace :

    *)
        minor=$((0x${1#??}))
        major=$((0x${1%??}))

by :

    *)
        value=$((0x${1}))
        minor=$(( ${value} % 256 ))
        major=$(( ${value} / 256 ))

2. Enter commands :

  cd /boot
  sudo mkinitramfs -o initrd.new `uname -r`

3. Modify configuration file for your preferred bootloader, then let it run to install your new boot configuration.

N.B. : In rescue mode from Live CD or another Linux system still booting, steps 2 and 3 must be run after mounting the partition containing your Ubuntu system and performing a "chroot" command.

Luca Castelluzzo (lucacastle) wrote :

tarski's solution has worked for me!
I think he has fixed this bug.

Thank you tarsky.

Matt Zimmerman (mdz) wrote :

I don't see how tarski's solution could fix things for anyone; the end result is a new initramfs in /boot/initrd.new, where it will not be used by the bootloader. One would need to move the new initramfs into place for any change to take effect.

tarski, can you explain the "something nasty" you are attempting to fix with your proposed changes? They look somewhat more correct, but I don't see any case where the existing code wouldn't do the right thing already.

Luca Castelluzzo (lucacastle) wrote :

Me neither. I can't explain why, but it works now.
I've just done those three steps (modifing lilo.conf at the end) and now the boot works smoothly.

tarski (guy-laffitte) wrote :

Here is an explanation.

There are several manners to represent a disk partition.
1 ) The readable one, such as "/dev/hda3", "/dev/sdb6" or "/dev/hdc1".
2 ) With a couple of hexadecimal numbers "major" and "minor". Each of them is in range 0 .. FF . For example, "/dev/hda3" is represented by ( 3, 3), "/dev/sdb6" by ( 8, 16 ) and "/dev/hdc1" by ( 16, 1 ).
3 ) With a single hexadecimal number given by formula ( 100 * major + minor ). For example, "/dev/hda3" is represented by "303", "/dev/sdb6" by "816" and "/dev/hdc1" by "1601".

Bootloaders often use the third notation for the "root" boot parameter. the previous examples become respectively : "root=303", "root=816" and "root=1601".

The "parse_numeric" function, when given the third form of root parameter, translates it into the second one, computing "major" and "minor", to give them to a "mknod" command for entry "/dev/root".

"major" is computed by removing the last two digits and taking into account hexadecimal notation. This is always correct, since "major" is never zero for a disk partition.
"minor" is computed by removing the last first digits and taking into account hexadecimal notation. This is correct if the number has four digits, or if the number has three digits and the second digit is zero. This is FAULTY if the number has three digits and the second digit is not zero.

In summary, it works for :
  - /dev/hdaX, with X in range 1 .. 15,
  - /dev/sdaX, for all X (remember that X is in range 1 .. 15),
  - /dev/hdcX and /dev/hddX, for all X in range 1 .. 63, since major=0x16.

It FAILS for :
  - /dev/hdaX, with X in range 16 .. 63,
  - /dev/hdbX, for all X (remember that X is in range 1 .. 63),
  - /dev/sdYX, for all X in range 1 .. 15 and all Y in range 'b' .. 'p'.

My proposed solution works because I use true arithmetic instead of 'tricky computing on representation'.

N.B. : I found a simpler way of bypassing this bug. I tested it successfully. Add a "root" boot parameter in readable form, such as "root=/dev/sdb6". You can add it manually ( for example during the first reboot during system install ), or permanently in "append" field of the corresponding entry in file "lilo.conf" if you use LILO. I think there must exist an analog way for GRUB, but I don't know GRUB. That's all. "parse_numeric" will behave correctly if your disk has been correctly recognized.

   Hoping it will be useful...

tarski (guy-laffitte) wrote :

Erratum. Read :

"minor" is computed by removing the FIRST TWO digits ...

    Sorry...

Luis Villa (luis-villa) wrote :

I'm seeing the same error (up-to-date breezy, raid, etc.) but tarski's fix didn't work for me, applied against the breezy initramfs-tools. I *think* I followed all his steps religiously, but I'm not sure.

Given Marcello Foschi's "I have exactly the same problem booting Ubuntu" and Luis VIlla's "I'm seeing the same error", I think it's safe to call this confirmed.

Changed in initramfs-tools:
status: Unconfirmed → Confirmed
David McNeill (davemc) wrote :

I'm seeing the same boot failure issue, but with a slightly different setup.

Dapper 6.06 Kubuntu

SATA /dev/sda1 and /dev/sda2 have RAID 1 /dev/md0 installed with LVM on top.

The BIOS can set these to 0x80 and lilo is happy with this. Boots every time.

Added 2 x IDE drives as /dev/hda and /dev/hdc. BIOS still happy to make the SATA 80 and 81, and the new drives 82 and 83, and lilo -v2 agrees.

However when any file system is put on /dev/hda & c, the boot failure as described above occurs.

Adam Conrad (adconrad) on 2008-01-23
Changed in initramfs-tools:
assignee: adconrad → nobody

Thank you for posting this bug.

Dapper is in End of Life status. Please update and repost detailed error report.

Changed in initramfs-tools (Ubuntu):
status: Confirmed → Incomplete
Evan Peck (colors) wrote :

This bug's Ubuntu version has reached EOL.
The last real activity was in 2006.
Marking as invalid, can expire.

Thank you!

Changed in initramfs-tools (Ubuntu):
status: Incomplete → Invalid
summary: - Boot failure: FATAL: Module unknown not found
+ Boot failure: FATAL: Module unknown not found (EOL)
tags: added: dapper
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.