Messages in this thread | | | Date | Tue, 8 Aug 2017 15:18:19 +0200 | From | Thomas Meyer <> | Subject | Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53? |
| |
On Tue, Aug 08, 2017 at 02:04:42PM +0200, Willy Tarreau wrote: > Hi Thomas, > > On Tue, Aug 08, 2017 at 01:46:25PM +0200, Thomas Meyer wrote: > > 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 ? 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 > > Willy
| |