Nano nvresizefs: on-line resizing required

Hi,

we have flashed SD card for Jetson Nano with JetPack image and installed libraries to it. I have taken the image using dd command. The goal is to have an image ready for production so that each device would have to install libraries but have already tested image instead.
We are aware of risks with passwords and other private data.

We’d like the image to expand itself on the first boot on the SD card.

I have added nvresizefs.sh back to /etc/systemd and added the service

cat <<EOT > nvresizefs.service
[Unit]
Description=Resize SD Card root partition and filesystem
Before=nvfb.service

[Service]
Type=oneshot
ExecStart=/etc/systemd/nvresizefs.sh

[Install]
WantedBy=multi-user.target
EOT

cp nvresizefs.service /etc/systemd/system
systemctl enable nvresizefs.service

Now, the last command of nvresize script: resize2fs /dev/mmcblk0p1 fails with message:
Filesystem at /dev/mmcblk0p1 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 4

What did I forget to do?

when I try to run the script when I ssh on as root then I get extra error line
resize2fs: Permission denied to resize filesystem

Cheers,
Martin

EDIT:

dmesg commad revealed this:

[    5.055347] EXT4-fs (mmcblk0p1): warning: mounting fs with errors, running e2fsck is recommended
[    5.071447] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[    5.081440] VFS: Mounted root (ext4 filesystem) on device 179:1.

[   11.008690] tegradc tegradc.0: unblank
[   11.008924] tegradc tegradc.1: blank - powerdown
[   11.512106] EXT4-fs warning (device mmcblk0p1): ext4_resize_begin:45: There are errors in the filesystem, so online resizing is not allowed
[   12.776063] wlan0: authenticate with a0:04:60:94:37:25
ubuntu@ubuntu-VirtualBox:/media/ubuntu$ sudo e2fsck -f /dev/sdb
[sudo] password for ubuntu: 
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb

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>

Found a gpt partition table in /dev/sdb

so did I take the image wrong? Did I flash it wrong? Why are there errors on the card to start with? Is there a way to fix them automatically when nano boots?

I can’t say for sure, but probably the filesystem was expanded incorrectly or reboot was not clean. The corruption cannot be allowed when resizing, nor resizing when the filesystem is mounted. The filesystem must be repaired before that resize can continue.

Is the Nano being shut down cleanly? Was the partition ever modified in such a way that the filesystem was not expanded with it? Can you verify the resize occurs prior to mount on “/”?

Hi @linuxdev,

the FS was mounted and that’s how nano does it as well. It expands the root partition upon first start. So they do it when the partition is mounted.

I have freshly flashed the SD card with jetpack image and ran e2fsck. Unfortunately, the FS is already corrupted there.

root@ubuntu-VirtualBox:/dev# e2fsck /dev/sdb
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb

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>

Found a gpt partition table in /dev/sdb

“/dev/sdb” is not a partition, it is the device as a whole. What do you see from “sudo gdisk -l /dev/sdb”? Most likely you need to run against “/dev/sdb1”, the first partition of sdb.

now, this is weird. Is my SD card in error or not :) It looks like the FS is ok, but the resize doesn’t work

root@ubuntu-VirtualBox:~# umount /dev/sdb1
root@ubuntu-VirtualBox:~# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 124735488 sectors, 59.5 GiB
Model: uSD UHS2 RDR    
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): D048AD43-24FD-4DED-B06E-7BB8ED98158C
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 62521310
Partitions will be aligned on 2048-sector boundaries
Total free space is 17854 sectors (8.7 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1           24576        62521310   29.8 GiB    8300  APP
   2            2048            2303   128.0 KiB   8300  TBC
   3            4096            4991   448.0 KiB   8300  RP1
   4            6144            7295   576.0 KiB   8300  EBT
   5            8192            8319   64.0 KiB    8300  WB0
   6           10240           10623   192.0 KiB   8300  BPF
   7           12288           13439   576.0 KiB   8300  TOS
   8           14336           14463   64.0 KiB    8300  EKS
   9           16384           17663   640.0 KiB   8300  LNX
  10           18432           19327   448.0 KiB   8300  DTB
  11           20480           20735   128.0 KiB   8300  RP4
  12           22528           22687   80.0 KiB    8300  BMP
root@ubuntu-VirtualBox:~# e2fsck /dev/sdb1
e2fsck 1.44.1 (24-Mar-2018)
/dev/sdb1: clean, 204237/1957888 files, 4954768/7812091 blocks

Have you verified that the resize is being applied to sdb1 and not sdb? If there is some script to detect “APP” partition within sdb, then this would work, but I don’t know for sure what is going on.

Hi zdary,

You may want to have a look at this script.

This script is to be executed right before the shutdown and dumping the image on your host PC.

Hi,

The problem in our case was incorrect shut down of the device resulting in FS corruption
i.e. wrong count of free blocks.
That’s why it didn’t work.

Cheers,
Martin