bcm4708-smartrg-sr400ac boot failures in next/arm-soc

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Tyler Baker]

Hi Hauke, Rafal, Alison,

The kernelci.org bot detected a boot regression[1] in -next/arm-soc
which bisected to b02ec7658c ("ARM: multi_v7_defconfig: Enable some
drivers for LS1021A"). Reverting this patch fixes the issue I was
seeing.

After a bit of investigation, I determined that CONFIG_BLK_DEV_RAM was
causing the issue and disabling it fixed the boot issue. Essentially,
the kernel cannot find the initrd that has been loaded into memory by
CFE bootloader with this option enabled as I inject the following
command line into the DT before it's loaded over tftp.

Loaded in CFE by: 'load -raw -tftp -addr=0x4000000 -max=0x900000
192.168.2.2:tmpqC9zOv/ramdisk.cpio.gz'

Kernel arguments injected into DT: 'console=ttyS0,115200
initrd=0x4000000,8M root=/dev/ram0 ip=dhcp'

I'm wondering how we should proceed forward here. Alison, Is it a firm
requirement you need CONFIG_BLK_DEV_RAM enabled by default? Hauke,
Rafal, Is there another way to configure this platform to boot a
kernel/ramdisk without passing the initrd option on the command line?

Cheers,

Tyler

[1] http://kernelci.org/boot/bcm4708-smartrg-sr400ac/?fail

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Arnd Bergmann]

On Friday 08 January 2016 14:33:39 Tyler Baker wrote:
> Hi Hauke, Rafal, Alison,
> 
> The kernelci.org bot detected a boot regression[1] in -next/arm-soc
> which bisected to b02ec7658c ("ARM: multi_v7_defconfig: Enable some
> drivers for LS1021A"). Reverting this patch fixes the issue I was
> seeing.
> 
> After a bit of investigation, I determined that CONFIG_BLK_DEV_RAM was
> causing the issue and disabling it fixed the boot issue. Essentially,
> the kernel cannot find the initrd that has been loaded into memory by
> CFE bootloader with this option enabled as I inject the following
> command line into the DT before it's loaded over tftp.
> 
> Loaded in CFE by: 'load -raw -tftp -addr=0x4000000 -max=0x900000
> 192.168.2.2:tmpqC9zOv/ramdisk.cpio.gz'
> 
> Kernel arguments injected into DT: 'console=ttyS0,115200
> initrd=0x4000000,8M root=/dev/ram0 ip=dhcp'
> 
> I'm wondering how we should proceed forward here. Alison, Is it a firm
> requirement you need CONFIG_BLK_DEV_RAM enabled by default? Hauke,
> Rafal, Is there another way to configure this platform to boot a
> kernel/ramdisk without passing the initrd option on the command line?

I would hope that we can actually do both, and turn off CONFIG_BLK_DEV_RAM
again: Nothing should rely on that these days, we can use initramfs and
tmpfs, which are both more efficient. At the same time, the boot loader
really needs to have a way to configure the command line properly, 
and the bcm4708 machine should also not use a fixed-size ramdisk but
use initramfs instead.

	Arnd

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Russell King - ARM Linux]

On Fri, Jan 08, 2016 at 02:33:39PM -0800, Tyler Baker wrote:
> After a bit of investigation, I determined that CONFIG_BLK_DEV_RAM was
> causing the issue and disabling it fixed the boot issue. Essentially,
> the kernel cannot find the initrd that has been loaded into memory by
> CFE bootloader with this option enabled as I inject the following
> command line into the DT before it's loaded over tftp.
> 
> Loaded in CFE by: 'load -raw -tftp -addr=0x4000000 -max=0x900000
> 192.168.2.2:tmpqC9zOv/ramdisk.cpio.gz'
> 
> Kernel arguments injected into DT: 'console=ttyS0,115200
> initrd=0x4000000,8M root=/dev/ram0 ip=dhcp'

What is the problem that the kernel is reporting?

I'm asking because kernelci.org uses javascript, which is not elinks
friendly, and it otherwise means I need to walk over to a different
machine to look at it, and then return to a different machine to finish
writing the email - as a result, I hardly ever look at the kernelci.org
results, and just rely on Olof's results.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Tyler Baker]

On 8 January 2016 at 14:50, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 08, 2016 at 02:33:39PM -0800, Tyler Baker wrote:
>> After a bit of investigation, I determined that CONFIG_BLK_DEV_RAM was
>> causing the issue and disabling it fixed the boot issue. Essentially,
>> the kernel cannot find the initrd that has been loaded into memory by
>> CFE bootloader with this option enabled as I inject the following
>> command line into the DT before it's loaded over tftp.
>>
>> Loaded in CFE by: 'load -raw -tftp -addr=0x4000000 -max=0x900000
>> 192.168.2.2:tmpqC9zOv/ramdisk.cpio.gz'
>>
>> Kernel arguments injected into DT: 'console=ttyS0,115200
>> initrd=0x4000000,8M root=/dev/ram0 ip=dhcp'
>
> What is the problem that the kernel is reporting?

The kernel complaining that there is no file system to mount, and
panics. Here is a plain text version of the issue if you want to have
a look[1].

> I'm asking because kernelci.org uses javascript, which is not elinks
> friendly, and it otherwise means I need to walk over to a different
> machine to look at it, and then return to a different machine to finish
> writing the email - as a result, I hardly ever look at the kernelci.org
> results, and just rely on Olof's results.

Apologies, we are trying our best to find a happy medium for all
users, and clearly we aren't there yet. We have the ability to provide
plain text e-mail, instead of the multi-part html ones we typically
send out. If that is helpful for you at all, we can setup a hook to
send the plain text e-mails directly to you. Unfortunately, there
isn't much we can do about the javascript elink issue without
re-writing the front end :\

Cheers,

Tyler

[1]http://storage.kernelci.org/arm-soc/v4.4-rc3-1097-g80f7f7e00215/arm-multi_v7_defconfig/lab-tbaker/boot-bcm4708-smartrg-sr400ac.txt

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Russell King - ARM Linux]

On Fri, Jan 08, 2016 at 03:17:19PM -0800, Tyler Baker wrote:
> On 8 January 2016 at 14:50, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Jan 08, 2016 at 02:33:39PM -0800, Tyler Baker wrote:
> >> After a bit of investigation, I determined that CONFIG_BLK_DEV_RAM was
> >> causing the issue and disabling it fixed the boot issue. Essentially,
> >> the kernel cannot find the initrd that has been loaded into memory by
> >> CFE bootloader with this option enabled as I inject the following
> >> command line into the DT before it's loaded over tftp.
> >>
> >> Loaded in CFE by: 'load -raw -tftp -addr=0x4000000 -max=0x900000
> >> 192.168.2.2:tmpqC9zOv/ramdisk.cpio.gz'
> >>
> >> Kernel arguments injected into DT: 'console=ttyS0,115200
> >> initrd=0x4000000,8M root=/dev/ram0 ip=dhcp'
> >
> > What is the problem that the kernel is reporting?
> 
> The kernel complaining that there is no file system to mount, and
> panics. Here is a plain text version of the issue if you want to have
> a look[1].

Thanks.

The error is:

[   16.557922] RAMDISK: EOF while reading compressed data

which is not surprising given:

initrd=0x4000000,8M

is given on the kernel command line, but:

Loader:raw Filesys:tftp Dev:eth0 File:192.168.2.2:tmpd9L7xr/ramdisk.cpio.gz Options:(null)
... 8450989 bytes read

the actual ramdisk is larger than 8M.  8M would've been 8388608 bytes,
but you're about 64k over that.

Hence, the decompression into /dev/ram0 fails when BLK_DEV_RAM is
enabled (that decompressor strictly follows the initrd limit), which
then goes on to cause the failure to mount the rootfs.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Tyler Baker]

On 8 January 2016 at 15:44, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 08, 2016 at 03:17:19PM -0800, Tyler Baker wrote:
>> On 8 January 2016 at 14:50, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Jan 08, 2016 at 02:33:39PM -0800, Tyler Baker wrote:
>> >> After a bit of investigation, I determined that CONFIG_BLK_DEV_RAM was
>> >> causing the issue and disabling it fixed the boot issue. Essentially,
>> >> the kernel cannot find the initrd that has been loaded into memory by
>> >> CFE bootloader with this option enabled as I inject the following
>> >> command line into the DT before it's loaded over tftp.
>> >>
>> >> Loaded in CFE by: 'load -raw -tftp -addr=0x4000000 -max=0x900000
>> >> 192.168.2.2:tmpqC9zOv/ramdisk.cpio.gz'
>> >>
>> >> Kernel arguments injected into DT: 'console=ttyS0,115200
>> >> initrd=0x4000000,8M root=/dev/ram0 ip=dhcp'
>> >
>> > What is the problem that the kernel is reporting?
>>
>> The kernel complaining that there is no file system to mount, and
>> panics. Here is a plain text version of the issue if you want to have
>> a look[1].
>
> Thanks.
>
> The error is:
>
> [   16.557922] RAMDISK: EOF while reading compressed data
>
> which is not surprising given:
>
> initrd=0x4000000,8M
>
> is given on the kernel command line, but:
>
> Loader:raw Filesys:tftp Dev:eth0 File:192.168.2.2:tmpd9L7xr/ramdisk.cpio.gz Options:(null)
> ... 8450989 bytes read
>
> the actual ramdisk is larger than 8M.  8M would've been 8388608 bytes,
> but you're about 64k over that.

Right, this was my initial reaction when I saw this issue. I've
attempted increase initrd limit passed to the kernel, the load size in
the bootloader (10MB+) and still the same issue occurs when I do this.
I am suspicious that the CFE bootloader may have some limitation on
initrd size it will load, even though it does not complain when I
increase the size. I was hoping Hauke or Rafal might be able help us
understand a bit more here, as they are maintainers of this platform.

Cheers,

Tyler

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Russell King - ARM Linux]

On Fri, Jan 08, 2016 at 03:59:16PM -0800, Tyler Baker wrote:
> On 8 January 2016 at 15:44, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Jan 08, 2016 at 03:17:19PM -0800, Tyler Baker wrote:
> >> On 8 January 2016 at 14:50, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Jan 08, 2016 at 02:33:39PM -0800, Tyler Baker wrote:
> >> >> After a bit of investigation, I determined that CONFIG_BLK_DEV_RAM was
> >> >> causing the issue and disabling it fixed the boot issue. Essentially,
> >> >> the kernel cannot find the initrd that has been loaded into memory by
> >> >> CFE bootloader with this option enabled as I inject the following
> >> >> command line into the DT before it's loaded over tftp.
> >> >>
> >> >> Loaded in CFE by: 'load -raw -tftp -addr=0x4000000 -max=0x900000
> >> >> 192.168.2.2:tmpqC9zOv/ramdisk.cpio.gz'
> >> >>
> >> >> Kernel arguments injected into DT: 'console=ttyS0,115200
> >> >> initrd=0x4000000,8M root=/dev/ram0 ip=dhcp'
> >> >
> >> > What is the problem that the kernel is reporting?
> >>
> >> The kernel complaining that there is no file system to mount, and
> >> panics. Here is a plain text version of the issue if you want to have
> >> a look[1].
> >
> > Thanks.
> >
> > The error is:
> >
> > [   16.557922] RAMDISK: EOF while reading compressed data
> >
> > which is not surprising given:
> >
> > initrd=0x4000000,8M
> >
> > is given on the kernel command line, but:
> >
> > Loader:raw Filesys:tftp Dev:eth0 File:192.168.2.2:tmpd9L7xr/ramdisk.cpio.gz Options:(null)
> > ... 8450989 bytes read
> >
> > the actual ramdisk is larger than 8M.  8M would've been 8388608 bytes,
> > but you're about 64k over that.
> 
> Right, this was my initial reaction when I saw this issue. I've
> attempted increase initrd limit passed to the kernel, the load size in
> the bootloader (10MB+) and still the same issue occurs when I do this.

Your ramdisk is 8450989 bytes.  You're telling _the kernel_ that it is
only 8388608 bytes.  The kernel is reporting that it reached the last
byte of the 8388608 and the decompression was not complete.

You need to tell the kernel that the ramdisk is bigger.  It's not the
bootloader, it's your "initrd=0x4000000,8M" argument to the kernel that's
causing the problem.

Increase that ",8M" to the kernel.

> I am suspicious that the CFE bootloader may have some limitation on
> initrd size it will load, even though it does not complain when I
> increase the size. I was hoping Hauke or Rafal might be able help us
> understand a bit more here, as they are maintainers of this platform.

It doesn't look like a platform issue, it looks like an incorrect
kernel argument issue.  The kernel is doing exactly what you've
asked it to do!

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Tyler Baker]

On 8 January 2016 at 16:07, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 08, 2016 at 03:59:16PM -0800, Tyler Baker wrote:
>> On 8 January 2016 at 15:44, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Jan 08, 2016 at 03:17:19PM -0800, Tyler Baker wrote:
>> >> On 8 January 2016 at 14:50, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Fri, Jan 08, 2016 at 02:33:39PM -0800, Tyler Baker wrote:
>> >> >> After a bit of investigation, I determined that CONFIG_BLK_DEV_RAM was
>> >> >> causing the issue and disabling it fixed the boot issue. Essentially,
>> >> >> the kernel cannot find the initrd that has been loaded into memory by
>> >> >> CFE bootloader with this option enabled as I inject the following
>> >> >> command line into the DT before it's loaded over tftp.
>> >> >>
>> >> >> Loaded in CFE by: 'load -raw -tftp -addr=0x4000000 -max=0x900000
>> >> >> 192.168.2.2:tmpqC9zOv/ramdisk.cpio.gz'
>> >> >>
>> >> >> Kernel arguments injected into DT: 'console=ttyS0,115200
>> >> >> initrd=0x4000000,8M root=/dev/ram0 ip=dhcp'
>> >> >
>> >> > What is the problem that the kernel is reporting?
>> >>
>> >> The kernel complaining that there is no file system to mount, and
>> >> panics. Here is a plain text version of the issue if you want to have
>> >> a look[1].
>> >
>> > Thanks.
>> >
>> > The error is:
>> >
>> > [   16.557922] RAMDISK: EOF while reading compressed data
>> >
>> > which is not surprising given:
>> >
>> > initrd=0x4000000,8M
>> >
>> > is given on the kernel command line, but:
>> >
>> > Loader:raw Filesys:tftp Dev:eth0 File:192.168.2.2:tmpd9L7xr/ramdisk.cpio.gz Options:(null)
>> > ... 8450989 bytes read
>> >
>> > the actual ramdisk is larger than 8M.  8M would've been 8388608 bytes,
>> > but you're about 64k over that.
>>
>> Right, this was my initial reaction when I saw this issue. I've
>> attempted increase initrd limit passed to the kernel, the load size in
>> the bootloader (10MB+) and still the same issue occurs when I do this.
>
> Your ramdisk is 8450989 bytes.  You're telling _the kernel_ that it is
> only 8388608 bytes.  The kernel is reporting that it reached the last
> byte of the 8388608 and the decompression was not complete.
>
> You need to tell the kernel that the ramdisk is bigger.  It's not the
> bootloader, it's your "initrd=0x4000000,8M" argument to the kernel that's
> causing the problem.
>
> Increase that ",8M" to the kernel.

I agree, and in my last reply I stated I did this. To be very
specific, I used "initrd=0x4000000,10M" which still did not work. Give
me a moment to reconfigure the scripts and I'll post and updated boot
log.

Cheers,

Tyler

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Tyler Baker]

On 8 January 2016 at 16:21, Tyler Baker <tyler.baker@linaro.org> wrote:
> On 8 January 2016 at 16:07, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Fri, Jan 08, 2016 at 03:59:16PM -0800, Tyler Baker wrote:
>>> On 8 January 2016 at 15:44, Russell King - ARM Linux
>>> <linux@arm.linux.org.uk> wrote:
>>> > On Fri, Jan 08, 2016 at 03:17:19PM -0800, Tyler Baker wrote:
>>> >> On 8 January 2016 at 14:50, Russell King - ARM Linux
>>> >> <linux@arm.linux.org.uk> wrote:
>>> >> > On Fri, Jan 08, 2016 at 02:33:39PM -0800, Tyler Baker wrote:
>>> >> >> After a bit of investigation, I determined that CONFIG_BLK_DEV_RAM was
>>> >> >> causing the issue and disabling it fixed the boot issue. Essentially,
>>> >> >> the kernel cannot find the initrd that has been loaded into memory by
>>> >> >> CFE bootloader with this option enabled as I inject the following
>>> >> >> command line into the DT before it's loaded over tftp.
>>> >> >>
>>> >> >> Loaded in CFE by: 'load -raw -tftp -addr=0x4000000 -max=0x900000
>>> >> >> 192.168.2.2:tmpqC9zOv/ramdisk.cpio.gz'
>>> >> >>
>>> >> >> Kernel arguments injected into DT: 'console=ttyS0,115200
>>> >> >> initrd=0x4000000,8M root=/dev/ram0 ip=dhcp'
>>> >> >
>>> >> > What is the problem that the kernel is reporting?
>>> >>
>>> >> The kernel complaining that there is no file system to mount, and
>>> >> panics. Here is a plain text version of the issue if you want to have
>>> >> a look[1].
>>> >
>>> > Thanks.
>>> >
>>> > The error is:
>>> >
>>> > [   16.557922] RAMDISK: EOF while reading compressed data
>>> >
>>> > which is not surprising given:
>>> >
>>> > initrd=0x4000000,8M
>>> >
>>> > is given on the kernel command line, but:
>>> >
>>> > Loader:raw Filesys:tftp Dev:eth0 File:192.168.2.2:tmpd9L7xr/ramdisk.cpio.gz Options:(null)
>>> > ... 8450989 bytes read
>>> >
>>> > the actual ramdisk is larger than 8M.  8M would've been 8388608 bytes,
>>> > but you're about 64k over that.
>>>
>>> Right, this was my initial reaction when I saw this issue. I've
>>> attempted increase initrd limit passed to the kernel, the load size in
>>> the bootloader (10MB+) and still the same issue occurs when I do this.
>>
>> Your ramdisk is 8450989 bytes.  You're telling _the kernel_ that it is
>> only 8388608 bytes.  The kernel is reporting that it reached the last
>> byte of the 8388608 and the decompression was not complete.
>>
>> You need to tell the kernel that the ramdisk is bigger.  It's not the
>> bootloader, it's your "initrd=0x4000000,8M" argument to the kernel that's
>> causing the problem.
>>
>> Increase that ",8M" to the kernel.
>
> I agree, and in my last reply I stated I did this. To be very
> specific, I used "initrd=0x4000000,10M" which still did not work. Give
> me a moment to reconfigure the scripts and I'll post and updated boot
> log.

Here is the boot log when using "initrd=0x4000000,10M" [1]. Obviously,
it does resolve the 'RAMDISK: EOF while reading compressed data'
error, but still fails to mount.

Cheers,

Tyler

[1] http://people.linaro.org/~tyler.baker/bcm4708-smartrg-sr400ac-arm-soc-boot.txt

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Russell King - ARM Linux]

On Fri, Jan 08, 2016 at 04:58:05PM -0800, Tyler Baker wrote:
> On 8 January 2016 at 16:21, Tyler Baker <tyler.baker@linaro.org> wrote:
> > I agree, and in my last reply I stated I did this. To be very
> > specific, I used "initrd=0x4000000,10M" which still did not work. Give
> > me a moment to reconfigure the scripts and I'll post and updated boot
> > log.
> 
> Here is the boot log when using "initrd=0x4000000,10M" [1]. Obviously,
> it does resolve the 'RAMDISK: EOF while reading compressed data'
> error, but still fails to mount.

Okay, thanks.  Things are better - there's another change in there.
We've gone from:

[    0.156295] Trying to unpack rootfs image as initramfs...
[    0.990981] rootfs image is not initramfs (read error); looks like an initrd

note the "read error" because we hit EOF while trying to read the
initramfs, which now has become:

[    0.156226] Trying to unpack rootfs image as initramfs...
[    0.993838] rootfs image is not initramfs (junk in compressed archive); looks like an initrd

I suspect the kernel has always complained about this, the difference
is that with BLK_DEV_RAM enabled, we will clean the initial rootfs,
which will return it to a pristine state after failed initramfs unpack.

Either way, turning off BLK_DEV_RAM doesn't _actually_ fix the problem -
it merely masks that the initramfs failed to properly unpack.

This is because unpack_to_rootfs() wants to consume all the data in the
passed image, so if you say it's 10MB in size, it will want 10MB of data.
So, I think the only proper solution is to set
"initrd=0x4000000,<actual-size>" and not "something that's larger"
which will prevent unpack_to_rootfs() reporting an error.

To prove this, if you look at a successful boot log from a kernel without
BLK_DEV_RAM enabled, I suspect you'll see:

Unpacking initramfs...
Initramfs unpacking failed: junk in compressed archive

in your log, which is just another symptom of the incorrect size being
passed.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

bcm4708-smartrg-sr400ac boot failures in next/arm-soc

[Tyler Baker]

On 8 January 2016 at 17:29, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 08, 2016 at 04:58:05PM -0800, Tyler Baker wrote:
>> On 8 January 2016 at 16:21, Tyler Baker <tyler.baker@linaro.org> wrote:
>> > I agree, and in my last reply I stated I did this. To be very
>> > specific, I used "initrd=0x4000000,10M" which still did not work. Give
>> > me a moment to reconfigure the scripts and I'll post and updated boot
>> > log.
>>
>> Here is the boot log when using "initrd=0x4000000,10M" [1]. Obviously,
>> it does resolve the 'RAMDISK: EOF while reading compressed data'
>> error, but still fails to mount.
>
> Okay, thanks.  Things are better - there's another change in there.
> We've gone from:
>
> [    0.156295] Trying to unpack rootfs image as initramfs...
> [    0.990981] rootfs image is not initramfs (read error); looks like an initrd
>
> note the "read error" because we hit EOF while trying to read the
> initramfs, which now has become:
>
> [    0.156226] Trying to unpack rootfs image as initramfs...
> [    0.993838] rootfs image is not initramfs (junk in compressed archive); looks like an initrd
>
> I suspect the kernel has always complained about this, the difference
> is that with BLK_DEV_RAM enabled, we will clean the initial rootfs,
> which will return it to a pristine state after failed initramfs unpack.

I took a look at the boot logs from mainline and your suspicion is
correct, it does complain about the 'junk in compressed' archive. As
far back as I have logs, this appears to be the case.

> Either way, turning off BLK_DEV_RAM doesn't _actually_ fix the problem -
> it merely masks that the initramfs failed to properly unpack.
>
> This is because unpack_to_rootfs() wants to consume all the data in the
> passed image, so if you say it's 10MB in size, it will want 10MB of data.

I did not realize this, but it seems like very rational behavior.

> So, I think the only proper solution is to set
> "initrd=0x4000000,<actual-size>" and not "something that's larger"
> which will prevent unpack_to_rootfs() reporting an error.

Good suggestion, tomorrow I'll update my scripts to pass the actual
file size and report back.

> To prove this, if you look at a successful boot log from a kernel without
> BLK_DEV_RAM enabled, I suspect you'll see:
>
> Unpacking initramfs...
> Initramfs unpacking failed: junk in compressed archive
>
> in your log, which is just another symptom of the incorrect size being
> passed.

Thanks for the help debugging this, I appreciate it.