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
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 “/”?
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.
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.
I’m flashing a 32gb image to a new 128gb sd card and expand the partition. Could you give me the full context of the process? I copied nvresizefs.sh and nvresizefs.service to respective directories and manually executed the systemctl enable command and rebooted: nothing happened.