paulk has quit [Read error: Connection reset by peer]
paulk has joined #linux-rockchip
Livio has joined #linux-rockchip
naoki has joined #linux-rockchip
SystemError has quit [Ping timeout: 260 seconds]
SystemError has joined #linux-rockchip
naoki has quit [Quit: naoki]
indy_ has quit [Ping timeout: 276 seconds]
Livio has quit [Ping timeout: 252 seconds]
mripard has quit [Quit: mripard]
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Quit: Stat_headcrabed]
naoki has joined #linux-rockchip
naoki has quit [Client Quit]
psydroid2 has joined #linux-rockchip
raster has joined #linux-rockchip
urja has quit [Read error: Connection reset by peer]
urja has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
stikonas has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
stikonas has quit [Read error: Connection reset by peer]
stikonas has joined #linux-rockchip
raster has joined #linux-rockchip
warpme has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
Daanct12 has quit [Quit: WeeChat 4.3.5]
krei-se has quit [Read error: Connection reset by peer]
krei-se has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #linux-rockchip
<dsimic>
good news, Radxa accepted my suggestion for upping the eMMC chip on ROCK 5 ITX from 8 GB to 32 GB :)
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<dsimic>
also, the recovery button will be changed to modify the boot selection resistor divider to LEVEL2 and make the microSD card first in boot order, instead of the button's current purpose to initiate USB-based recovery, which is nothing but pain
Livio has joined #linux-rockchip
jmabsd has joined #linux-rockchip
<jmabsd>
Hi! I just did "aptitude update; aptitude upgrade" on a Rock Pi RK3588, one which boots from NVMe SSD. On boot now, the boot fails with the kernel complaining that there is no "root=" parameter. How fix?
<jmabsd>
Of course this device already has the boot loader on the SPI flash.
<jmabsd>
As you see in the log, "U-Boot SPL 2017.09-gbf47e8171f4-220414-dirty #stephen (Jun 07 2023 - 17:56:02)" boots, and then it loads the boot loader from "MTD2"
<jmabsd>
You get "U-Boot Menu" with "1: Debian GNU/Linux 11 (bullseye) 5.10.110-38-rockchip"
<jmabsd>
Is it that this kernel doesn't support PCI/NVMe?????
<dsimic>
it's a Rock 5B?
<jmabsd>
yes
<jmabsd>
dsimic: yes
<jmabsd>
Was it a mistake by me to allow "aptitude update; aptitude upgrade" to do its work
<jmabsd>
Does the "u-boot" console contain any "ls" function etcetra using which I can figure out what "root=" should be set from, or like, what is the issue. I am not clear
<jmabsd>
I don't remember what steps I took to make the NVMe installation work in the first place.
<dsimic>
the "root=..." part of the kernel command line comes from what the kernel sees as the devices
<dsimic>
is there way to get the complete kernel messages from failed boot attempt?
<jmabsd>
dsimic: What is your idea how I fix this now
<jmabsd>
dsimic: sure, I will restart the device and paste you all of it, 1 second
<jmabsd>
Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
<jmabsd>
... is now current device Scanning nvme 0:2... Scanning nvme 0:3... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf"
<jmabsd>
So u-boot indeed finds the NVMe device, indeed loads /boot/extlinux/extlinux.conf , indeed loads a kernel (not sure which) and then that kernel just halts with complaint about root= not specified lol
<jmabsd>
meanwhile this boot is from the eMMC indeed, "mount" shows "/dev/mmcblk1p2 on / type ext4 (rw,relatime)".
<dsimic>
what does output of lsblk look like?
<jmabsd>
# lsblk
<jmabsd>
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
<jmabsd>
mtdblock0 31:0 0 16M 0 disk
<jmabsd>
mmcblk1 179:0 0 28.9G 0 disk
<jmabsd>
├─mmcblk1p1 179:1 0 512M 0 part
<jmabsd>
└─mmcblk1p2 179:2 0 28.4G 0 part /
<jmabsd>
mmcblk1boot0 179:32 0 4M 1 disk
<jmabsd>
mmcblk1boot1 179:64 0 4M 1 disk
<jmabsd>
nvme0n1 259:0 0 931.5G 0 disk
<jmabsd>
├─nvme0n1p1 259:1 0 16M 0 part /mnt
<jmabsd>
├─nvme0n1p2 259:2 0 300M 0 part
<jmabsd>
└─nvme0n1p3 259:3 0 931.2G 0 part
<dsimic>
nice, nvme0 is there
<dsimic>
let's see the contents of boot/extlinux/extlinux.conf and /etc/kernel/cmdline, please
<jmabsd>
okey I now did " mount /dev/nvme0n1p1 /mnt"
<jmabsd>
there is only one text file in /mnt . then I did the same for p2, and it's an empty partition. and then I did the same for p3 and that is the actual filesystem.
<mps>
probably you have to add 'append root=/dev/nvme0n1p3' to extlinux.conf
<dsimic>
the way I see it, /etc/kernel/cmdline should handle that... perhaps?
<mps>
dsimic: doesn't u-boot add content of 'append' to kernel cmdline?
<jmabsd>
aha here we go. okay. right so, the machine had the root argument inside /etc/kernel/cmdline .
<dsimic>
there's no "root" in extlinux.conf indeed
<jmabsd>
can I fix this quickly now
<jmabsd>
can I just "vim" extlinx.conf ?
<jmabsd>
easy peasy
<dsimic>
mps: U-Boot shouldn't add anything there
<mps>
jmabsd: yes, vim is 'swiss army knife' :-)
<dsimic>
jmabsd: perhaps you should regenerate the U-Boot configuration the Debian way
<jmabsd>
so I just add " root=UUID=29a94882-5add-4f09-8cc5-3f43918624fa " to *the end* of the first "append ........." line
<dsimic>
FWIW, I'd rather investigate the proper way
<jmabsd>
dsimic: I agree this was not cleanly done
<jmabsd>
but let's see if it makes the machine boot.
<dsimic>
let's se
<dsimic>
let's see *
<mps>
jmabsd: if you use 'UUID' you have to find it for root FS, blkid command could help
<jmabsd>
Okey, now when I rebooted, I see that indeed the " root=.." command was loaded into the u-boot/boot environment. Great. And let's see if it boots..