[Bug 1886148] Re: failure to boot groovy daily

[Thomas Schmitt]

Hi,

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

Me not so much. GPT has that backup at the end of the device. But when
an image is made, the size of the storage device is not known. So after
putting (cloning) the image onto the USB stick, the backup GPT is
misplaced.

So we'd actually need an adjustment step after cloning, although the boot
firmwares don't care for that flaw. But partition editors do.
(Modern versions of program sfdisk fix the problem silently when any
 manipulation of GPT is done. E.g.:
   echo 'name=DATA' | sudo sfdisk -a /dev/sdc
)

But if more machines boot by GPT than by MBR partition table, i can hardly
be against it. Let's see what problems this causes ...


> I do see that the GPT has an extra partition at the end; is this required
> for alignment?

It's the padding against the TAO CD Read-Ahead Bug. This bug is caused by
an ambiguity in SCSI MMC specs about command READ CAPACITY when the last
track ends by two TAO Run-out blocks. About 80 percent of CD capable drives
count them as readable, which they are not for data read command READ(10).

By a cargo cult theory of last century, ISO 9660 producers and most burn
programs add 300 KiB of padding to keep legitimate read operations away
from the dangerous end of the device.
Actually it would have to be the buffer size of Linux when reading ahead
of the block range that is requested by the ISO 9660 filesystem driver.

(If i had a better standing at linux-scsi it would already be fixed for
 single session by testing the last two blocks for readability and
 adjusting the device size perception of the kernel if they are not
 readable by READ(10). I have made me a kernel which does this.)

With ISO images which never end up on a CD you can safely suppress this
padding by xorriso -as mkisofs option

  -no-pad

Even then most CD burn programs will add their own padding by default or
use write type SAO which produces no Run-out blocks.


> I haven't seen such partition entries when using MBR.

With MBR partition table the padding is either counted as part of
partition 1 (old Fedora/Debian/Ubuntu layout) or not marked as partition
(with appended partition).

The reason for that GPT partition is probably in my discussions with
Vladimir Serbinenko when i made xorriso ready for serving under
grub-mkrescue. If we find compelling reasons not to create it, i could
try to suppress this.
(The boot preparation code in libisofs is quite entangled by the many
 variations and little stunts which it accumulated over time.)

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