New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#2951 - x86_64 ext4 generic: online resizing of root partition fails #7729
Comments
jneuhauser: Some time ago i´m able to install all needed packages into my rootfs partition without the need of resizing. The following commits changed the old size of 256 MB first to 128 MB and later to 104 MB. This really sucks as i do not understand the reason for such small and not resizeable rootfs partiitons on the x86_64 target. |
cronix: I can confirm this issue,
|
MarioT: Issue was already present in the x86_64 image on 19.07.7 Could be related to the partition not aligned to 4k boundary.
|
orev: I'm seeing the same issue on the 21.02.0 release and Mario's workaround did seem to work. However, I had better success resizing it when booted to a live USB (Fedora in my case). Using tune2fs/fsck causes the filesystem to need repairs, which just doesn't seem like the "right" way to approach it. |
SiNONiMiTY: This is working. Must be added as a reference for those who needs this. |
in my case; to resized my root (/) only these commands has been required # Remount root as ReadOnly
mount -o remount,ro /
# Check and Repair blocks
e2fsck -f /dev/sda2 then after a reboot |
for x86 openwrt 21.02:
|
resize2fs /dev/sda2resize2fs: Invalid argument While trying to add group #1 |
add a comment for caution: I modified the partition by fdisk, just delete partition and create it again, because the |
This looks to be a bug in If using imagebuilder you can apply this patch:
Then you can simply live resize with:
|
https://openwrt.org/docs/guide-user/installation/openwrt_x86 Documents here using |
I can confirm that the change to mkfs.ext4 as suggested by @jck112 above does indeed produce filesystems that are resizeable without any workarounds. Does anyone know if this is a change that would be acceptable as PR, or are there some reasons why make_ext4fs would be preferred by openwrt? As far as I can tell, e2fsprogs is already included in the build environment so this doesn't add any new dependency and maybe could even get rid of make_ext4fs completely. If I understand the loopback workaround correctly, it is basically tricking resize2fs to do offline resize despite the partition being mounted. That feels wildly unsafe, I assume the offline/online resize distinction is there for a good reason. |
I just realized a major problem using mke2fs: it does not change the uid/gid of files, so all the files in the created FS end up being owned by the uid/gid of builder! There is a PR for e2fsprogs that allows forcing a uid/gid, but idk if it'll ever get merged: tytso/e2fsprogs#126 Android seems to be doing something clever here, so maybe we could borrow from them |
In case anyone is following along, I did start working on a patchset to make mkfs.ext4 happen: https://github.com/openwrt/openwrt/compare/main...zokier:openwrt:mkfs.ext4?expand=1 It is still very much WIP and not much tested, but I did build one image with it already successfully :) I'll try to get that cleaned up and posted as PR when I'm ready |
jneuhauser:
Used HW/SW:
Steps to reproduce:
root@OpenWrt:~# opkg update && opkg install fdisk resize2fs
root@OpenWrt:~# fdisk /dev/mmcblk0 << EOF
p
d
2
n
p
2
33792
+256M
w
EOF
root@OpenWrt:~# resize2fs /dev/mmcblk0p2
Here are the output of resize2fs:
root@OpenWrt:~# resize2fs /dev/mmcblk0p2
resize2fs 1.45.4 (23-Sep-2019)
Filesystem at /dev/mmcblk0p2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/mmcblk0p2 to 65664 (4k) blocks.
resize2fs: Invalid argument While trying to add group #1
Here are the dmesg output:
root@OpenWrt:~# dmesg | tail -n 6
[50698.949591] EXT4-fs (mmcblk0p2): resizing filesystem from 32768 to 65664 blocks
[50698.957030] EXT4-fs (mmcblk0p2): resizing filesystem from 32768 to 65536 blocks
[50698.969299] EXT4-fs warning (device mmcblk0p2): reserve_backup_gdb:1033: reserved block 8 not at offset 7
[50698.978959] EXT4-fs warning (device mmcblk0p2): ext4_resize_fs:2120: error (-22) occurred during file system resize
[50698.989429] EXT4-fs (mmcblk0p2): resized filesystem to 32768
[50698.999227] EXT4-fs warning (device mmcblk0p2): reserve_backup_gdb:1033: reserved block 8 not at offset 7
Offline resizing does work as expected.
The text was updated successfully, but these errors were encountered: