-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing to install 24.04 #6
Comments
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? |
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
|
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 |
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
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAANMBNA7CPRNOFHKJXNOFTZDJ2ZHAVCNFSM6AAAAABH75DBZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRRGMZDKNZYGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
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 |
I've tried a bunch of times and it never actually takes a full 2s real 0m1.276s |
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 |
Perhaps if we exclude loop devices? Adding a "-e 7" to the lsblk command looks much better here |
On systems with a very large number of snap packages installed, there are a considerable number of loop devices. In this case, the `lsblk` command in linuxdrivelist fills the stdout pipe, blocks, and the rpi-imager process assumes it has timed out [1]. This is a trivial work-around that simply excludes loop devices (major=7) from the `lsblk` output. Given subsequent code excludes everything starting with `/dev/loop` anyway, there should be no change in user experience with this exclusion. [1]: waveform80/imager-snap#6
On systems with a very large number of snap packages installed, there are a considerable number of loop devices. In this case, the `lsblk` command in linuxdrivelist fills the stdout pipe, blocks, and the rpi-imager process assumes it has timed out [1]. This is a trivial work-around that simply excludes loop devices (major=7) from the `lsblk` output. Given subsequent code excludes everything starting with `/dev/loop` anyway, there should be no change in user experience with this exclusion. [1]: waveform80/imager-snap#6
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). |
On systems with a very large number of snap packages installed, there are a considerable number of loop devices. In this case, the `lsblk` command in linuxdrivelist fills the stdout pipe, blocks, and the rpi-imager process assumes it has timed out [1]. This is a trivial work-around that simply excludes loop devices (major=7) from the `lsblk` output. Given subsequent code excludes everything starting with `/dev/loop` anyway, there should be no change in user experience with this exclusion. [1]: waveform80/imager-snap#6
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
The text was updated successfully, but these errors were encountered: