[Bug 1886148] Re: failure to boot groovy daily

Thu Oct 8 20:17:37 UTC 2020

Hi,

> 3. The Dell boots to the grub prompt both in BIOS mode and UEFI mode.
> Success :-) What's next :-P

You could try a GPT partitioned groovy.iso.

In the hope that the automat knows best:

  test -f test.iso && rm test.iso

  xorriso \
    -indev groovy-desktop-amd64.iso \
    -outdev test.iso \
    -boot_image any replay \
    -boot_image any appended_part_as=gpt \
    -boot_image any mbr_force_bootable=off

The "replay" command is supposed to apply the commands to set up the
same boot equipment as the original ISO has. The two following commands
-boot_image switch from MBR partition table to GPT and disable the
forced boot flag, which was inherited from the original's boot flag.

Partition editors should then report GPT in test.iso . Like

  $ /sbin/gdisk -l test.iso
  ...
  Found valid GPT with protective MBR; using GPT.
  ...
  Number  Start (sector)    End (sector)  Size       Code  Name
     1              64         5714919   2.7 GiB     0700  ISO9660
     2         5714920         5724871   4.9 MiB     EF00  Appended2

(The alternative to above replay automat would be what i show in
   https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1895131/comments/22
 with other numbers. For
   0ca0a6242caffcb7c67497fc659f2b8c  groovy-desktop-amd64.iso
 they would be 5715916 and 9952.)

-------------------------------------------------------------------------

About the theory that the position of the EFI partition is too far up:

  test -f test.iso && rm test.iso

  xorriso \
    -indev groovy-desktop-amd64.iso.1 \
    -outdev test.iso \
    -boot_image any replay \
    -rm_r /pool /casper/filesystem.squashfs --

This produces a much smaller ISO with MBR partition table (add above
-boot_image commands to get GPT):

  $ /sbin/fdisk -l test.iso
  ...
  Disklabel type: dos
  ...
  Device     Boot  Start    End Sectors   Size Id Type
  test.iso1  *        64 238375  238312 116.4M cd unknown
  test.iso2       238376 248327    9952   4.9M ef EFI (FAT-12/16/32)

It will probably not boot successfully beyond GRUB, because the ~2 GB of
filesystem.squashfs will be painfully missed as soon as the kernel is up.

But if it gets to the Ubuntu GRUB menu then this would indicate that
the start address of the EFI partition matters.

(Another test could be to move the EFI partition of a working USB stick
 high up and to check whether it then does not boot any more.)

-------------------------------------------------------------------------

I refrain for now from proposing to try a partition table layout like
with the older ubuntu ISOs (the barely legal one).

Have a nice day :)

Thomas

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