On Tue, Aug 08, 2017 at 03:18:19PM +0200, Thomas Meyer wrote: > 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?!
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
