error after loop module is loaded

[obbardc]

hi,
I have an error like this on the first system boot, mount fails with code 32 (and no further error). The second time the command is run it works OK.

I think it's due to loading loop module then attempting to setup the loop device so quickly.

Mar 16 07:24:23 localhost rauc[661]: Verifying bundle... 
Mar 16 07:24:23 localhost rauc[661]: Mounting bundle '/tmp/_download.raucb' to '/run/rauc/bundle'
Mar 16 07:24:23 localhost kernel: loop: module loaded
Mar 16 07:24:23 localhost rauc[661]: mount: /run/rauc/bundle: failed to setup loop device for /tmp/_download.raucb.
Mar 16 07:24:23 localhost rauc[661]: Failed mounting bundle: failed to run mount: Child process exited with code 32
Mar 16 07:24:23 localhost rauc[661]: installing https://fs.local/staging.raucb: Failed mounting bundle: failed to run mount: Child process exited with code 32
Mar 16 07:24:23 localhost rauc[661]: installing https://fs.local/staging.raucb: finished
Mar 16 07:24:23 localhost rauc[661]: installing `https://fs.local/staging.raucb` failed: 1
Mar 16 07:24:23 localhost system-bridge-d[743]: Failed mounting bundle: failed to run mount: Child process exited with code 32 (1)
Mar 16 07:24:23 localhost kernel: loop_set_status: loop0 () has still dirty pages (nrpages=1)

[obbardc]

according to the hassos guys, this patch should fix it: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/block/loop.c?id=7e81f99afd91c937f0e66dc135e26c1c4f78b003

[ejoerns]

@obbardc That is something I haven't seen myself yet, but I have never used loop support as a module yet.
In my opinion, on an embedded system targeted to use RAUC, the SquashFS support should normally be built-in.

The patch you mention is now part of released Linux v5.7, thus we could add a note in the integration documentation that loop should not be used as a module before 5.7.

@obbardc Is there any special reason to use SquashFS as a module instead of having it built-in that we should have in mind?

[obbardc]

That all sounds good to me. Some projects (like the linked HASSOS above) use rauc with Debian and with the default kernel config, squashfs is loaded as a module. Other than that, I can't see any problem with built-in squashfs. I'll add the documentation points mentioned to a MR at some point shortly.

…

On Wed, 17 Jun 2020, 00:12 Enrico Jorns, ***@***.***> wrote: @obbardc <https://github.com/obbardc> That is something I haven't seen myself yet, but I have never used loop support as a module yet. In my opinion, on an embedded system targeted to use RAUC, the SquashFS support should normally be built-in. The patch you mention is now part of released Linux v5.7, thus we could add a note in the integration documentation that loop should not be used as a module before 5.7. @obbardc <https://github.com/obbardc> Is there any special reason to use SquashFS as a module instead of having it built-in that we should have in mind? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#562 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH3LVRBZLSQ6MQ4NVMJ4V3RW7323ANCNFSM4LL4MAVQ> .

[ejoerns]

@obbardc Ok, for the Debian kernel I understand the issue. A MR for documentation sounds great.

Thanks!