# [Solved] Kernel doesn't get past "Loading initial ramdisk"

## IQgryn

I've had a working Gentoo system for a while, but something stopped working around the time I upgraded to kernel 4.14, and I've been unable to figure it out on my own.  Specifically, trying to boot any of the 4.14 kernels I've installed hangs immediately after displaying the "Loading initial ramdisk" message.  I'm still able to boot into 4.12.12 without problems.  I've tried searching online, but it seems like most instances of this problem are on new systems, and due to incorrect configuration somewhere.  I don't think that's the case here, since I didn't change anything (at least, not intentionally).

I've compared everything I can think to compare between the two (mostly kernel configuration), and I don't see any real differences.  I've been unable to find anything in my logs that could clue me in (and it seems like it's failing before the point that the filesystem the logs are on gets mounted).

Here's my setup -- let me know if you need any additional information:

lspci

4.12.12 kernel config (works)

4.14.11-r2 kernel config (doesn't work)

GRUB config entries

I use genkernel to create the initramfs, and I used the same command line for both:

```
genkernel --install --disklabel --lvm --no-ramdisk-modules initramfs
```

I've also tried it without --no-ramdisk-modules, with no change.

I'm mostly looking for help with getting more information about what's going wrong -- I'm not sure how to get more information out of the boot process when it fails so early and so completely like this.  I'm not able to switch to another console to get more information, and it doesn't even look like the hard drive is busy (based on the HDD activity LED).  Any help is appreciated!Last edited by IQgryn on Sun Feb 18, 2018 11:05 pm; edited 1 time in total

----------

## bunder

i've heard of a few instances where people had issues booting 4.14, but i thought they had ironed it out by the time 4.14.11 came out.  is 4.14.18 any better?

sadly, 4.14 wasn't the best of releases. 

https://archives.gentoo.org/gentoo-dev/message/3b80bb9d2791e459d9cc78e1e7b9edfa

 *Quote:*   

> Most of the above issues have resolutions already, and yes, 4.14 is
> 
> being a bit more "temperamental", sorry, it will pay off in the end...
> 
> thanks,
> ...

 

----------

## IQgryn

Oh, good to know.  I haven't tried that yet.  I'll try 4.14.18 and maybe 4.15.2 and report back.

----------

## IQgryn

I tried 4.14.18, 4.14.19, and 4.15.2.  Unfortunately, all of them behave exactly the same as 4.14.11-r2.

----------

## albright

maybe this is too obvious but did you build a kernel version

with all INITRD stuff turned off?

----------

## IQgryn

I haven't yet. I have my root filesystem on LVM -- is it possible to boot without some sort of initial filesystem? I was under the impression that root on LVM needed username tools available.

I do have /boot on a standard partition with some extra space (at least 100 mb), and I'm using GRUB 2.Last edited by IQgryn on Thu Feb 15, 2018 1:19 am; edited 1 time in total

----------

## NeddySeagoon

IQgryn,

"Loading initial ramdisk" is the last message from Grub rather than the first message from the kernel.

The first message from the kernel is Decompressing Linux ...

It follows that something is going wrong very early in the kernel startup or things are going normally but the kernel can't tell you.

To mount root inside LVM, you need LVM, mount, fsck and a few other things in the initrd.

It need only be userspace tools  if the kernel can do the rest.  

I don't know if 

```
genkernel --install --disklabel --lvm --no-ramdisk-modules initramfs
```

 works.

How does genkernel know to build the right things into the kernel?

Will it boot if you drop the --no-ramdisk-modules?

I suspect not as its failing before the initrd is mounted as root.

----------

## IQgryn

 *NeddySeagoon wrote:*   

> To mount root inside LVM, you need LVM, mount, fsck and a few other things in the initrd.
> 
> It need only be userspace tools  if the kernel can do the rest.  
> 
> I don't know if 
> ...

 

What should I use to build the initrd instead?  I've only ever used genkernel, but I'm willing to try something else.

That genkernel command line does work for 4.12.12 (I didn't change it between versions).

I tried dropping the --no-ramdisk-modules option, but there's no change in behavior (for either version).

----------

## NeddySeagoon

IQgryn,

You can make your own initrd.

You need an init script and a list of things to include.

If that's a step too far right now, try genkernel-next.

You may need to keyword it.

----------

## IQgryn

genkernel-next also didn't behave any differently.  I'll try building my own (following https://wiki.gentoo.org/wiki/Custom_Initramfs), but it may take me a few days.

I assume we're using initrd and initramfs interchangeably -- let me know if that's not the case and I should be making an initrd instead.

----------

## IQgryn

I ended up having a little more time today, so I gave it a try.  It doesn't work yet, but I've upgraded from no text to a kernel panic!

The most relevant-looking part says:

>> Booting (initramfs)

/sbin/switch_root: invalid option -- 'c'

I'm not sure where the c is coming from -- it's not in my init script in the initramfs

Here's said init script:

```
#!/bin/busybox sh

# Mount the /proc and /sys filesystems.

mount -t proc none /proc

mount -t sysfs none /sys

# Do your stuff here.

# Mount the root filesystem.

vgscan --mknodes

vgchange -a y gentoo

vgscan --mknodes

mount -o ro $(findfs UUID=79444134-fb79-4c8c-a434-1bb655582f3a) /mnt/root

# Clean up.

umount /proc

umount /sys

# Boot the real thing.

exec switch_root /mnt/root /sbin/init
```

I'll dig into it more in a few days -- I might have enough to figure out the rest on my own at this point, but I'll certainly accept an easy answer if anyone knows why the latest error is happening.

----------

## charles17

 *IQgryn wrote:*   

> 
> 
> ```
> mount -o ro $(findfs UUID=79444134-fb79-4c8c-a434-1bb655582f3a) /mnt/root
> 
> ...

 

You might want to compare 

```
# blkid | grep 79444134-fb79-4c8c-a434-1bb655582f3a
```

----------

## NeddySeagoon

IQgryn,

Pepper that script with echo statements so you can see what's going on and some sleep statements, to give you time to read the echo outputs. 

The rescue shell is a good idea too, since when it fails, you can look around.

My initrd int script may give you some idea. 

I didn't set $PATH in the initrd, so one of my problems was that no commands were actually executed.

Notice $PATH is still not set, commands use absolute paths.

The terms initrd and initramfs tesd to be used interchangably. The difference is in the detail.

An initrd is traditionally an ext2 filesystem in a file, then compressed.

An initramfs is a cpio archive of cpioarchives

To use a traditional initrd, you need kernel support for whatever filesystem is in the file. ext2 dates from the time when that's all there was so it was in the kernel for root anyway.

The kernel can deal with cpio an its own.

Both cases require kernel support for the compression.

As that wiki page makes a cpio archive, you are actually making an initramfs.

I don't make my initrd/initramfs quite like that but it looks OK.

----------

## IQgryn

With some additional poking around, I finally got things working.  Thank you all for the help and suggestions!

My final setup is as follows:

I made a custom initramfs, with just these tools:

busybox (with all symlinks installed)

lvm (with the vgscan and vgchange symlinks)

The needed libraries for lvm (found with lddtree)

Extra libraries needed in the boot process: libkmod, liblzma, and libz

A custom lvm.conf file (below)I modified the standard grub-mkconfig output to skip the root parameter (since my init script already mounts root)

I updated my init script again (below)

I removed the genkernel-generated initramfs files from /boot so grub-mkconfig would use the new ones instead

lvm.conf:

```
global {

        use_lvmetad = 0

}

activation {

        udev_sync = 0

        udev_rules = 0

}

```

init:

```
#!/bin/sh

rescue_shell() {

        echo "Something went wrong with $1. Launching rescue shell..."

        exec /bin/sh

}

# Mount the /proc and /sys filesystems.

mount -t proc none /proc || rescue_shell "Mounting /proc"

mount -t sysfs none /sys || rescue_shell "Mounting /sys"

mount -t devtmpfs none /dev || rescue_shell "Mounting /dev"

# Mount the root filesystem.

vgscan --mknodes

vgchange -a y gentoo

vgscan --mknodes

mount -o ro $(findfs UUID=79444134-fb79-4c8c-a434-1bb655582f3a) /mnt/root || rescue_shell "Mounting root"

# Clean up.

umount /proc || rescue_shell "Unmounting /proc"

umount /sys || rescue_shell "Unmounting /sys"

umount /dev || rescue_shell "Unmounting /dev"

# Boot the real thing.

exec switch_root /mnt/root /sbin/init || rescue_shell "switch_root"

```

The init script could be made more flexible, but I'm ok with updating the UUID in it if I ever need to change that.

----------

## charles17

 *IQgryn wrote:*   

> My final setup is as follows:
> 
> I made a custom initramfs, with just these tools:
> 
> busybox (with all symlinks installed)
> ...

 

For comparison, see this topic.  In my case, the only reason for using an initramfs is LVM.  And there is no lvm.conf or lib* in my /usr/src/initramfs/

----------

