Just as I zipped my backpack closed to head home from JavaOne, I overheard a conversation. One of the JBoss booth staff had been trying to find something on a media for an attendee. I inquired, and it turned out they were looking for Fedora media; one of the fellows had a laptop to resurrect.
Naturally I said, “I can take care of that,” and I woke my machine from sleep while getting out a USB flash drive. Unfortunately, in packing, the extended battery had moved a bit and the machine was powered down. I booted, where I faced the usual sight of Compiz (aka “Desktop Effects”) not started, except this time it won’t start manually. Not wanting to waste their time (or mine), I switched to a virtual console. I could get them the live USB of Fedora 9 Preview in a few seconds that way, too, straight from memory without referring to the Fedora Live USB How To.
Plugged in the USB drive and typed:
sudo livecd-iso-to-disk /home/iso/Fedora-9-Preview-i686-Live.iso /dev/sda1
The copy started, and we commented on how fast it was going. But after it reached a small percentage, it complained the disk was full. That seemed odd, but I figured I would reboot and see if it worked; maybe the media was bad?
OK, some of you have figured it out already. Can you guess what happened when I rebooted?
I got told “No operating system.” Hmm, guess the live USB didn’t take, right? No, reboot again and see what happened. No operating system found for the laptop itself.
Oh! The USB key first partition was /dev/sdb1. My laptop’s hard drive /boot partition, that was the one on /dev/sda1. That was the one I filled up. At the same time, the MBR must have been overwritten, so GRUB wouldn’t boot.
Naturally, I had no rescue media on me and couldn’t recover quickly and get these gentlemen on their way. I had to send them off disappointed, and myself home, speeding down the peninsula, with a thrashed MBR.
Lesson? Well, sure, be careful. But we are telling people it is so easy to make these Live USB keys, yet … if they get one letter incorrect in the wrong direction, they hose their system and ability to recover easily when they do reboot. It’s a hidden problem, too; it could be weeks until they reboot and have no recollection of the chain of events.
Not sure where to focus for a fix. Is it in using the sd* namespace? Having all media be in such a similar path is a bit scary, since some media is treated destructively (CD and DVD writables, flash media) where others are not.
We certainly need to educate people who are going to be making these drives to very carefully check what the device path is for their mounted media before proceeding. We don’t typically direct normal users to do things so close to their /boot, or, well, any other partition. The fact that this happened to me, a fairly experienced Linux sysadmin, could either be a clear case of PEBCAK and moving too fast, or it could be a sign of warning about spreading these tools to people.
Perhaps I should make a feature request of livecd-tools to do a check that the partition about to be written to doesn’t happen to have a system label, such as /boot or /home. 🙂
The underlying problem is that all those scripts which mess around with partitions and partition tables need or want to be root.
When I, as a user, want to write data to a memory stick I have just plugged in, I should not need any root access for that.
Is it possible to query what bus is a sdx drive is installed? If is is easy we should patch livecd-iso-to-disk to test if the partition is on a usb connected disk and ask for confirmation.
Another easy sanity test is to check if the target partion is mounted. I will fill those out in bugzilla.
[…] Karsten, I don’t think we should be using, or telling others to use, the /dev/sd* device names at all anymore, when there’s a far better alternative — /dev/disk/*. […]
Suggest to also make the tool check if the target device is mounted / claimed by other devices (e.g. dm and md).
Oops.
GUI Live USB creator FTW?
More seriously… I know you were in a console… maybe incorporate that df listing into the script, so that you can select a target after seeing sizes.
A simple safety check would be to look and see if the partition the user asked to write to is already mounted, and refuse to do anything if it is.
The real answer is making it so that people aren’t using a shell script with all the pain that implies. Hence, Luke and Kushal’s work on liveusb-creator which is a nice PyQT frontend to the process.