Failure and inconsistency

[Brottweiler]

Category

• behavior (bootiso didn't behave as promised)

Describe the bug

I hate using dd, and i dislike the GUIs (like etcher), so bootiso seemed to fit my case. When using it however, it seems like it succeeds, but actually using the USB stick to boot with causes failure.

I copied Ubuntu MATE 18.04.2 LTS with bootiso, and booted my old laptop with it. The Ubuntu MATE logo shows up with 5 dots. Two dots fill up, then freeze. Starting with nomodeset shows me errors scroll by, then getting a kernel panic.

I try another USB stick. Same issue, but this time the errors are different, then kernel panic.

I then try plain old dd and it worked like intended, I can boot the laptop with the USB stick and install MATE.

Expected behavior (for behavioral bugs only)

I expect bootiso to work as intended so I can boot the computer with my USB stick and install the distro.

To Reproduce

1. Run bootiso ubuntu-mate-18.04.2-desktop-amd64.iso with this ISO

2. See error log:

I don't have the log for bootiso anymore (unless its logged to a file somewhere), but I can tell you the output was fine. Bootiso said the action was fine, and bootiso was using dd because it said it was using dd.

Environment:

OS: Arch Linux x86_64
Kernel: 5.0.7-arch1-1-ARCH
Packages: 1095 (pacman)
Shell: zsh
WM: Openbox
Terminal: st
Terminal Font: Misc Fixed
CPU: i5-4460 (4) @ 3.4GHz
GPU: GeForce GTX 1050 Ti
Memory: [━━━━━━━━━━━━━━━] 2492MiB / 7840MiB
Disk (/): [━━━━━━━━━━━━━━━] 29G / 110G (28%)
Disk (home): [━━━━━━━━━━━━━━━] 77G / 439G (19%)

Additional context (optional)

As I said, I was using dd bs=4M if=path/to/archlinux.iso of=/dev/sdx status=progress oflag=sync as adviced here just fine, where bootiso failed, twice, on two sticks.

[jsamr]

@Brottweiler I did try to reproduce and I could boot without issue. I'm using kernel 4.19.

Normally, a call to sync after the dd invocation guarantees that all the blocks are transferred before ejecting the device. The corruption you are referring to makes me think this sync phase might have been skipped, or the device ejected too early. Did you notice any difference in the duration of those two tasks, dd and bootiso ?

oflag=sync seems to achieve the same purpose.
I forgot to include bootiso version in the bug template ; I bet you are using the latest 3.3.1?
If so, you could try to apply this patch (adding the sync option) and tell me if you can reproduce the same bug:

--- a/bootiso
+++ b/bootiso
@@ -1222,7 +1222,7 @@ copyWithDD() {
                typeset statusFile=$(createTempFile "bootiso-status")
                temporaryAssets+=("$statusFile")
                (
-                       dd if="$selectedIsoFile" of="$selectedDevice" bs=4MB status=none
+                       dd if="$selectedIsoFile" of="$selectedDevice" bs=4MB status=none oflag=sync
                        echo "$?" >"$statusFile"
                ) &
                pid=$!

PS I have the feeling it might be related to kernel 5 and the fact I am calling sync from a parent shell.

[Brottweiler]

Both dd and bootiso took roughly the same amount of time. One thing I did notice was that when bootiso said it was finished, it takes a really long time until bootiso exits and I get my prompt back.

I seem to be using 3.3.0 from the AUR, I just flagged it out of date.

Also, oflag=sync is probably new-ish, because the recommended procedure used to be to just call && sync afterwards but now it seems to be "integrated" with dd.

I'll try the patch when I get the chance. Thanks!