Failing to install 24.04

[kenvandine]

When running rpi-imager to install 24.04 Desktop I'm getting the following error and it never populates the storage target.

QProcess: Destroyed while process ("lsblk") is still running.

For me the target would end up being /dev/sda, which is an external USB SSD.

I have rev 630 installed from the stable channel

[waveform80]

Hmmm, works for me with revision 630 on a PC running jammy (22.04), writing to a 500GB SSD attached over USB3. What version of Ubuntu are you running the snap under? And just in case it makes any difference, could you paste in the full console output?

[kenvandine]

I'm running the snap on noble and using a 500G USB3 SSD as well.

Here's the console log, it continues like this forever

ken@monster:~$ rpi-imager 
Gtk-Message: 17:51:21.021: Failed to load module "canberra-gtk-module"
Gtk-Message: 17:51:21.024: Failed to load module "canberra-gtk-module"
Qt: Session management error: Could not open network socket
qrc:/main.qml:795:9: QML QQuickItem: Binding loop detected for property "height"
Enumerating drives took a long time: 1.9 seconds
Enumerating drives took a long time: 1.984 seconds
Enumerating drives took a long time: 1.887 seconds
Enumerating drives took a long time: 1.873 seconds

** (rpi-imager:568694): WARNING **: 17:51:47.436: atk-bridge: get_device_events_reply: unknown signature
Error executing lsblk
QProcess: Destroyed while process ("lsblk") is still running.
Enumerating drives took a long time: 2.012 seconds
Enumerating drives took a long time: 1.975 seconds
Error executing lsblk
QProcess: Destroyed while process ("lsblk") is still running.
Enumerating drives took a long time: 2.013 seconds
QProcess: Destroyed while process ("lsblk") is still running.
Enumerating drives took a long time: 2.02 seconds
Enumerating drives took a long time: 1.972 seconds
Error executing lsblk
QProcess: Destroyed while process ("lsblk") is still running.
Enumerating drives took a long time: 2.013 seconds
Enumerating drives took a long time: 2.026 seconds

[waveform80]

I've retried this with rpi-imager on my desktop Pi running noble, writing to a USB-attached SSD and it works fine for me there too. However, digging into upstream's code a bit, I find they've got a 2-second timeout on lsblk which you're apparently running into (I wondered why all the times were roughly 2 seconds). Does lsblk take a curiously long time to run for you? If so, any idea why?

[kenvandine]

Yes, I do have hundreds of snaps installed and lsblk returns all the loop mounts.

On Mon, May 20, 2024, 6:32 PM Dave Jones @.***> wrote:

I've retried this with rpi-imager on my desktop Pi running noble, writing to a USB-attached SSD and it works fine for me there too. However, digging into upstream's code a bit, I find they've got a 2-second timeout on lsblk https://github.com/raspberrypi/rpi-imager/blob/16c298beb43a9b3fc52a7d802df2707c2b7e688b/src/linux/linuxdrivelist.cpp#L53 which you're apparently running into (I wondered why all the times were roughly 2 seconds). Does lsblk take a curiously long time to run for you? If so, any idea why?

— Reply to this email directly, view it on GitHub https://github.com/waveform80/imager-snap/issues/6#issuecomment-2121325782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAANMBNA7CPRNOFHKJXNOFTZDJ2ZHAVCNFSM6AAAAABH75DBZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRRGMZDKNZYGI . You are receiving this because you authored the thread.Message ID: @.***>

[waveform80]

Sounds like this is a bug for upstream. I wonder why the 2s limit is there; my guess would be to deal with network block devices timing out or something, but I suspect it could be bumped without too much impact.

Out of curiosity could you time lsblk --bytes --json --paths --output-all for me? If we take that time and double it we should have a reasonable number to propose to upstream.

[kenvandine]

I've tried a bunch of times and it never actually takes a full 2s

real 0m1.276s user 0m0.819s sys 0m0.396s

[waveform80]

Ahhh ... I think I know what's going on here, now. 1.2s is an impressively long runtime, but I took a look at what lsblk --json --output-all actually outputs. On my system with a mere 37 snaps installed, it's throwing out 122KB of JSON (in 0.04s). I'm betting on yours it's throwing out several MB. This is probably filling the stdout pipe, which then blocks, and the process times out because the parent isn't continually draining the pipe. So, bumping the timeout is not going to help here; I need to have a read up on QProcess (been a good few years since I last played with Qt)!

[kenvandine]

Perhaps if we exclude loop devices?

Adding a "-e 7" to the lsblk command looks much better here

[waveform80]

Patch merged upstream now; it should make its way into the rpi-imager snap once the next release is cut; I'll leave this open until it's actually in the snap (note to self: remember to bump this in oracular, and maybe SRU to noble).