Greetings!

I'm running into this error when trying to build a usb bootable disk for 14.1. I did not have any problems when I did this for current. Here is the code:
Any ideas? Thanks!

Judging by the line number of that error you are using the usbimg2disk.sh script from my web site and not the somewhat shorter version contained in Slackware's usb_and_pxe_installer directory.

The error occurs on the line which calls the "makebootable" function, which uses sfdisk to set the first partition bootable. Perhaps your computer does not have sfdisk installed?
In any case, try adding "--logfile </path/to/some/logfilename>" as parameter and after the script stops, inspec the content of that log file to see if it helps you find the cause of the error.

The difference between my original usbimg2disk.sh and the version maintained by Pat in Slackware, is that my script extracts the initrd image, changes a few things so that the USB stick is automatically mounted on boot and then selected as the default location from which to install the packages, and then re-creates the initrd image.

Eric

If instead of the version from Eric's website you want to use the version included in Slackware's usb_and_pxe_installer directory, and you'd like to boot a machine with an EFI firmware, apply attached patch first.

Caveat emptor: I'm not telling that will solve your issue, just an off-topic reminder.

Attached Files

usbimg2disk.sh.patch.txt (536 Bytes, 25 views)

Care to tell us why this is a good thing? What will it fix? Why just change these lines and not take care of the other commands relating to the /syslinux directory in the USB image?

I do not own any hardware with UEFI so I can not test what the effect of your modification is.

Eric

@ Alien BoB. That puts the content of the initrd directly at the root of the tree instead of in the /syslinux directory IIRC, that is needed for EFI booting. I have no EFI firmware either, but tried in a VM.

PS To make sure, I'll apply the patch and test again.

This hardware is not that old, but it is also not EFI. Going to try the version from the official release and see if I get better results. Will report back. Thank you all for the help.

Ah! Found the culprit. This thumb drive was previously a Fedora 20 Live Disc. When looking at the logfile (thanks AlienBOB for pointing that out), I found that sfdisk did not support GPT and thus the reason why it would fail to make the thumb drive bootable. What I had to do was to use gdisk, and do the following:
That's it! The usbimg2disk.sh works correctly. I tested using the one from Slackware (which was failing with the same error). I am assuming that it will work for the one provided by AlienBOB.

Hopefully this will help someone else! Thank you all for your help.

Thanks Didier for the insight, I failed to realize that UEFI needs the syslinux files in the root.

stormtracknole, I need to think that over. GPT formatted USB sticks should be properly handled.

Eric

Maybe it's the way Fedora partitioned the drive?

If you're trying to make a complete bootable USB installer for a non-UEFI machine, just dd or cat the appropriate ISO image to the stick. The ones for 14.1 will boot directly from a stick just fine.

Thank you! That is good to know. Last time I had tried that, it didn't work.

Great news! Thanks!

I ran into this very same problem, and I think I found the cause of the issue. You see, at lines 94 and 95 of the “usbimg2disk.sh” script (as found on the Slackware64 14.1 DVD), the following snippet is to be found:
The thing is, this will (as the comment says) wipe the MBR—but it will leave the GPT data structures on the disk (or stick) intact. Any software that knows about GPT will, then, assume (and correctly, at that) that the disk is still partitioned using a GPT scheme, but with a corrupted MBR. Indeed, the “gdisk” utility will inform you that it:
Non-GPT utilities (e.g., “fdisk”), assuming that they are recent enough to at least detect the presence of GPT data structures, will tell you that they don’t support GPT, and that you should use other utilities, such as “gdisk”, to operate on the disk partition table.

As stormtracknole noted, you can use “gdisk” to zap the GPT data structures, and the disk will subsequently be properly handled as an MBR-partitioned disk.

Otherwise, if you don’t want to, or cannot, use “gdisk”, then you should zap not only the MBR, but also the GPT tables—both at the beginning and at the end of the disk. Instead of wiping just the MBR (i.e., the first sector of the disk), you should zap the first 34 sectors—i.e.:
Then, to wipe the backup copy of the GPT tables, you should zap the final 34 sectors of the disk as well:
(where NUMBER_OF_SECTORS represents the total number of sectors on the disk).

(In fact, the backup GPT tables do not include a copy of the MBR, and occupy not 34 sectors, but one sector less, so you could replace both occurrences of the number “34” with “33” in that last command. Also, it is probably sufficient to zap only the MBR and both copies of the GPT Header—i.e., the first two sectors, and the single last sector—but I haven’t actually tried that.)

Also, I’m assuming that the GPT partition table has the default size, which allows for 128 partitions, recording four partitions per 512-byte sector—which works out to 32 sectors. The beginning of the disk has 1 sector for the “Protective” MBR, one sector for the GPT Header, plus 32 sectors for the GPT partition table; the end of the disk has only the 32 sectors for the GPT backup partition table, plus the GPT Header. The 32-sector, 128-partition size of the partition table is, however, not hard-wired; in principle, it could be made larger—though, for current-generation disks, 128 partitions should be more than sufficient. If you really want to be sure about the GPT table size, you will have to look into the GPT Header—i.e., the second sector of the disk—which, somewhere, includes a record of these values.)

EDIT:

There appears to exist an “sgdisk” utility, which can zap the MBR and GPT structures for you, as follows:
(provided, of course, that you have access to the utility).

For more info, cfr. The GPT fdisk Tutorial, by Rod Smith (which is where I learned this)—specifically, Wiping Out Old GPT Data.

The script in Slackware-14.1/usb-and-pxe-installers, is worng in the line 151.

Replace the line

/sbin/sfdisk -A $USBDRV 1

by

/sbin/sfdisk -a $USBDRV 1

The -A is append a partition and sfdisk stay way for input commands.

Looks like the developer changed the meaning of a parameter here. How stupid can you get?

On Slackware 13.37:
On Slackware 14.1: