Bootable thumb drive

I didn’t know which forum was the best place for this so I put it here.

Can someone walk me through the process of creating a bootable thumb drive from an .iso? This .iso creates an installation disk for Project Trident which is a desktop variant of Bsd. The website doesn’t mention using the .iso to create a thumb drive. Is this an issue? The reason I want to use a thumb drive is that my dvd seems to have quit working properly.

I have had trouble in the past creating bootable thumb drives because the they wouldn’t boot up after writing and restoring them to a normal blank read and write mode for every day use again afterward has been extremely difficult so I would appreciate being taught to erase the files and restore the drive to normal read write mode too.

Is it visible with fdisk (need to be root)? For example an openSUSE iso image shows;

fdisk -l openSUSE-Tumbleweed-DVD-x86_64-Snapshot20190217-Media.iso

Disk openSUSE-Tumbleweed-DVD-x86_64-Snapshot20190217-Media.iso: 4.3 GiB, 4600102912 bytes, 8984576 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1a6bfd1c

Device                                                     Boot Start     End Sectors  Size Id Type
openSUSE-Tumbleweed-DVD-x86_64-Snapshot20190217-Media.iso1       3624   11435    7812  3.8M ef EFI (FAT-12/16/32)
openSUSE-Tumbleweed-DVD-x86_64-Snapshot20190217-Media.iso2 *    11436 8984575 8973140  4.3G 17 Hidden HPFS/NTFS

You should be able to use dd to lay the image down

dd if=your_iso_image.iso of=/dev/sdX

Where sdX is the USB drive.

fdisk -l produced this:

fdisk -l Trident-19.04-U1-x64-20190515.iso
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
**Disk Trident-19.04-U1-x64-20190515.iso: 3.4 GiB, 3655399424 bytes, 7139452 sectors**
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FA3DF87D-7740-11E9-8F66-AC1F6B626660

**Device****Start****  End****Sectors**** Size****Type**
Trident-19.04-U1-x64-20190515.iso1    80  1679    1600  800K EFI System
Trident-19.04-U1-x64-20190515.iso2     3    32      30   15K FreeBSD boot

Partition table entries are not in disk order.

I downloaded it twice so…

Also I have 2 thumb drives but no entry in /dev for any file named sdX

I still don’t remember how to insert those code: boxes. So I just copy pasted text. Sorry. Perhaps you can refresh my memory.

What is the output with the USB device plugged in from the command;


sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 240G 0 part /var
├─sda2 8:2 0 683.7G 0 part /home
└─sda3 8:3 0 7.8G 0 part [SWAP]
sdb 8:16 0 465.8G 0 disk
sdc 8:32 1 1.9T 0 disk
└─sdc1 8:33 1 1.9T 0 part
sdd 8:48 1 57.7G 0 disk
└─sdd1 8:49 1 57.7G 0 part /run/media/scott/Patriot
sr0 11:0 1 4.4G 0 rom
pktcdvd0 253:0 1 4.4G 0 disk

sdc and sdd are the thumbs.

Dang a 2TB thumb drive???

So, as root user (not your user) umount /dev/sdd1 if you want to put the image on this device, but I would get rid of the partitions as well and set as a gpt disk (since the output shows this iso is a gpt rather than dos)

CAUTION The following will delete all data off the 64GB patriot device…

su -
umount /dev/sdd1
wipefs -a /dev/sdd1
wipefs -a /dev/sdd
gdisk /dev/sdd
dd if=<your.iso> of=/dev/sdd

Since we wiped all the info with wipefs, need to go back in with gdisk to set as gpt type disk rather than dos type.

Are you saying that I need to type “gdisk /dev/sdd” into a root console and hit enter and that will bring me back to a prompt and then I simply need to type “w” and hit enter which will bring me back to a prompt and then I need to type just a “y” and hit enter to set the thumb drive as gpt or are you saying that I need to place the gdisk /dev/sdd before th “w” and “y” each time or do you mean something else entirely?

Alright all you guys, stop laughing.

I’m not laughing. You asked reasonable questions.

The “gdisk” with “w” is intended to fix a broken “gpt” partition table. But, in my opinion, that should be done after the “dd” (copying the iso) rather than before.

Most linux distros are using traditional BIOS partitioning for an iso intended for writing to a USB. That’s because gpt partitioning causes problems. Part of the “gpt” partition table (the secondary copy) is written to the end of the disk. But the people preparing the iso do not know what size USB disk you will use. So that’s likely to always finish up as a broken gpt table.

So how do I restore it to dos afterwards? Just replace the “gpt” with “dos” in the gdisk command?

Use “gdisk”.
Use the ‘x’ command (extended functionality).
Then use the ‘z’ command (zap the gpt structures and exit).

Ok. Well it didn’t work. It came up with a loader version, indicated bios drive letter assignments, some other information that I could not decipher and halted.

At least it started to work.

Dolphin gives this error when I try to access the drive:

An error occurred while accessing ‘INSTALLER’, the system responded: The requested operation has failed: Error mounting /dev/sdd2 at /run/media/scott/INSTALLER: wrong fs type, bad option, bad superblock on /dev/sdd2, missing codepage or helper program, or other error

Could the errors fdisk -l revealed be the cause?

What I wanted to know before was is the command to restore to dos specifically “dos”? Is there anything else like that “w” command I should do?

Okay, sorry about that.

What I said to do with “gdisk” will remove the “gpt” structures. But then you need to put dos structures back there. You can do that with “fdisk”, then create a single partition with “fdisk”. Maybe then format as FAT or NTFS with “mkfs”, or plug into a Windows box and format there.

Just fyi for some unknown reason my dvd started working again and when I ran the installer dvd that I had already made to install bsd it behaved the same way the thumb drive did.

Thanks for your help guys and for the useful information

Sure it’s not a UEFI boot only and your booting legacy (mbr), if you look at the openSUSE iso’s it sets the boot flag on the second partition from the fdisk output.

If you use gdisk -l <image.iso> instead of fdisk, what’s the output like?

Did you check the download sha256sum or equivalent?

I’m not sure what your first question means. When you say uefi do you refer to the iso or my hardware. My hardware is older bios based.

To answer your second question:

gdisk -l Trident-19.04-U1-x64-20190515.iso
GPT fdisk (gdisk) version 1.0.4

Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Main and backup partition tables differ! Use the ‘c’ and ‘e’ options
on the recovery & transformation menu to examine the two tables.

Warning! One or more CRCs don’t match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged

Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.

Disk Trident-19.04-U1-x64-20190515.iso: 7139452 sectors, 3.4 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): FA3DF87D-7740-11E9-8F66-AC1F6B626660
Partition table holds up to 4 entries
Main partition table begins at sector 2 and ends at sector 2
First usable sector is 3, last usable sector is 7139449
Partitions will be aligned on 1-sector boundaries
Total free space is 7137817 sectors (3.4 GiB)

Number Start (sector) End (sector) Size Code Name
1 80 1679 800.0 KiB EF00
2 3 32 15.0 KiB A501

Third question: No I did not. Strictly speaking I don’t know exactly how to do that.

I think at this point I would prefer to have a healthy file to begin with rather than one that I had to depend on my ability to repair. This one looks pretty ****** up.

Can I say that in here?

HA. I guess not.

The image checksums are published here;

I see they have a lua based bootloader which may have issues… they suggest a bug report?

So for the sha256 sum for example, you can either download the checksum file and have this in the same directory as the iso image, then use (it can take a little time to complete, be patient);

sha256sum -c Trident-19.04-U1-x64-20190515.iso.sha256

It should report the iso image is OK, or just check the sum produced from;

sha256sum Trident-19.04-U1-x64-20190515.iso

As long as it checks out, the dd command should work…