Skip to contentSkip to conversation

INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53?

DISCUSSION Thomas Meyer 3 participants 6 messages Aug 8, 2017 – Aug 9, 2017

lore
Share & tools
lore

Thomas Meyer

author
#0 lore raw

Hi,

did the commit 6e19eded3684dc184181093af3bff2ff440f5b53 break a linux kernel build with an included ramdisk?

As fas as I understand you must expliclity add rootfstype=ramfs to the kernel command line to boot from the included ramfsdisk?

bug or feature?

with kind regards
thomas

#1 lore raw

Hi Thomas,

Quoted 9 lines · Thomas Meyer

Hi,

did the commit 6e19eded3684dc184181093af3bff2ff440f5b53 break a linux kernel build with an included ramdisk?

As fas as I understand you must expliclity add rootfstype=ramfs to the kernel command line to boot from the included ramfsdisk?

bug or feature?

Strange, I'm running my kernels with the modules packaged inside the initramfs and never met this problem even after this commit (my 4.9 kernels are still packaged this way and run fine). And yes, I do have TMPFS enabled. I can't tell whether tmpfs or ramfs was used however given that at this level I don't have all the tools available to report the FS type (and proc says "rootfs"). Are you sure you're not missing anything ?

Willy

author
#2 lore raw
Quoted 11 lines · Willy Tarreau

Hi Thomas,

Quoted 8 lines · Thomas Meyer

Hi,

did the commit 6e19eded3684dc184181093af3bff2ff440f5b53 break a linux kernel build with an included ramdisk?

As fas as I understand you must expliclity add rootfstype=ramfs to the kernel command line to boot from the included ramfsdisk?

Quoted 8 lines
Quoted 1 line

bug or feature?

Strange, I'm running my kernels with the modules packaged inside the initramfs and never met this problem even after this commit (my 4.9 kernels are still packaged this way and run fine). And yes, I do have TMPFS enabled. I can't tell whether tmpfs or ramfs was used however given that at this level I don't have all the tools available to report the FS type (and proc says "rootfs"). Are you sure you're not missing anything ?

Pretty much I miss something!

I see that the embedded ramdisk is populated in populate_rootfs() without any errors.
But later it fails in mount_root -> mount_block_root with:

[   27.070000] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[   27.070000] Please append a correct "root=" boot option; here are the available partitions:
[   27.070000] DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify explicit textual name for "root=" boot option.
[   27.070000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

but adding rootfstype=ramfs seems to end up with an empty ramfs?!

any hint is welcome what I may miss here.

with kind regards
thomas

Quoted 2 lines

Willy

#3 lore raw
Quoted 26 lines · Thomas Meyer
Quoted 11 lines · Willy Tarreau

Hi Thomas,

Quoted 8 lines · Thomas Meyer

Hi,

did the commit 6e19eded3684dc184181093af3bff2ff440f5b53 break a linux kernel build with an included ramdisk?

As fas as I understand you must expliclity add rootfstype=ramfs to the kernel command line to boot from the included ramfsdisk?

Quoted 8 lines
Quoted 1 line

bug or feature?

Strange, I'm running my kernels with the modules packaged inside the initramfs and never met this problem even after this commit (my 4.9 kernels are still packaged this way and run fine). And yes, I do have TMPFS enabled. I can't tell whether tmpfs or ramfs was used however given that at this level I don't have all the tools available to report the FS type (and proc says "rootfs"). Are you sure you're not missing anything ?

Pretty much I miss something!

I see that the embedded ramdisk is populated in populate_rootfs() without any errors.
But later it fails in mount_root -> mount_block_root with:

Quoted 6 lines
[   27.070000] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[   27.070000] Please append a correct "root=" boot option; here are the available partitions:
[   27.070000] DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify explicit textual name for "root=" boot option.
[   27.070000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

but adding rootfstype=ramfs seems to end up with an empty ramfs?!

It would be nice to ensure that your initramfs is really packaged within the kernel (try to see if adding a large file to it changes the bzImage size). Maybe it's really empty and the problem happens during the build and not at boot.

Willy

#4 lore raw
In reply to Willy Tarreau
Quoted 11 lines · Willy Tarreau

Hi Thomas,

Quoted 8 lines · Thomas Meyer

Hi,

did the commit 6e19eded3684dc184181093af3bff2ff440f5b53 break a linux kernel build with an included ramdisk?

As fas as I understand you must expliclity add rootfstype=ramfs to the kernel command line to boot from the included ramfsdisk?

Quoted 8 lines
Quoted 1 line

bug or feature?

Strange, I'm running my kernels with the modules packaged inside the initramfs and never met this problem even after this commit (my 4.9 kernels are still packaged this way and run fine). And yes, I do have TMPFS enabled. I can't tell whether tmpfs or ramfs was used however given that at this level I don't have all the tools available to report the FS type (and proc says "rootfs"). Are you sure you're not missing anything ?

If your rootfs has a size= in /proc/mounts it's tmpfs, ala:

rootfs / rootfs rw,size=126564k,nr_inodes=31641 0 0

Rob

#5 lore raw
Quoted 3 lines · Rob Landley

If your rootfs has a size= in /proc/mounts it's tmpfs, ala:

rootfs / rootfs rw,size=126564k,nr_inodes=31641 0 0

You're right, I have it and thought about it. Anyway the point is that it works transparently for me. Apparently for Thomas there's an issue where his initramfs isn't properly extracted and he ends up with an empty rootfs.

Willy