mkinitrd problems with kernel

Hi all, I have experiencing a very weird problem which I hope someone can help explain to me.

I currently have OpenSUSE 12.1 installed on my laptop in a multiboot with the following partitions:

  • /dev/sda1 → Windows MSR
  • /dev/sda2 → /boot/efi
  • /dev/sda3 → <something which i can’t remember>
  • /dev/sda4 → Main Windows partition
  • /dev/sda5 → swap
  • /dev/sda6 → /

The default 3.11 kernel did not suit my needs, so I built a 3.12 kernel from kernel.org using “make rpm” and installed it, then ran

mkinitrd -A -k vmlinuz-3.12.53-default -i initrd-3.12.53-default

to create a so-called monster initrd with every single module in it. Upon restarting, OpenSUSE refused to boot; the error returned near the end of the boot process is “Unable to mount /boot/efi”. Digging deeper into the logs using systemctl status boot-efi.target reveals the following:

/dev/sda2 is already mounted or /boot/efi is busy

However, when I run mkinitrd without the -A argument, i.e.:

mkinitrd -k vmlinuz-3.12.53-default -i initrd-3.12.53-default

, i get a couple of errors but an initrd img file was generated which was able to successfully boot my custom kernel.

Can someone help explain to me why the monster initrd fails and yet the minimal, default initrd boots perfectly? Is there any way I can manipulate the monster initrd to make it boot my kernel?

You could try to find out what’s going on inside your initrd by looking into it:


mkdir tmp; cd tmp
gunzip </boot/your-initrd |cpio -id

I don’t have an answer to that question. My suggest would be to comment out the line in “/etc/fstab” for “/boot/efi” and see if it boots then. The running system does not normally need “/boot/efi” except when changing/updating the boot configuration.

This would be a temporary change, to help investigate the problem.

Thanks for helping.

I tried your suggestion and I got some interesting results:

By commenting out the line containing /boot/efi in my fstab, the machine was able to boot with the monster initrd! But as a result, both swap and /boot/efi were not mounted. And running the command

mount /dev/sda2 /boot/efi

returns the same error:

/dev/sda2 is already mounted or /boot/efi is busy

Feeling that something was not quite right, I ran df and it turns out that I now have 12 (!) partitions listed:

  • /dev/mapper/-part1
  • /dev/mapper/-part2
  • /dev/mapper/-part3
  • /dev/mapper/-part4
  • /dev/mapper/-part5
  • /dev/mapper/-part6
  • /dev/dm-1
  • /dev/dm-2
  • /dev/dm-3
  • /dev/dm-4
  • /dev/dm-5
  • /dev/dm-6

I tried running

mount /dev/mapper/<long string containing HDD serial no and name>-part2 /boot/efi

and what do you know, it mounted successfully. :open_mouth:

The next thing I did was run

swapon /dev/mapper/<long string containing HDD serial no and name>-part5

and I got my swap back, but it is now labelled as /dev/dm-5 when queried using free -m. :open_mouth:

What’s going on here?

Are you using RAID?

Not at all. I’m on a single HDD.

Usually those “/dev/mapper” entries are either related to RAID or related to using encrypted partitions.

Maybe that “-A” option to “mkinitrd” causes it to do some funky RAID related stuff.

I sure am not on RAID, but i recall seeing LUKS as one of the modules that got included in the monster initrd. Could that be the reason /dev/mapper is being used?

But even if LUKS was used, my partitions are not encrypted…

Are you sure you have 12.1?

/dev/mapper/<long string containing HDD serial no and name>-part6 … Could that be the reason /dev/mapper is being used?

If you show actual content of /dev/mapper instead of “long string” someone may be able to guess further.