groovy daily won't boot anymore on some older BIOS boxes

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

For ~exact dating on when this issue occurs - look at my Lubuntu daily testing...

Lubuntu daily boots on hp8200 (the same thumb-drive that I mentioned failing earlier as it no longer boots on hp dc7700 which is a box I very regularly re-wipe with QA-test installs). Of late I've favored the d755 that still boots (it has an issue with calamares.) but my iso.qa.ubuntu.com logs should I'd hope show when this issue first appeared by scanning my lubuntu testing.

(PS: if you have a job I can use to copy text from my searches, I'd love it - forum question hasn't got any answers on how to... I'm not a python coder)

We have recently upgraded the xorrisso utility that is used to produce the
images on the host that builds images.

We are also planning to switch the bootloader on the images from syslinux
to grub.

I wonder if this is related to the switch.

For comparison purposes, does the daily focal images boot for you?

syslinux hasn't changed since 2020-04-24 so is unlikely to be the culprit. Actually I can't see any candidate that has changed recently.

syslinux will be wrong package then, sorry.
I don't understand boot process so can't help with cause.

(my focusing on a `calamares` issue on the d755 that didn't have this issue also means I've favored that box in hopes to gain more detail on lubuntu's calamares issue, but do regularly use dc7700 for QA full disk installs)

Will grab *focal* and test that as I'm able (I'm assuming flavor doesn't matter, I had failures with same boxes with lubuntu - http://iso.qa.ubuntu.com/qatracker/milestones/413/builds/214460/testcases/1303/results/ though it wasn't booted on as many http://iso.qa.ubuntu.com/qatracker/milestones/413/builds/214468/testcases/1303/results)

A thought: on Friday/Saturday/Sunday (5-7 June) testing of Lubuntu, I won't have used the d755 that fails to boot now, in fact may not have used either box

(to open all menu programs in 'live' testing, it's faster on keyboards that have a super key; those boxes share a 1980s ibm model m keyboard. The dc7700 does have it's second (newer) keyboard plugged in so may have used that box one day but may not have)

Focal daily (2020-06-10) booted fine on both d755 & dc7700 boxes that currently fail to boot groovy.

http://iso.qa.ubuntu.com/qatracker/milestones/408/builds/214527/testcases/1303/results

nothing new... I'll type what I see on today's lubuntu ISO on dc7700
(http://iso.qa.ubuntu.com/qatracker/milestones/413/builds/214535/testcases/1303/results/ with thumb-drive booted on hp8200 before hand to prove it's good)

[999. ima:Error Communicating with TPM chip (i ignore this & above 13 messages a number of which are just repeated... they're most likely NOT new)
-- messages that I don't expect --

stdin: Not a typewriter
/init: line 49: can't open /dev/sr0: No medium found
/init: line 49: can't open /dev/sr0: No medium found
Unable to find a medium container a live file system
Attempt interactive netboot from a URL?
yes no (default yes):

--
then a few more messages I consider unrelated

[a bad] photo of above can be found at https://photos.google.com/share/AF1QipMVvJkfURew9B14g4-wmVSUoPMmwjrWCBY1GS9ZDxTa_NPvEwJTEngUnnZAOmsqkQ/photo/AF1QipMVaUp-TGeBobXL4jldkZQ5CcHV2hR8UFnNHOvE?key=dkU2T2c0WUJzVi1xNVI3cURUTG9TZlJyYnNNSnFn

identical messages on d755-5 that has this issue
--
stdin: Not a typewriter
/init: line 49: can't open /dev/sr0: No medium found
/init: line 49: can't open /dev/sr0: No medium found
Unable to find a medium container a live file system
Attempt interactive netboot from a URL?
yes no (default yes):
--

[another bad] photo can be found at https://photos.app.goo.gl/A7dGmC6MLhWh5L6n9
(clean this time without the bs messages I ignore on dc7700)

Lubuntu's current groovy daily booted on d755-5
dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)

[shaky] MOVIE: https://photos.app.goo.gl/zXbsSLd1k3MTzwLw5

Video in case help, you can see
- language selection
- start lubuntu/start lubuntu(safe graphics)/test memory/boot first hdd
- screen blank
- briefly the plymouth then error.

NOTE: the very brief plymouth isn't always detectable on dc7700

WARNING: lower volume.. I didn't think about my playing music

is my timeline accurate??

I don't know how to scan http://iso.qa.ubuntu.com/qatracker/api to download all my tests so I can grep for those specific (impacted) boxes (I copy/paste boxes from a list on first comment line of recorded tests) to see when I booted each... however ..

I booted dc7700 and it only has focal installs; no groovy. Most of my tests are 'live' anyway, and I've already stated I've been focusing on a box unaffected by this issue (due other calamares ~timing issue) so maybe I've used those boxes less & my timeline is inaccurate (my boxes share keyboard/screens anyway [kvm boxes] so mechanical memory is minimal; only usb-insertion & power switch)

@guiverc,

1. Apropos xnox's comment: You could create a persistent live drive with mkusb. It boots via grub (not syslinux) also in BIOS mode. That way you could make sure that it is not related to syslinux.

2. I have seen [the same or similar] complaints about missing optical media recently, but the boot process continued anyway.

3. How far does the boot process proceed? Is the 'writable' partition created? Is it mounted? Is some error log written to it or some crash dump?

Item 3 above concerns cloned live drives, that I think you have been using.

summary: no difference with dus `persistent' over dus `live`

I have written my last lubuntu [groovy] daily ISO (comment #11) using `dus` (mkusb) however where for comment #11 it was written using the 'l' option for 'live' media.. this time I selected "persistent"

In writing (dus) I selected msdos at the format option, default 50% for persistent storage and it wrote.

On booting, on selecting either "Start Lubuntu - persistent" or "Start Lubuntu" the end result is the same
--
stdin: Not a typewriter
/init: line 49: can't open /dev/sr0: No medium found
/init: line 49: can't open /dev/sr0: No medium found
Unable to find a medium container a live file system
Attempt interactive netboot from a URL?
yes no (default yes):
--

I booted the 'persistent' thumb-drive on hp 8200 & it booted fine.. (expected result as box isn't impacted by this issue)

I booted the 'persistent' thumb-drive on d755-5 (also impacted) and other than seeing the `plymouth` lubuntu screen (which I do NOT see on hp dc7700, but appears in my pasted video link as it was filmed on this box) it ended with the same "Attempt interactive netboot' issue..

Possibly?? this proves `syslinux` is wrong package? (based on prior comments)

@guiverc,

Yes, syslinux is not involved at all in persistent live drives by mkusb-dus, so it is innocent.

Will you get more information, when you remove 'quiet splash' from the linux line in grub?

@guiverc,

[Unfortunately for squashing this bug] I got rid of some old computers when I moved to a smaller apartment last summer. My oldest 64-bit computer now has an Intel i3 processor, and it is not affected by this bug.

- Can you boot the current groovy mini.iso into the computers affected by this bug?

- Can you install a text screen system with it?

- Can you install Lubuntu or some other desktop flavour of Ubuntu with it?

The result of such tests might reveal something about the bug.

I'll respond as I can do items. For now I'll provide

Lubuntu groovy daily (maybe two days old, same as my prior two comments)
https://photos.app.goo.gl/ZnGr7E4XHDhJby2r9
https://photos.app.goo.gl/1zPczBNR6BB28b5n6

photos are of same thing, first portrait (more lines vertically seen), second landscape (you can read more of each line) booted on dell 755(-5)

FYI: I haven't found a mini.iso, only netboot iamges for releases up to focal

Found it :) (thanks to @dax on IRC)
http://archive.ubuntu.com/ubuntu/dists/groovy/main/installer-amd64/20101020ubuntu621/legacy-images/netboot/mini.iso

it boots on both boxes (to installer boot menu). I won't overwrite d755 so only went further on dc7700; it commenced debian installer, i went language, keyboard, it recognized network, I selected mirror and it started downloading components... I installed (full disk), including basic server, lubuntu desktop & ssh-server

The install worked perfectly (no date in the /etc/apt/sources.list) file where I usually look for install .. but I can provide /var/log/installer/syslog or whatever but quick glance & all looks good.

Nope; scratch my last (#19) - it's reporting 20.04 & not focal (lsb_release & neofetch given lubuntu-desktop is installed)...

Something is wrong with what I did in #19

Via this link:

http://iso.qa.ubuntu.com/qatracker/milestones/413/builds/213471/testcases

and its 'Link to the download information' you *should* be able to download the relevant mini.iso file. That way I find #621, the same as you refer to. But your results indicate that it is not upgraded from focal, so it was a dead end street :-(

-o-

Looking at your screenshots I see 'casper' mentioned

Begin: Running /scripts/casper-premount ... done.

/init: line 49 ...

If not casper maybe in a more basic 'init' system script.

I think the screenshots in comment #18 are helpful for a developer who knows better than I what should happen when booting a live drive :-)

Thank you for pictures in comment #18

So the above means that it did boot. I.e. bootloader was found, kernel was found, initrd was found, and initrd is booting.

However initrd fails to find the block device where the .iso is.

One change that was done in groovy is to reduce the timeout that initrd waits for was reduced a lot. I am guessing it might be causing the issue here. Let me revert that, and see if things look better.

Please never assign bugs to syslinux.... Please always use "ubuntu-cdimage" project. Because it is clear that iso did boot past the bootloader, kernel and the initrd. Thus it cannot be a syslinux issue.

This bug was fixed in the package casper - 1.451

---------------
casper (1.451) groovy; urgency=medium

  * caser: revert changes to quick-boot (LP: #1883040)

 -- Dimitri John Ledkov <email address hidden> Mon, 15 Jun 2020 11:46:39 +0100

Partial revert is uploaded.

Please try _tomorrows_ images with build-stamp 20200616 or higher, and let me know if you see improvements in bootability of lubuntu images.

Today's Lubuntu groovy daily (20200615) booted on dc7700 :)
Alas it failed on d755-5 box
I'll monitor it anyway (fingers crossed for 20200616...)

@guiverc

If 20200616 is successful, please attach the full syslog from said machine.

i.e. $ sudo journalctl -b > journal.txt

And then attach that file here.

I am interested to know the exact timings, from that machine that was affected. I.e. the d755-5 box with a successful groovy boot.

Successful boot of 20200616 on
dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550)
and requested file

(I'll complete a quick QA-test on this box; then upload same from dc7700 or the other box that was impacted by this issue (the one that booted in comment #26))

Successful boot on 20200616 on
hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)

(this is NOT the box wanted; but in case it's helpful as it suffered from this issue too)

This is now occurring on Ubuntu MATE 2020078 Groovy ISO.

Thinkpad T430N , this system has previous installed prior Groovy Daily ISOs.

Confirmed Ubuntu MATE 20200807 on VAIO F13, i7-740qm, legacy only - fails to boot

Confirmed Ubuntu MATE 20200708 on Thinkpad SL500, c2d T9550, legacy only - fails to boot

Confirmed Ubuntu MATE 20200708 on Asus UX32A, i7-3537u, legacy - fails to boot

Please see bug #1886148 for tracking of the current issue.

A workaround is to write the daily image with unetbootin.github.io that uses syslinux instead of grub.

This is still an issue 9/13/20, ubuntu mate groovy daily build. pre-uefi server won't boot w/ubuntu usb creator, works with unetbootin. Whatever the change was, it happened within the last 10 days or so. An earlier daily build did boot on that same machine without trouble.

server was bare-metal S5000PSL