[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cubox-i does not boot after upgrade to bullseye



Am Dienstag, 28. Dezember 2021, 00:20:32 CET schrieb Vagrant Cascadian:

> I have several cubox-i systems all running bullseye, so it certainly is
> possible! I think they're all using eSATA for both /boot and rootfs,
> though I checked that one does detect /dev/mmcblk1 and relevent
> partitions for the microSD.
> 
> It *might* be possible that there are some missing modules in the
> initrd/initramfs to use mmcblk devices, but based on the above it looks
> more likely that you're not passing the initrd/initramfs at boot.
> 

I have on my second cubox-i also bullseye running, it works perfectly and 
boots from microSD.

What I noticed though: the one which does not boot has different u-boot env 
variables. The one which does not boot has seen the third distribution upgrade 
now, i.e. I think I installed there initially Debian 9.

Now the boot process looks at least different, instead of waiting for the root 
filesystem, it does not find anything:

[    3.764843] AppArmor: AppArmor sha1 policy hashing enabled
[    3.796946] vcc_3v3: supplied by v_5v0
[    3.813579] List of all partitions:
[    3.817141] No filesystem could mount root, tried:
[    3.817146]
[    3.823575] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)
[    3.831868] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.10.0-10-armmp #1 
Debian 5.10.84-1
[    3.840066] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[    3.846608] Backtrace:
[    3.849090] [<c0cf9144>] (dump_backtrace) from [<c0cf94f0>] 
(show_stack+0x20/0x24)


I did the setup which you proposed:
CuBox-i U-Boot > setenv bootargs "root=UUID=233113e0-67d1-409f-
b2c0-57bd496213de console=ttymxc0,115200 console=tty1"
CuBox-i U-Boot > printenv bootargs
bootargs=root=UUID=233113e0-67d1-409f-b2c0-57bd496213de console=ttymxc0,115200 
console=tty1
CuBox-i U-Boot > ext4ls mmc 0:1
<DIR>       4096 .
<DIR>       4096 ..
<DIR>      12288 lost+found
<SYM>         23 vmlinuz
          209257 config-4.19.0-0.bpo.5-armmp
<SYM>         43 dtb-4.19.0-0.bpo.5-armmp
          209279 config-4.19.0-17-armmp
<SYM>         23 vmlinuz.old
<SYM>         26 initrd.img.old
         4960768 vmlinuz-5.10.0-10-armmp
<DIR>       1024 dtbs
         4235776 vmlinuz-4.19.0-0.bpo.5-armmp
         3124796 System.map-4.19.0-0.bpo.5-armmp
         3145625 System.map-4.19.0-18-armmp
          209332 config-4.19.0-18-armmp
<SYM>         40 dtb-5.10.0-10-armmp
           35234 dtb-4.9.0-0.bpo.1-armmp.bak
              83 System.map-5.10.0-10-armmp
        19574146 initrd.img-4.19.0-0.bpo.5-armmp
          250465 config-5.10.0-10-armmp
        24040022 initrd.img-5.10.0-10-armmp
           34350 dtb-4.6.0-0.bpo.1-armmp.bak
         4272640 vmlinuz-4.19.0-18-armmp
           29346 dtb-3.16.0-4-armmp.bak
<SYM>         40 dtb-4.19.0-17-armmp
           34450 dtb-4.8.0-0.bpo.2-armmp.bak
           34402 dtb-4.7.0-0.bpo.1-armmp.bak
<SYM>         26 initrd.img
<SYM>         40 dtb
            3721 boot.scr
            3721 boot.scr.orig
           34233 dtb-4.5.0-0.bpo.2-armmp.bak
         4272640 vmlinuz-4.19.0-17-armmp
           35234 dtb-4.9.0-0.bpo.2-armmp.bak
         3144170 System.map-4.19.0-17-armmp
        22182359 initrd.img-4.19.0-17-armmp
<SYM>         40 dtb-4.19.0-18-armmp
        22794613 initrd.img-4.19.0-18-armmp
CuBox-i U-Boot > load mmc 0:1 ${kernel_addr_r} vmlinuz-5.10.0-10-armmp
4960768 bytes read in 377 ms (12.5 MiB/s)
CuBox-i U-Boot > load mmc 0:1 ${fdt_addr_r}  dtbs/5.10.0-10-armmp/imx6q-cubox-
i.dtb
37880 bytes read in 254 ms (145.5 KiB/s)
CuBox-i U-Boot > load mmc 0:1 ${ramdisk_addr_r}  initrd.img-5.10.0-10-armmp
24040022 bytes read in 1553 ms (14.8 MiB/s)
CuBox-i U-Boot >  bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} $
{fdt_addr_r}
Kernel image @ 0x10800000 [ 0x000000 - 0x4bb200 ]
## Flattened Device Tree blob at 18000000
   Booting using the fdt blob at 0x18000000
EHCI failed to shut down host controller.
   Using Device Tree in place at 18000000, end 1800c3f7



In order to exclude that I got something wrong with the UUID:
Does root=/dev/mmcblk0p2 also work if ext4ls mmc 0:2 shows the rootfs?

Thanks.

Rainer


-- 
Rainer Dorsch
http://bokomoko.de/



Reply to: