Kernel 5.13.8-mvebu-tld-1 bootargs

Hello,

I followed the instructions to update to kernel 5.13.8 but booting ends in kernel panic:

VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6

It looks like bootargs are not handled over to the kernel:

Kernel command line: console=ttyS0,115200

Bute bootargs are set to
console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=armada-nand:2m(u-boot),2m(env),2m(config),15m(kernel1),110m(rootfs1),15m(kernel2),-(rootfs2) earlyprintk=serial

So the kernel seems to ignore the bootargs. Booting with kernel 4.12.4 is fine, the rootdelay=10 is applied, so the HDDs can spin up and finally boot the rootfs.

I attached the printenv output and the boot log of the kernel

ptosch,

The real problem is that your booting envs needs to be adjusted for the new kernel. Please see the instruction for newer kernel, that now we need to load uImage and uInitrd.

https://forum.doozan.com/read.php?2,88619

setenv curr_bootfrom 1
setenv next_bootfrom 1
setenv load_initrd_addr 0x2900000
setenv load_image_addr 0x02000000
setenv usb_init 'mw.l f1018100 20420000; mw.l f1018140 003E8800; sleep 3; usb start'
setenv set_bootargs_stock 'setenv bootargs "console=ttyS0,115200 ubi.mtd=4,2048 rootfstype=ubifs root=ubi0:rootfs1 rw rootdelay=2"'
setenv bootcmd_stock_1 'run set_bootargs_stock; echo Booting from NAND kernel 1 ...; nand read 0x2000000 0x00E00000 0xF00000 && bootz 0x2000000'
setenv bootcmd_stock_2 'run set_bootargs_stock; echo Booting from NAND kernel 2 ...; nand read 0x2000000 0x08700000 0xF00000 && bootz 0x2000000'
setenv usb_set_bootargs 'setenv bootargs "console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial"'
setenv usb_bootcmd 'echo Booting from USB ...; setenv fdt_skip_update yes; run usb_init; ext2load usb 0:1 $load_image_addr /boot/uImage; ext2load usb 0:1 $load_initrd_addr /boot/uInitrd; run usb_set_bootargs; bootm $load_image_addr $load_initrd_addr'
setenv bootcmd_custom 'if run usb_bootcmd; then; else if run bootcmd_stock_1; then; else run bootcmd_stock_2; reset; fi; fi'
setenv kernel_addr_1 '0x00000000; run bootcmd_custom; '
saveenv

Sorry, it is my bad. I should have kept the warning for the case when someone upgrading kernel from version before 5.2.9 to the latest.

Quote

Updated 20 Aug 2019:

Kernel linux-5.2.9-mvebu-tld-1 package has been uploaded.

New in this release:

- Keep MTD and NAND drivers as builtin kernel drivers (to overcome a mainline kernel regression for MTD and NAND).
- Pickup security patches from mainline.

Important Note for all boxes: The new kernel zImage has increased in size significantly that it will no longer work to be used in booting with the Marvell u-boot typically installed in these Armada boxes. To make it more resilient (avoid messing with u-boot envs again when the kernel image size increases), from this kernel version, we need to boot with uImage. Please see this post for an example how to adjust u-boot envs using the Thecus N2350

Thanks for bringing this problem to light! I need to update the instruction to include the upgrade warning and instruction.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hello,

thanks, these settings resolved my boot problems, I can boot with the new kernel.

Now there is a very strange thing going on: as soon as I mount my big 2.7TB partition, ext4lazyinit starts and is using sda1 very heavy for about 90 seconds

This is output of iotop:
2945 be/4 root 1102.72 K/s 0.00 B/s 0.00 % 95.78 % [ext4lazyinit]

The partiton in question is fscked and no errors occur. But every time i mount this partition ext4lazyinit starts again.

Do You have an idea what is going on?

Regards,
Peter

I found the matter [https://www.spinics.net/lists/linux-ext4/msg78855.html]:

"It's a new feature which optimizes block allocations for very large
file systems. The work being done by ext4lazyinit is to read the
block allocation bitmaps so we can cache the buddy bitmaps and how
fragmented (or not) various block groups are, which is used to
optimize the block allocator."

"To revert old behavior, the filesystem should be mounted with -o no_prefetch_block_bitmaps "

Indeed when mounting with option no_prefetch_block_bitmaps

Is it safe to use this option?:

"It is perfectly safe to use "no_prefetch_block_bitmaps" with new
optimizations. In fact file system throughput also will NOT be
affected if you mount the file system with this option. The only
impact of mounting with this mount option would be that the file
system can potentially make sub-optimal decisions for allocation
requests in certain scenarios. For example, let's say the allocator
gets a request to allocate 10 contiguous blocks and only the last
group in the file system has 10 contiguous blocks. If you mount the
file system with "no_prefetch_block_bitmaps", Ext4 will not have
cached the last group's buddy bitmap because of which it might not
know that the last group has 10 contiguous blocks available. At this
point, Ext4 will satisfy the request for 10 blocks by allocating
fragments instead of allocating a contiguous region. This might
increase the fragmentation levels of the file system. However, note
that this is not a regression. If you were not using
"prefetch_block_bitmaps" before 5.13, then this is the allocator
behavior that you would have seen anyway. So, mounting with
"no_prefetch_block_bitmaps" in your setup, would not cause any
regressions whatsoever."

So I gonna use the new feature and wont use no_prefetch_block_bitmaps.

Regards,
Peter

Peter,

Yes, that's why I recommended Ext3 for the the initial rootfs during installation.

What you should do is finalize the disk during formatting (using the option). It will take a longer (as it should be) but then you can move it to another system without worrying.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)