# [SOLVED] kernel freezes while loading initial ramdisk.

## crocket

gentoo-sources-4.14.83 has booted very well with ZFS modules in its initial ramdisk. I need ZFS modules in initial ramdisk because the root filesystem is ZFS.

I installed gentoo-sources-4.19.23 which froze forever while loading initial ramdisk. I also installed gentoo-sources-4.14.101, but it froze while loading initial ramdisk.

I compiled 4.19.23 and 4.14.101 with gcc-7.3.0-r3 and gcc-8.2.0-r6, but the freezing issue wasn't solved by using different gcc versions.

A few times, 4.19.23 and 4.14.101 booted, but I couldn't replicate success. Now, I'm stuck with 4.14.83.

What is going on?

I used sys-kernel/dracut-049-r1 to build initial ramdisk.

/etc/fstab

```
PARTUUID="e271ef53-7377-0545-9f0e-8467fafd1202" none swap sw 0 0

PARTUUID="d5179cfd-ea96-4183-8c0b-9ffc20a9b990" none swap sw 0 0

tmpfs /var/tmp/portage tmpfs size=14G,uid=portage,gid=portage,mode=775,noatime 0 0

tmpfs /tmp tmpfs size=8G,mode=1777,noatime 0 0

PARTUUID="7e95e77c-f08c-f34d-a2d3-9d540ff191c4" /boot btrfs rw,noatime,discard 0 0

PARTUUID="17485930-4257-41fc-bc1a-5921ea09c2a4" /boot/efi vfat rw,noatime,discard 0 0
```

Last edited by crocket on Tue Feb 26, 2019 10:59 am; edited 1 time in total

----------

## NeddySeagoon

crocket,

Your bootloader loads the kernel and the initrd, then jumps to the kernel entry point.

The kernel decompesses itself, mounts your initrd as root then runs the init script it finds there.

I suspect that the bootloader is doing its thing as the kernel is loaded first.

Either its really freezing, as you say, or the kernel console isn't working, leaving you with a blank console but its otherwise working normally ... or something in between.

Please pastebin your kernel .config file, post your lspci output and tell if you are using UEFI or legacy (BIOS) mode to boot.

Oh, if you intend to use the evil binary blob nvidia-drivers, we need to know that too.

The first steps will be getting some diagnostic information, not a fix.

----------

## crocket

 *NeddySeagoon wrote:*   

> Please pastebin your kernel .config file, post your lspci output and tell if you are using UEFI or legacy (BIOS) mode to boot.
> 
> Oh, if you intend to use the evil binary blob nvidia-drivers, we need to know that too.

 

config-4.14.101-gentoo & config-4.19.23-gentoo & lspci -nnk

I use UEFI with sys-boot/grub-2.02-r3. I use radeon kernel module for Radeon HD6450.

It seems dracut produces a faulty ZFS initial ramdisk for 4.14.101 and 4.19.23. Dracut used to produce good ZFS initial ramdisks for 4.14.83 and below as long as `/etc/hostid` existed. You can produce /etc/hostid by executing zgenhostid.

I produced a new initial ramdisk by executing `genkernel initramfs --zfs` with sys-kernel/genkernerl-9999 which I compiled today.

genkernel's initial ramdisk can boot ZFS root, but it takes tens of seconds to import the root ZFS pool.

ZFS is a pain in the ass. I'd migrate to btrfs if I knew how to make btrfs report scrub errors to my email address.

----------

## NeddySeagoon

crocket,

Heres your video card.

```
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779]

   Subsystem: Tul Corporation / PowerColor Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [148c:2327]

   Kernel driver in use: radeon

   Kernel modules: radeon
```

In your kernel, turn off CONFIG_FB_VESA=y

CONFIG_FB_EFI=y is harmless.

Turn on # CONFIG_FB_SIMPLE is not set

CONFIG_FB_SIMPLE lets the kernel use the framebuffer left behind by grub for output.

The kernel will not configure it, just draw on it.

That might get us some debug information.

As you have CONFIG_DRM_RADEON=m, your framebuffer console won't start until modules can be loaded and you have said CONFIG_FRAMEBUFFER_CONSOLE=y, so you want a framebuffer console.

----------

## xdarma

 *crocket wrote:*   

> 
> 
> ZFS is a pain in the ass. I'd migrate to btrfs if I knew how to make btrfs report scrub errors to my email address.

 

There are some scripts on portage: btrfsmaintenance

Don't know if works.

----------

## crocket

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Solution !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Setting `GRUB_CMDLINE_LINUX` to `dozfs=cache` in `/etc/default/grub` and executing `grub-mkconfig -o /boot/grub/grub.cfg` fixed the issue for initial ramdisks produced by genkernel, but I will try your framebuffer improvement.

I explained the details in a github issue.

`man genkernel` explains dozfs.

Weirdly, after genkernel initial ramdisk successfully imports root zpool, dracut initial ramdisk can do it, too. I suspect dracut initial ramdisk couldn't import root zpool after kernel upgrade for some reason until genkernel initial ramdisk imported the zpool for the new kernel.Last edited by crocket on Thu Feb 28, 2019 10:44 am; edited 15 times in total

----------

## crocket

 *xdarma wrote:*   

> There are some scripts on portage: btrfsmaintenance
> 
> Don't know if works.

 

btrfsmaintenance depends on `btrfs scrub start -Bd` which is quite brittle against reboot. If a ZFS scrub was interrupted by a reboot, it would start again and report errors via ZFS event daemon. It also doesn't send scrub errors to email addresses.

 *NeddySeagoon wrote:*   

> crocket,
> 
> Heres your video card.
> 
> ```
> ...

 

I disabled CONFIG_FB_VESA and enabled CONFIG_FB_EFI and CONFIG_FB_SIMPLE. During the boot process, simple framebuffer is taken over by another framebuffer. Is it EFI framebuffer or Radeon framebuffer? I haven't enabled CONFIG_FB_RADEON, yet.

Would EFI framebuffer and Radeon framebuffer try to override each other?

----------

## NeddySeagoon

crocket,

Do not enable RADEON_FB.

The Radeon DRM driver you have selected gives you a free framebuffer. 

dmesg will show how the console is handed over.

RADEON_FB is for very old Radeon cards.  If you have a card that can use RADEON_FB, its unlikely you have a motherboard you can plug it into. :)

----------

