amd64+mac images no longer necessary

Bug #1298894 reported by Chris Bainbridge on 2014-03-28
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Ubuntu CD Images
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)

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1298894

tags: added: iso-testing

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.

> 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://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso

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.

No, this Debian ISO does not boot either.

> No, this Debian ISO does not boot either.

Could you report it as a bug in Debian, against package "cdimage.debian.org"

Thomas Schmitt (scdbackup) wrote :

Hi,

i wgot
  http://archive.ubuntu.com/ubuntu/dists/saucy/main/installer-amd64/current/images/netboot/mini.iso

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://mjg59.dreamwidth.org/11285.html

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

> 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://glandium.org/blog/?p=2830

Hi,

I had two Fedora CDs which I tried:
Fedora-17-x86_64-Live-Desktop
Fedore-18-x86_64-netinst

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 :

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/grub/efi.img for EFI
Fedora Live-CD (2 years old) has
  /isolinux/isolinux.bin for BIOS
  /isolinux/efiboot.img for EFI containing FAT
  /isolinux/macboot.img for EFI containing HFS+

Do you get any progress if you select one blindly ?
Probably 2 and 3 would be good candidates.

Have a nice day :)

Thomas

> ----------
> 1.
>
> 2.
>
> Select CD-ROM Boot Type :
> -----------

This is mentioned in http://mjg59.dreamwidth.org/4957.html copy/paste follows..:

[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.

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://support.apple.com/kb/ht1635

From the comments on http://mjg59.dreamwidth.org/11285.html :
"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://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64+mac.iso
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 :

Hi,

> http://mjg59.dreamwidth.org/4957.html

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_efi_only.iso \
     -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_bios_only.iso \
     -r -V "CDROM" \
     -c boot.cat \
     -b isolinux.bin \
        -no-emul-boot -boot-load-size 4 -boot-info-table \
     /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/grub/efi.img' , platform_id=0xEF
  TOC layout : Idx , sbsector , Size , Volume Id
  ISO session : 1 , 0 , 14879s , CDROM
  ...

Sebastian Bush:
> The ISO that works is
> http://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64+mac.iso

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.cat'
  Boot image : '/isolinux/isolinux.bin' , boot_info_table=on
  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-desktop-amd64+mac.iso bs=512 count=1 of=isohybrid.mbr
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

> 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://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744959 for that

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://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image

Thomas Schmitt (scdbackup) wrote :

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-desktop-amd64+mac.iso.

> Have you seen
> http://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image

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/grub/efi.img' , platform_id=0xEF
  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

Thomas: The URL of the "regular" amd64 ISO is
http://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64.iso

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://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso
on it without problems on my Macbook.

Chris: Thank you for opening the Debian bug. Fedora 20 ISO
download.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64/iso/Fedora-20-x86_64-DVD.iso
installed from a DVD fails with
-----------
1.

2.

3.
Select CD-ROM Boot Type:
-----------
and an unresponsive system.

Thomas Schmitt (scdbackup) wrote :

Hi,

> http://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64.iso

If you are curious enough, here is a C program which i assume
makes the trusty-desktop-amd64.iso bootable on your 2,1.

- Put both, a copy of the ISO and the C program as
    make_single_eltorito.c
  into the same directory.

- Compile the C program:
    cc -g -Wall -o make_single_eltorito make_single_eltorito.c

- Run it without arguments (the ISO name is hardcoded in variable iso_name):
    ./make_single_eltorito

- Put the ISO onto DVD and try booting.

========================= Begin of C program =========================
/*
 Removes all entries but the first one from the El Torito boot catalog of
   http://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64.iso

 Compile by:
   cc -g -Wall -o make_single_eltorito make_single_eltorito.c

 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-desktop-amd64.iso"};

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);
}
========================== End of C program ==========================
(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 :

For reference, here is how the current xorriso is configured:

xorriso-1.2.4/xorriso/xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V Ubuntu\ 14.04\ LTS\ amd64 -o /srv/cdimage.ubuntu.com/scratch/ubuntu/trusty/daily-live/debian-cd/amd64/trusty-desktop-amd64.raw -isohybrid-mbr syslinux/usr/lib/syslinux/isohdpfx.bin -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat -isohybrid-apm-hfsplus boot1 CD1

Thomas Schmitt (scdbackup) wrote :

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_algorithm_iso md5,sha1

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://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/checksums.txt
)

> -isohybrid-apm-hfsplus

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

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 :

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

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

Walter Lapchynski (wxl) wrote :

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://support.apple.com/kb/HT1237
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`.

Walter Lapchynski (wxl) wrote :

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://wiki.ubuntu.com/UtopicUnicorn/ReleaseNotes#Boot.2C_installation_and_post-install

Changed in ubuntu-cdimage:
status: New → Fix Released
guynux (guynux) wrote :

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 :

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.009A.B00.0706281359
        Release Date: 06/28/07
        ROM Size: 2048 kB
        Characteristics:
                PCI is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                ACPI is supported
                IEEE 1394 boot is supported
                Smart battery is supported
                Function key-initiated network boot is supported
        BIOS Revision: 0.1

Apple's firmware update page doesn't show any available updates for this machine.

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.

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 **

http://netkas.org/?p=127

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:

http://www.everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html

...

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/ESP//EFI/refind
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

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.