Page 6 of 6 FirstFirst ... 456
Results 51 to 59 of 59

Thread: Call for testing the current daily Groovy iso files

  1. #51
    Join Date
    Nov 2011
    Location
    /dev/root
    Beans
    Hidden!

    Re: Call for testing the current daily Groovy iso files

    @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'.
    Last edited by sudodus; October 15th, 2020 at 08:20 AM. Reason: I noticed your test reports at the iso testing tracker and modified this post accordingly

  2. #52
    Join Date
    Apr 2008
    Beans
    11,672

    Re: Call for testing the current daily Groovy iso files

    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

  3. #53
    Join Date
    Aug 2017
    Location
    melbourne, au
    Beans
    739
    Distro
    Lubuntu Development Release

    Re: Call for testing the current daily Groovy iso files

    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!)
    Last edited by guiverc; October 16th, 2020 at 04:11 AM. Reason: add thanks to kansasnoob instead of adding another post

  4. #54
    Join Date
    Nov 2011
    Location
    /dev/root
    Beans
    Hidden!

    Re: Call for testing the current daily Groovy iso files

    Quote Originally Posted by sudodus View Post
    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
    Quote Originally Posted by kansasnoob View Post
    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.

  5. #55
    Join Date
    Aug 2017
    Location
    melbourne, au
    Beans
    739
    Distro
    Lubuntu Development Release

    Re: Call for testing the current daily Groovy iso files

    Quote Originally Posted by sudodus View Post
    @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.

  6. #56
    Join Date
    May 2014
    Beans
    14

    Re: Call for testing the current daily Groovy iso files

    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?

  7. #57
    Join Date
    Apr 2008
    Beans
    11,672

    Re: Call for testing the current daily Groovy iso files

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

  8. #58
    Join Date
    Aug 2017
    Location
    melbourne, au
    Beans
    739
    Distro
    Lubuntu Development Release

    Re: Call for testing the current daily Groovy iso files

    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

  9. #59
    Join Date
    Nov 2011
    Location
    /dev/root
    Beans
    Hidden!

    Re: Call for testing the current daily Groovy iso files

    Quote Originally Posted by kansasnoob View Post
    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".
    Quote Originally Posted by guiverc View Post
    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

Page 6 of 6 FirstFirst ... 456

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •