[SOLVED] Kernel wont boot initramfs with CONFIG_BLOCK

[Derived1964]

When I try and boot from the kernel without CONFIG_BLOCK (and all sub items), the kernel boots into the initramfs perfectly. I need the initramfs to be able to mount sata ports disks, so I had to enable CONFIG_BLOCK, and this made the kernel think it was a filesystem?

Code: Select all

[    6.621256] List of all partitions:
[    6.621490] 0100            4096 ram0 
[    6.621494]  (driver?)
[    6.621912] No filesystem could mount root, tried: 
[    6.621913] 
[    6.622302] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

I have added support for CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD, but this gives the error as above. (Without the dev ram it just lists no partitions.) I know all my configurations besides the kernel work as once I disable CONFIG_BLOCK it works perfectly, just does not have sata support. I tried launching linux with root=/dev/ram0 and giving no root, and that does not look to effect anything (besides unkown-block(1,0)/unkown-block(0,0), from my understanding just meaning the kernel knows what to boot just cant read it). The initramfs is also just a simple cpio archive with newc. I also wanted to see if this had something to do with my grub configs, so I booted it off of qemu with

Code: Select all

qemu-system-x86_64 -kernel bzImage -initrd initramfs.cpio -nographic -append "console=ttyS0"

and that gives the same problem. Here is my whole kernel config if it helps, some things might randomly be on just from me testing. This also uses https://github.com/anthraxx/linux-hardened but I dont think that should effect anything.

https://paste.gentoo.zip/WYXXDZCr

[pietinger]

Derived1964,

Welcome to Gentoo Forums !

Your kernel will not try to mount any partition IF the kernel has an initramfs ! (because it is now the job of the init script of your initramfs to mount the root partition)

This means: Something is wrong with your start of your kernel AND its associated (external) initramfs.

My questions would be:

Where is your kernel ? Where is your initramfs ? Do you boot with a bootmanager (which?) or directly with UEFI ? Do you try to boot from a USB stick ?

Maybe you want read:

UEFI starts directly a kernel with external CPIO archive: viewtopic-p-8805827.html#8805827

I have seen also:

Code: Select all

# CONFIG_CMDLINE_BOOL is not set

# CONFIG_MODULES is not set

CONFIG_EXTRA_FIRMWARE=""

CONFIG_HYPERV_STORAGE=y

Yes, I am using also a monolithic kernel. If your init of your initramfs doesnt load the CPU microcode AND some firmware (you maybe need) then you really should include them also into your kernel image.

I am using an embedded initramfs ... maybe it is interesting for you also (because monolithic kernel). This might help:
https://wiki.gentoo.org/wiki/User:Pieti ... s_Overview

THEN you dont need the solution form above and can simply do this:
https://wiki.gentoo.org/wiki/User:Pieti ... l_via_UEFI



(Your kernel .config is little bit ugly ... maybe do this both:
https://wiki.gentoo.org/wiki/User:Pieti ... ersion_6.6
https://wiki.gentoo.org/wiki/User:Pieti ... _with_KSPP)

[molletts]

I have added support for CONFIG_BLK_DEV_RAM...

You don't need CONFIG_BLK_DEV_RAM enabled if you're using an initramfs, only if you plan to use the legacy initrd support. Try just enabling the block device subsystem and leaving ramdisk support turned off - this is how I configure the systems I have which need an initramfs (either to assemble a software RAID root device or for the "offloaded updates via NBD" scheme that I use on weaker systems).

(initramfs works by unpacking a cpio archive into what is basically a tmpfs - storing the files directly in RAM without an underlying block device - whereas initrd loads a filesystem image - ext4 or whatever - into a ramdisk which then functions just like a disk partition.)

[NeddySeagoon]

Derived1964,

Welcome to Gentoo.

Boot your virtual system with whatever works and post the output of

Code: Select all

lspci -nnk

As it's a virtual system, there are two ways it can expose hardware.

1. by virtualising ancient but real hardware. This allows g7uests o run unmodified.
2. by using virtual interfaces.

The two want different drivers, so we need to know which you are using.

We may need to see both the host and guest kernel configs too, as using virtual interfaces requires host kernel support.

Using virtual interfaces requires both

Code: Select all

# CONFIG_VIRTIO_BLK is not set
# CONFIG_SCSI_VIRTIO is not set

turned on.

[Derived1964]

Where is your kernel ? Where is your initramfs ? Do you boot with a bootmanager (which?) or directly with UEFI ? Do you try to boot from a USB stick ?

Well in the end its just booting off of a usb stick, but currently I am just testing running off of a virtual matchine. I am currently not worried about actually mounting any drives in the initramfs yet. The bootmanager that I am using for testing is just the qemu default one, as I feel like I have less things that could go wrong.

I am using an embedded initramfs ... maybe it is interesting for you also (because monolithic kernel).

I tried embedding my initramfs, but I still get the exact same output as before.

Boot your virtual system with whatever works and post the output of

Code: Select all

lspci -nnk

The output of the command is

Code: Select all

00:01.0 Class 0601: 8086:7000
00:00.0 Class 0600: 8086:1237
00:01.3 Class 0680: 8086:7113 piix4_smbus
00:03.0 Class 0200: 8086:100e e1000
00:01.1 Class 0101: 8086:7010
00:02.0 Class 0300: 1234:1111 bochs-drm

I don't know if this is of any help as this is booting without CONFIG_BLOCK enabled.

When you talk about exposing hardware, I don't know if I need that yet. I currently just want to boot the initramfs, then care about accessing hard drives and such later. Am I am thinking about the initramfs wrong and I do actually need support for the hardware devices of the vm?

I tried booting off of real hardware before to see what it would give, but it was the exact same as qemu. It was easier for testing to use qemu instead of hardware.

[Derived1964]

The main confusing part for me, is that I have not tried a single configuration that had CONFIG_BLOCK enabled and worked. I tried both the arch linux default kernel configuration and the defconfig configuration (I don't remember if that configuration had CONFIG_BLOCK enabled, if it did I tried turned it on.)

I was hoping atleast one of these would work so then I could see what was different to my configuration and then work from there to get it added to my configuration.

[NeddySeagoon]

Derived1964,

You test the kernel and initrd together.
The kernel provides drivers for the hardware and the initrd will use them to access the underlying devices.

8086:7000 is a Intel 82371SB PIIX3 ISA [Natoma/Triton II chipset, as faked by QEMU
8086:1237 is a Intel 440FX - 82441FX PMC [Natoma]
8086:7113 is a Intel 82371AB/EB/MB PIIX4 ACPI, using the piix4_smbus kernel driver.
8086:100e is an intel network card using the e1000 kernel driver.
8086:7010 is a Intel PIIX/ICH chipset. In its day it was an IDE chipset. You need its driver to see any (emulated) HDD attached to it.
1234:1111 is a qemu stdvga device.

That's the hardware QEMU is exposing to the guest. The alternative is Virtio. From one of my guests.

Code: Select all

$ lspci -nnk
00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0]
	Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
00:01.0 VGA compatible controller [0300]: Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 05)
	Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
00:02.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
	Subsystem: Red Hat, Inc. QEMU PCIe Root port [1b36:0000]
	Kernel driver in use: pcieport
00:02.1 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
	Subsystem: Red Hat, Inc. QEMU PCIe Root port [1b36:0000]
	Kernel driver in use: pcieport
00:02.2 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
	Subsystem: Red Hat, Inc. QEMU PCIe Root port [1b36:0000]
	Kernel driver in use: pcieport
00:02.3 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
	Subsystem: Red Hat, Inc. QEMU PCIe Root port [1b36:0000]
	Kernel driver in use: pcieport
00:02.4 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
	Subsystem: Red Hat, Inc. QEMU PCIe Root port [1b36:0000]
	Kernel driver in use: pcieport
00:02.5 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
	Subsystem: Red Hat, Inc. QEMU PCIe Root port [1b36:0000]
	Kernel driver in use: pcieport
00:02.6 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
	Subsystem: Red Hat, Inc. QEMU PCIe Root port [1b36:0000]
	Kernel driver in use: pcieport
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
	Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9) LPC Interface Controller [8086:2918] (rev 02)
	Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] [8086:2922] (rev 02)
	Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02)
	Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
01:00.0 Ethernet controller [0200]: Red Hat, Inc. Virtio 1.0 network device [1af4:1041] (rev 01)
	Subsystem: Red Hat, Inc. Virtio 1.0 network device [1af4:1100]
	Kernel driver in use: virtio-pci
02:00.0 USB controller [0c03]: Red Hat, Inc. QEMU XHCI Host Controller [1b36:000d] (rev 01)
	Subsystem: Red Hat, Inc. QEMU XHCI Host Controller [1af4:1100]
03:00.0 Communication controller [0780]: Red Hat, Inc. Virtio 1.0 console [1af4:1043] (rev 01)
	Subsystem: Red Hat, Inc. Virtio 1.0 console [1af4:1100]
	Kernel driver in use: virtio-pci
04:00.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio 1.0 block device [1af4:1042] (rev 01)
	Subsystem: Red Hat, Inc. Virtio 1.0 block device [1af4:1100]
	Kernel driver in use: virtio-pci
05:00.0 Unclassified device [00ff]: Red Hat, Inc. Virtio 1.0 memory balloon [1af4:1045] (rev 01)
	Subsystem: Red Hat, Inc. Virtio 1.0 memory balloon [1af4:1100]
	Kernel driver in use: virtio-pci
06:00.0 Unclassified device [00ff]: Red Hat, Inc. Virtio 1.0 RNG [1af4:1044] (rev 01)
	Subsystem: Red Hat, Inc. Virtio 1.0 RNG [1af4:1100]
	Kernel driver in use: virtio-pci

Going back to your Intel PIIX/ICH chipset. it requires either

Code: Select all

# CONFIG_ATA_PIIX is not set
# CONFIG_PATA_OLDPIIX is not set

Setting both to yes is harmless.

It does not need

Code: Select all

# CONFIG_PATA_MPIIX is not set

That's for even older PIO mode only chipsets.

You don't have emulated SATA disks. They will be IDE but they will have /dev/sd... names.

Your initrd init script sould catch failures and drop you to a shell, so you can investigate, it should never allow the kernel to panic.
Please post your init script.

[Derived1964]

Your initrd init script sould catch failures and drop you to a shell, so you can investigate, it should never allow the kernel to panic.
Please post your init script.

Currently my initramfs is just busybox core utils, and the actual init script is just the busybox shell. The actual code is

Code: Select all

#!/bin/sh

/bin/sh

Doing something like chroot initramfs /sbin/init just brings you into a shell, so I feel like it should be working.

I tried adding setsid cttyhack sh to the init script but that did not look to change anything.

The interesting parts about the boot logs are this:

Code: Select all

[    0.006488] RAMDISK: [mem 0x3734d000-0x3799dfff]
...
[    3.606401] Unpacking initramfs...
...
[    3.687039] Freeing initrd memory: 6468K

I could be wrong, but I don't feel like it should be freeing the initrd memory, that is not how big the initramfs is though?

For the full boot logs they are here https://paste.gentoo.zip/hbx0ldPm , I could not find anything about running the init function in the initramfs though.

[Derived1964]

I figured out the problem, CONFIG_DEFAULT_INIT is not for the initramfs as it seems. I was putting my init script at /sbin/init and not /init. I will now change the title to have [SOLVED] in it.