Booting with noembed^W copy2fs.flg occasionally leaves package files mounted

[thirdwheel]

I've not been able to reproduce this reliably, but on occasion booting with noembed leaves some loops mounted, thus the filesystem with the packages gets left mounted read-write.

I've searched the scripts but I just can't see where this occurs in order to try fixing it.

[thirdwheel]

Adding that I experienced this on raspberry pi, not tested on x86*.

[clbr]

Are you sure it's related to noembed? Rpi has its own python loader, which has had some race conditions in the past IIRC.

[thirdwheel]

Are you sure it's related to noembed? Rpi has its own python loader, which has had some race conditions in the past IIRC.

Ok so I was under the impression that it was noembed that did this. It's the copy2fs.flg file.

[paul-1]

First. A squashfs is read only, it cannot be read-write.

Yes the copy2fs.flg should unmount all extensions, but I this functionality does not get tested much. copy2fs.lst is not implemented during boot.

What version of piCore are you using? Can you share some more information, perhaps on the forums.

[thirdwheel]

First. A squashfs is read only, it cannot be read-write.

I get this. This isn't what I'm talking about - this is the SD card itself. When it manages to unmount all extensions, it mounts as read-only, which is what I want - I don't want a write at the wrong time to corrupt the SD card. Occasionally a small number get left behind and when it tries to dismount, it fails with "device or resource busy".

What version of piCore are you using? Can you share some more information, perhaps on the forums.

This is piCore 14, though I've experienced the same thing in 13.1. I'm not using copy2fs.lst, only the "flg" file. I'm not sure what other information I can provide.

[paul-1]

A small number of what? Extensions left mounted? If so is it always the same extension?

provide screenscrapes of what specifically is left behind.

[thirdwheel]

Apologies for the late reply, the devices were at the office and we've been closed for two weeks.

I'm not sure if it's always the same extensions (running tests now to see) but it's not always the same number of packages. Sometimes it's one or two, sometimes it's six, and mixture in between.

I'll run a bunch of reboot cycles and gather data to see if it's the same packages each time when it does happen.

[thirdwheel]

Ok, test is complete - I rebooted the Pi one hundred times and collected the data. Raw results in this text file, but here's a rundown of the packages that were "left behind" in the 53 incidents where this happened:

$ grep '^/dev/loop' rpi_test_results.txt | sed 's/  */ /g' | cut -d' ' -f 6 | cut -d/ -f 4 | sort | uniq -c | sort -r
     13 Xlibs
     11 Xorg-fonts
     11 libX11
      6 adwaita-icon-theme
      2 xkeyboard-config
      2 giflib
      2 gamin
      2 fontconfig
      1 xdotool
      1 wpa_supplicant
      1 wifi
      1 shared-mime-info
      1 pcre
      1 pango
      1 libXau
      1 libtiff
      1 libfontenc
      1 libdrm
      1 imlib2
      1 gtk3
      1 graphite2
      1 gdk-pixbuf
      1 fribidi
      1 expat2
      1 dbus
      1 ca-certificates

Here's the packages I have installed:

openssh.tcz
TC.tcz
firefox.tcz
harfbuz.tcz
x11vnc.tcz
firmware-rpi-wifi.tcz
wireless_tools.tcz
wpa_supplicant.tcz
wifi.tcz
ntp.tcz
xdotool.tcz

[paul-1]

Thanks for the detail.

What pi are you using? And which OS image?

[thirdwheel]

This is a Raspberry Pi 4, 4gb and 8gb models. Image is piCore 13.1.0 - and now that I'm trying to reproduce it in 14.0.1, it's making a liar out of me.

[paul-1]

Well nothing has changed with tce-bootload since piCore12. If piCore 14.x is working, it might just have been a kernel level issue holding resources not allowing the unmount to occur, or issue in busybox mount/unmount. Let me know if you can get it to occur in 14.1

[thirdwheel]

I've run 14.1 through the ringer and I can't reproduce it. I did notice something interesting though - the tce-bootload script appears to make no attempt to check if a package has already been installed. I wonder if this could be a contributing factor given it forks the process each time it installs a package. I reinstalled 13.1 and enabled the "debugbootload" code, log attached - imlib appears three times in that log and it was the one left behind:

$ ssh [email protected] df
Filesystem           1K-blocks      Used Available Use% Mounted on
tmpfs                  3538252    377572   3160680  11% /
tmpfs                  1965692     14904   1950788   1% /dev/shm
/dev/mmcblk0p2          199648    150296     45176  77% /mnt/mmcblk0p2
/dev/loop43                640       640         0 100% /tmp/tcloop/imlib2

(ETA: also, I may have only just noticed the picore branch...)

[paul-1]

Well that log makes more sense, the copy of tce-bootload in that image is flawed, it is missing the #20 that never got merged. I thought I had included it anyway, but perhaps not. piCore14 for sure has that change.

I would just move to piCore14. And I'm getting ready soon to start work on 15.x

[thirdwheel]

Yeah I tested the picore14.1 rootfs against the picore 13 kernel (yes, I know, not a recommended configuration - nothing network related worked afterwards beyond ping) and the issue went away - I had a look at tce-bootload and it has the changes. I'm guessing by encapsulating all system command executions the same as mounts in older versions, you've covered a situation where a umount fails.

[thirdwheel]

Is it worth adding a check for a package being installed before trying? Might shave some time off boot for large package sets - also I'm one of those weirdos who thinks a CPU cycle is a terrible thing to waste. I haven't touched Python for a while but I did throw this together based on your fork.

[thirdwheel]

Closing this since this appears to have been fixed in picore 14.