ChanServ changed the topic of #linux-cros-arm to:
hexdump01 has joined #linux-cros-arm
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-cros-arm
<hexdump0815> aceridus: here is how i use the kernel config fragments: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/readme.cbr#L40
<hexdump0815> this readme describes how i build the veyron kernel
<hexdump0815> aceridus: btw. i retested my bullseye image from https://github.com/hexdump0815/imagebuilder/releases/tag/220820-01 and for me it works fine - no readonly fs
<hexdump0815> i tested it on mighty ... did you have any mmc errors maybe which might have resulted in the btrfs ro you saw?
<aceridus> hexdump0815: So there is a script for merging configs, nice! Thanks for the info.
<aceridus> hexdump0815: I just checked the bullseye sdcard again and mount still shows '/dev/mmcblk1p4 on / type btrfs (ro, ...)'. If I run 'mount -o remount,rw /' it fails with 'mount: /: cannot remount /dev/mmcblk1p4 read-write, is write-protected'
<aceridus> hexdump0815: Ok, I see the following in dmesg 'mmcblk1: mmc1:59b4 USD00 58.9 GiB (ro)', so for some reason when the drive detects the card it thinks it is read-only. It is a microSD so no physical lock switch like full size SD cards and/or adapters have. Not sure why the driver is flagging it read only...
<aceridus> hexdump0815: Found the problem. I had to change /boot/extlinux/extlinux.conf to add a menu entry for veyron-jerry that loads the jerry dtb and now everything is working. I am booted and logged into the desktop now