[Bug 1886148] Re: failure to boot groovy daily

Fri Oct 9 22:57:26 UTC 2020

Thanks very much for the analysis, Thomas!

> There remain riddles:

> Why does the grub-mkrescue ISO not boot on V14IIL ?
> (I still wonder which other ISOs boot on that machine.)

> Why did the old Ubuntu ISOs with their invalid GPT boot on sudodus' V130
> whereas a similarly invalid GPT did not help with the 20201007.1 ISO ?

Yes, that is puzzling.

> Maybe Canonical Ltd. should ask Lenovo Group Limited for
enlightenment.

I've escalated it internally to the right team, and they will follow up, but
no guarantees we'll get a meaningful answer :)

>
-------------------------------------------------------------------------

> The xorrisofs option to cause GPT during the production of an Ubuntu ISO
> would be

>   -appended_part_as_gpt

Thinking it through, I am happy for us to make this change from MBR to
GPT.

- optical media don't care about the partition table, only the El-Torito
  boot image.
- BIOS boot of USB doesn't care about the partition table, only the MBR
- UEFI 2.0 requires systems to understand GPT
- pre-2.0 UEFI systems are mostly not guaranteed to work anyway.

I've made this switch now and confirmed the result at
<http://cdimage.ubuntu.com/ubuntu/daily-live/20201009.1>.  

I do see that the GPT has an extra partition at the end; is this required
for alignment?  I haven't seen such partition entries when using MBR.

$ gdisk -l ~/devel/iso/groovy-desktop-amd64.iso 
GPT fdisk (gdisk) version 1.0.5

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

Found valid GPT with protective MBR; using GPT.
Disk /home/vorlon/devel/iso/groovy-desktop-amd64.iso: 5736268 sectors, 2.7 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 8897A8AA-43A3-4BD4-A4AA-C472E4376703
Partition table holds up to 248 entries
Main partition table begins at sector 2 and ends at sector 63
First usable sector is 64, last usable sector is 5736204
Partitions will be aligned on 4-sector boundaries
Total free space is 1 sectors (512 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              64         5725651   2.7 GiB     0700  ISO9660
   2         5725652         5735603   4.9 MiB     EF00  Appended2
   3         5735604         5736203   300.0 KiB   0700  Gap1
$

Here is the full commandline used to construct this image.

xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V Ubuntu\
20.10\ amd64 -o /srv/cdimage.ubuntu.com/scratch/ubuntu/groovy/daily-live
/debian-cd/amd64/groovy-desktop-amd64.raw -J -joliet-long -l -b
boot/grub/i386-pc/eltorito.img -no-emul-boot -boot-load-size 4 -boot-
info-table --grub2-boot-info --grub2-mbr cd-boot-images/usr/share/cd-
boot-images-amd64/images/boot/grub/i386-pc/boot_hybrid.img
-append_partition 2 0xef cd-boot-images/usr/share/cd-boot-images-
amd64/images/boot/grub/efi.img -appended_part_as_gpt -eltorito-alt-boot
-e --interval\:appended_partition_2\:all\:\: -no-emul-boot
-partition_offset 16 cd-boot-images/usr/share/cd-boot-images-amd64/tree
CD1

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cd-boot-images-arm64 in Ubuntu.
https://bugs.launchpad.net/bugs/1886148

Title:
  failure to boot groovy daily

Status in OEM Priority Project:
  New
Status in Ubuntu CD Images:
  In Progress
Status in casper package in Ubuntu:
  Invalid
Status in cd-boot-images-amd64 package in Ubuntu:
  Fix Released
Status in cd-boot-images-arm64 package in Ubuntu:
  Fix Released

Bug description:
  When reported the groovy daily was failing on most boxes..

  Originally occurred if ISO is written via `dd`, `mkusb`, `Startup Disk
  Creator`, or `gnome-disks` (Restore disk image)

  Box still impacted are (owned by sudodus/nio-wiklund)

  * Lenovo V130

  and owned by Leó Kolbeinsson

  * Lenovo V14 IIL,Intel Core i3-1005G!,8GB,256GB SSD

  ---
  Original detail follows
  (with minimal edits; these boxes now boot groovy ISOs)

  This is very similar to https://bugs.launchpad.net/bugs/1883040

  Boxes that have failed to boot it are

  dell [optiplex] 755 (c2d-e8300, 8gb, amd/ati radeon rv610/radeon hd2400 pro/xt)
  dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
  dell [optiplex] 780 (c2q-q9400, 4gb, amd/ati cedar radeon hd 5000/6000/7350/8350)
  hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
  hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)
  sony vaio svp112a1cw (i5-9400u, 4gb, intel haswell-ULT)

  --  sudodus' boxes
  dell Precision M4800
  dell Latitude E7240
  Toshiba Satellite Pro C850-19w
  HP Probook 6450b - works now

  --  leok's boxes
  Acer [Aspire] E3-111-P60S (Pent.N3530, 4GB, Intel HD Graphics, Realtek RTL8111/81681/8411 GB Ethernet, Qualcomm Atheros AR9462 Wireless, Bluetooth Atheros A315-53, 500 GB hd)

  Dell [Optiplex] 7010 ( i5-3470 , 16 GB, Intel Graphics 2500, Intel
  82579LM GB Ethernet ,1TB hd) VirtualBox

  Dell [Inspiron] 3521, (i3-3217U, 4GB, Intel HD Graphics 4000, Intel HM76 chipset 10/100 Mbps ethernet controller integrated on system board, WiFi 802.11 b/g/N, Bluetooth 4.0, 500 GB hd)
  --

  The ISO was written twice to two different thumb-drives. Same issue
  each time on same boxes.

  On a number of boxes it’s wanting me to download aka
  https://bugs.launchpad.net/ubuntu-cdimage/+bug/1883040 however it’s
  done that on boxes not impacted by that bug, which makes me think
  thumb-drive/squashfs errs related.  Also results of boot appeared
  different on varying boxes (inconsistent; dc7700 reported no thumb-
  drive; d755-5 also did that sometimes, sometimes it got to wanting to
  download - those two boxes were impacted by prior report; the
  remaining boxes were more consistent in response..; but if trouble
  reading data on thumb-drive then the slower boxes (dc7700/d755-5) may
  have more issues & thus be less consistent?)

  I'll file this as a bug report so I can close my failed QA-tests, but
  I'm considering changing the status to 'incomplete', and re-testing
  tomorrow, OR it needs me to re-write ISO from a different box to a
  third-thumb-drive as I don't think I've ruled out media issues given
  Leok's report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1886148/+subscriptions