There is no overlay filesystem in the pure ext4 images. It mounts like a
regular ext4 filesystem would on any other Linux system:
root@alix:~# mount
rootfs on / type rootfs (rw)
/dev/root on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)
none on /proc type proc (rw,noatime)
sysfs on /sys type sysfs (rw,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /dev type tmpfs (rw,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,noatime,mode=600)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
root@alix:~#
Overlays are only used on the JFFS2 or squashfs file systems. Both of
which can technically be used with this double root partition approach
as well, however ext4 makes the most sense on a compact flash card.
Adam
On 4/21/12 2:52 PM, Philip Prindeville wrote:
Sorry for being dense: where is the overlay filesystem during all of this?
/dev/sda4?
On 4/12/12 8:28 PM, Adam Gensler wrote:
I think the layout of the x86 filesystem needs to change in order to
support sysupgrade properly. Personally I'm using an alix2 board with
the ext4 filesystem (trunk image). I've not had much luck getting
reliable sysupgrades when using a pure ext4 filesystem. It works only
sporadically. More often than not the file system ends up corrupted.
I've been tinkering with the following layout:
/dev/sda1 = boot partition, contains two copies of the kernel, vmlinuz
and vmlinuz2
/dev/sda2 = root partition, contains ext4 file system
/dev/sda3 = second root partition, contains ext4 file system
The grub menu.lst would be modified such that vmlinuz would use rootfs
/dev/sda2. vmlinuz2 would use root in /dev/sda3.
When it is time to upgrade the image, the inactive rootfs partition
would be the one upgraded. /dev/sda1 would be mounted, the correct
kernel overwritten, and menu.lst updated to default to the new kernel.
This would allow the system to remain fully operational during an
upgrade, no ramdisk needed.
I've got this part working so far, albeit via manual partition creation
and upgrades. I'm hacking around in
target/linux/x86/image/gen_image_x86.sh and
target/linux/x86/image/Makefile to make the extra partition creation
automatic, an initial duplicate copy of the rootfs, and the appropriate
menu.lst entries.
Presumably once this infrastructure is in place it should be possible to
mount the upgraded rootfs and extract the sysupgrade backup tarball onto
it. That's just a theory though, I haven't gotten that far.
Thoughts?
Adam
On 4/10/12 6:24 PM, Philip Prindeville wrote:
Just a reminder that this bounty is still unclaimed.
On 2/10/12 3:11 PM, Philip Prindeville wrote:
Sysupgrade currently doesn't allow updating software in place without
clobbering the existing config (stored on the ext4 overlay filesystem that
immediately follows the jffs2 filesystem).
I've spoken to various interested parties using x86 hardware, and we'd like to
see if anyone is interested in doing bounty work to support sysupgrade on x86.
Thanks,
-Philip
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
