Missing Operating System [message at boot]

I get a similar problem. After choosing USB Removable Media (or similar) as the bootable device I get "Invalid or damaged Bootable partition" (I don't know why the B is capitalized).

I ran usb-creator with and without -s and in both cases the end result was the same. I'm using the ubuntu-8.04.1-desktop-i386.iso and a new 4G usb memory stick:

$ sudo parted /dev/sdb print
Model: Kingston DataTraveler 2.0 (scsi)
Disk /dev/sdb: 4063MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 4129kB 4063MB 4059MB primary fat32 boot, lba

$ df -h /media/KINGSTON/
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 3.8G 823M 3.0G 22% /media/KINGSTON

$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 4063 MB, 4063232000 bytes
5 heads, 32 sectors/track, 49600 cylinders
Units = cylinders of 160 * 512 = 81920 bytes
Disk identifier: 0x0008e42c

   Device Boot Start End Blocks Id System
/dev/sdb1 * 51 49600 3963968 c W95 FAT32 (LBA)

I don't know if it's interesting that the first 4MB of the disk is not being used. (well, actually it's the first 4,000 KB -- 50 cylinders * 81,920 bytes = 4,096,000 bytes)

Confirmed, repartitioning fixed the problem:

$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 4063 MB, 4063232000 bytes
254 heads, 16 sectors/track, 1952 cylinders
Units = cylinders of 4064 * 512 = 2080768 bytes
Disk identifier: 0x0008e42c

   Device Boot Start End Blocks Id System
/dev/sdb1 * 1 1953 3967999+ c W95 FAT32 (LBA)

Now it boots.

After looking at the above posts, I noticed that their flash drives have the LBA flag. After turning on this flag [to my flash drive] with gparted the flash drive boots!
Should usb-creator have enabled that flag during setup? If so, the bug is more about the LBA flag than anything else...

I just used gparted to turn my disk's LBA flag on, and I would still get the error message.

I'm getting this with latest version

$ apt-cache show usb-creator
Package: usb-creator
Installed-Size: 192
Architecture: all
Version: 0.1.9

I know I shouldn't do this myself, but two people have confirmed this bug since reporting.

I have the same problem as David. I set the LBA flag with gparted, but at boot the system tells "pendrive without operating system.".

Disco /dev/sdb: 8027 MB, 8027897856 byte
255 heads, 63 sectors/track, 976 cylinders
Units = cilindri of 16065 * 512 = 8225280 bytes
Disk identifier: 0x04030201

Dispositivo Boot Start End Blocks Id System
/dev/sdb1 * 1 976 7839688+ c W95 FAT32 (LBA)

I can confirm that this happens to me as well. I have tried multiple operating systems on my Flash drive. Fedora 9, gOs Gadgets and Linux Mint - all return "Missing operating system" at boot time...

same problem for me.

same problem for me too

As a work around, I used the UNetBootin (http://unetbootin.sourceforge.net/) application to create a bootable USB Drive and it worked perfectly.

I would like to confirm this bug and the workaround posted by ronald.

@Ronald
Is it possible to make it persistent with the help of unetbootin?
can somebody confirm whether the solution mentioned at the link mentioned below works?

http://ubuntuliving.blogspot.com/2008/11/missing-operating-system-step-by-step.html

After checking some howto's on making bootable flash drives, I think the possible cause of this problem is that a default installation of 8.10 has syslinux 3.63 instead of the 3.71 (the required version for the howto's). "If you use [a] version earlier than 3.71 to do the following command, the created USB flash drive or USB hard drive won't be able to boot correctly. "

If there's more to it than the syslinux version, then we could try running:
* "cat /usr/lib/syslinux/mbr.bin > /dev/sdb" # to install an mbr
* "syslinux -s /dev/sdb1" # to install the syslinux boot loader
Running the above fixed an error where I'd see "Boot Error" after attempting to boot a U3 flashdrive (that had been through usb-creator of course).

HowTo's:
http://clonezilla.org/clonezilla-live/liveusb.php
http://clonezilla-sysresccd.hellug.gr/usb.html

@manishmahabir

By persistent do you mean being able to save data back to the USB Drive once you have booted from it? If so, I think this is possible as I recall that option in UNetBootin but have not tested it as I was just creating a bootable USB drive for the purpose of installation.

I worked about the problem by using a different model of thumb drive. The boot failure happened only with a 16MB Kingston drive, but 2MB and 8MB SanDisk "Cruzer" drives work just fine.

Oops. I meant "GB", of course.

I reported the syslinux bug before ibex release, but no one looked at it:
https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/270822

@Bob
I don't think you need to use a different model
i had the same problem with a 2 GB kingston drive
i followed the workaround here and it worked!
http://ubuntuliving.blogspot.com/2008/11/missing-operating-system-step-by-step.html

I tried manishmahabir's solution. (In fact, I think it's equivalent to what I tried before.) No joy.

The "works on a 2GB Kingston drive" data point is relevant, however. Maybe size matters. Has anyone gotten it to work on a 16GB Kingston drive? On any 16GB or larger drive?

I also tried manishmahabir's solution (from the ubuntuliving blog) and it worked for me :)

I have a 8GB Corsair Voyager (with ready boost...which was a bad purchase since I on use Ubuntu now instead of Windows). The live USB worked on many computers except for one Dell desktop for which I was given the message "Missing operating system" (I don't remember how it was capitalized). After following the steps on the ubuntuliving blog, I tested it on the Dell computer again, and it worked as expected. I also tried it on one of the other computers on which it previously worked correctly and it still worked there as well.

FYI...

I was having problems using UNetbootin with an iso for Linpus Linux Lite on a 1GB JetLinx flash drive. So I decided to follow the same reformatting and partitioning that fixed my problem here...and it worked! There is something about that procedure described on the ubuntuliving blog that is crucial.

I still facing the problem even reformatting and partitioning as said in the mentioned blog. I am using a Kingston 8GB DataTraveler 100 Model and this is its partition info:

ubuntu@ubuntu:~$ sudo fdisk /dev/sdb

Orden (m para obtener ayuda): p

Disco /dev/sdb: 8027 MB, 8027897856 bytes
255 cabezas, 63 sectores/pista, 976 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Identificador de disco: 0x04030201

Disposit. Inicio Comienzo Fin Bloques Id Sistema
/dev/sdb1 * 1 976 7839688+ b W95 FAT32

First I did the reformatting and partitioning things and then usb-creation with no success.

Thanks.

I did have one difference from the blog.

After executing all the fdisk-related commands, there was a warning-type message that informed me that the kernel was still using the old structures. So before continuing on and creating the partitions with Gparted, I first restated my computer to assure myself that no problems would arise from the kernel using outdated structures.

I also see the 'No operating system' from the bios. If it is the same underlying problem, I don't know.
Mine went away using the Windows version of syslinux with the -m switch (to install to MBR) on the pendrive.

Here is what fixed it for me: Deleting the original (FAT32) Partition on the USB pen drive. The Wizard will then allow you to "Format" the stick. Doing that solved it for me.

@Dennis
I confirm that this method also solved my problem. Using 2GB stick on MSI Wind U100x.

@Dennis
@Copter
this worked for me too!

I'm going to repeat here my findings that I originally attached to bug #293083 "USB startup thumb drive fails to boot" since the discovery could point to some users being affected by a BIOS bug.

If I remove the hard drive from the system, rather than just change the BIOS boot order so USB is tried first, The USB device boots successfully.

The "Missing Operating System" message is written by the syslinux MBR code when it can't find the second stage code in the bootable file-system.

In the process of investigating this issue I discovered this boot-device issue which suggests a BIOS bug. The affected Sony Vaio has a Phoenix BIOS.

It suggests that when the syslinux MBR (Master Boot Record) code asks the BIOS to read the first sector from the bootable partition (the file-system's boot-loader code) one of two things might be happening:

1. BIOS passes the wrong drive number to the boot-loader as part of the PnP header (available in DL when execution is passed to the MBR from BIOS along with the PnP header at ES:DI)
2. BIOS ignores the drive number passed (in DL) to int 0x13 (Read sector)

I've debugged this issue by creating a diagnostic MBR (see http://syslinux.zytor.com/archives/2009-March/011906.html) that reports the values the BIOS passes (see http://syslinux.zytor.com/archives/2009-March/011876.html).

It transpires that the system BIOS has a bug (in this case a Phoenix BIOS).

Although the boot specifications for Plug and Play require the device numbering be based on the order of bootable devices the value passed to the MBR at boot from BIOS in register DL does not use this order.

Therefore when the BIOS is configured with a boot-order such as:

0x80 USB masss-storage device
0x81 IDE hard-disk drive

The numbering of the devices for Plug'n'Play should be as shown above.

In some cases the BIOS (in the existing case a Phoenix BIOS in a Sony Vaio VGN-FE41Z) incorrectly passes 0x81 in register DL, causing the MBR to read from the wrong device when loading the active partition's boot-sector.

I've created a work-around which patches the MBR and allows the user to force the MBR to use drive 0x80 if a Ctrl key is pressed when the MBR boots, regardless of what the BIOS passes in register DL.

With this MBR installed on the USB flash mass-storage device, if the Ctrl key is pressed at boot the device boots successfully.

I'm preparing an updated syslinx patch with this MBR patch installed and it will be available from my PPA shortly.

For most users, all that is needed is the ~440-byte MBR file. I've attached mbr.bin.gz to this bug report. To install it on the device:

1. download the new MBR (mbr.bin.gz)
2. unpack it

gunzip mbr.bin.gz

3. connect the device
4. determine what device node it is (e.g. /dev/sdc)

DEV=/dev/sd?

5. write the modified MBR to the device

sudo dd if=mbr.bin of=$DEV

6. Start the affected PC
7. Press one of the Ctrl keys and hold it down whilst the USB device boots

I'm attaching the diagnostic MBR so users can test whether their system is affected and, more importantly, report the actual values their PC's BIOS is using.

Installing it is the same process as the instructions above, but using "mbr-diag.bin.gz" and "mbr-diag.bin". The MBR will produce a *very* concise report (it can only have 440 bytes of code). It will *not* try to boot the active partition, only read its boot-sector.

Replace this diagnostic MBR with the one above for regular booting.

At boot-time it will test for two key presses:

1. Ctrl key = Force use of first hard-disk regardless of the BIOS drive number in register DL
2. Shift = Force use of CHS addressing method for read_sector even when LBA addressing is available

The output will look like this:

 L D80 C3FF H10 S3F P1 O00000020 MAA55 E00
 Description Codes:
   L | C LBA or CHS addressing mode
   D drive number BIOS-reported drive number
   C cylinders Geometry of drive according to BIOS
   H heads
   S sectors
   P partition active partition number (first partition flagged active). '?' if no active partition
   O offset absolute sector offset of active partition . '????????' if no active partition
   M magic magic bytes of active partition boot sector (sector <offset> as read by BIOS).
                                '????' if no active partition. Value is reset to 0xDEAD before the sector is read
                                to avoid inheriting the MBR magic on error
   E error error code returned by BIOS 'read sector' interrupt (0x02 or 0x42, int 0x13).
                                '??' if no active partition.

Here's a debdiff against the current package to create the new MBR.

I've added optimisations to reduce byte-count. Attached updated debdiff, mbr.bin and mbr-diag.bin

I am also affected by this bug. I booted Ubuntu 9.04-i386 image from CD. To be sure the usbdrive is empty i run the following command first:
$ sudo dd if=/dev/zero of=/dev/sdc

After dd was finished cleaning the usbdrive I run the tool "USB disk creator" and formatted the usbdrive from within the tool.

I could then boot the usbdrive on one of my computers but on the other one I get "Could not find kernel image: linux".

After that I followed the blog and deleted the partition with fdisk and created a new fat32-partition with GParted instead (including boot and lba options) and then copied the CD onto the usbdrive with "USB disk creator", without formatting the drive inside the tool.

And that worked for me! I can now boot the usbdrive from both my computers.

The failing motherboard is "Gigabyte GA-M55PLUS-S3G", BIOS version "F11 (04/23/2007)".

The output from the diagnostic MBR (the link from TJ on 2009-03-30) when I hold CTRL-key own during boot is: "L D80 C07C HFF S3F P1 O0000003F MAA55 E00". I have no clue of what that means but I hope it is valuble for TJ. :)

On Sun, 2009-04-26 at 10:53 +0000, Anders Häggström wrote:
> The output from the diagnostic MBR (the link from TJ on 2009-03-30) when
> I hold CTRL-key own during boot is: "L D80 C07C HFF S3F P1 O0000003F
> MAA55 E00". I have no clue of what that means but I hope it is valuble
> for TJ. :)

Here's the documentation from my mbr-diag.S source submitted to syslinux upstream:

 Due to the severe space constraints the output uses 1-character description codes to prefix each printed value.
 Values are in hexadecimal.

 Description Codes:
 L | C LBA or CHS addressing mode
 D drive number BIOS-reported drive number
 C cylinders Geometry of drive according to BIOS
 H heads
 S sectors
 P partition active partition number (first partition flagged active). '?' if no active partition
 O offset absolute sector offset of active partition . '????????' if no active partition
 M magic magic bytes of active partition boot sector (sector <offset> as read by BIOS).
      '????' if no active partition. Value is reset to 0xDEAD before the sector is read
      to avoid inheriting the MBR magic on error
 E error error code returned by BIOS 'read sector' interrupt (0x02 or 0x42, int 0x13).
      '??' if no active partition.

syslinux (3:6.03+dfsg-8ubuntu3) wily; urgency=medium

  * Revert "Also skipping isohd*x_{c,f}.bin in syslinux-common" (LP: #277903)

 -- TJ <email address hidden> Sat, 26 Sep 2015 18:23:12 +0100

Replacing the original isohdpfx.bin in sector 0 of the USB mass storage device containing the Desktop ISO image of 14.04 and 15.10 with the alternative isohdpfx_c.bin provides the desired workaround: Holding down Ctrl as the bootstrap code is loaded by the BIOS forces use of drive 0x80 and the ISO image starts correctly.

If we can get this used in the standard CD images it gives the user a valuable workaround for this buggy BIOS behaviour.

We also need to document it - need to identify which Wiki pages require editing, and now to add instructions to the Release Notes.

The attachment "Include alternative MBR images in packages" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

I recently purchased a GA-990XA-UD3 and experienced this problem.
This is an UEFI board, with support for Legacy boot, etc.
I had no problems creating a TAILS persistent USB flash disk, within TAILS DVD. It booted normally from USB.

But then, when I used a Sandisk Cruzer Blade (another flash drive) to create a standard Ubuntu 15.04 Live USB, using the tool called "Universal Boot Installer", following the right steps. Everything in place, FAT32, etc, and to my surprise....

"Missing operating system".

I found out that the flash drive had two configurations, when investigating through gparted, and fdisk.

1) The flash drive was as GPT partition.
2) It had the msftdata flag.

I don't know WHICH one of those could have caused the problem.
I think this happened to this flash pendrive when I was playing around with "Windows 8 Disk Management" tools.

What I did was to completely wipe the flash drive, with gparted, recreating the partition table as msdos, and formatting as FAT32.
Using "Universal USB Installer" recreated the system, and then I found out it also flagged the drive as "boot, lba".

I hope this helps, if you're stuck.

DjznBR: Your issue may be caused by allowing the PC to boot the installer image using Legacy/BIOS mode, rather than its native UEFI mode.

ISO Desktop images are hybrid; that is they are configured to boot in any of three different modes:

1. In UEFI mode using the Simple Boot Path (EFI/BOOT/BOOTX64.EFI) with GPT and an EFI System Partition (bootable as optical media or removable mass storage)
2. In BIOS mode using the hybrid/protective MBR containing the isolinux boot-strap and isolinux.bin
3. As pure ISO9660 media using the BIOS El Torito boot specification for CD/DVD media

These combinations allow the device to boot as removable optical media or removable mass storage on BIOS and UEFI systems.

If you experienced the "Missing operating system" message the UEFI PC tried to boot the image using Legacy BIOS/Compatibility Support Module mode. You'll not see that message when booting in UEFI mode.

(it's assigned to Mathieu, unsubscribing sponsors)

Trying to install xubuntu-20.10 desktop installs fine, no errors reported.
Operating system is missing.
Previous version of xubuntu installed fine and booted fine.
Just for fun i tried to install ubuntu-20.04.1 desktop, and it install fine, no errors reported.
With this image it boots fine.

Laptop is HP Probook 6460b Bios version 68SCE Ver. F.22

From my last comment I can report that both latest xubuntu 20.x is not able to update files during installation of image. I checked partition table and boot settings, and it seems that GRUB breaks while updating files during installation.
Image of standard release of Ubuntu 20.x is able to update files during installation though. Works fine.