amd64+mac images no longer necessary
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu CD Images |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
From my post in bug #633983
> I just tested an Ivy Bridge Macbook with the latest trusty daily amd64 image (written to USB stick with dd):
> 1. boot from apple manager works
> 2. boot from refind (efi) works
> 3. boot from refind (bios) works
> So it appears this bug is fixed, the amd64+mac images are no longer necessary, at least on this particular hardware.
I can confirm that the regular amd64 image is booting fine on a 2012 Macbook. I just checked the trusty images and it appears they are now built with xorriso, which supports hfsplus hybrid multiboot images, so afaics the amd64+mac images may no longer be necessary. Obviously it would be useful to check this on a wider range of hardware. (Debian also use xorriso and they do not seem to have any problems supporting amd64 on mac with their single image)
Sebastian Busch (webmaster-thamnos) wrote : | #2 |
With a Macbook 2,1 the regular amd64 image of 14.04 (Trusty Thar), daily build of the GNOME version 15.04.2014, does not boot.
Chris Bainbridge (chris-bainbridge) wrote : | #3 |
> With a Macbook 2,1 the regular amd64 image of 14.04 (Trusty Thar), daily build of the GNOME version 15.04.2014, does not boot.
Does the Debian ISO boot? http://
The Debian and Ubuntu ISO images are built using the same Xorriso tool, so if the Debian one boots then it should be possible for the Ubuntu one to boot if created with the same settings. If the Debian image does not boot, then that is a bug in Debian which they would want to know about.
Sebastian Busch (webmaster-thamnos) wrote : | #4 |
No, this Debian ISO does not boot either.
Chris Bainbridge (chris-bainbridge) wrote : | #5 |
> No, this Debian ISO does not boot either.
Could you report it as a bug in Debian, against package "cdimage.
Thomas Schmitt (scdbackup) wrote : | #6 |
Hi,
i wgot
http://
It contains El Torito boot equipment for CD/DVD via BIOS and EFI.
Further it contains an MBR for USB stick or alike via BIOS.
There is no GPT for USB stick via EFI without BIOS emulation.
There is no Apple Partition Map (APM) and no HFS+ boot image.
The current Debian 7.4 amd64 contains a GPT and a APM, but no
HFS+ boot image.
A not very young Fedora Live-CD contains GPT, APM and a HFS+
image. See
http://
So this would be a candidate for a test. If it boots, then Ubuntu
could ask mjg about how the HFS+ image was produced. xorriso would
then be able to put it into the ISO and mark it by GPT and APM.
Have a nice day :)
Thomas
Chris Bainbridge (chris-bainbridge) wrote : | #7 |
> The current Debian 7.4 amd64 contains a GPT and a APM, but no HFS+ boot image.
So then Debian can't possibly boot on older Macs? Surprising, afaics this isn't mentioned in the Debian MacBook wiki and it seems like the kind of thing that people would notice.
> If it boots, then Ubuntu could ask mjg about how the HFS+ image was produced.
There are some instructions for producing a bootable HFS+ grub partition at http://
Sebastian Busch (webmaster-thamnos) wrote : | #8 |
Hi,
I had two Fedora CDs which I tried:
Fedora-
Fedore-
They do not work with my Macbook 2,1. The Error message is slightly different: while the Ubuntu CD stops with
----------
1.
2.
Select CD-ROM Boot Type :
-----------
the Fedora CDs stop with
----------
1.
2.
3.
Select CD-ROM Boot Type :
-----------
Thomas Schmitt (scdbackup) wrote : | #9 |
Hi,
Sebastian Busch wrote:
> Select CD-ROM Boot Type
So you had the ISOs on CD or DVD, not on USB stick ?
Question is whether Macbook 2,1 interprets El Torito like
PC firmware would do in this situation.
How old is Macbook 2,1 anyway ?
(I learned about old, new, very new Macs, but never got
some tangible description about which ones boot by what.)
Do you have any ISO or medium that would boot on this machine ?
> Ubuntu CD stops with 1. 2.
> the Fedora CDs stop with 1. 2. 3.
This would match the number of El Torito Boot images in those ISOs.
Ubuntu mini.iso has
/isolinux.bin for BIOS
/boot/
Fedora Live-CD (2 years old) has
/isolinux/
/isolinux/
/isolinux/
Do you get any progress if you select one blindly ?
Probably 2 and 3 would be good candidates.
Have a nice day :)
Thomas
Chris Bainbridge (chris-bainbridge) wrote : | #10 |
> ----------
> 1.
>
> 2.
>
> Select CD-ROM Boot Type :
> -----------
This is mentioned in http://
[4] Obviously if you want your media to be bootable via both BIOS and EFI you need to produce a CD with two El Torito images. BIOS systems should ignore the image that says it's for EFI, and EFI systems should ignore the BIOS one. Some especially creative BIOS authors[5] have decided that users shouldn't have their choices limited in such a way, and so pop up a screen that says:
1.
2.
Select CD-ROM boot type:
and wait for the user to press a key. The lack of labels after the numbers is not a typographical error on my part.
[5] Older (pre-2009, and some 2009 models) Apple hardware has this bug if a dual-El Torito CD is booted via the BIOS compatibility layer. This is especially unfortunate because said machines often fail to provide a working keyboard emulation at this stage, resulting in you being stuck forever at an impressively unhelpful screen. This isn't a Linux bug, since it's happening before we've run any of our code at all. It's not even limited to Linux. 64-bit install media for Vista SP1, Windows 7 and Server 2008 all have similar El Torito layout and all trigger the same bug on Apple hardware. Apple's aware of this, and has resolved the issue by declaring that these machines don't support 64 bit Windows.
Sebastian Busch (webmaster-thamnos) wrote : | #11 |
Thanks Thomas,
Yes, I had the ISOs on CD (Fedora) / DVD (Ubuntu). I can't get it to recognize USB sticks as bootable media.
My Macbook 2,1 is from the "late 2006" series; http://
From the comments on http://
"You're booting via the BIOS compatibility layer, which is broken on images with multiple El-Toritos on Macs. The problem is that the Macbook 2,1 has 32-bit firmware even though it has a 64-bit CPU, and right now we don't support that."
The ISO that works is
http://
which is fine; I just wanted to flag up that the normal ISO does not work so I would vote for keeping the "amd64+mac" version alive in contrast to the suggestion of Chris in bug #633983 which was based on the assumption that it wasn't needed any more.
Best,
Sebastian.
Thomas Schmitt (scdbackup) wrote : | #12 |
Hi,
> http://
Yeah ... booting is a multifarious endeavor.
mjg:
> > Some especially creative BIOS authors[5] have decided that users
> > shouldn't have their choices limited in such a way, and so pop up
> > a screen that says:
> > 1. 2. Select CD-ROM boot type:
So it might be worth a try to repack the Ubuntu ISO so that it
only offers the El Torito EFI boot image.
Regrettably Ubuntu does not publish the used xorriso -as mkisofs
options. (Debian has them in /.disk/mkisofs.)
So one would have to guess:
# Mount existing ISO
mount -o loop mini.iso /mnt
# Use the mounted file tree to build a new ISO
xorriso -as mkisofs \
-o eltorito_
-r -V "CDROM" \
-c boot.cat \
-e boot/grub/efi.img -no-emul-boot \
/mnt
The result will not boot via BIOS and not from USB stick.
EL Torito BIOS only would be:
xorriso -as mkisofs \
-o eltorito_
-r -V "CDROM" \
-c boot.cat \
-b isolinux.bin \
/mnt
The Volume ID "CDROM" and the paths of El Torito boot images and catalog
have been inquired by
xorriso -indev mini.iso -toc
which reports for mine
...
Boot catalog : '/boot.cat'
Boot image : '/isolinux.bin' , boot_info_table=on
Boot image : '/boot/
TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 0 , 14879s , CDROM
...
Sebastian Bush:
> The ISO that works is
> http://
Let's see what it bears ... (962 MB gives enough time to cook a tea) ...
Surprise. It's BIOS only:
Boot record : El Torito , ISOLINUX isohybrid MBR pointing to boot image
Boot catalog : '/isolinux/
Boot image : '/isolinux/
TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 0 , 492544s , Ubuntu 14.04 LTS amd64
There is an MBR partition table with partition start at 32 KB
and a second ISO superblock matching that offset (caused by
xorriso -as mkisofs option -partition_offset 16).
The isohybrid MBR could be extracted by
dd if=trusty-
and brought into effect when repacking, by option
-isohybrid-mbr isohybrid.mbr \
Now i wonder why an "amd64+mac" image is offering only the two
boot paths for PC-BIOS firmware.
It would be really interesting to see whether an EFI-only repack
of the "regular" amd64 ISO.
(Which URL would that be, btw ?)
Do not forget to adjust the -V text in above example to the Volume Id
of the original ISO. Many systems get stuck after kernel booting if
the Volume Id is not as expected.
> Preparer Id : XORRISO-1.2.4 2012.07.20.130001, LIBISOBURN-1.2.4, LIBISOFS-1.2.4, LIBBURN-1.2.4
(There are newer versions of xorriso around. With fresher bugs.)
Have a nice day :)
Thomas
Chris Bainbridge (chris-bainbridge) wrote : | #13 |
> I would vote for keeping the "amd64+mac" version alive in contrast to the suggestion of Chris in
> bug #633983 which was based on the assumption that it wasn't needed any more.
My incorrect reasoning was that since Fedora and Debian both ship a single image, so it may not be necessary for Ubuntu to ship two. I'm still surprised that Debian does not boot, so it seems there's no official way to install Debian on your system.. I've opened bug https:/
I wonder if Fedora 20 fails on your Macbook? If so, it would seem that having two images really is necessary, and both Fedora and Debian are doing it wrong.
> Now i wonder why an "amd64+mac" image is offering only the two
> boot paths for PC-BIOS firmware.
Have you seen http://
Thomas Schmitt (scdbackup) wrote : | #14 |
Hi,
> so it seems there's no official way to install Debian on your system.
If the theory with the multiple El Torito boot images is right,
then Debian 7 i386 ISOs should boot.
They have the same firmware related equipment as
trusty-
> Have you seen
> http://
Now i have. It all smells like "One leg good, two legs bad".
One could cut off the surplus leg.
Boot record : El Torito , ISOLINUX isohybrid MBR pointing to boot image
Boot catalog : '/boot.cat'
Boot image : '/isolinux.bin' , boot_info_table=on
Boot image : '/boot/
TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 0 , 14879s , CDROM
- I read the catalog block number as little endian 32-bit word from
ISO image byte offset 32768 + 2048 + 71. (Byte offset count starts at 0.)
- In that block (2048 bytes per block), i zeroize the bytes 64 to 2047.
Actually it should suffice to zeroize only byte 64. But i see all
zeros in the working boot catalog of amd64+mac.
Et voila ...
Boot record : El Torito , ISOLINUX isohybrid MBR pointing to boot image
Boot catalog : '/boot.cat'
Boot image : '/isolinux.bin' , boot_info_table=on
TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 0 , 14879s , CDROM
This can be done by shell commands on a little endian machine.
Just combine eval, expr, dd, od, head, sed. :)))
Nevertheless one will be better off with a different programming
language.
Such a program could be included in the ISO.
Usage: Mount ISO, run program, unmount ISO, burn to DVD.
Have a nice day :)
Thomas
Sebastian Busch (webmaster-thamnos) wrote : | #15 |
Thomas: The URL of the "regular" amd64 ISO is
http://
From what I read, the i386 ISOs can generally be installed without problems. I have also tried and can confirm that I can get to the "Debian GNU/Linux installer boot menu" using a CD with
http://
on it without problems on my Macbook.
Chris: Thank you for opening the Debian bug. Fedora 20 ISO
download.
installed from a DVD fails with
-----------
1.
2.
3.
Select CD-ROM Boot Type:
-----------
and an unresponsive system.
Thomas Schmitt (scdbackup) wrote : | #16 |
Hi,
> http://
If you are curious enough, here is a C program which i assume
makes the trusty-
- Put both, a copy of the ISO and the C program as
make_
into the same directory.
- Compile the C program:
cc -g -Wall -o make_single_
- Run it without arguments (the ISO name is hardcoded in variable iso_name):
./make_
- Put the ISO onto DVD and try booting.
=======
/*
Removes all entries but the first one from the El Torito boot catalog of
http://
Compile by:
cc -g -Wall -o make_single_
Run without arguments in the directory where the ISO image is stored.
*/
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
static char *iso_name = {"trusty-
int main(int argc, char **argv)
{
int fd, ret;
unsigned char buf[2048 - 64];
off_t lba;
size_t buf_size = 2048 - 64;
fd = open(iso_name, O_RDWR);
if (fd == -1)
goto err_ex;
if (lseek(fd, (off_t) 32768 + 2048 + 71, SEEK_SET) == -1)
goto err_ex;
ret = read(fd, buf, 4);
if (ret == -1)
goto err_ex;
if (ret < 4) {
fprintf(stderr, "Cannot read 4 bytes from %s\n", iso_name);
exit(1);
}
lba = buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24);
if (lseek(fd, lba * 2048 + 64, SEEK_SET) == -1)
goto err_ex;
memset(buf, 0, buf_size);
ret = write(fd, buf, buf_size);
if (ret == -1)
goto err_ex;
if (ret < buf_size) {
fprintf(stderr, "Cannot write %d bytes to %s\n", (int) buf_size, iso_name);
exit(1);
}
close(fd);
printf("done\n");
exit(0);
err_ex:;
perror(iso_name);
exit(1);
}
=======
(Of course it would apply to any El Torito equipped ISO, not only to
the Ubuntu image in question.)
Have a nice day :)
Thomas
Dave Walker (davewalker) wrote : | #17 |
For reference, here is how the current xorriso is configured:
xorriso-
Thomas Schmitt (scdbackup) wrote : | #18 |
Hi,
> For reference, here is how the current xorriso is configured:
The current theory (obviously already known to Colin Watson)
is that the combination of -b and -e is to blame for the
reaction of the Mac.
As soon as more than one single -b (or -e) was given, it offers
the user an unusable choice menu of boot images.
-------
Some upstream nitpicking:
> -checksum_
This option is a surplus remnant of Jigdo production.
Being alone, it has no effect.
(One can record MD5 for image and each data file by option --md5.
The checksums are stored in an array at the end of the ISO.
Format described in
http://
)
> -isohybrid-
I already asked at debian-cd why this option is used although no
HFS+ image file is added as third boot image (as Fedora does).
It seems that Macs which want an Apple Partition Map also want HFS+.
(We will never find out if the option is not omitted until
somebody reports that it really would be needed.)
Have a nice day :)
Thomas
Sebastian Busch (webmaster-thamnos) wrote : | #19 |
Hi Thomas,
Your little C program works for me using the official 14.04 release (obviously adjusting the name of the iso file). Thank you!
Best,
Sebastian.
Thomas Schmitt (scdbackup) wrote : | #20 |
Hi,
> Your little C program works for me
So if maintainance of the separate amd64+mac image becomes
cumbersome, it would be possible to replace it by some ISO 9660
patching service for the current amd64 images.
Possible occasions for patching:
- After production of standard ISO (making obsolete the need
for maintaining separate production scripts).
- At download time on the server (if it is economic to do it
on-the-fly).
- After download by help of a program that is executable
(or can be copied) from the mounted ISO.
The byte manipulation procedure is based on El Torito specs:
Version 1.0, January 25, 1995, IBM and Phoenix Technologies.
(Read underlined text in paragraph 2.0, hop to figure 7,
see what shall stay preserved in figures 2 and 3, see what shall
be erased in figures 4 and 5.)
It assumes that not more than 32 boot images are announced by the
boot catalog, or that it suffices to deface the first additional
boot section in order to truncate the catalog.
As for the name "amd64+mac": Wouldn't "amd64-bios-only" be more
appropriate ?
We know by now that there is nothing Mac-specific in the image
compared with the standard "amd64" image. It just does not step into
a known Mac firmware bug by restricting itself to amd64 pre-UEFI.
Have a nice day :)
Thomas
Jean-Francois Dockes (jean-francois-dockes) wrote : | #21 |
Just as an additional data point, I can confirm that, on a 2008 core2 duo macbook pro, the amd64+mac images work, the amd64 ones don't and an xubuntu 14.04 amd64 image fixed by the above c program works too.
jf
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote : | #22 |
i agree that since it is known that there are other machines that have this problem outside of macs, "amd64-bios-only" or "amd64-old-efi" (since uefi is a subset of efi, or at least a fork!) renaming would make the most amount of sense.
going back to the apples, they have released a series of firmware updates:
http://
i have a theory that assuming these updates are applied there may actually be no need for the +mac images at all, at least for any mac. i would suggest that everyone make sure they have the latest firmware and then try again. additionally, i would suggest posting the results here along with your model and efi version, which you can find through `dmidecode`.
ԜаӀtеr Ⅼарсһуnѕkі (wxl) wrote : | #23 |
i'm calling this fix released because ubuntu got rid of the amd64+mac images as of 14.10. see here for more info https:/
Changed in ubuntu-cdimage: | |
status: | New → Fix Released |
guynux (guynux) wrote : | #24 |
My iMac 6.1 (late 2006) need the amd64+mac image to boot (DVD only).
This machine has a 32 bit EFI/firmware (non upgradable) and a core 2 duo. Does'nt boot with amd64 only, but does with all 32 bit images.
So, my opinion is that amd64+mac images are necessary if it does not make to much work for the bave developpers. Thks
Brian (ubuntu-one-m) wrote : | #25 |
Mac Mini (Mid 2007):
Had the unusable-"Select CD-ROM Boot Type"-menu error with Debian Wheezy, but Trusty+mac worked.
(I think) the relevant output of dmidecode (under uname Linux ubuntu 3.13.0-32-generic):
BIOS Information
Vendor: Apple Inc.
Version: MM21.88Z.
Release Date: 06/28/07
ROM Size: 2048 kB
PCI is supported
BIOS Revision: 0.1
Apple's firmware update page doesn't show any available updates for this machine.
Rogerio Luz Coelho (rogerio-luz-coelho) wrote : | #26 |
I confirme that on a Macbook 4,1 (circa 2008) I have updated the firmware and that the "14.04.3 -amd" DOES NOT boot while the "14.04.3-amd+mac" does.
Will try to make intall media from other distros using the above program, but will have to report this later.
Thanks.
Rogerio Luz Coelho (rogerio-luz-coelho) wrote : | #27 |
- refind.conf that enables booting the 14.04.3 amd+mac DVD Edit (24.7 KiB, text/plain)
For those willing to try to make their Mac with 64bits capabilities boot 64bit kernels natively there is this hack ** you will use it by your own risk **
For those who don't know if their EFI is 32 or 64 bits:
you have to know your Mac's processor and its speed, than go to this site:
...
I have been able to boot to Ubuntu 14.04.3 64bit after I made modifications to rEFInd's configuration files (while logged in in the OSX) on a originally 32bit OSX by intalling rEFInd (witch automatically detects the 64bit) and then tweaking the refind.conf.
BUT it will NOT work to boot a USB !!!
So to all who may try it , I recomend getting Textwrangler for Mac ... I is easier to copy paste that way ... they have a compatibility page and will run on anything from 10.4 onwards.
1) Download rEFInd
2) unzip it
3) open Terminal and do a "sudo su"
4) go the unzipped folder
5) type "./refind-install"
6) reboot your Mac -- new rEFInd boot screen - choose Mac OSX
7) after boot open Terminal again - "sudo su" again
8) Go to rEFInd folder again type "./mountesp"
9) go to /Volumes/
10) edit the refind.conf file as below (copy paste should work if you installed TextWrangler above)
11) reboot with the 14.04.3 DVD in the MacBook 4,1
Let us know how it went!
Rogerio
Rogerio Luz Coelho (rogerio-luz-coelho) wrote : | #28 |
CONFIRMED !!!
Ubuntu 14.04.3 -amd64+mac successfully installed in a Macbook 4,1 with Core 2 Duo in 64 bits with rEFInd tweak as the above coment / attachment.
It takes a while but all went well .
Rogerio
This bug has been reported on the Ubuntu ISO testing tracker.
A list of all reports related to this bug can be found here: iso.qa. ubuntu. com/qatracker/ reports/ bugs/1298894
http://