| brent timothy saner on 2 Aug 2014 20:58:15 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] Why Doesn't dd work for all ISO files? |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/02/2014 08:40 AM, Casey Bralla wrote:
> I've been doing a bunch of distro testing lately, and so have had the
> opportunity to transfer iso files to thumb drives.
>
> Most distros can be loaded onto a bootable thumb drive using the
> fantastic unetbootin utility. Some (such as KaOS (http://kaosx.us/ )
> cannot be loaded with netbootin and instead need the "dd" command to
> copy the iso file as a binary onto the thumb drive.
>
> BTW, isn't KaOS a great distro name? They could have cool code names for
> their versions such as "Chief", "Siegfried", or "Hymie".
>
> Anyway, it seem to me that __ALL__ iso files from distros should be
> transferable to thumb drives by using dd. I've tried this, however, and
> most of them fail to boot.
>
> Can anybody explain why this is so?
Howdy! Live-distro hacker, here.
I'll try to keep this pretty simple, because once you go down this
rabbit-hole you lose sleep for three nights straight and then once you
get it you make an obnoxious ALL CAPS tag in your git repo and your
commit message is just sobbing.
ISO files are, essentially, raw image dumps.
"Well, duh- I knew THAT. How else could I dd from /dev/cdrom to MAKE an
.iso from an existing disc?"
Well, chill, sassypants. Because there is a difference between an ISO
file and a *bootable* ISO file, just as there's a difference between a
hard drive and a *bootable* hard drive (assuming you're using MBR/BOIS.
UEFI, the same holds true, but it's a bit different from my comparison,
but more on that in a bit)...
Where was I?
Oh! Right. So of these bootable ISOs, there are two types:
- -normal "el torito" bootable image, "legacy"; these are the ISOs that
have been popular and used ever since some nerd first thought to make a
linux bootable CD, more or less.
- -Hybrid ISO's, which support the eltorito image but *also* have an
embedded MBR in the ISO image
Pre-boot Execution (BIOS, UEFI...) when booting from CD are looking
*specifically* for an el torito header. When booting from a hard drive
(i.e., as far as the system is concerned, a USB thumb-drive), it's
looking for an MBR.
SO the short, tl;dr (I know, I know. I'm not even done yet.) answer is
"because the newer ISO's that not every distro is even using yet but
should be is actually using two different boot technologies within the
same ISO image".
Not all distro's engineers/development teams even REALIZE the above.
Granted, a lot of live-centric distros avoid hybrid ISO's because it
would generally render the rest of the USB stick unusable from the live
environment without some nasty hackstuffs. It's possible, just not
generally worth it compared to releasing separate USB image files or
scripts.
The "sl;lr" version (or "Super-Long? Let's Read!"):
....
So let's look at a normal, "legacy" el torito-only bootable ISO:
[bts@workhorse sysresc]$ dumpet -i systemrescuecd-x86-4.3.1-beta002.iso
Validation Entry:
Header Indicator: 0x01 (Validation Entry)
PlatformId: 0x00 (80x86)
ID: ""
Checksum: 0x55aa
Key bytes: 0x55aa
Boot Catalog Default Entry:
Entry is bootable
Boot Media emulation type: no emulation
Media load segment: 0x0 (0000:7c00)
System type: 0 (0x00)
Load Sectors: 4 (0x0004)
Load LBA: 156607 (0x000263bf)
Section Header Entry:
Header Indicator: 0x91 (Final Section Header Entry)
PlatformId: 0xef (EFI)
Section Entries: 1
ID: ""
Boot Catalog Section Entry:
Entry is bootable
Boot Media emulation type: no emulation
Media load address: 0 (0x0000)
System type: 0 (0x00)
Load Sectors: 2880 (0x0b40)
Load LBA: 191900 (0x0002ed9c)
[bts@workhorse sysresc]$ isoinfo -d -i systemrescuecd-x86-4.3.1-beta002.iso
CD-ROM is in ISO 9660 format
System id:
Volume id: sysrcd-4.3.1
Volume set id:
Publisher id:
Data preparer id: XORRISO-1.2.8 2013.03.18.093001, LIBISOBURN-1.2.8,
LIBISOFS-1.2.8, LIBBURN-1.2.8
Application id:
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 198675
El Torito VD version 1 found, boot catalog is in sector 71
Joliet with UCS level 3 found
Rock Ridge signatures version 1 found
Eltorito validation header:
Hid 1
Arch 0 (x86)
ID ''
Key 55 AA
Eltorito defaultboot header:
Bootid 88 (bootable)
Boot media 0 (No Emulation Boot)
Load segment 0
Sys type 0
Nsect 4
Bootoff 263BF 156607
And now a hybrid ISO!
[bts@workhorse arch]$ dumpet -i archlinux-2014.07.03-dual.iso
Validation Entry:
Header Indicator: 0x01 (Validation Entry)
PlatformId: 0x00 (80x86)
ID: ""
Checksum: 0x55aa
Key bytes: 0x55aa
Boot Catalog Default Entry:
Entry is bootable
Boot Media emulation type: no emulation
Media load segment: 0x0 (0000:7c00)
System type: 0 (0x00)
Load Sectors: 4 (0x0004)
Load LBA: 43 (0x0000002b)
Section Header Entry:
Header Indicator: 0x91 (Final Section Header Entry)
PlatformId: 0xef (EFI)
Section Entries: 1
ID: ""
Boot Catalog Section Entry:
Entry is bootable
Boot Media emulation type: no emulation
Media load address: 0 (0x0000)
System type: 0 (0x00)
Load Sectors: 63488 (0xf800)
Load LBA: 63 (0x0000003f)
[bts@workhorse arch]$ isoinfo -d -i archlinux-2014.07.03-dual.iso
CD-ROM is in ISO 9660 format
System id:
Volume id: ARCH_201407
Volume set id:
Publisher id: ARCH LINUX <HTTP://WWW.ARCHLINUX.ORG>
Data preparer id: PREPARED BY MKARCHISO
Application id: ARCH LINUX LIVE/RESCUE CD
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 285696
El Torito VD version 1 found, boot catalog is in sector 42
NO Joliet present
Rock Ridge signatures version 1 found
Eltorito validation header:
Hid 1
Arch 0 (x86)
ID ''
Key 55 AA
Eltorito defaultboot header:
Bootid 88 (bootable)
Boot media 0 (No Emulation Boot)
Load segment 0
Sys type 0
Nsect 4
Bootoff 2B 43
Yes, they both support UEFI as well, that's the "Section Header Entry"
part. But they both boot just fine for MBR/BIOS systems, which is what
the original post was asking about.
So! Did you catch the difference?
No? I don't blame you. It's subtle. VERY, very subtle.
Well, let's try to sleuth the hell out of it, then:
Legacy:
[bts@workhorse sysresc]$ fdisk -l systemrescuecd-x86-4.3.1-beta002.iso
Disk systemrescuecd-x86-4.3.1-beta002.iso: 388 MiB, 406886400 bytes,
794700 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
[bts@workhorse sysresc]$ file systemrescuecd-x86-4.3.1-beta002.iso
systemrescuecd-x86-4.3.1-beta002.iso: # ISO 9660 CD-ROM filesystem data
'sysrcd-4.3.1' (bootable)
Hybrid:
[bts@workhorse arch]$ fdisk -l archlinux-2014.07.03-dual.iso
Disk archlinux-2014.07.03-dual.iso: 558 MiB, 585105408 bytes, 1142784
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: 0x6039e1c4
Device Boot Start End Blocks Id System
archlinux-2014.07.03-dual.iso1 * 0 1142783 571392 0 Empty
archlinux-2014.07.03-dual.iso2 252 63739 31744 ef EFI
(FAT-12/16/32)
[bts@workhorse arch]$ file archlinux-2014.07.03-dual.iso
archlinux-2014.07.03-dual.iso: DOS/MBR boot sector
AHA!
AHA!!
Pay special attention to the output from the File commands- because the
embedded MBR is at the beginning of the hybrid ISO, it is able to be
booted from persistent media (USB flash drive).
And, for the sake of thoroughness, in case you doubt:
Legacy:
[bts@workhorse sysresc]$ strings systemrescuecd-x86-4.3.1-beta002.iso |
head -n5
CD001
sysrcd-4.3.1
XORRISO-1.2.8 2013.03.18.093001,
LIBISOBURN-1.2.8, LIBISOFS-1.2.8, LIBBURN-1.2.8
2014073017414300
2014073017414300
CD001
Hybrid:
[bts@workhorse tmp]$ strings archlinux-2014.07.03-dual.iso | head -n5
fSfQ
xpu
isolinux.bin missing or corrupt.
f`f1
{fRfP
(you should see a similar output to the Hybrid if you operate the same
on /dev/sda<boot partition #> *and* are using MBR/BIOS booting rather
than UEFI.)
I hope this helps.
In retrospect, I should have done a talk on it.
On that note, who wants a "spin your own livecd from bare scratch" talk?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJT3bNOAAoJEIwATC+TSB9rVMoP/R4zMbf5T27J4c/GhQ1aWunv
R63lbPHocw0xTi3VIDn0m5GvVk1KLG2gWTt6r7RQ7y/uDp6Fgw4bE2y/e6kUV9En
DjbxV8kuHeMFqDGcCL04kuk5zZHpRDEXJrmm7cInEUvRtV3OYC1LTSWI+TbgZllG
MgaPJBGrkZPq1tISgXEIbO2UB/oD8mVybqfZPl4zKOxr2mDccrZkMMm/pQ/oCXWJ
+G28pV34nOL6ej+HoMqBJiFNbRRN4hVm/TCwDF2NRg/bnGi0qBfMavcyHUcwbter
lnj6JIgnhKfOL79VzG+awAZ7/FEsY+zjiU7MfOdVdQ71IdcOEF/NqAdK57kUY/+F
pW9ERlouIcrUpRpk4+ZYVfM5wN+0pJUeSiEFHPWKU1/A4irc9Lg2ynait0EWdq7k
0CErQ0cP1ek4JGS9xx+P0GGCPSujMwq+svo3joHolZKhafm5WjMLqI91DrQG68DK
Npu5BlCpGIVXNRkBY3MQHeJEkHYVDyrS45zweCE8dpRoTBhgCBbY2IU7FgDaojJi
/iz6IrtqB5Vx/akDgIFjk9WFRNJ6b9Wo7FClIPnGfaoe2si2GeEKgkWeZnuSaJ/J
s/m37hrjIcGMMISlAW2Fd8GdQ+ZJk9mSUJmmvxgGq9VXBKIRZgl8FJPMlf+yNQVu
xjYHx+IFcaHm/8Nrtn8y
=qiB1
-----END PGP SIGNATURE-----
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug