Hi,

I upgraded a cubox-i from buster to bullseye. The upgrade went through without any issues. But after the upgrade the system does not boot anymore. The output of the serial console is below. The boot process hangs at

[ 3.816424] Waiting for root device /dev/mmcblk1p2...

Did the device enumeration change?

How would I find out the new device name and how would I change the boot parameters (which apparently specifies /dev/mmcblk1p2 according to the output below)?

Many thanks
Rainer

Willkommen zu minicom 2.8

Optionen: I18n
Port /dev/ttyUSB0, 15:10:16

Drücken Sie CTRL-A Z für Hilfe zu speziellen Tasten

U-Boot SPL 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43)


U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43)

CPU: Freescale i.MX6Q rev1.2 at 792 MHz
Reset cause: POR
Board: MX6-CuBox-i
DRAM: 2 GiB
MMC: FSL_SDHC: 0
*** Warning - bad CRC, using default environment

In: serial
Out: vga
Err: vga
Net: Phy not found
PHY reset timed out
FEC [PRIME]
(Re)start USB...
USB0: Port not available.
USB1: USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
** File not found uEnv.txt **
3721 bytes read in 159 ms (22.5 KiB/s)
Running bootscript from mmc ...
## Executing script at 10800000
4960768 bytes read in 378 ms (12.5 MiB/s)
37880 bytes read in 254 ms (145.5 KiB/s)
24040022 bytes read in 1551 ms (14.8 MiB/s)
Booting Debian 5.10.0-10-armmp from mmc 0:1...
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

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.10.0-10-armmp (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian )
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: SolidRun Cubox-i Dual/Quad
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 16 MiB at 0x8f000000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000010000000-0x000000003fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000040000000-0x000000008fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x000000008fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000008fffffff] [ 0.000000] percpu: Embedded 21 pages/cpu s54604 r8192 d23220 u86016
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 522560
[ 0.000000] Kernel command line: console=ttymxc0,115200 enable_wait_mode=off root=/dev/mmcblk1p2 rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 0.000000] Memory: 2018148K/2097152K available (11264K kernel code, 1668K rwdata, 3192K rodata, 2048K init, 337K bss, 62620K reserved, 16384K cma- reserved, 1294336K highmem)
[ 0.000000] random: get_random_u32 called from __kmem_cache_create+0x30/0x450 with crng_init=0
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 37402 entries in 110 pages
[ 0.000000] ftrace: allocated 110 pages with 5 groups
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[ 0.000000] Rude variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C: DT/platform modifies aux control register: 0x32070000 -> 0x32470000
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[ 0.000000] Switching to timer-based delay loop, resolution 333ns
[ 0.000007] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 715827882841ns
[ 0.000028] clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 637086815595 ns
[ 0.002979] Console: colour dummy device 80x30
[ 0.003593] printk: console [tty1] enabled
[ 0.003655] Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=12000)
[ 0.003694] pid_max: default: 32768 minimum: 301
[ 0.004052] LSM: Security Framework initializing
[ 0.004171] Yama: disabled by default; enable with sysctl kernel.yama.*
[ 0.004341] AppArmor: AppArmor initialized
[ 0.004371] TOMOYO Linux initialized
[ 0.004484] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.004516] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.005789] CPU: Testing write buffer coherency: ok
[ 0.005848] CPU0: Spectre v2: using BPIALL workaround
[ 0.006190] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.007297] Setting up static identity map for 0x10300000 - 0x103000ac
[ 0.008670] rcu: Hierarchical SRCU implementation.
[ 0.011192] EFI services will not be available.
[ 0.011783] smp: Bringing up secondary CPUs ...
[ 0.012747] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.012757] CPU1: Spectre v2: using BPIALL workaround
[ 0.013909] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.013918] CPU2: Spectre v2: using BPIALL workaround
[ 0.015045] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.015054] CPU3: Spectre v2: using BPIALL workaround
[ 0.015277] smp: Brought up 1 node, 4 CPUs
[ 0.015307] SMP: Total of 4 processors activated (24.00 BogoMIPS).
[ 0.015327] CPU: All CPU(s) started in SVC mode.
[ 0.016170] devtmpfs: initialized
[ 0.026237] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.026594] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.026675] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[ 0.028030] pinctrl core: initialized pinctrl subsystem
[ 0.029349] DMI not present or invalid.
[ 0.029784] NET: Registered protocol family 16
[ 0.033245] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.034239] audit: initializing netlink subsys (disabled)
[ 0.035469] audit: type=2000 audit(0.032:1): state=initialized audit_enabled=0 res=1
[ 0.036020] thermal_sys: Registered thermal governor 'fair_share'
[ 0.036028] thermal_sys: Registered thermal governor 'bang_bang'
[ 0.036055] thermal_sys: Registered thermal governor 'step_wise'
[ 0.036076] thermal_sys: Registered thermal governor 'user_space'
[ 0.036098] thermal_sys: Registered thermal governor 'power_allocator'
[ 0.036451] CPU identified as i.MX6Q, silicon rev 1.2
[ 0.473504] No ATAGs?
[ 0.473740] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[ 0.473770] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.475560] debugfs: Directory 'dummy-iomuxc-gpr@20e0000' with parent 'regmap' already present!
[ 0.475909] imx6q-pinctrl 20e0000.pinctrl: initialized IMX pinctrl driver
[ 0.477615] Serial: AMBA PL011 UART driver
[ 0.485778] Kprobes globally optimized
[ 2.201066] mxs-dma 110000.dma-apbh: initialized
[ 2.202659] reg-fixed-voltage regulator-vcc-3v3: Failed to register regulator: -517
[ 2.205516] iommu: Default domain type: Translated
[ 2.206730] vgaarb: loaded
[ 2.207922] mc: Linux media interface: v0.10
[ 2.207988] videodev: Linux video capture interface: v2.00
[ 2.209836] NetLabel: Initializing
[ 2.209863] NetLabel: domain hash size = 128
[ 2.209882] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 2.209988] NetLabel: unlabeled traffic allowed by default
[ 2.210442] clocksource: Switched to clocksource mxc_timer1
[ 2.295706] VFS: Disk quotas dquot_6.6.0
[ 2.295852] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 2.296714] AppArmor: AppArmor Filesystem Enabled
[ 2.309370] NET: Registered protocol family 2
[ 2.309610] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
[ 2.311244] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[ 2.311323] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 2.311450] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 2.311597] TCP: Hash tables configured (established 8192 bind 8192)
[ 2.311780] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 2.311848] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 2.312418] NET: Registered protocol family 1
[ 2.312485] NET: Registered protocol family 44
[ 2.312519] PCI: CLS 0 bytes, default 64
[ 2.313122] Trying to unpack rootfs image as initramfs...
[ 2.313168] Initramfs unpacking failed: invalid magic at start of compressed archive
[ 2.338783] Freeing initrd memory: 23480K
[ 2.339252] hw perfevents: no interrupt-affinity property for /pmu, guessing.
[ 2.339594] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
[ 2.342665] Initialise system trusted keyrings
[ 2.342735] Key type blacklist registered
[ 2.342974] workingset: timestamp_bits=14 max_order=19 bucket_order=5
[ 2.350594] zbud: loaded
[ 2.351837] integrity: Platform Keyring initialized
[ 2.351874] Key type asymmetric registered
[ 2.351895] Asymmetric key parser 'x509' registered
[ 2.352115] bounce: pool size: 64 pages
[ 2.352225] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[ 2.352533] io scheduler mq-deadline registered
[ 2.372506] imx-sdma 20ec000.sdma: firmware: failed to load imx/sdma/sdma- imx6q.bin (-2)
[ 2.372549] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 2.372580] imx-sdma 20ec000.sdma: Direct firmware load for imx/sdma/sdma- imx6q.bin failed with error -2
[ 2.380075] Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled
[ 2.383596] Serial: AMBA driver
[ 2.384467] 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 33, base_baud = 5000000) is a IMX
[ 3.219595] printk: console [ttymxc0] enabled
[ 3.225606] 21f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 73, base_baud = 5000000) is a IMX
[ 3.236767] STM32 USART driver initialized
[ 3.244310] libphy: Fixed MDIO Bus: probed
[ 3.250265] mousedev: PS/2 mouse device common for all mice
[ 3.259042] snvs_rtc 20cc000.snvs:snvs-rtc-lp: registered as rtc0
[ 3.265218] snvs_rtc 20cc000.snvs:snvs-rtc-lp: setting system clock to 1970-01-01T00:00:00 UTC (0)
[ 3.279643] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.287804] NET: Registered protocol family 10
[ 3.300693] Segment Routing with IPv6
[ 3.304517] mip6: Mobile IPv6
[ 3.307540] NET: Registered protocol family 17
[ 3.312183] mpls_gso: MPLS GSO support
[ 3.316513] ThumbEE CPU extension supported.
[ 3.320901] Registering SWP/SWPB emulation handler
[ 3.325901] registered taskstats version 1
[ 3.330079] Loading compiled-in X.509 certificates
[ 3.730024] Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[ 3.738901] Loaded X.509 cert 'Debian Secure Boot Signer 2021 - linux: 4b6ef5abca669825178e052c84667ccbc0531f8c'
[ 3.749264] zswap: loaded using pool lzo/zbud
[ 3.754495] Key type ._fscrypt registered
[ 3.758548] Key type .fscrypt registered
[ 3.762500] Key type fscrypt-provisioning registered
[ 3.767697] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.799782] vcc_3v3: supplied by v_5v0
[ 3.816424] Waiting for root device /dev/mmcblk1p2...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Montag, 27. Dezember 2021, 15:26:33 CET schrieb Rainer Dorsch:

Hi,

I upgraded a cubox-i from buster to bullseye. The upgrade went through without any issues. But after the upgrade the system does not boot anymore. The output of the serial console is below. The boot process hangs at

[ 3.816424] Waiting for root device /dev/mmcblk1p2...

Did the device enumeration change?

How would I find out the new device name and how would I change the boot parameters (which apparently specifies /dev/mmcblk1p2 according to the
output below)?

I tried to get an initramfs shell to better debug, but failed:

I understood from

https://wiki.debian.org/InitramfsDebug

that I should add

break=mountroot

as kernel parameter.

Then from

https://wiki.debian.org/U-boot

I understand that I can add the kernel parameters by

setenv bootargs ${bootargs} break=mountroot
boot

u-boot passes the parameter

[ 0.000000] Kernel command line: break=mountroot console=ttymxc0,115200 enable_wait_mode=off root=/dev/mmcblk1p2 rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1

but the kernel seems to ignore the parameter and ends up again in

[ 3.818950] Waiting for root device /dev/mmcblk1p2...



Even if I copy the example literally,

setenv bootargs ${bootargs} init=/bin/bash
boot

u-boot passes the parameters

init=/bin/bash console=ttymxc0,115200 enable_wait_mode=off root=/dev/mmcblk1p2 rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1

but the kernel seems to ignore the parameter and ends up again in

[ 3.818950] Waiting for root device /dev/mmcblk1p2...


Any hint or advise how I get a debug shell is welcome.

Thanks
Rainer

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-12-27, Rainer Dorsch wrote:

I upgraded a cubox-i from buster to bullseye. The upgrade went through without
any issues. But after the upgrade the system does not boot anymore. The output
of the serial console is below. The boot process hangs at

[ 3.816424] Waiting for root device /dev/mmcblk1p2...

Did the device enumeration change?

Very likely; it is not promised to remain constant even between boots
with the same kernel, unfortunately!

You really want to use root=UUID=abcde-12345... or partition labels, or anything that isn't going to have surprise changes...

How would I find out the new device name and how would I change the boot parameters (which apparently specifies /dev/mmcblk1p2 according to the output
below)?

If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
or:

lsblk --fs /dev/DEVICE

It might be possible to discover from u-boot as well, but I forget off
the top of my head.


Once you have the UUID, try passing root=UUID=$uuid in bootparams
instead of root=/dev/mmcblk...


live well,
vagrant

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYcn2ZgAKCRDcUY/If5cW qn6aAP4z6UlHIw6NTq5TOqphqVJkjmeO+A1+5tHqy7s2sWmZlwEAnd3lUPu+h+7e x4cIysHVWCGGD6Pt4CasSsi8r6FugQs=WFd9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks for your quick reply Vagrant.

Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:

On 2021-12-27, Rainer Dorsch wrote:

I upgraded a cubox-i from buster to bullseye. The upgrade went through without any issues. But after the upgrade the system does not boot
anymore. The output of the serial console is below. The boot process
hangs at

[ 3.816424] Waiting for root device /dev/mmcblk1p2...

Did the device enumeration change?

Very likely; it is not promised to remain constant even between boots
with the same kernel, unfortunately!

Wow. I installed bullseye on a second cubox-i and there I get

You really want to use root=UUID=abcde-12345... or partition labels, or anything that isn't going to have surprise changes...

Makes perfect sense.

How would I find out the new device name and how would I change the boot parameters (which apparently specifies /dev/mmcblk1p2 according to the output below)?

If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
or:

lsblk --fs /dev/DEVICE

It might be possible to discover from u-boot as well, but I forget off
the top of my head.

I realized that ext4ls uses dev 0 for the root filesystem

CuBox-i U-Boot > ext4ls mmc 0:2 /
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 16384 lost+found
<DIR> 4096 boot
<DIR> 12288 etc
<DIR> 4096 media
<DIR> 4096 var
<DIR> 4096 usr
<DIR> 4096 bin
<DIR> 4096 lib
<DIR> 176128 tmp
<DIR> 4096 sys
<DIR> 12288 sbin
<DIR> 4096 run
<DIR> 4096 root
<DIR> 4096 proc
<DIR> 4096 home
<DIR> 4096 dev
<DIR> 4096 mnt
<DIR> 4096 srv
<DIR> 4096 opt
CuBox-i U-Boot >

also mmcroot implies dev 0

mmcroot=/dev/mmcblk0p2 rootwait rw

but u-env tries to mount device 1:

Waiting for root device /dev/mmcblk1p2


But figuring out the uuid should also be not problem.

Once you have the UUID, try passing root=UUID=$uuid in bootparams
instead of root=/dev/mmcblk...

Here I am stuck:
- I do not find any reference to bootparam in udev or boot.scr
- In boot.scr I see an unconditional assignment

setenv bootargs " ${bootargs} enable_wait_mode=off root=/dev/mmcblk1p2 rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1"

(for reference https://paste.debian.net/1224931/ )

i.e. I see no way to overwrite root there.

Is there a way to modify boot.scr itself?

Thanks
Rainer

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Montag, 27. Dezember 2021, 19:34:36 CET schrieb Rainer Dorsch:

Thanks for your quick reply Vagrant.

Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:

On 2021-12-27, Rainer Dorsch wrote:

I upgraded a cubox-i from buster to bullseye. The upgrade went through without any issues. But after the upgrade the system does not boot anymore. The output of the serial console is below. The boot process hangs at

[ 3.816424] Waiting for root device /dev/mmcblk1p2...

Did the device enumeration change?

Very likely; it is not promised to remain constant even between boots
with the same kernel, unfortunately!

Wow. I installed bullseye on a second cubox-i and there I get

You really want to use root=UUID=abcde-12345... or partition labels, or anything that isn't going to have surprise changes...

Makes perfect sense.

How would I find out the new device name and how would I change the boot parameters (which apparently specifies /dev/mmcblk1p2 according to the output below)?

If you can insert the microSD into another Debian machine, you can get the UUID by looking in /dev/disk/by-uuid/ to find the matching device

or:
lsblk --fs /dev/DEVICE

It might be possible to discover from u-boot as well, but I forget off
the top of my head.

I realized that ext4ls uses dev 0 for the root filesystem

CuBox-i U-Boot > ext4ls mmc 0:2 /
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 16384 lost+found
<DIR> 4096 boot
<DIR> 12288 etc
<DIR> 4096 media
<DIR> 4096 var
<DIR> 4096 usr
<DIR> 4096 bin
<DIR> 4096 lib
<DIR> 176128 tmp
<DIR> 4096 sys
<DIR> 12288 sbin
<DIR> 4096 run
<DIR> 4096 root
<DIR> 4096 proc
<DIR> 4096 home
<DIR> 4096 dev
<DIR> 4096 mnt
<DIR> 4096 srv
<DIR> 4096 opt
CuBox-i U-Boot >

also mmcroot implies dev 0

mmcroot=/dev/mmcblk0p2 rootwait rw

but u-env tries to mount device 1:

Waiting for root device /dev/mmcblk1p2

But figuring out the uuid should also be not problem.

Once you have the UUID, try passing root=UUID=$uuid in bootparams
instead of root=/dev/mmcblk...

Here I am stuck:
- I do not find any reference to bootparam in udev or boot.scr
- In boot.scr I see an unconditional assignment

setenv bootargs " ${bootargs} enable_wait_mode=off root=/dev/mmcblk1p2 rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1"

(for reference https://paste.debian.net/1224931/ )

i.e. I see no way to overwrite root there.

Is there a way to modify boot.scr itself?

Is it safe to use the boot.scr from a second device with

rd@h370:~$ diff -u /tmp/boot.cmd ~/tmp.nobackup/boot.cmd
--- /tmp/boot.cmd 2021-12-27 19:43:58.174529197 +0100
+++ /home/rd/tmp.nobackup/boot.cmd 2021-12-27 19:57:22.144927257 +0100
@@ -72,7 +72,7 @@
setenv bootargs "${bootargs} console=${console}"
fi

-setenv bootargs " ${bootargs} enable_wait_mode=off root=/dev/mmcblk1p2 rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1"
+setenv bootargs " ${bootargs} quiet"


if test -z "${fk_kvers}"; then
rd@h370:~$

Where boot.cmd was generated by

dd if=/boot/boot.scr bs=72 skip=1 of=/tmp/boot.cmd

?

Or are there some device specific addresses encoded in the first 72 bytes?

Thanks
Rainer

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:

Very likely; it is not promised to remain constant even between boots
with the same kernel, unfortunately!

You really want to use root=UUID=abcde-12345... or partition labels, or anything that isn't going to have surprise changes...

Hmm...I think the problem is something different.

I inserted the SDcard in a different Linux-System and I extracted the UUID:

root@h370:~# lsblk --fs /dev/sdc2
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sdc2 ext4 1.0 233113e0-67d1-409f-b2c0-57bd496213de
root@h370:~#


I manually loaded now the kernel in uboot (does the manual sequence look reasonable?):

CuBox-i U-Boot > mmc dev ${mmcdev};
switch to partitions #0, OK
mmc0 is current device
CuBox-i U-Boot > mmc rescan
CuBox-i U-Boot > load mmc 0:1 0x10800000 vmlinuz-5.10.0-10-armmp
4960768 bytes read in 380 ms (12.4 MiB/s)
CuBox-i U-Boot > load mmc 0:1 0x18000000 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 0x11800000 initrd.img-5.10.0-10-armmp
24040022 bytes read in 1551 ms (14.8 MiB/s)
CuBox-i U-Boot > setenv bootargs " ${bootargs} enable_wait_mode=off root=UUID=233113e0-67d1-409f-b2c0-57bd496213de rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1 break"
CuBox-i U-Boot > printenv bootargs
bootargs= enable_wait_mode=off root=UUID=233113e0-67d1-409f-b2c0-57bd496213de rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1 break CuBox-i U-Boot > bootz 0x10800000 0x11800000: 0x18000000
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

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.10.0-10-armmp (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.84-1 (2021-12-08)
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7),
cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: SolidRun Cubox-i Dual/Quad
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 16 MiB at 0x8f000000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000010000000-0x000000003fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000040000000-0x000000008fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x000000008fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000008fffffff] [ 0.000000] percpu: Embedded 21 pages/cpu s54604 r8192 d23220 u86016
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 522560
[ 0.000000] Kernel command line: enable_wait_mode=off root=UUID=233113e0-67d1-409f-b2c0-57bd496213de rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1 break
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 0.000000] Memory: 2041628K/2097152K available (11264K kernel code, 1668K rwdata, 3192K rodata, 2048K init, 337K bss, 39140K reserved, 16384K cma- reserved, 1294336K highmem)
[ 0.000000] random: get_random_u32 called from __kmem_cache_create+0x30/0x450 with crng_init=0
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 37402 entries in 110 pages
[ 0.000000] ftrace: allocated 110 pages with 5 groups
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[ 0.000000] Rude variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C: DT/platform modifies aux control register: 0x32070000 -> 0x32470000
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[ 0.000000] Switching to timer-based delay loop, resolution 333ns
[ 0.000007] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 715827882841ns
[ 0.000026] clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 637086815595 ns
[ 0.002970] Console: colour dummy device 80x30
[ 0.003586] printk: console [tty1] enabled
[ 0.003647] Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=12000)
[ 0.003685] pid_max: default: 32768 minimum: 301
[ 0.004038] LSM: Security Framework initializing
[ 0.004159] Yama: disabled by default; enable with sysctl kernel.yama.*
[ 0.004331] AppArmor: AppArmor initialized
[ 0.004360] TOMOYO Linux initialized
[ 0.004474] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.004507] Mountpoint-cache hash table entries: 2048 (order: 1, 8192
bytes, linear)
[ 0.005775] CPU: Testing write buffer coherency: ok
[ 0.005835] CPU0: Spectre v2: using BPIALL workaround
[ 0.006180] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.007274] Setting up static identity map for 0x10300000 - 0x103000ac
[ 0.008644] rcu: Hierarchical SRCU implementation.
[ 0.011160] EFI services will not be available.
[ 0.011750] smp: Bringing up secondary CPUs ...
[ 0.012731] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.012741] CPU1: Spectre v2: using BPIALL workaround
[ 0.013903] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.013911] CPU2: Spectre v2: using BPIALL workaround
[ 0.015024] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.015033] CPU3: Spectre v2: using BPIALL workaround
[ 0.015256] smp: Brought up 1 node, 4 CPUs
[ 0.015286] SMP: Total of 4 processors activated (24.00 BogoMIPS).
[ 0.015308] CPU: All CPU(s) started in SVC mode.
[ 0.016160] devtmpfs: initialized
[ 0.026244] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.026591] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.026667] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[ 0.028033] pinctrl core: initialized pinctrl subsystem
[ 0.029350] DMI not present or invalid.
[ 0.029787] NET: Registered protocol family 16
[ 0.033267] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.034241] audit: initializing netlink subsys (disabled)
[ 0.034544] audit: type=2000 audit(0.032:1): state=initialized audit_enabled=0 res=1
[ 0.035999] thermal_sys: Registered thermal governor 'fair_share'
[ 0.036007] thermal_sys: Registered thermal governor 'bang_bang'
[ 0.036035] thermal_sys: Registered thermal governor 'step_wise'
[ 0.036057] thermal_sys: Registered thermal governor 'user_space'
[ 0.036078] thermal_sys: Registered thermal governor 'power_allocator'
[ 0.036449] CPU identified as i.MX6Q, silicon rev 1.2
[ 0.473485] No ATAGs?
[ 0.473721] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
watchpoint registers.
[ 0.473752] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.475534] debugfs: Directory 'dummy-iomuxc-gpr@20e0000' with parent 'regmap' already present!
[ 0.475885] imx6q-pinctrl 20e0000.pinctrl: initialized IMX pinctrl driver
[ 0.477575] Serial: AMBA PL011 UART driver
[ 0.485760] Kprobes globally optimized
[ 2.200761] mxs-dma 110000.dma-apbh: initialized
[ 2.202374] reg-fixed-voltage regulator-vcc-3v3: Failed to register regulator: -517
[ 2.205294] iommu: Default domain type: Translated
[ 2.206502] vgaarb: loaded
[ 2.207700] mc: Linux media interface: v0.10
[ 2.207770] videodev: Linux video capture interface: v2.00
[ 2.209653] NetLabel: Initializing
[ 2.209681] NetLabel: domain hash size = 128
[ 2.209698] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 2.209808] NetLabel: unlabeled traffic allowed by default
[ 2.210323] clocksource: Switched to clocksource mxc_timer1
[ 2.295588] VFS: Disk quotas dquot_6.6.0
[ 2.295735] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 2.296593] AppArmor: AppArmor Filesystem Enabled
[ 2.310024] NET: Registered protocol family 2
[ 2.310267] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
[ 2.311879] tcp_listen_portaddr_hash hash table entries: 512 (order: 0,
6144 bytes, linear)
[ 2.311957] TCP established hash table entries: 8192 (order: 3, 32768
bytes, linear)
[ 2.312087] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 2.312229] TCP: Hash tables configured (established 8192 bind 8192)
[ 2.312400] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 2.312466] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes,
linear)
[ 2.313044] NET: Registered protocol family 1
[ 2.313111] NET: Registered protocol family 44
[ 2.313143] PCI: CLS 0 bytes, default 64
[ 2.314074] hw perfevents: no interrupt-affinity property for /pmu, guessing.
[ 2.314504] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
[ 2.317353] Initialise system trusted keyrings
[ 2.317419] Key type blacklist registered
[ 2.317646] workingset: timestamp_bits=14 max_order=19 bucket_order=5
[ 2.325359] zbud: loaded
[ 2.326642] integrity: Platform Keyring initialized
[ 2.326680] Key type asymmetric registered
[ 2.326700] Asymmetric key parser 'x509' registered
[ 2.326913] bounce: pool size: 64 pages
[ 2.327021] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[ 2.327303] io scheduler mq-deadline registered
[ 2.347086] imx-sdma 20ec000.sdma: firmware: failed to load imx/sdma/sdma- imx6q.bin (-2)
[ 2.347128] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 2.347158] imx-sdma 20ec000.sdma: Direct firmware load for imx/sdma/sdma- imx6q.bin failed with error -2
[ 2.354549] Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled
[ 2.357951] Serial: AMBA driver
[ 2.358903] 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 33, base_baud
= 5000000) is a IMX
[ 3.178125] printk: console [ttymxc0] enabled
[ 3.184115] 21f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 73, base_baud
= 5000000) is a IMX
[ 3.195317] STM32 USART driver initialized
[ 3.202826] libphy: Fixed MDIO Bus: probed
[ 3.208766] mousedev: PS/2 mouse device common for all mice
[ 3.217435] snvs_rtc 20cc000.snvs:snvs-rtc-lp: registered as rtc0
[ 3.223624] snvs_rtc 20cc000.snvs:snvs-rtc-lp: setting system clock to 1970-01-01T00:00:00 UTC (0)
[ 3.238027] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.246151] NET: Registered protocol family 10
[ 3.259215] Segment Routing with IPv6
[ 3.263086] mip6: Mobile IPv6
[ 3.266076] NET: Registered protocol family 17
[ 3.270798] mpls_gso: MPLS GSO support
[ 3.275176] ThumbEE CPU extension supported.
[ 3.279544] Registering SWP/SWPB emulation handler
[ 3.284552] registered taskstats version 1
[ 3.288736] Loading compiled-in X.509 certificates
[ 3.688518] Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[ 3.697390] Loaded X.509 cert 'Debian Secure Boot Signer 2021 - linux: 4b6ef5abca669825178e052c84667ccbc0531f8c'
[ 3.707798] zswap: loaded using pool lzo/zbud
[ 3.713011] Key type ._fscrypt registered
[ 3.717099] Key type .fscrypt registered
[ 3.721055] Key type fscrypt-provisioning registered
[ 3.726262] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.758428] vcc_3v3: supplied by v_5v0
[ 3.775058] Waiting for root device UUID=233113e0-67d1-409f- b2c0-57bd496213de...

Stuck at the same position (and I also tried /dev/mmcblk0p2 instead of /dev/ mmcblk1p2, but the same result).

Now I am out of ideas :-/

Rainer

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-12-27, Rainer Dorsch wrote:

Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:

Very likely; it is not promised to remain constant even between boots
with the same kernel, unfortunately!

You really want to use root=UUID=abcde-12345... or partition labels, or
anything that isn't going to have surprise changes...

Hmm...I think the problem is something different.

I inserted the SDcard in a different Linux-System and I extracted the UUID:

root@h370:~# lsblk --fs /dev/sdc2
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
sdc2 ext4 1.0 233113e0-67d1-409f-b2c0-57bd496213de root@h370:~#

I manually loaded now the kernel in uboot (does the manual sequence look reasonable?):

...

CuBox-i U-Boot > load mmc 0:1 0x10800000 vmlinuz-5.10.0-10-armmp
4960768 bytes read in 380 ms (12.4 MiB/s)
CuBox-i U-Boot > load mmc 0:1 0x18000000 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 0x11800000 initrd.img-5.10.0-10-armmp
24040022 bytes read in 1551 ms (14.8 MiB/s)

I would use $kernel_addr_r, $fdt_addr_r and $ramdisk_addr_r instead of hard-coded values.

CuBox-i U-Boot > setenv bootargs " ${bootargs} enable_wait_mode=off root=UUID=233113e0-67d1-409f-b2c0-57bd496213de rootfstype=ext4 ro rootwait
console=ttymxc0,115200 console=tty1 break"
CuBox-i U-Boot > printenv bootargs
bootargs= enable_wait_mode=off root=UUID=233113e0-67d1-409f-b2c0-57bd496213de
rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1 break

All you should really need are:

root=UUID=... console=ttymxc0,115200 console=tty1

CuBox-i U-Boot > bootz 0x10800000 0x11800000: 0x18000000

You might want instead:

bootz $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r

The $filesize is (or at least used to be) important, and should be set
to the size of the last file loaded with "load" or similar commands.

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

It looks like it did not load the initramfs, possibly due to not using $filesize above ... though I would expect an error, because the raw
initrd doesn't contain headers to detect the size, but maybe passing the
empty value after the colon silences that error?


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.


live well,
vagrant

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYcpKRgAKCRDcUY/If5cW qv1TAP0azlOjtZtj2WMQQCfk6YQQ4Op4hK5P68kuYaap2tNKigEAgBWEqvWoMA44 OmDnOIPDeXGxE4o0qeji6oAoJnrwzwQ=o6zy
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Dienstag, 28. Dezember 2021, 01:10:39 CET schrieb Rainer Dorsch:

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?

At least the result is the same for /dev/mmcblk0p2:

[...]
[ 3.743918] zswap: loaded using pool lzo/zbud
[ 3.749114] Key type ._fscrypt registered
[ 3.753212] Key type .fscrypt registered
[ 3.757174] Key type fscrypt-provisioning registered
[ 3.762439] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.794654] vcc_3v3: supplied by v_5v0
[ 3.811521] List of all partitions:
[ 3.815075] No filesystem could mount root, tried:
[ 3.815079]
[ 3.821507] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 3.829798] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-10-armmp #1 Debian 5.10.84-1
[ 3.837995] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 3.844536] Backtrace:

If a module is missing, would that be different for a new installation and an upgrade?

Thanks
Rainer


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------yu0rq8ujNx0XzYZqB40HyC4u
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMTIvMjcvMjEgMTg6MjIsIFZhZ3JhbnQgQ2FzY2FkaWFuIHdyb3RlOg0KPiBPbiAyMDIx LTEyLTI3LCBSYWluZXIgRG9yc2NoIHdyb3RlOg0KPj4gSSB1cGdyYWRlZCBhIGN1Ym94LWkg ZnJvbSBidXN0ZXIgdG8gYnVsbHNleWUuIFRoZSB1cGdyYWRlIHdlbnQgdGhyb3VnaCB3aXRo b3V0DQo+PiBhbnkgaXNzdWVzLiBCdXQgYWZ0ZXIgdGhlIHVwZ3JhZGUgdGhlIHN5c3RlbSBk b2VzIG5vdCBib290IGFueW1vcmUuIFRoZSBvdXRwdXQNCj4+IG9mIHRoZSBzZXJpYWwgY29u c29sZSBpcyBiZWxvdy4gVGhlIGJvb3QgcHJvY2VzcyBoYW5ncyBhdA0KPj4NCj4+IFsgICAg My44MTY0MjRdIFdhaXRpbmcgZm9yIHJvb3QgZGV2aWNlIC9kZXYvbW1jYmxrMXAyLi4uDQo+ Pg0KPj4gRGlkIHRoZSBkZXZpY2UgZW51bWVyYXRpb24gY2hhbmdlPw0KPiANCj4gVmVyeSBs aWtlbHk7IGl0IGlzIG5vdCBwcm9taXNlZCB0byByZW1haW4gY29uc3RhbnQgZXZlbiBiZXR3 ZWVuIGJvb3RzDQo+IHdpdGggdGhlIHNhbWUga2VybmVsLCB1bmZvcnR1bmF0ZWx5IQ0KPiAN Cj4gWW91IHJlYWxseSB3YW50IHRvIHVzZSByb290PVVVSUQ9YWJjZGUtMTIzNDUuLi4gb3Ig cGFydGl0aW9uIGxhYmVscywgb3INCj4gYW55dGhpbmcgdGhhdCBpc24ndCBnb2luZyB0byBo YXZlIHN1cnByaXNlIGNoYW5nZXMuLi4NCj4gDQo+IA0KPj4gSG93IHdvdWxkIEkgZmluZCBv dXQgdGhlIG5ldyBkZXZpY2UgbmFtZSBhbmQgaG93IHdvdWxkIEkgY2hhbmdlIHRoZSBib290 DQo+PiBwYXJhbWV0ZXJzICh3aGljaCBhcHBhcmVudGx5IHNwZWNpZmllcyAvZGV2L21tY2Js azFwMiBhY2NvcmRpbmcgdG8gdGhlIG91dHB1dA0KPj4gYmVsb3cpPw0KPiANCj4gSWYgeW91 IGNhbiAgaW5zZXJ0IHRoZSBtaWNyb1NEIGludG8gYW5vdGhlciBEZWJpYW4gIG1hY2hpbmUs IHlvdSBjYW4gZ2V0DQo+IHRoZSBVVUlEICBieSBsb29raW5nIGluICAvZGV2L2Rpc2svYnkt dXVpZC8gdG8gZmluZCB0aGUgIG1hdGNoaW5nIGRldmljZQ0KPiBvcjoNCj4gDQo+ICAgIGxz YmxrIC0tZnMgL2Rldi9ERVZJQ0UNCj4gDQo+IEl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGRp c2NvdmVyIGZyb20gdS1ib290IGFzIHdlbGwsIGJ1dCBJIGZvcmdldCBvZmYNCj4gdGhlIHRv cCBvZiBteSBoZWFkLg0KDQpJIGNhbiByZWNvbW1lbmQgYmFyZWJveCBoZXJlIGluc3RlYWQg b2YgVS1Cb290LiBpLk1YIGlzIHRoZSBwcm9iYWJseSANCmJlc3Qgc3VwcG9ydGVkIHBsYXRm b3JtIGZvciBpdCBhbmQgSSB3b3VsZCBleHBlY3QgdGhlIGN1Ym94LWkgdG8gYmUgDQpkaXJl Y3RseSBzdXBwb3J0ZWQuDQoNCkJhcmVib3ggY2FuIG1vdW50IHZhcmlvdXMgZmlsZXN5c3Rl bXMgYW5kIGlmIHRoZXJlIGlzIGEgYm9vdHNwZWMgZW50cnkgDQppbiB5b3VyIHJvb3RmcyAo ZS5nLiBmbGFzaC1rZXJuZWwgY2FuIHdyaXRlIHN1Y2ggYW4gZW50cnkpIHlvdSBjYW4ganVz dCBkbzoNCg0KCWJvb3QgL21udC9tbWMwLjANCg0KdG8gbGV0IGJhcmVib3ggcGljayB0aGUg a2VybmVsLCBpbml0cmQgYW5kIGR0YiBmcm9tIHRoZSBmaWxlc3lzdGVtIG9uIA0KbW1jMC4w IGFuZCBwYXNzIHJvb3Q9VVVJRD0kdGhlcmlnaHRvbmUuDQoNCkJlc3QgcmVnYXJkcw0KVXdl
DQo=

--------------yu0rq8ujNx0XzYZqB40HyC4u--

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmHK60oACgkQwfwUeK3K 7An5Awf+IbnRBQ9ROAwmIW+cL4quuQ8i7vPBmQ0AIhOQ+jcNl/LTnjLYO7eJMhLl MBPJt4bB2HA+rdjachnOlJIQNZZKbojCv1Kjq2I+MrG6l4hiWQ1ixrixPUYBEsSI ycs+J6V1IB+F160E08SEPpNtJrzN5rYTfpKpiJwsjtePEF9kgqyOF+naUVmOiIYZ q6F0lrtod2mtdH7T1I4chK+5Yhl8kPAj2/p/o6nFYpuLxcBa6IpYgGWE401Gni7j BdxpWcqP4CELHEiCkq2UkSQgjHWxp/X/lYAknl87ifElGEFpYTrbk3XYdlkaPZTc U7DTRXokG9peoZGgyAHDSS0Ego75bg==
=Gfeg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Dienstag, 28. Dezember 2021, 11:47:37 CET schrieb Uwe Kleine-König:

On 12/27/21 18:22, Vagrant Cascadian wrote:

On 2021-12-27, Rainer Dorsch wrote:

I upgraded a cubox-i from buster to bullseye. The upgrade went through
without

any issues. But after the upgrade the system does not boot

anymore. The output of the serial console is below. The boot process
hangs at



[ 3.816424] Waiting for root device /dev/mmcblk1p2...



Did the device enumeration change?

Very likely; it is not promised to remain constant even between boots
with the same kernel, unfortunately!

You really want to use root=UUID=abcde-12345... or partition labels, or anything that isn't going to have surprise changes...

How would I find out the new device name and how would I change the boot >> parameters (which apparently specifies /dev/mmcblk1p2 according to the
output

below)?

If you can insert the microSD into another Debian machine, you can get the UUID by looking in /dev/disk/by-uuid/ to find the matching device or:

lsblk --fs /dev/DEVICE

It might be possible to discover from u-boot as well, but I forget off
the top of my head.

I can recommend barebox here instead of U-Boot. i.MX is the probably
best supported platform for it and I would expect the cubox-i to be
directly supported.

Barebox can mount various filesystems and if there is a bootspec entry
in your rootfs (e.g. flash-kernel can write such an entry) you can just do:

boot /mnt/mmc0.0

to let barebox pick the kernel, initrd and dtb from the filesystem on
mmc0.0 and pass root=UUID=$therightone.

Thanks for the advice. Is barebox already packaged for Debian and I just don't find it or do I need to install it from non-Debian sources?

Thanks
Rainer


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:

If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
or:

lsblk --fs /dev/DEVICE

It might be possible to discover from u-boot as well, but I forget off
the top of my head.

There is

part uuid mmc 1:2

8ad3fb70-02

part uuid mmc 1:3

8ad3fb70-03


but "root=UUID=8ad3fb70-03" is not working for mounting the rootfs.

In the bullseye installation, there is also a variable defined finduuid

finduuid=part uuid mmc 0:1 uuid

which is even called by bootcmd, but I am not sure if that is doing anything useful.

Rainer

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------fvrt2KSqfhbsEalviw08j3sN
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGkgUmFpbmVyLA0KDQpPbiAxMi8yOC8yMSAxMzo0NiwgUmFpbmVyIERvcnNjaCB3cm90ZToN Cj4gQW0gRGllbnN0YWcsIDI4LiBEZXplbWJlciAyMDIxLCAxMTo0NzozNyBDRVQgc2Nocmll YiBVd2UgS2xlaW5lLUvDtm5pZzoNCj4+IEkgY2FuIHJlY29tbWVuZCBiYXJlYm94IGhlcmUg aW5zdGVhZCBvZiBVLUJvb3QuIGkuTVggaXMgdGhlIHByb2JhYmx5DQo+PiBiZXN0IHN1cHBv cnRlZCBwbGF0Zm9ybSBmb3IgaXQgYW5kIEkgd291bGQgZXhwZWN0IHRoZSBjdWJveC1pIHRv IGJlDQo+PiBkaXJlY3RseSBzdXBwb3J0ZWQuDQo+Pg0KPj4gQmFyZWJveCBjYW4gbW91bnQg dmFyaW91cyBmaWxlc3lzdGVtcyBhbmQgaWYgdGhlcmUgaXMgYSBib290c3BlYyBlbnRyeQ0K Pj4gaW4geW91ciByb290ZnMgKGUuZy4gZmxhc2gta2VybmVsIGNhbiB3cml0ZSBzdWNoIGFu IGVudHJ5KSB5b3UgY2FuIGp1c3QgZG86DQo+Pg0KPj4gCWJvb3QgL21udC9tbWMwLjANCj4+ DQo+PiB0byBsZXQgYmFyZWJveCBwaWNrIHRoZSBrZXJuZWwsIGluaXRyZCBhbmQgZHRiIGZy b20gdGhlIGZpbGVzeXN0ZW0gb24NCj4+IG1tYzAuMCBhbmQgcGFzcyByb290PVVVSUQ9JHRo ZXJpZ2h0b25lLg0KPiANCj4gVGhhbmtzIGZvciB0aGUgYWR2aWNlLiBJcyBiYXJlYm94IGFs cmVhZHkgcGFja2FnZWQgZm9yIERlYmlhbiBhbmQgSSBqdXN0IGRvbid0DQo+IGZpbmQgaXQg b3IgZG8gSSBuZWVkIHRvIGluc3RhbGwgaXQgZnJvbSBub24tRGViaWFuIHNvdXJjZXM/DQoN Ckl0J3Mgbm90IHlldCBwYWNrYWdlZCwgdGhlcmUgaXMgb25seSBhbiBJVFAsIHdoaWNoIHdh aXRzIGZvciBzb21lIGVmZm9ydCANCnRvIGNvbnZlcnQgYmFyZWJveCB0byBTUERYLiBodHRw czovL2J1Z3MuZGViaWFuLm9yZy85MDA5NTgNCg0KQmVzdCByZWdhcmRzDQpVd2UNCg==

--------------fvrt2KSqfhbsEalviw08j3sN--

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmHMk2kACgkQwfwUeK3K 7AndgAf/Xgq13id+LFTCWSjIIabmkzMPpldEnL0Cod7kCJzL7KJsfm/qSmQKaaE0 9AFEKP/Z18+Qsff2wnDNfKcHaSiRaqYVTJ2SS0KSjEi3PED3yiWlKthmltrLoyrd Tm4mxpS86rC162Gpt2jznq+zs5ysVHD1jaN/36PtqlCdoE770Tr5zid+GTTlzNil V40770Y38jGCfq2yYv3jX1Pm2Dv/W+9qeSsL5yGidAuXEQ8Fk/btNdbMzoxCHwFE oFal1UfZt+4iBY72soBeXVw1/AQT9sXyfOHtAUh156ZNcZO/B1Qyt1FiG6FtynWS zNHMPF6/CJnCwODHw1vcGlzatYgAWA==
=kDjC
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-12-29, Rainer Dorsch wrote:

Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:

If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
or:

lsblk --fs /dev/DEVICE

It might be possible to discover from u-boot as well, but I forget off
the top of my head.

There is

part uuid mmc 1:2

8ad3fb70-02

part uuid mmc 1:3

8ad3fb70-03

but "root=UUID=8ad3fb70-03" is not working for mounting the rootfs.

In the bullseye installation, there is also a variable defined finduuid

finduuid=part uuid mmc 0:1 uuid

which is even called by bootcmd, but I am not sure if that is doing anything useful.

That *may* be a partition UUID, rather than a filesystem
UUID... initramfs-tools 0.121 and newer supports using
root=PARTUUID=...

You can see the available partition uuids on linux in
/dev/disk/by-partuuid/


live well,
vagrant

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYcyrWQAKCRDcUY/If5cW qnKRAP9z4la3aCEm4/g4je1I8nsjwGEXmHz5NNyt8Q/iMaABagEAgXzKPIKsSzdx NzZul5cxDpGtEn8e0biMUxJ6bu5imQU=ft/K
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mittwoch, 29. Dezember 2021, 19:39:18 CET schrieb Vagrant Cascadian:

On 2021-12-29, Rainer Dorsch wrote:

Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:

If you can insert the microSD into another Debian machine, you can get >> the UUID by looking in /dev/disk/by-uuid/ to find the matching device >>
or:
lsblk --fs /dev/DEVICE

It might be possible to discover from u-boot as well, but I forget off
the top of my head.

There is

part uuid mmc 1:2

8ad3fb70-02

part uuid mmc 1:3

8ad3fb70-03

but "root=UUID=8ad3fb70-03" is not working for mounting the rootfs.

In the bullseye installation, there is also a variable defined finduuid

finduuid=part uuid mmc 0:1 uuid

which is even called by bootcmd, but I am not sure if that is doing anything useful.

That *may* be a partition UUID, rather than a filesystem
UUID... initramfs-tools 0.121 and newer supports using
root=PARTUUID=...

You can see the available partition uuids on linux in
/dev/disk/by-partuuid/

Indeed that works.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, December 29, 2021 1:39:18 PM EST Vagrant Cascadian wrote:

On 2021-12-29, Rainer Dorsch wrote:

Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian:

If you can insert the microSD into another Debian machine, you can
get
the UUID by looking in /dev/disk/by-uuid/ to find the matching
device

or:
lsblk --fs /dev/DEVICE

It might be possible to discover from u-boot as well, but I forget off
the top of my head.

There is

part uuid mmc 1:2

8ad3fb70-02

part uuid mmc 1:3

8ad3fb70-03

but "root=UUID=8ad3fb70-03" is not working for mounting the rootfs.

In the bullseye installation, there is also a variable defined finduuid

finduuid=part uuid mmc 0:1 uuid

which is even called by bootcmd, but I am not sure if that is doing anything useful.

That *may* be a partition UUID, rather than a filesystem
UUID... initramfs-tools 0.121 and newer supports using
root=PARTUUID=...

You can see the available partition uuids on linux in
/dev/disk/by-partuuid/

Thank you very very much, vagrant. I've been wondering how those were
married, but a much more informative answer is from ls -l + the above path.

From my 2 gig rpi4, serving as a buildbot, and heavily modified to move much of the buildbot traffic off the u-sd:

pi@rpi4:~/linuxcnc/configs/sheldon-lathe $ ls -l /dev/disk/by-partuuid/
total 0
lrwxrwxrwx 1 root root 15 Oct 18 06:55 5e3da3da-01 -> ../../mmcblk0p1 lrwxrwxrwx 1 root root 15 Oct 18 06:55 5e3da3da-02 -> ../../mmcblk0p2 lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-01 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-02 -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-03 -> ../../sda3
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-04 -> ../../sda4
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c61252a1-01 -> ../../sdb1

sda/sdb are SSD's on usb3-sata adapters

live well,

You too,

vagrant

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-12-29, Uwe Kleine-König wrote:

On 12/28/21 13:46, Rainer Dorsch wrote:

Am Dienstag, 28. Dezember 2021, 11:47:37 CET schrieb Uwe Kleine-König:

I can recommend barebox here instead of U-Boot. i.MX is the probably
best supported platform for it and I would expect the cubox-i to be
directly supported.

Barebox can mount various filesystems and if there is a bootspec entry
in your rootfs (e.g. flash-kernel can write such an entry) you can just do: >>>
boot /mnt/mmc0.0

to let barebox pick the kernel, initrd and dtb from the filesystem on
mmc0.0 and pass root=UUID=$therightone.

Thanks for the advice. Is barebox already packaged for Debian and I just don't
find it or do I need to install it from non-Debian sources?

I briefly tried barebox and must say I liked it; if it's supported by a platform you use I can definitely recommend trying barebox! The shell
felt more like a bourne shell (e.g. bash) than u-boot and maybe a bit
more comfortable for someone not already familiar with u-boot...

It's not yet packaged, there is only an ITP, which waits for some effort
to convert barebox to SPDX. https://bugs.debian.org/900958

That looks to be *mostly* done, from a quick glance.

Looking forward to seeing it in Debian!


live well,
vagrant

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)