Why Installing From a USB Is Difficult

xaos52 · 2016-06-17 08:54:47

Here is an explanation for this

The first dd command writes to buffer cache and terminates almost immediately. dd is in async mode. It terminates when the data has been written to cache. Transferring the content of the cache to the device is the kernels reponsability. It does this by spawning a 'kernel thread'.

Then the second dd command is launched. It also tries to write the data to cache, but the kernel detects that the data in cache has not been written out to disk yet, and a new (destructive) write command for device /dev/sdb arrives. The kernel stops the kernel thead still running and forces the new dd process to write the output to /dev/sdb without using the cache.
That is why it takes so much longer.
But now dd finishes only when the data has effectively been written to cache.

How to prevent this:
Use the 'sync' command immediately after the dd command, and the image on /dev/sdb will be OK after the first dd.

dd if=... of=... bs=4M; sync

Head_on_a_Stick · 2016-06-17 19:59:01

^ Good call Doctor!

And this is why code tags should be used for terminal output: I didn't even notice the lack of `;sync` in the screenshot...

:8

hhh · 2016-06-17 23:41:49

https://forums.bunsenlabs.org/viewtopic … 968#p28968

lowrider · 2016-06-18 00:03:03

xaos52 wrote:

dd if=... of=... bs=4M; sync

Yes this is what i did for ages and it worked, ever.
But, what about those new to BL and coming from a foreign system (err windows)?
I am free from microsoft for a long time, but just curious.

pvsage · 2016-06-18 00:08:36

^ Debian has that covered:
https://www.bunsenlabs.org/installation … key-method
https://www.debian.org/CD/faq/#record-windows
https://www.debian.org/CD/faq/#record-mac

lowrider · 2016-06-18 00:19:28

pvsage wrote:

^ Debian has that covered:
https://www.bunsenlabs.org/installation … key-method
https://www.debian.org/CD/faq/#record-windows
https://www.debian.org/CD/faq/#record-mac

^Ah ok. Thank you sage. So is someone here to confirm that this worked for a win user?

Horizon_Brave · 2016-06-18 03:46:59

But I'm still unclear as to why dd needed to be run twice. Once he ran it the first time, yes it would have gone to the buffer first, but how long does that take to get written to disk? Surely if you just wait, until it's written, you can avoid this whole issue, correct?

pvsage · 2016-06-18 05:17:10

^ Theoretically. Note that the advice on the Debian wiki for writing to a USB drive includes the ';sync', which (in most cases) won't return to the command prompt until the cache has been flushed.

My general rule of thumb has been to wait until a couple minutes after the light on the USB drive has stopped flashing, then issue a second 'sync' just to be sure before removing the drive.

damo · 2016-06-18 09:33:46

lowrider wrote:

...
But, what about those new to BL and coming from a foreign system (err windows)?
....

Then it is up to them to do some basic research about how to install. In the case of BL, the information is provided on the Installation page, as pointed out by @pvsage.

bra10n · 2016-06-19 04:50:34

pvsage wrote:

^ Theoretically. Note that the advice on the Debian wiki for writing to a USB drive includes the ';sync', which (in most cases) won't return to the command prompt until the cache has been flushed.
My general rule of thumb has been to wait until a couple minutes after the light on the USB drive has stopped flashing, then issue a second 'sync' just to be sure before removing the drive.

I tried adding the sync command to write a BL iso to usb and what I observed was exactly the above scenario. The prompt returned beyond 8min write time (8min being the last time I checked) and sometime before the 15min mark when I again returned.

I tried booting the usb on this laptop for no result. Booted to a flashing prompt only.

I'm not trying to be difficult here and merely began posting in this thread simply to outline my observations. I'm not tech savy so I can't explain why this is occuring... I just know what works for me.

Head_on_a_Stick · 2016-06-19 08:57:28

bra10n wrote:

I tried booting the usb on this laptop for no result. Booted to a flashing prompt only.

The system has booted correctly but the graphical session has failed, use <Ctrl>+<Alt>+F2 to switch to a TTY from which you can log in.

To get the graphical session working, try disabling kernel modesetting by following the advice in these two links:
https://wiki.archlinux.org/index.php/Ke … odesetting
https://wiki.archlinux.org/index.php/Ke … eters#GRUB

#21 2016-06-17 08:54:47

Re: Why Installing From a USB Is Difficult

#22 2016-06-17 19:59:01

Re: Why Installing From a USB Is Difficult

#23 2016-06-17 23:41:49

Re: Why Installing From a USB Is Difficult

#24 2016-06-18 00:03:03

Re: Why Installing From a USB Is Difficult

#25 2016-06-18 00:08:36

Re: Why Installing From a USB Is Difficult

#26 2016-06-18 00:19:28

Re: Why Installing From a USB Is Difficult

#27 2016-06-18 03:46:59

Re: Why Installing From a USB Is Difficult

#28 2016-06-18 05:17:10

Re: Why Installing From a USB Is Difficult

#29 2016-06-18 09:33:46

Re: Why Installing From a USB Is Difficult

#30 2016-06-19 04:50:34

Re: Why Installing From a USB Is Difficult

#31 2016-06-19 08:57:28

Re: Why Installing From a USB Is Difficult

Board footer