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
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 ?
Willy
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
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
On 08/08/2017 07:04 AM, 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 ?
If your rootfs has a size= in /proc/mounts it's tmpfs, ala:
rootfs / rootfs rw,size=126564k,nr_inodes=31641 0 0
Rob
On Tue, Aug 08, 2017 at 05:12:03PM -0500, Rob Landley wrote:
> 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