Rpi core image - root cannot mount

– Please Write here your help request, –

Trying to burn the rpi 5.0 core arm64 image on my SD card…
using raspberry pi 4b 8gb ram
Updated the eeprom.

Not using berryboot, I don’t want the 2019 berry boot image…I’m just doing it directly onto the SD. I’ve tried balena etcher and dd with different block sizes.

I keep getting the bad fs type or superblock error when I try to mount. I tried booting it, and it can’t recognize the ext4 or any partition. I tried gparted resize, it won’t allow me to continue because of fsck.

On fsck,
Superblock filesystem size says 446464 and physical size says 219136 blocks. Ive tried 32gb and 64gb sd cards.

This is what gets created everytime:
Partition 1 (boot) fat32, 252M
Partition 2 (should be root) ext4, 856M

Pls help

Edit: I tried recreating the partition from scratch to 1.2gb but still get the error after dd command.
2.0gb works. Will see how it boots up.

Edit #2: boots into emergency mode only, complaining of systemd-udevd.service services not loading. /boot/firmware is empty. Do I compile the kernel myself? I found a parrot arm64 kernel that’s labeled beta from gitlab…for rpi 4b.

Is this why the image I downloaded from parrotsec has “core” in the name? Barebones?

  • Parrot version in use (if you are not aware of it, open terminal and type cat /etc/os-release | grep VERSION):


  • Kernel version (if you are not aware of it, open terminal and type uname -r):

  • Logs/Terminal output (use pastebin or similar services):

  • Screenshots:

Ok, so update:

I used dd with bs=4096 to save rootfs.img. What I did next was delete the rootfs partition on the SD, and make a new ext4 partition that is 2GB and used dd again with the saved .img.

I can mount it now but let’s see what happens…I’ll update.

1 Like

Hello. We need a lot of feedback on this edition, so please keep us updated, thank you.

Set up network connection, but apt update shows something about gpg missing sig for parrot rolling. Will try again later. Good night


trying To do the last instruction messed me up. (Install the built kernel dpkg’s in cli mode leaves me unable to boot). It seems that 5.10 is already there anyway? It says 5.10 when I login.

I F*****ING DID IT !!! (I think?) I’m out of emergency mode and in cli now.

  • make your sd card msdos. Partition #1: fat16, 1024mb with 4mb unpartitioned at the beginning. lba flag.
    #2: ext4 with 50mb unpartitioned at the END (so it can auto-resize).

-download this and build ROOTFS

Mount your ext4 partition and cp -r (copy everything) from inside the built folder, rootfs, into the mountpoint.

Mount the fat16 partition.
-now copy contents in boot, from the “out” dir per the instructions, into /boot of the sd card.

-Go back to the first link and copy the contents inside the “configuration” folder directly into the fat16 boot directory. No configuration folder. Unmount all , eject, power-off, and DO IT

Our build works, indeed, you took the older (and less updated) one. The problem is that there was some error when creating the image. But we’re working out, I hope to get you the new image within a few days.

This does not use our own compiled kernel, so a lot of problems could arise. Use it as a test, but wait until you download it from our official website.

Thanks :slight_smile:

I just learned this via Wikipedia, forgive my being novice.
(It didn’t work for the parrot root rpi partition, but good to know anyway for other imgs,)

mount -o loop,offset=32256 /path/to/image.img /mnt/mountpoint

To determine the correct offset you can run

fdisk -l /path/to/image.img

and the offset you need is the start of a partition multiplied by sector size. For example if start is 128 and sector size is 512 then the offset is 65536.

Im getting the exact same error.

Try now, download the Raspberry Pi edition again. We’ve solved that problem.

1 Like

thank you it works.
can i know how it was fixed? so i understand better about kernels and compiling in general?

From what i know, we just modified preinstall packages rather than recompile kernel. @danterolle might know it better than me.

We have added the right package (taken from Raspbian) about the firmware and put it in the right directory. Basically it was a package conflict problem, so we had to test multiple times.