I have a process used to create bootable CentOS 6.3 installer sticks. I use a command similar to

dd if=myimage.img of=/dev/sdx bs=16k

to burn my custom image onto a USB stick, and from here I can boot my systems with one of these systems to perform the OS install.

I've hit a problem which I've never seen before that I cannot understand. After burning a USB stick, I sometimes mount it and copy additional files to it (for example for debugging purposes). So I might do this:

dd if=myimage.img of=/dev/sdx bs=16k
partx -av /dev/sdx
mount /dev/sdx1 /mnt
cp myfile.dat /mnt
umount /mnt
partx -dv /dev/sdx

After doing this, for some reason the stick is no longer bootable. The system comes up with the error "No operating system", which of course is the error you typically see when booting with a disk that had a partition flagged as bootable but there is no OS present on the disk. The OS *is* there though, so the error doesn't make sense.

What's more confusing though is all I have to do is just mount the disk--I don't even have to copy anything to it. Just the acting of burning an image to the disk and then mounting it causes it to be not bootable. Even if I mount the disk read-only, it will longer boot.

I have another bootable image created by the same process and this problem does not occur with that image. I can repeat these same steps and the stick boots fine afterwards.

So I'm stuck with this. Does anyone have any idea what's going on?

I have seen weird errors like yours without ever getting to an explanation. If you try the same process on a different USB stick (just another one, doesn't even have to be different) does it happen as well?

If that other one is correct, trash the problematic stick. Unless you want to research it for academic reasons. Highly unsatisfactory of course.

jlinkels

I don't get the partx reason. (OK, don't know why you do partx)

The dd command from file to device should have been part of the original image. It shouldn't need any more partition issues unless you are trying to fill it??


Why don't you just mount or automount the usb and make changes?

Not sure I'd even use bs= either. I'm on the fence on that.

You could do the simple "mount and unmount", and then compare the data on the drive with the original image (not the contents of the files, but a byte-by-byte compare of the image). I suspect it's some variant of what happens when the boot files get moved without re-installing the boot loader. Everything appears to work just fine, but the boot loader is actually using the data from the old physical locations, blocks that are now marked as "free" in the file system. Then you make some unrelated change, those free blocks get used for something else, and your system won't boot any more.

What's the file system inside that image? SWAG here: If it's ext3 or ext4, then it could be the journal that is overwriting the blocks that the boot loader is using.

I resolved the problem, although I don't have a good explanation for the solution. I decided to reboot the system where I was generating my image and then created a new image. After doing this, the problem went away. I can now burn this image onto a USB stick, mount/umount the USB stick, and the USB still boots. It always used to work so I knew there was something wonky going on, but this definitely is *very* wonky.

Unfortunately I lost a day of my life before deciding to reboot the system.

'Nuff said...

Thanks for the update.

Then you probably wont find this clip as funny as I did!
The IT Crowd - Have you tried turning it off and on again?