On 2017-09-29 13:04, Daniel Golle wrote: > On Fri, Sep 29, 2017 at 12:20:08PM +0200, Felix Fietkau wrote: >> On 2017-09-11 02:33, Philip Prindeville wrote: >> > Changing the subject from the previous thread as it turned out to not have >> > to do with sysupgrade at all. >> > >> > What I can tell is this, having added some tracing to fstools. >> > >> > We get to the call to system() in rootdisk_volume_init(): >> > >> > https://git.lede-project.org/?p=project/fstools.git;a=blob;f=libfstools/rootdisk.c;h=dd00c1b4e5b4aa9b748610fa3e93d301a67101a7;hb=HEAD#l269 >> > >> > and it never seems to return. The value of “str” is “mkfs.f2fs -q -l >> > rootfs_data /dev/loop0”. >> > >> > What would cause this to hang rather than return an error? >> I've used sysrq to trace this and found out that it's hanging in the >> getrandom system call, which could be used through util-linux library >> code. That also explains why the update broke it. >> >> I will prepare a patch that forces util-linux to stick to /dev/urandom >> instead - that should hopefully fix this for good. > > mkfs.f2fs also uses getrandom(3) and hangs there for some minutes when > creating the initial snapshot... I don't see any direct calls to getrandom from mkfs.f2fs, so I assume they are issued through util-linux libuuid. That would explain why my change fixes the issue (with f2fs as overlay fs) for me, and results in the following new warning:
[ 8.756017] random: mkfs.f2fs: uninitialized urandom read (16 bytes read) - Felix _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
