Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 8374

Raspberry Pi OS • Re: Using Raspberry Pi Imager for a 4B

$
0
0
I'm puzzled within SSD rootfs/boot/cmdline.txt that is empty but a warning stating "Don't Edit - It is moved to /boot/firmware/cmdline.txt" when nowhere in the SSD there is a firmware folder but the empty rootfs/boot/firmware ????

The mount point for the boot partition changed with Bookworm from /boot to /boot/firmware if it's empty it hasn't been mounted. Check your /etc/fstab is correct and check the output from dmesg for errors.
As for whether you need the SD card, that depends. If you SSD has both the boot and root partitions and your boot order is set correctly to allow booting from USB you don't.
Hi thagrol
Thanks for help
I'm afraid I surely miss something huge. The SSD was imaged with Imager where I selected Pi4 (BTW, I see mine seems to be a Rev 1.1).
After I put the SDCard in the Pi now I quickly get a stop instead of bootloop

Code:

[    0.919791] Failed to execute /init (error -2)[    0.919985] Kernel panic - not syncing: No working init found. Try passing init= option to the kernel. See Linux Documentation/admin-guide/init.rst for guidance.[    0.920032] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.47+rpt-rpi-v8 #1  Debian 1:6.12.47-1+rpt1[    0.920068] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)[    0.920089] Call trace:[    0.920101]  dump_backtrace.part.0+0xe0/0x100[    0.920133]  show_stack+0x20/0x40[    0.920149]  dump_stack_lvl+0x60/0x80[    0.920172]  dump_stack_lvl+0x18/0x28[    0.920190]  panic+0x170/0x370[    0.920208]  kernel_init+0x13C/0x150[    0.920227]  ret_from_fork+0x10/0X20[    0.920247] SMP: stopping secondary CPUs[    0.920269] Kernel offset: 0x127f600000 from 0xffffffc080000000[    0.920291] PHYS_OFFSET: 0x0[    0.920304] CPU features: 0x08,00002013,c0200000,0200412b[    0.920325] Memory Limit: none[    0.920344] ---[ end Kernel panic - not syncing: No working init found. Try passing init= option to the kernel. See Linux Documentation/admin-guide/init.rst for guidance. ]---_

My experience is that the above is often caused by having the wrong PARTUUID in cmdline.txt. If the kernel can't find the root partition it can't do very much at all.
I wander how I could check dmesg when Pi won't boot.
Looking the SSD with another USB/SATA adapter with gparted in my laptop is see sdb1 doesn't have the boot flag - Is it intended as Pi don't need that but instead require BOOT_ORDER register to be set, but again how to get/check/set this when the Pi won't boot. I'm really puzzled by Imager presented as the recommanded Imager, I imagined it would manage all these low level settings automatically only with the info of target device. Beside this all settings like hostname, user name, wifi/reg_domain etc are real improvements that would make a debian-like seamless installation... but I'm not sure I used it for Buster in 2020.

Here is the rootfs/etc/fstab that was created in the SSD

Code:

proc            /proc           proc    defaults          0       0PARTUUID=2d1ca6b1-01  /boot/firmware  vfat    defaults          0       2PARTUUID=2d1ca6b1-02  /               ext4    defaults,noatime  0       1
and details of what my laptop sees in the SSD :

Code:

sudo fdisk -l /dev/sdb*Disk /dev/sdb : 465,76 GiB, 500107862016 bytes, 976773168 sectorsDisk model: Generic         Units : sector of 1 × 512 = 512 bytesSector size (logical / physical) : 512 bytes / 4096 bytesE/S size (minimal / optimal) : 4096 bytes / 4096 bytesDisk label type: dosDisk identifier: 0x2d1ca6b1Device    Boot          Start       End   Sectors   Size Id Type/dev/sdb1               16384   1064959   1048576   512M  c W95 FAT32 (LBA)/dev/sdb2             1064960 976773167 975708208 465,3G 83 LinuxDisk /dev/sdb1: 512 MiB, 536870912 bytes, 1048576 sectorsUnits: sector of 1 × 512 = 512 bytesSector size (logical / physical): 512 bytes / 4096 bytesE/S size (minimal / optimal): 4096 bytes / 4096 bytesDisk label type: dosDisk identifier: 0x00000000Disk /dev/sdb2 : 465,25 GiB, 499562602496 bytes, 975708208 sectorsUnits : sector de 1 × 512 = 512 bytesSector size (logical / physical) : 512 bytes / 4096 bytesE/S size (minimal / optimal): 4096 bytes / 4096 bytes
Curiously gparted show a warning about sdb2 :
459.75 GiB unallocated space in the partition.
To extend the filesystem so that it fills the partition, select the partition and choose menu item: Partition --> Check.

Not curious at all. Imager doesn't expand the filesystem. That's done as part of the initial boot.
Below the fdisk output for the SDCard from a laptop that has a SDCard reader:

Code:

Disk /dev/sda : 7,24 GiB, 7776239616 bytes, 15187968 sectorsDisk model: SD/MMC/MS PRO   Units: sector of 1 × 512 = 512 bytesSector size (logical / physical): 512 bytes / 512 bytesE/S size (minimal / optimal): 512 bytes / 512 bytesDisk label type: dosDisk identifier: 0x6f7af9ecDevice    Boot         Start      End  Sectors   Size Id Type/dev/sda1               8192   532480   524289   256M  c W95 FAT32 (LBA)/dev/sda2             540672 15187967 14647296     7G 83 LinuxDisk /dev/sda1 : 256 MiB, 268435968 bytes, 524289 sectorsUnits: sector of 1 × 512 = 512 bytesSector size (logical / physical): 512 bytes / 512 bytesE/S size (minimal / optimal): 512 bytes / 512 bytesDisk label type: dosDisk identifier: 0x00000000Disk /dev/sda2 : 6,98 GiB, 7499415552 bytes, 14647296 sectorsUnits: sector of 1 × 512 = 512 bytesSector size (logical / physical): 512 bytes / 512 bytesE/S size (minimal / optimal): 512 bytes / 512 bytes
For this trial to resolve the issue myself I made a backup copy of the whole tree in my Buster SDCard then I deleted everything in the SDCard boot partition and then I copied there (recursive) everything from SSD bootfs partition.
[EDIT] BTW, the SDCard also as a rootfs partition that was not used anymore in my Buster setup since in the end I reached to have a working rootfs in the SSD.

Here is the content of SSD's bootfs/cmdline.txt, that is, IIUC, read before the partition is mounted to rootfs/boot/firmware isn't it?

Code:

console=serial0,115200 console=tty1 root=PARTUUID=2d1ca6b1-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=FR

Looks like the correct PARTUUID. This all points to the USB/SATA adapter you're using or to the SSD. As I'm unlikely to have identical units there isn't anything else I can really suggest. Sorry.

Though I guess you could try a full boot from SD and see how the drives behaves. Or try updating the 4B'd firmware via SD card and the Bootloader/recovery image (look under "Misc utility images")

Statistics: Posted by thagrol — Sun Jan 25, 2026 6:17 pm



Viewing all articles
Browse latest Browse all 8374

Trending Articles