lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 18 Nov 2017 10:44:52 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Richard Schmitt <rschmitt@...epeach.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Cannot boot with rootfs from eMMC if maxcpus=1

On 11/09/2017 08:14 AM, Richard Schmitt wrote:
> Using a 4.9 kernel, trying to boot a kernel using an eMMC based rootfs will result in a crash
> 
> The message preceeding the crash is:
> 
> [    3.285566] VFS: Cannot open root device "mmcblk0p9" or unknown-block(0,0): error -6
> [    3.293338] Please append a correct "root=" boot option; here are the available partitions:
> 
> Our kernel boot args can be seen in the boot log but for easy reference are:
> 
>  root=/dev/mmcblk0p9 earlycon clk_ignore_unused cpuidle.off=1 DEBUG_MODE=y siq_board_type=RP maxcpus=1
> 
> Note that we do specify root=/dev/mmcblk0p9.  If I simply remove maxcpus=1 from the kernel boot args, the system will boot up fine.
> 
> Seems like there might be a race in bringing up the eMMC partitions prior to mounting the rootfs but I don’t want to hypothesis any further.
> 
> Any ideas?

If you suspect a timing issue, an easy test would be to add to the kernel
boot/command line either:
  rootwait
or
  rootdelay=10
(in seconds) to see if that helps.


or send email to linux-arm-kernel@...ts.infradead.org ...

-- 
~Randy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ