Expand SquashFS on SD Card: error superblock

Installing and Using OpenWrt
1

Hi,

trying to follow this doc https://openwrt.org/docs/guide-user/installation/installation_methods/sd_card

I'm using those images

https://downloads.openwrt.org/releases/23.05.0-rc3/targets/rockchip/armv8/openwrt-23.05.0-rc3-rockchip-armv8-friendlyarm_nanopi-r4s-squashfs-sysupgrade.img.gz

https://downloads.openwrt.org/releases/22.03.5/targets/rockchip/armv8/openwrt-22.03.5-rockchip-armv8-friendlyarm_nanopi-r4s-squashfs-sysupgrade.img.gz

I got this error:

[david@another r4s]$ LANG=C sudo fsck /dev/loop0
fsck from util-linux 2.38.1
e2fsck 1.46.5 (30-Dec-2021)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/loop0

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

I'm working on fedora and to be sure the partition to expand is the SquashFS one (/dev/sda2)

image
image1181×158 56.5 KB

2

Sometimes the writable overlay is created as f2fs (flash friendly) rather than ext4. Also I've seen posts indicating that the overlay is initialized at first boot, so in that case it might not be possible to expand the overlay immediately after copying the image to an sd card.

For the R4S, expanding it live on a booted devices works fine.

See this thread (and others) for info and examples:
https://forum.openwrt.org/t/resizing-the-hidden-overlay-filesystem-when-it-is-ext4-and-not-f2fs/140490

Note, that on many, if not most systems (non x86), the overlay expansion does not survive a system upgrade as most copy a new image to the raw storage device, wiping the partition table and the overlay can be at a new offset.

1 Like
3

thx !!

Ok, because for now I'm trying to tweak the SD Card from my laptop

I'm lost halfway.

Can you tell if I'm wrong or not:

  • losetup creates a "virtual" device /dev/loopX on top of a real device /dev/xyzX at a certain OFFSET
  • bad magic number: non existent >>> maybe created at first boot
  • next step: try it live on the target device !
4

Hi,

Yes.

Maybe, but you can see for yourself.

If you just want it done without understanding, just try that.

EDIT: For doing everything on linux make sure you have f2fs-tools installed, specifically fsck.f2fs.

$ which fsck.f2fs
/usr/sbin/fsck.f2fs

If that is installed, your offset is correct and fsck doesn't work, try running fsck.f2fs explicitly.

End EDIT.

If you want to learn how things work and possibly be able to do the expansion on linux before firstboot then here are the steps I recommend.

Flash the image to the sd card.
Determine offset for the overlay area.
Record the contents from that offset to a file with something like: hexdump -Cn 2048 /dev/sdb2 -s $OFFSET | cut -d\ -f 2- >/tmp/hdump-linux-offset

Put the sd-card in the router and boot it.

Log in and check that the loopback for /overlay is using the exact same offset that you saw on linux.

R4S# losetup -lv
NAME       SIZELIMIT  OFFSET AUTOCLEAR RO BACK-FILE  DIO LOG-SEC
/dev/loop0         0 9502720         1  0 /mmcblk1p2   0     512

Check the filesystem used for /overlay

R4S# mount | grep "/overlay"
/dev/loop0 on /overlay type ext4 (rw,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)

I am not running the same image as you are working with so don't expect your output to match mine.
Mine is currently ext4 but your setup might show up as f2fs. *** Especially for standard images ***
It has been posted that the filesystem type for overlay can change and one example was for the size, or amount of added packages in image builder can trigger it.

grab a hexdump of the beginning of /dev/loop0 and save it on your linux system.
R4S# hexdump -Cn 2048 /dev/loop0 | cut -d\ -f 2-

diff it with the first hexdump from linux.
If it is an exact match then you probably can expand /overlay on linux before firstboot using the tools appropriate for the filesystem.
Make sure that ypu have the f2fs-tools package installed on linux if needed.

poweroff your router and move the sd-card back to linux.

Proceed based on what you learned, adjusting the offset if needed or changing fsck tools etc.

If the hexdumps matched, start again from scratch and try to get it to work.

I did verify commands like losetup mount hexdump on my R4S but the overall steps were just thought out and some command options on linux may differ slightly so adjust as needed.

Good luck!

This is what the output of hexdump looks like on my router:

R4S# hexdump -Cn 2048 /dev/loop0 | cut -d\  -f 2- 
 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
 e0 5e 00 00 c0 7b 01 00  fc 12 00 00 c6 20 01 00  |.^...{....... ..|
 32 5e 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |2^..............|
 00 20 00 00 00 20 00 00  e8 07 00 00 c7 0c f9 50  |. ... .........P|
 c7 0c f9 50 0b 00 ff ff  53 ef 01 00 01 00 00 00  |...P....S.......|
 cf e0 da 63 00 00 00 00  00 00 00 00 01 00 00 00  |...c............|
 00 00 00 00 0b 00 00 00  00 01 00 00 3c 00 00 00  |............<...|
 c6 02 00 00 6b 04 00 00  c1 6c 28 dd f7 01 41 e6  |....k....l(...A.|
 ba cf 76 85 18 3a 54 20  72 6f 6f 74 66 73 5f 64  |..v..:T rootfs_d|
 61 74 61 00 00 00 00 00  2f 00 00 00 00 00 00 00  |ata...../.......|
 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|
 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 08 00 00 00 00 00 00 00  00 00 00 00 59 99 7f db  |............Y...|
 5b 19 4a 7a 91 12 b9 db  e5 f0 43 56 01 01 40 00  |[.Jz......CV..@.|
 0c 00 00 00 00 00 00 00  cf e0 da 63 0a f3 01 00  |...........c....|
 04 00 00 00 00 00 00 00  00 00 00 00 00 10 00 00  |................|
 01 80 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 00 00 00 00 00 00 00 00  00 00 00 00 00 00 40 00  |..............@.|
 00 00 00 00 00 00 00 00  00 00 00 00 20 00 20 00  |............ . .|
 02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 00 00 00 00 04 01 00 00  aa 01 00 00 00 00 00 00  |................|
 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
 00 00 00 00 00 00 00 00  dd 2d 00 00 00 00 00 00  |.........-......|
 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
 00 00 00 00 00 00 00 00  00 00 00 00 32 22 3a 59  |............2":Y|
00000800

I hope all this helps!

5

Thx a lot !!!

The r4s should be in my physical mail box today...

Can't wait

1 Like
6

OK !

WIth your guidance I manage to navigate with squashfs...

I confirmed the hexdump were OK etc etc

But in the end fsck and resize2fs are not working directly

What is working more or less with the official doc

Burn the image, boot with it.
Back to the PC, follow the expand doc but finish with

fsck.f2fs -f /dev/loop0
resize.f2fs /dev/loop0

But not working so well -> got a strange df -h (30 Go were said used...)

So I tried something else...

  • Burn the SD Card from the image (with balenaEtcher)
  • Used cfdisk /dev/_sdcard_device_X (/dev/sda for me) before booting to max the "overlay hosting" partition (/dev/sda2 for me, and nothing else from the official doc)
  • Boot my SD Card with the r4s

The overlay is created with max size at first boot...

1 Like
7

How can I alert the doc team to patch the doc ?

8

The docs are community maintained as far as I know. You can ask for access to edit it. There is a link at the bottom of the doc page, or probably all doc pages.

If you want to ask a recent editor to make an update, you can see who made changes by clicking on the icon on the right side of the page.
Screenshot from 2023-09-16 14-27-29

I hope this helps.

1 Like
9

@wryun Hi, just to signal that wiki on expanding squashfs SD card could be slightly reworked. The actual steps can be simplified. thx

10

Ah, my apologies, I wrote these steps for people who'd already booted from their SD card (which causes the overlay to be created).

If you've never booted, then there's no overlay FS yet, so it's safe to just change the partition size, and apparently it's smart enough to create an overlay that fills the partition.

I'm not an OpenWrt dev, just a user who requested docs access and apparently wrote something confusing, so thanks for raising this. I'll fix it up once I get a chance to verify the behaviour,

1 Like