Call for testing the current daily Groovy iso files

**sudodus** · October 15th, 2020

@guiverc,

1. I think your tests with the current Ubuntu Groovy iso file are enough for this purpose.

2. This is another test, that you should do with an iso file that makes the USB drive perform differently between the first and subsequent boot attempts: In the bug report, comment #41 I am suggesting some methods to test in a way that should not change the content of the USB drive, and the result should be possible to reproduce: Use the boot option 'nopersistent'.

**kansasnoob** · October 16th, 2020

So, back to testing on the Dell Latitude E6510 with Ubuntu daily 20201015 on a USB created by Start Up Disk Creator in Focal and still no dice so I added a comment here:

https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308

**guiverc** · October 16th, 2020

I did more testing this morning... however i'm hopeful my issues with 1899308 will be resolved when casper is bumped to 1.454 (current ISOs are using 1.452); ie. in the 1.454 changelog are what I hope will fix it. (1.454 was queued prior to final freeze)

For Lubuntu purposes I've posted on our discourse (I can always hope we'll get more testing). My (this) post is a mixture of details from bug report (where loads of it goes above my head!), plus a lot from IRC discussions (I'm a fly on the wall in #ubuntu-release).

@sudodus I hadn't read your comment #51 of this thread before my earlier testing today; I was completing tests I wanted to do yesterday but lacked time (ie. to prove it wasn't just `dus`)

I'll test a standard `dus` written ISO with boot option `nopersistent` when/if I can. (I no longer see it as high-priority unless 1.454 doesn't work like I hope it will)

ps: Thanks for your testing @kansasnoob (knowledge it impacts non-HP added weight!)

**sudodus** · October 16th, 2020

Originally Posted by sudodus

I'm glad you found this before the release of Groovy.

So now there are problems not only with old HPs but also old Dells, and you can add more heat to the bug report #1899308

Please be sure to test the current Ubuntu Desktop Groovy iso file when cloned (for example via Startup Disk Creator or mkusb) in the old Dells:

Ubuntu Groovy version dated Okt 13 08:36 from zsync,

- '20201013.1' in the testing tracker

Code:

$ ls -l groovy-desktop-amd64.iso
-rw------- 1 sudodus sudodus 2894153728 okt 13 08:36 groovy-desktop-amd64.iso

$ sha256sum groovy-desktop-amd64.iso
3b92cb0d427998b5a7f58377d0204ef56e3f21e8748331bef4005f8f244e814f groovy-desktop-amd64.iso

It might work, and anyway your test result will be valuable information for squashing this bug.

I think the old Dells will boot from

- DVD

- a tweaked iso file converted to msdos partition table using xorriso according to instructions from Thomas Schmitt in the bug report #1899308

- a persistent live drive made with mkusb with the settings

. 'usb-pack-efi' and
. 'msdos partition table'

- a 'nopersistent' USB drive created by mkusb-plug might work. See the details at

. bug report 1899308, comment #41 and #56 and
. help.ubuntu.com/community/mkusb/plug

Originally Posted by kansasnoob

So, back to testing on the Dell Latitude E6510 with Ubuntu daily 20201015 on a USB created by Start Up Disk Creator in Focal and still no dice so I added a comment here:

https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308

@ kansasnoob,

It would be interesting to know if any of the suggested workarounds (that work for the old HPs with c2d CPUs) will work for your old Dells. I think DVD or persistent live drive made with mkusb are most likely to work.

On the other hand, maybe you do not intend to use 20.10 on these old Dells, but intend to stay with 20.04.x LTS. But I think this bug should be squashed or at least worked around until the next LTS version.

**guiverc** · October 16th, 2020

Originally Posted by sudodus

@guiverc,
..

2. This is another test, that you should do with an iso file that makes the USB drive perform differently between the first and subsequent boot attempts: In the bug report, comment #41 I am suggesting some methods to test in a way that should not change the content of the USB drive, and the result should be possible to reproduce: Use the boot option 'nopersistent'.

Today's (2020-10-15) ISO was re-written to thumb-drive using normal `dus` in live mode.

Booted on
- hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915)

with 'nopersistent' added to kernel line at grub.

It was shutdown (I ejected & re-inserted) thumb-drive.

It booted a second time as you expected (again using `nopersistent`) on
- hp dc7900 (c2d-e8400, 4gb, intel 4 series integrated i915)
Machine was shutdown.

It was then tested on (again using `nopersistent`)
- hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)
and booted (again using `nopersistent).

Yep, the `nopersistent` option allows the thumb-drive to be re-used, as you believed.

**brisch** · October 16th, 2020

I am a long time user of UBUNTU and have upgraded every cycle.
Started the latest cycle in May and have been updating every two days.
About a week ago I decided to install a latest test and ended up crashing in smoke like many others.
Used my usual way of starting an install (this I the way I do it) selecting the something else in the
install menu. After several failures I went back to gparted and started with a fresh setup of the disk.
Still no luck so I decided to go at it in another way.
rather then selecting something else I chose a clean install including clearing the disk.
This one worked and now I am going to describe some of the things I found.
I found the discussion on the GUID partiltion table and how it arranges the disk structure.
This I my WAG many of the computers have been set up for the disk for the user.
I found that comparing the older partition table I set up.
The GUID table was different so my predefined partition table did not work.
By allowing the install to define the disk structure it was not exactly like how I set
up the partition table. Perhaps people are trying to use their old disk structure
and grub-install will not work. It is possible that partition table uses the whole disk
and grub can't configure properly. What are your thoughts?

**kansasnoob** · October 17th, 2020

The latest daily seems to have my Latitude's sorted out. First boot OK, second boot OK, and trying in yet another laptop it's still good so I'd call that "sorted out".

**guiverc** · October 17th, 2020

Yeah, I agree with @kansasnoob.

Casper 1.455 has fixed Ubuntu groovy 2020-10-16.4, so with luck flavors will be fixed with tomorrow's daily.

Another win (unrelated to ISO booting, but with `calamares` so Lubuntu & Ubuntu Studio) was also fixed ~today; https://bugs.launchpad.net/ubuntu/+s...s/+bug/1898501

**sudodus** · October 17th, 2020

Originally Posted by kansasnoob

The latest daily seems to have my Latitude's sorted out. First boot OK, second boot OK, and trying in yet another laptop it's still good so I'd call that "sorted out".

Originally Posted by guiverc

Yeah, I agree with @kansasnoob.

Casper 1.455 has fixed Ubuntu groovy 2020-10-16.4, so with luck flavors will be fixed with tomorrow's daily.

Another win (unrelated to ISO booting, but with `calamares` so Lubuntu & Ubuntu Studio) was also fixed ~today; https://bugs.launchpad.net/ubuntu/+s...s/+bug/1898501

+1

The current Ubuntu Desktop (standard Ubuntu) Groovy version dated Okt 17 08:30 from zsync,

- '20201017' in the testing tracker

Code:

ls -l groovy-desktop-amd64.iso
-rw------- 1 sudodus sudodus 2942062592 okt 17 08:30 groovy-desktop-amd64.iso

$ sha256sum groovy-desktop-amd64.iso
f572ff624215e00b398233be6a9e482d41b706c24266ed05bd019a6ab75bf53d groovy-desktop-amd64.iso

when cloned to a USB3 pendrive, can boot

- an old HP Elitebook 8560p (in BIOS mode) - This was problematic in the previous daily iso file, it booted only the first time. Now it booted successfully 3 times in a row. The 300K partition is preserved and the ext4 partition is created correctly (and preserved between boots).

- a middle-aged Dell Precision M4800 (in BIOS mode and UEFI mode) - Works as usual.

- a newer Lenovo V130 (in UEFI mode with secure boot) - Works since GUID partition table.

I tested with a second USB drive, this time an SSD connected via a USB3 to SATA adapter and cloned from the iso file.

- I started booting the Lenovo V130 in UEFI mode with secure boot (and let it create the ext4 partition). The 300K partition is preserved and the ext4 partition is created correctly.

- Then I tested with the previously problematic HP Elitebook 8560p (in BIOS mode). It booted as it should.

It looks like we have squashed this bug