Using an IMG instead of an ISO to put Debian on a USB Flash drive
|
|
|
Comments (24)
4 earlier comments in the full thread.
I have run into the problem and yes, you can zero the device with dd and start over.
I have had this problem, and I've just taken the easy way out and reformatted in Windows and then went back to Linux.
dd works at the block level so it cares not at all for filesystems and their silly read-only restrictions. They are as the barking of the spiders, the whispering of the gnats.
*No, fs was not mounted,
*no, dd to descriptor block didn't work,
*no, dd'ing entire partition didn't work (this is where you go wrong TC: dd gives an error and bails out! Hence, I said: Try!)
*no, did not try 'badblocks -wsv',
*other commands tried: sfdisk, cfdisk and fdisk, all as root of course, all give errors,
*tried this on two USB sticks, at least one had a second ext3 partition on it (persistent storage for LiveUSB), and tried it on at least two SD cards which were fitted in some Icidu thingy which you connect via USB.
IIRC, I also tried putting the SD cards in a photo camera (Fuji probably) and it failed to 'format' (to FAT). Yes, as mentioned, Windows via VirtualBox solved the issue (one SD, two USB-sticks, one SD failed), three of four times.
If you search on Google, you can find a handful of people who posted the same problem, were also told to dd, but it didn't work. The 'U3' topic is noise and can be ignored, it's not the way to fix the issue. I tried some "un-U3" tools both in wine and VirtualBox, but to no avail. Moreover, my sticks didn't come with U3 installed.
Maybe I have to add I put the ISO-fs in place with dd, if such a thing would matter.
IIRC, I also tried putting the SD cards in a photo camera (Fuji probably) and it failed to 'format' (to FAT). Yes, as mentioned, Windows via VirtualBox solved the issue (one SD, two USB-sticks, one SD failed), three of four times.
If you search on Google, you can find a handful of people who posted the same problem, were also told to dd, but it didn't work. The 'U3' topic is noise and can be ignored, it's not the way to fix the issue. I tried some "un-U3" tools both in wine and VirtualBox, but to no avail. Moreover, my sticks didn't come with U3 installed.
Maybe I have to add I put the ISO-fs in place with dd, if such a thing would matter.
It would help a lot of you posted the error emitted.
Then I'd might have to 'offer' another SD-card to the ISO-gods if I can't fix it afterwards, but I'll see what I can do.
> The 'U3' topic is noise and can be ignored,
U3 is one of the software sets which comes on a partition formatted as ISO9660, which is why you see it in with your query. The USB sticks I've seen which come from the factory this way mostly used the U3 software.
U3 is one of the software sets which comes on a partition formatted as ISO9660, which is why you see it in with your query. The USB sticks I've seen which come from the factory this way mostly used the U3 software.
Quoting:I'd might have to 'offer' another SD-card to the ISO-gods if I can't fix it afterwards, but I'll see what I can do.No, just the error from trying to wipe with "dd". No need to destroy another card, when a card already destroyed should generate an error message.
BTW, about that U3... For someone trying to eliminate the U3 partition, this might be useful: http://en.wikipedia.org/wiki/U3#Removal
I guess I've been lucky. I haven't had a USB stick or SD card I couldn't recover. I'm not discounting Hans' experiences and I know he certainly knows what he is doing. I've just always found a way to recover.
One thought: Hans, you said taking dd to the entire partition didn't work. Did you consider taking dd to the entire device, as in wiping out the partition table? I had to do that with a 1GB USB stick that unetbootin turned into an ornament rather than anything functional.
One thought: Hans, you said taking dd to the entire partition didn't work. Did you consider taking dd to the entire device, as in wiping out the partition table? I had to do that with a 1GB USB stick that unetbootin turned into an ornament rather than anything functional.
Thanks for the comments Caitlyn, I've had such an ornament as well. Will try dd'ing to entire device and post a vid, just installed 'recordmydesktop'.
gus3: All 3 cards / sticks were recovered with Windows, and the 'bricked' one was thrown away by my sister. But I will try again.
gus3: All 3 cards / sticks were recovered with Windows, and the 'bricked' one was thrown away by my sister. But I will try again.
There it is, my first 'desktop capture' of a konsole session:
http://lxer.com/pub/files/hkwint/iso_failure.ogv
I was new to desktop capturing, so I hope you can view the OGG-file with mplayer or vlc (I tested them both).
Made sure the 'lock' pin of the physical card isn't set to 'lock'. This shows an 1GB SD-card fitted in my Icidu 13-in-1 cardreader (identified as Alcor). Dolphin can see the card and contents (forgot to do a cd and ls). It is configured with two partitions, sdd1 ISO9660 Fedora 13 partition of ~700+MB, probably made by unetbootin, but I'm not sure anymore; could be dd as well. It's mounted by Dolphin (not in the capture) and one other partition for persistent storage. FS type looks wrong (should be 96 I found out), but can't change it.
Sorry for my clumsy typing (should go to bed earlier), but it should show cfdisk, fdisk, badblocks and dd failing (and me trying to highlight errors).
If I feel like it, I could post a vid of how VBox-bin + WinXP saves the day tomorrow. I'll promise not to touch the SD card.
BTW on my desktop, mplayer hangs after playing the vid. Close manually if it does.
http://lxer.com/pub/files/hkwint/iso_failure.ogv
I was new to desktop capturing, so I hope you can view the OGG-file with mplayer or vlc (I tested them both).
Made sure the 'lock' pin of the physical card isn't set to 'lock'. This shows an 1GB SD-card fitted in my Icidu 13-in-1 cardreader (identified as Alcor). Dolphin can see the card and contents (forgot to do a cd and ls). It is configured with two partitions, sdd1 ISO9660 Fedora 13 partition of ~700+MB, probably made by unetbootin, but I'm not sure anymore; could be dd as well. It's mounted by Dolphin (not in the capture) and one other partition for persistent storage. FS type looks wrong (should be 96 I found out), but can't change it.
Sorry for my clumsy typing (should go to bed earlier), but it should show cfdisk, fdisk, badblocks and dd failing (and me trying to highlight errors).
If I feel like it, I could post a vid of how VBox-bin + WinXP saves the day tomorrow. I'll promise not to touch the SD card.
BTW on my desktop, mplayer hangs after playing the vid. Close manually if it does.
@hkwint:
Yeah, my mplayer also hanged. Minor issue, contrasted to the issue at hand.
I'm guessing that you used something like:
dd if=/path/to/image.iso of=/dev/sdd1
to write the ISO image to your Flash drive's first partition. Am I correct?
What is your output from "fuser -m /dev/sdd1" and "fuser -m /dev/sdd"? If you have any processes accessing the Flash drive in question, this will list them. You can then see what these processes are, via "ps".
And another, frustrating question: What if you set the partition type to 0x83 (Linux non-swap) before you copy the image to /dev/sdd1? Does the partition type remain the same? Frustrating, because I know it will require yet another recovery via a Win boot.
Now, as I type this, I'm running the "badblocks -wsv" command. I've had no problem of any kind mounting, unmounting, writing, re-writing, or wiping the partition in question (in my case, /dev/sdc1). I even set the partition type of /dev/sdc1 to 0x17, as yours was, before I wrote the ISO to the partition... And now badblocks has finished, and the partition is completely wiped.
It's nice to have experience in tech support. And it's especially nice to be able to use it, without answering to someone else about using it. Yay Freedom!
Yeah, my mplayer also hanged. Minor issue, contrasted to the issue at hand.
I'm guessing that you used something like:
dd if=/path/to/image.iso of=/dev/sdd1
to write the ISO image to your Flash drive's first partition. Am I correct?
What is your output from "fuser -m /dev/sdd1" and "fuser -m /dev/sdd"? If you have any processes accessing the Flash drive in question, this will list them. You can then see what these processes are, via "ps".
And another, frustrating question: What if you set the partition type to 0x83 (Linux non-swap) before you copy the image to /dev/sdd1? Does the partition type remain the same? Frustrating, because I know it will require yet another recovery via a Win boot.
Now, as I type this, I'm running the "badblocks -wsv" command. I've had no problem of any kind mounting, unmounting, writing, re-writing, or wiping the partition in question (in my case, /dev/sdc1). I even set the partition type of /dev/sdc1 to 0x17, as yours was, before I wrote the ISO to the partition... And now badblocks has finished, and the partition is completely wiped.
It's nice to have experience in tech support. And it's especially nice to be able to use it, without answering to someone else about using it. Yay Freedom!
As promised, a kinda boring 1 minute vid 1of how XP saved the day, showing the drive is mounted via VirtualBox at the end:
http://lxer.com/pub/files/hkwint/iso_failure_xp.ogv
Showing what cfdisk and fdisk think of the disk after halting WinXP afterwards; seems Linux and Windows don't understand each other. Output doesn't make sense at all, though booting XP a second time, it's completely fine with the SD card.
http://lxer.com/pub/files/hkwint/after.ogv
But the nice thing is, after Windows did something 'miraculous' to the card, I can dd the complete drive (of=/dev/sdd) with zeros, and reformat using fdisk. Which means, Linux doesn't see the drive as read-only anymore.
Now I'm going to try the fuser / partition type hints.
http://lxer.com/pub/files/hkwint/iso_failure_xp.ogv
Showing what cfdisk and fdisk think of the disk after halting WinXP afterwards; seems Linux and Windows don't understand each other. Output doesn't make sense at all, though booting XP a second time, it's completely fine with the SD card.
http://lxer.com/pub/files/hkwint/after.ogv
But the nice thing is, after Windows did something 'miraculous' to the card, I can dd the complete drive (of=/dev/sdd) with zeros, and reformat using fdisk. Which means, Linux doesn't see the drive as read-only anymore.
Now I'm going to try the fuser / partition type hints.
Surprise, setting it to 0x83 (and maybe unsetting DOS compatible mode) solves the issue!
So, here's the next session:
--- fdisk /dev/sdd; n, p, 1, [Enter], [Enter], t, 0x83, w, p:
shows:
/dev/sdd1 2048 1983999 990976 83 Linux
I thought the topic of this tread / article was Debian, hence a Debian derivative following.
#md5sum linuxmint-9-gnome-cd-i386.iso: Turned out OK via Google; #dd if=${PWD}/linuxmint-9-gnome-cd-i386.iso of=/dev/sdd1
707096576 bytes (707 MB) copied, 295.35 s, 2.4 MB/s
Afterwards, type is still 0x83, as suggested.
#fuser -m /dev/sdd1 returns nothing; empty.
---
Afterwards fdisk can delete the partition first time.
I think the faulty SD-card was created with a tool like unetbootin or something, next thing on the list to find out.
So, here's the next session:
--- fdisk /dev/sdd; n, p, 1, [Enter], [Enter], t, 0x83, w, p:
shows:
/dev/sdd1 2048 1983999 990976 83 Linux
I thought the topic of this tread / article was Debian, hence a Debian derivative following.
#md5sum linuxmint-9-gnome-cd-i386.iso: Turned out OK via Google; #dd if=${PWD}/linuxmint-9-gnome-cd-i386.iso of=/dev/sdd1
707096576 bytes (707 MB) copied, 295.35 s, 2.4 MB/s
Afterwards, type is still 0x83, as suggested.
#fuser -m /dev/sdd1 returns nothing; empty.
---
Afterwards fdisk can delete the partition first time.
I think the faulty SD-card was created with a tool like unetbootin or something, next thing on the list to find out.
Or, Windows screwed around with the partition type ("Hidden HPFS/NTFS") without telling anyone. That passes both Occam's Razor and Hanlon's Razor with ease.
What I thought, but I don't think Windows is to blame though. More 'research' to follow.
Turns out it was Fedora 13 (KDE) iso who set the 'type' to 17, NTFS/HPFS hidden, even if you set type 83 before.
However, when dd'ing that one, you can delete it afterwards. So probably the problem occurs if you use a tool / script like livecd-creator or something.
However, when dd'ing that one, you can delete it afterwards. So probably the problem occurs if you use a tool / script like livecd-creator or something.
I can't imagine that happening as a side-effect. That has to be deliberate.
But dagnabbit, WHY?!?
But dagnabbit, WHY?!?
Even more questionable as the HOWTO suggest setting 'type' to 06 (FAT16):
http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo#How_to_P...
http://fedoraproject.org/wiki/FedoraLiveCD/USBHowTo#How_to_P...
Well, that's another DOS/Windows partition type. I suppose setting it to 0x83 (Linux non-swap) would be unusable to Windows.
No, I don't intend to test that hypothesis.
No, I don't intend to test that hypothesis.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
