Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752119AbdHHNSZ (ORCPT ); Tue, 8 Aug 2017 09:18:25 -0400 Received: from www17.your-server.de ([213.133.104.17]:45303 "EHLO www17.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751925AbdHHNSX (ORCPT ); Tue, 8 Aug 2017 09:18:23 -0400 Date: Tue, 8 Aug 2017 15:18:19 +0200 From: Thomas Meyer To: Willy Tarreau Cc: rob@landley.net, linux-kernel@vger.kernel.org Subject: Re: INITRAMFS_SOURCE broken by 6e19eded3684dc184181093af3bff2ff440f5b53? Message-ID: <20170808131819.GA15596@localhost.localdomain> References: <20170808114625.GA13532@localhost.localdomain> <20170808120442.GE27367@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170808120442.GE27367@1wt.eu> User-Agent: Mutt/1.8.3 (2017-05-23) X-Authenticated-Sender: thomas@m3y3r.de Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1595 Lines: 39 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