You are not logged in.
Hey everyone. So after seeing a few different topics on booting/installing from a USB drive, it got me thinking... What is it that makes writing the Bunsen live image to a USB, and then booting from it and installing the OS to a HDD/SDD, so problematic? Maybe not exactly "problematic" but what makes booting and isntalling the OS from a USB drive so different than doing it from a normal CD/DVD?
There are a few tools like unetbootin and rufus that seem to be available to handle this, but I've seen on here that there are issues with using them and the install process may not actually work. Is it something on Bunsen's side that involves the partition table? Is it just the live iso that has this issue with the USB tools like unetbootin?
I suppose i'm looking more for an underlying issue here that causes USB installs to differ from CD/DVD installs.
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
I used Win32 Disk Imager from Windows 7 to make my USB drive. It works with Bunsen if that helps.
Offline
With unetbootin is a case of Ubuntu not being compatible with Debian. The reast I don't know.
But is cp & or dd work, I'm happy.
Debian 12 Beardog, SoxDog and still a Conky 1.9er
Offline
Is it just the live iso that has this issue with the USB tools like unetbootin
^ This, although I would reverse that statement.
The Debian ISO images (and hence the BL images) are of the so-called "iso-hybrid" type.
These type of ISO images can be burned directly to both CD/DVDs and USB sticks without further modification.
As such, the recommended techniques should be used.
There is no ambiguity here, the methods are clearly linked in the BunsenLabs site Installation section:
https://www.debian.org/CD/faq/#write-usb
From that link:
Please note, that Debian advises not using unetbootin for this task. It can cause difficult-to-diagnose problems with booting and installing, so is not recommended.
The reason why tools such as unetbootin fail is because they they attempt to modify the ISO image as if it were an old-style non-isohybrid image (this used to be needed to boot a CD ISO image on a USB stick way back in the stone ages). This is not needed and will break isohybrid ISO images.
Offline
Sounds like unetbootin needs to be updated.
You can file or peruse bugs here and optionally just ask for bunsenlabs to have a bundled install option. But this seems like something they'll want to fix on their end since debian is a commonly used distro.
Offline
No, no, no ...
unetbootin is a relic of the past. Should be obsoleted instead!
Offline
It belongs in The Deborian Museum of Ancient Linux Software.
Debian 12 Beardog, SoxDog and still a Conky 1.9er
Offline
Thanks for the explanation Head_on_a_Stick.
Offline
this seems like something they won't want to fix on their end since debian is not Ubuntu.
Fixed.
Be excellent to each other, and...party on, dudes!
BunsenLabs Forum Rules
Tending and defending the Flame since 2009
Offline
Thanks for the explanation Head_on_a_Stick.
+1
Lenovo IdeaPad Yoga 13 | BunsenLabs Hydrogen (x64)
Intel Core i7-3537U | Intel HD4000 | 8GB DDR3 | 256GB SSD
Offline
dolly wrote:Thanks for the explanation Head_on_a_Stick.
+1
+1 as well!
Thanks as always HoaS! (and +1 for me for asking )
Makes sense though, which is why doing the dd ( or dcfldd) or cp method works better since you're by passing any assumptions about the format of the iso and target.
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
(and +1 for me for asking
)
Indeed! It's something I suppose I always wondered but never thought to ask.
Lenovo IdeaPad Yoga 13 | BunsenLabs Hydrogen (x64)
Intel Core i7-3537U | Intel HD4000 | 8GB DDR3 | 256GB SSD
Offline
I use unetbootin to make Puppy live drives. It allows you to allocate space on the drive and turns on persistence. I have to give it cu-does for that.
Offline
I'm not sure if this is at all relevant to the topic, but this is something I notice each time I write a BL iso to usb;
having to write the iso twice... note the differences in time taken, write speeds using the identical command.
Mod Note: Oversized image replaced with thumbnail link, please limit images to ~250x250px
-HoaS
Offline
bra10n, just out of curiosity, why *did* you have to write the iso twice to the usb? You wrote it to the same partition, so what was the point of that?
Also, does that difference in speed fluctuate each time you write? If you use a gui tool to burn a disc or something, do you see the same speed variations?
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
note the differences in time taken, write speeds using the identical command.
Looks like the first time it just writes to the buffer cache
Are you running one of Manjaro's weird-ass unusual kernels?
uname -a
cat /proc/cmdline
Also, please post text (using code tags) rather than pictures of text -- some forum users have very limited bandwidth
Last edited by Head_on_a_Stick (2016-06-17 06:33:00)
Offline
[bra10n@manjaro ~]$ uname -a
Linux manjaro 4.7.0-1-MANJARO #1 SMP PREEMPT Sun Jun 12 18:07:02 UTC 2016 x86_64 GNU/Linux
Here's an iso write for my Intel Compute Stick;
image redacted -HoaS
No need to write twice there.
I have no idea what is happening TBH... merely a suggestion this situation might be the cause of some complaining about failed bl iso -> usb. Maybe not.
Last edited by Head_on_a_Stick (2016-06-17 07:08:50)
Offline
Also, please post text (using code tags) rather than pictures of text -- some forum users have very limited bandwidth
Just saw your edit. Apologies, and noted.
Last edited by bra10n (2016-06-17 07:05:37)
Offline
[bra10n@manjaro ~]$ uname -a Linux manjaro 4.7.0-1-MANJARO #1 SMP PREEMPT Sun Jun 12 18:07:02 UTC 2016 x86_64 GNU/Linux
That's an RC kernel...
https://kernel.org/
Does it work normally with a stable kernel?
All the cases of reported failed transcriptions so far have been due to the user not reading the instructions, there are no faults with the ISO image so far.
EDIT: Thanks for reporting this
Last edited by Head_on_a_Stick (2016-06-17 07:09:52)
Offline
Does it work normally with a stable kernel?
All the cases of reported failed transcriptions so far have been due to the user not reading the instructions, there are no faults with the ISO image so far.
EDIT: Thanks for reporting this
To be clear I wasn't pointing any fingers or hinting at any failures. I simply offerred my observations as to how dd & BL iso's behave for me here on a Manjaro base. The kernel, whether an RC or stable makes absolutely no difference here as can be seen with the 14.04 iso write above.
My only wish is this info is somewhat helpful to you.
cheers
Offline