Hi Tim,
Am 2017-08-15 01:29, schrieb Tim Harvey:
On Thu, Sep 1, 2016 at 11:05 PM, Gerhard Bertelsmann
<i...@gerhard-bertelsmann.de> wrote:
Hi,
I want to distribute a small Lede image for BananaPi. This image
should be automatically expanded to the maximum size of the SD card
like the way Raspbian is doing it.
But resize2fs exits with a fault.
Gerd,
Did you ever get to the bottom of this? I'm running into the same
issue and see you never got a response from the dev mailing list.
nope. There was some activity on the list weeks later but the
problem wasn't fixed. As you alreday know, resize2fs still throws
the same error.
I'm using a larger filesystem (2GByte) as workaround.
Regards,
Tim
Regards
Gerd
Here the steps I have done:
Before reboot:
root@Modellbahn-BPi:/# fdisk -l | egrep "Device|^/dev"
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 2048 43007 40960 20M c W95 FAT32 (LBA)
/dev/mmcblk0p2 45056 1093631 1048576 512M 83 Linux
Resized and booted:
root@Modellbahn-BPi:/# fdisk -l | egrep "Device|^/dev"
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 2048 43007 40960 20M c W95 FAT32 (LBA)
/dev/mmcblk0p2 45056 15130623 15085568 7.2G 83 Linux
root@Modellbahn-BPi:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 504040 65256 428300 13% /
tmpfs 515568 44 515524 0% /tmp
tmpfs 512 0 512 0% /dev
And now try to resize:
root@Modellbahn-BPi:~# resize2fs /dev/mmcblk0p2
resize2fs 1.43.1 (08-Jun-2016)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing
required
old_desc_blocks = 1, new_desc_blocks = 1
resize2fs: Invalid argument While checking for on-line resizing
support
which also shows following on the console:
[ 120.846183] EXT4-fs (mmcblk0p2): resizing filesystem from 131072 to
1885696 blocks
[ 120.910386] EXT4-fs warning (device mmcblk0p2):
reserve_backup_gdb:968:
reserved block 32 not at offset 31
[ 120.920136] EXT4-fs (mmcblk0p2): resized filesystem to 1885696
[ 124.239447] EXT4-fs warning (device mmcblk0p2):
ext4_group_extend:1730:
can't shrink FS - resize aborted
As far as I know (googled), the small GDT number is the problem. My
slightly
modified image (size 256M -> 512M and 12,000 -> 48,000 inodes) looks
like:
% tune2fs -l lede-sunxi-root.ext4
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 57f8f4bc-abf4-655f-bf67-946fc0f9f25b
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode filetype
extent
sparse_super large_file uninit_bg
Filesystem flags: unsigned_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Remount read-only
Filesystem OS type: Linux
Inode count: 48000
Block count: 131072
Reserved block count: 0
Free blocks: 109688
Free inodes: 40349
First block: 0
Block size: 4096
Fragment size: 4096
Reserved ks: 31
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 12000
Inode blocks per group: 750
Last mount time: n/a
Last write time: Thu Jan 1 01:00:00 1970
Mount count: 0
Maximum mount count: -1
Last checked: Thu Jan 1 01:00:00 1970
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: tea
Journal backup: inode blocks
I had a look at make_ext4fs.c but I don't get any clue how to increase
the amount of GDT entries created.
Does anybody know how I could influence the GDT number ?
Regards
Gerd
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
