On Saturday, May 5, 2018 3:44:15 PM CEST Paul Spooren wrote: > On Thu, Mar 29, 2018 at 9:22 AM, Daniel Golle <dan...@makrotopia.org> > wrote: > > On Tue, Mar 27, 2018 at 07:42:18PM +0200, Christian Lamparter wrote: > >> This patch adds a image with squashfs as the root filesystem. > >> A rootfs_data partition will be generated on the first boot > >> and placed inside the rootfs partition (just after the squashfs > >> image). > >> [...] > > I tried the patch and the created squashfs works! However, trying a > sysupgrade errored saying it's unsupported. Ok, I can look into this, but I would need more information to debug it:
Can you please trace from where the message is coming from? By chance: Does it look it is created by the fwtool check? [0] ("Device $device is not supported by this image") or was it a different message? Also, can you please tell me which sysupgrade method (good-old sysupgrade via ssh/serial or the LuCI App) you used? If you went through ssh, it should look like this: (tested with rpi-b) |squashfs: |root@rpi-b:/tmp# sysupgrade -v openwrt-brcm2708-bcm2708-rpi-squashfs-sdcard.img.gz |Reading partition table from bootdisk... |Reading partition table from image... |Saving config files... |boot/config.txt |etc/config/attendedsysupgrade |[...] |etc/uhttpd.crt |Commencing upgrade. All shell sessions will be closed now. |Connection to rpi-b closed by remote host. |Connection to rpi-b closed. and for ext4: |root@rpi-b:/tmp# sysupgrade -v openwrt-brcm2708-bcm2708-rpi-ext4-sdcard.img.gz |Reading partition table from bootdisk... |Reading partition table from image... |Saving config files... |boot/config.txt |etc/config/attendedsysupgrade |[...] |etc/uhttpd.crt |Commencing upgrade. All shell sessions will be closed now. |Connection to rpi-b closed by remote host. |Connection to rpi-b closed. In my testing the LuCI app did work as well, as long as I tested with the rpi-3 (this is a bit of a problem, since it has a use... unlike the old rpi-b it replaced). The rpi-b is currently not in the snapshot.yml [2]. (But there's an easy WA: edit /tmp/sysinfo/board_name). As for adding the various RaspberryPI: There's the issue that the RPI-3(+) and RPI3-CM can also have the rpi-2 image installed because the user specifically wanted the 32-bit ARMv7 environment (over the 64-Bit ARMv8). And this is a problem, because the database model 'board_rename_table' in tables.sql [3] does not look like it can handle 1:n mappings required for this case. > Is it possible we have to teach the sysupgrade that squashfs is compatible, > too? I switched the brcm2708 target to x86's sysupgrade routines in "brcm2708: use x86's upgrade scripts for all rpi targets" [1]. This sysupgrade method works by comparing the MBR partition layout on the sdcard and if the layout is compatible it "dd" the (extracted) data into the /dev/mmcblk0p[12] partitions. The method and tools don't really care about whats in the partitions though. It should work regardless of what filesystem is being used... so yeah: o_O?! (I'm really wondering what went wrong?) > Except from that, it works and runs with no problems on my RPI3, please > merge. > > Regarding the doubts of Christian, is there any problem producing the > ext4 and squashfs per default? Maybe CDN? Since two images are now created for every (sub-)target. That said, x86 is doing the same with combined-ext4.img.gz and combined-squash.img.gz ;) . Maybe someone can provide some downloadstats on which image is more popular? Best Regards, Christian [0] <https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/base-files/files/lib/upgrade/fwtool.sh;h=49f02b7bd9ed735a43a487ea2d7d306a604be6c0;hb=HEAD#l34> [1] <https://github.com/openwrt/openwrt/commit/246916ddf4a1a95fd063e6d7c00d73bb0b5f36a6#diff-6c9507e28c71114ef1e6505ba5fb33b4> [2] <https://github.com/aparcar/attendedsysupgrade-server/blob/dev/distributions/openwrt/snapshot.yml> [3] <https://github.com/aparcar/attendedsysupgrade-server/blob/fe810d27556d60cfeb840b1d7079545ebd62d314/utils/tables.sql#L624> _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev