[Bug 1886129] Re: xubuntu : displays have become blank & unusable

2020-10-02 Thread sudodus
This bug is still alive in the current Ubuntu Desktop Groovy daily iso file dated October 2. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1886129 Title: xubuntu : displays have become blank & unusa

[Bug 1886148] Re: failure to boot groovy daily

2020-09-30 Thread sudodus
@ RussianNeuroMancer, > I guess this bugreport is about first behavior rather about the second? - Yes, because cloning (e.g. with usb-creator-gtk) is what the developers say should work. - On the other hand, no, several users (including me) would like the new boot configuration to work (in UEFI

[Bug 1886148] Re: failure to boot groovy daily

2020-09-29 Thread sudodus
@ Chris Guiver (guiverc), Yes, there is a workaround. The Lenovo V130 can boot with the current daily Lubuntu Groovy iso file also in UEFI mode, when making a persistent live drive by mkusb-dus and selecting 'usb-pack-efi'. See also the following link, https://help.ubuntu.com/community/mkusb/pe

[Bug 1895329] Re: when booting cloned live drive 3rd partition is created without file system

2020-09-27 Thread sudodus
The bug is still there in the current daily Lubuntu Groovy iso file (beta candidate). See the attached screenshot. Please notice that the error is not temporary. It persists after reboot. ** Attachment added: "bug-1895329-in-lubuntu-beta-candidate.jpg" https://bugs.launchpad.net/ubuntu/+sourc

[Bug 1886148] Re: failure to boot groovy daily

2020-09-26 Thread sudodus
@ Norbert (nrbrtx), When you have time and energy, please test - a current daily iso file of a developing version of the flavour that you like - *cloned* to a USB drive - in both BIOS and UEFI mode - in the computers where you want future versions of Ubuntu flavours to work, and that are avail

[Bug 1886148] Re: failure to boot groovy daily

2020-09-26 Thread sudodus
Thanks for the details about the computer, where Ubuntu Groovy fails in UEFI mode, @C.S.Cameron. Now I think there is information for the developers as well as for users with similar hardware as yours. See comments # 115,117-119,121,127. Summary: Computer : Gigabyte GB-BXi7-5775R Processor : In

[Bug 1886148] Re: failure to boot groovy daily

2020-09-26 Thread sudodus
@ Norbert (nrbrtx), You are welcome to systemize all our findings on public Google Spreadsheet :-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1886148 Title: failure to boot groovy daily To mana

[Bug 1886148] Re: failure to boot groovy daily

2020-09-26 Thread sudodus
@ C.S.Cameron, Thanks for the details about the computer. Please add the output of the following command to get info about the graphics chip/card: sudo lshw -C display -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.lau

[Bug 1886148] Re: failure to boot groovy daily

2020-09-25 Thread sudodus
@ C.S.Cameron, It is strange that it works fine in BIOS mode but needs nomodeset in UEFI mode. Something must fail to get activated in UEFI mode. There are obvious problems with Ubuntu Groovy in this computer. Please specify the details about it: Brand name and model of the computer itself as wel

[Bug 1892440] Re: Shell text with wrong size in mutter 3.36.4-0ubuntu0.20.04.2 (mostly on Nvidia)

2020-09-24 Thread sudodus
I tested the current daily Ubuntu Desktop Focal iso file (with a persistent live system), and fractional scaling works with a 4k monitor, where is used to fail. So I see a big improvement :-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubu

[Bug 1886148] Re: failure to boot groovy daily

2020-09-24 Thread sudodus
@ C.S.Cameron, What happens if you try with the same computer, iso file, and USB drive as in comment #115 to make the USB drive persistent live with mkusb-dus using 1. default settings, 2. usb-pack-efi, and if you 3. *clone* from the iso file to the USB drive? -o- @ Steve Langasek (vorlon),

[Bug 1895329] Re: when booting cloned live drive 3rd partition is created without file system

2020-09-22 Thread sudodus
Now I tested the current Lubuntu Groovy iso file dated Sept 21. I could repeat the results from yesterday: The Lubuntu iso file makes USB boot drives, that can create a file system in the third partition, while the Ubuntu Desktop and Xubuntu iso files (of the same date, Sept 21, fail to do so. --

[Bug 1895329] Re: when booting cloned live drive 3rd partition is created without file system

2020-09-21 Thread sudodus
Something has happened, that I discovered today: Lubuntu works. I tested the current Groovy iso files of Ubuntu Desktop, Lubuntu and Xubuntu. - with the USB drives in used state (with various data, typically leftovers after previous tests with live or persistent live systems) - both in UEFI mode

[Bug 1886148] Re: failure to boot groovy daily

2020-09-16 Thread sudodus
mkusb version 12.6.1 (mkusb-dus) can create persistent live drives, that boot both in BIOS mode and UEFI mode, also with secure boot from the current daily Ubuntu Groovy iso file. I used the setting 'usb-pack-efi'. This works also with a Lenovo V130 in UEFI with secure boot, so there is a work-aro

[Bug 1886148] Re: failure to boot groovy daily

2020-09-16 Thread sudodus
- A Lenovo V130 finds the Linpus Lite boot option, but when selected it skips directly to the internal drive's grub menu (with dual boot Ubuntu and Windows). Back to square one. - A Toshiba Satellite Pro C850 19w boots both in UEFI mode with *secure boot* and in BIOS mode. - An old Lenovo X131e w

[Bug 1886148] Re: failure to boot groovy daily

2020-09-16 Thread sudodus
I started testing with my Dell Precision M4800 with a 4th generation Intel Core i7-4810MQ CPU, and its works - to clone the current Ubuntu Groovy iso file to a USB drive and make the Dell Precision M4800 boot both in BIOS mode and UEFI mode. See the attached file :-) - But there is no file system

[Bug 1895329] Re: when booting cloned live drive 3rd partition is created without file system

2020-09-16 Thread sudodus
This bug is still alive when tested with the current daily Ubuntu Groovy iso file cloned to a USB drive and tested in a Dell Precision M4800. This iso file is improved in many other ways, but this bug remains to be fixed. Maybe there is some kind of race condition, that affects drives, that were n

[Bug 1886148] Re: failure to boot groovy daily

2020-09-15 Thread sudodus
I can confirm that the current daily iso files make cloned USB drives that - boot in BIOS mode - fail to boot UEFI mode (not even recognized as a bootable drive). I tested the current daily Ubuntu iso file dated Sep 15 08:54 $ <<<'920c90aa90b81c48e6ef57c1579dcad97a168fc3e460b3cbdb6a096a0daadbbf

[Bug 1886148] Re: failure to boot groovy daily

2020-09-12 Thread sudodus
w--- 1 sudodus sudodus 1803091968 sep 12 02:07 xubuntu/groovy-desktop-amd64.iso See the attached screenshot. -o- When cloned to a USB drive, this file does not boot in BIOS mode. ** Attachment added: "xubuntu-persistent-live.jpg" https://bugs.launchpad.net/ubuntu-cdimage/+bug

[Bug 1895329] Re: when booting cloned live drive 3rd partition is created without file system

2020-09-12 Thread sudodus
I could reproduce the bug with today's daily Xubuntu Groovy iso file (with the leftovers after testing yesterday's daily Lubuntu Groovy iso fil in the 60 GB SSD, OCZ-AGILITY ITY3 drive). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1895329] Re: when booting cloned live drive 3rd partition is created without file system

2020-09-12 Thread sudodus
I have seen several cases, where bugs appear in situations typical for end users, who want to install Ubuntu and Ubuntu family flavours in their computers. If I understand correctly, you have not seen these bugs in your internal tests. Instead of testing only in virtual machines, I think at least

[Bug 1895329] Re: when booting cloned live drive 3rd partition is created without file system

2020-09-11 Thread sudodus
Sorry for the garbled list in 'details.txt', the non-standard characters are not rendered nicely by Firefox. Here is a better list from this computer: lubuntu@lubuntu:~$ lsblk -lo name,fstype,label,size NAME FSTYPE LABEL SIZE loop0 squashfs 1.6G sda

[Bug 1886148] Re: failure to boot groovy daily

2020-09-11 Thread sudodus
@ Steve Langasek (vorlon), See Bug #1895329: "when booting cloned live drive 3rd partition is created without file system" -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1886148 Title: failure to b

[Bug 1895329] [NEW] when booting cloned live drive 3rd partition is created without file system

2020-09-11 Thread sudodus
Public bug reported: When iso testing the current daily Lubuntu iso file (dated 2020-09-11), I notice that a third partition is created (during the boot process), but no file system is recognized by lsblk -f, and it is not used for logging (as we are used to from Focal and previous versions of Gro

[Bug 1886148] Re: failure to boot groovy daily

2020-09-11 Thread sudodus
... minor correction: I used a small SSD connected via a USB to SATA adapter instead of a pendrive because it is so much faster. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1886148 Title: failure

[Bug 1886148] Re: failure to boot groovy daily

2020-09-11 Thread sudodus
I tested also with plain extraction from the current Lubuntu Groovy iso file to a FAT32 partition with what I think are the correct flags $ LANG=C sudo parted /dev/sdc p Model: OCZ-AGIL ITY3 (scsi) Disk /dev/sdc: 60,0GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:

[Bug 1886148] Re: failure to boot groovy daily

2020-09-11 Thread sudodus
@ Leo, I made an installed Lubuntu 20.04 LTS system in an HP Probook 6450b to be up to date. This computer used to be my daughter's, but it is now degraded to an occasional test computer for this kind of purpose. And I double-checked the Groovy iso file with sha256sum: $ <<<'43eff66f35b78b933b983

[Bug 1886148] Re: failure to boot groovy daily

2020-09-11 Thread sudodus
... The problem occurs only in BIOS mode. As before, it boots in UEFI mode, where I get "Check finished. No errors found" and I reach to the desktop as expected. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.

[Bug 1895131] Re: Groovy Desktop *BREAKS* the most common method of creating UEFI bootable drives for Ubuntu installation

2020-09-11 Thread sudodus
@ Thomas Schmitt (scdbackup), Thanks for chipping in and offering help :-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895131 Title: Groovy Desktop *BREAKS* the most common method of creating UE

[Bug 1886148] Re: failure to boot groovy daily

2020-09-11 Thread sudodus
@ Leo, My experience is that cloning is cloning is cloning, whereever it is done, as long as the cloning operation is done correctly, and it is not too difficult. And the test of the files at boot indicates no error, so I am rather confident. Anyway, I can do the cloning elsewhere, in another com

[Bug 1886148] Re: failure to boot groovy daily

2020-09-11 Thread sudodus
I am working with these current iso files: $ md5sum ../[lx]ubuntu/groovy-desktop-amd64.iso 5d4756194e6d917b45584a10109f8e0e ../lubuntu/groovy-desktop-amd64.iso 8ad63bfc247563dae765af648ea62b47 ../xubuntu/groovy-desktop-amd64.iso and, Leo, I looked at the links provided by Steve. Now a cloned U

[Bug 1886148] Re: failure to boot groovy daily

2020-09-11 Thread sudodus
I can find today's groovy iso files of lubuntu and xubuntu. But there are no groovy-desktop-amd64.iso groovy-desktop-amd64.iso.zsync files (only arm files). How come? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launc

[Bug 1886148] Re: failure to boot groovy daily

2020-09-11 Thread sudodus
I can find today's groovy iso files of lubuntu and xubuntu. But there are no groovy-desktop-amd64.iso groovy-desktop-amd64.iso.zsync files (only arm files) for Ubuntu Desktop. How come? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1895131] Re: Groovy Desktop *BREAKS* the most common method of creating UEFI bootable drives for Ubuntu installation

2020-09-10 Thread sudodus
@ Michael Hudson-Doyle (mwhudson), Please let us know, when this change will be available for iso testing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895131 Title: Groovy Desktop *BREAKS* the m

[Bug 1895131] Re: Groovy Desktop *BREAKS* the most common method of creating UEFI bootable drives for Ubuntu installation

2020-09-10 Thread sudodus
@Akeo, I have seen the problem that you address in this bug report, and I was afraid that it may cause problems for you[r tool] and others who use extracting methods. Thanks for speaking out load about it. There is an additional problem too, that some computers do not even boot from cloned drives

[Bug 1886148] Re: failure to boot groovy daily

2020-09-08 Thread sudodus
I can report progress: There are new compressed image files to be extracted and cloned to USB drives for UEFI and BIOS mode, that can boot also with secure boot in a computer updated to squash the boothole bug. You find these image files at https://phillw.net/isos/linux-tools/uefi-n-bios/?C=M;O=D

[Bug 1886148] Re: failure to boot groovy daily

2020-09-04 Thread sudodus
> We can't debug or support a boot entry that we can't examine. I can understand that. I do hope that this "Linpus Lite" is a corner case. Otherwise, if this kind of USB boot systems will get common in UEFI mode, Ubuntu will have severe problems. > When you say AHCI, do you mean UEFI? AHCI has no

[Bug 1886148] Re: failure to boot groovy daily

2020-09-04 Thread sudodus
@ LeĆ³ Kolbeinsson (leok), Thanks for this heads up :-) It was likely that an updated version of the BIOS system could fix this issue. I did the BIOS update, and it was successful. The computer works after the update :-) But it did not fix this bug. The temporary boot option "Linpus Lite ()" is

[Bug 1892754] Re: Unable to boot in UEFI+secure boot mode

2020-09-04 Thread sudodus
@ Steve Langasek (vorlon), According to your request I continue the dialogue about the Lenovo V130 issue at https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpa

[Bug 1886148] Re: failure to boot groovy daily

2020-09-04 Thread sudodus
I attach a photo of the temporary boot menu to this comment too, so that you need not skip between the bug reports. I am almost 100% sure that no user has tampered with the boot settings until yesterday, when I turned off first secure boot, then UEFI. The boot menu option "Linpus Lite ()" was th

[Bug 1886148] Re: failure to boot groovy daily

2020-09-03 Thread sudodus
@ Steve Langasek (vorlon), According to your request I continue the dialogue here about problems to boot a Lenovo V130 in UEFI mode with the current daily Groovy iso files. This problem was reported in comment #31 https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148/comments/31 - When I selec

[Bug 1886148] Re: failure to boot groovy daily

2020-09-03 Thread sudodus
I attach the output of mokutil to this comment too, so that you need not skip between the bug reports. ** Attachment added: "mokutil-of-lenovo-v130.txt" https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148/+attachment/5407573/+files/mokutil-of-lenovo-v130.txt -- You received this bug notif

[Bug 1892754] Re: Unable to boot in UEFI+secure boot mode

2020-09-03 Thread sudodus
... continuing: This is when using the boot option in the temporary boot menu (F12) "Linpus Lite ()" in the picture attached to the previous comment. This is the only available USB boot option in UEFI mode. Then I turned off UEFI mode and set teh computer to boot in 'legacy mode'. Now there wer

[Bug 1892754] Re: Unable to boot in UEFI+secure boot mode

2020-09-03 Thread sudodus
@ Steve Langasek (vorlon), Previously I have not touched the UEFI/BIOS system of the *Lenovo V130* that I have access to, but now, that you ask about it, I had better do it in order to help identify what goes wrong, when trying to boot USB drives cloned from Groovy ISO files. When testing Groovy

[Bug 1892754] Re: Unable to boot in UEFI+secure boot mode

2020-09-02 Thread sudodus
The problem with the Lenovo V130 was reported at this bug report/comment: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148/comments/31 ** Attachment added: "mokutil-of-lenovo-v130.txt" https://bugs.launchpad.net/ubuntu/+source/cd-boot-images-amd64/+bug/1892754/+attachment/5407095/+fi

[Bug 1892754] Re: Unable to boot in UEFI+secure boot mode

2020-09-02 Thread sudodus
Thanks, this bug is squashed :-) I can confirm that a USB drive cloned from the current daily Lubuntu iso file boots in UEFI mode with secure boot in my Dell Precision M4800. (This computer can also boot in UEFI mode without secure boot and in BIOS mode with the current daily Lubuntu iso file.)

[Bug 1892754] Re: Unable to boot in UEFI+secure boot mode

2020-08-28 Thread sudodus
This bug affects the current Ubuntu Desktop Groovy iso file too (not only Lubuntu). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1892754 Title: Unable to boot in UEFI+secure boot mode To manage no

[Bug 1892754] Re: Unable to boot in UEFI+secure boot mode

2020-08-28 Thread sudodus
I tried again in the Lenovo V130, and this second time the internal UEFI system is upgraded so that it no longer allows booting (not even when the current daily Lubuntu Groovy iso file is used to create a persistent live drive with mkusb (with the setting 'upefi', using 'usb-pack-efi'). So the bugf

[Bug 1892754] Re: Unable to boot in UEFI+secure boot mode

2020-08-28 Thread sudodus
Additional test results: - As before, the Lenovo V130 can boot when the current daily Lubuntu Groovy iso file is used to create a persistent live drive with mkusb (with the setting 'upefi', using 'usb-pack-efi'). This indicates that there is a security problem with grub. - The Dell Precision M480

[Bug 1892754] Re: Unable to boot in UEFI+secure boot mode

2020-08-28 Thread sudodus
Need I say that the old failure mode is still there in a Lenovo V130: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148/comments/60 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1892754 Title:

[Bug 1892754] Re: Unable to boot in UEFI+secure boot mode

2020-08-28 Thread sudodus
This bug affects my Dell Precision M4800 too. A current daily Lubuntu Groovy iso file cloned to a USB drive works in BIOS mode and UEFI mode without secure boot, but with secure boot I get this message: 'Error: security violation' and the boot process cannot continue. I double-checked and a Foc

[Bug 1886148] Re: failure to boot groovy daily

2020-07-19 Thread sudodus
@leok, When cloning works (in all computers and boot modes), we can consider this bug as squashed. When Rufus fails in its default mode, we can select 'dd-mode' which means cloning, and the result should be identical to that of the Ubuntu Startup Disk Creator and other cloning tools (Disks, mkusb

[Bug 1886148] Re: failure to boot groovy daily

2020-07-18 Thread sudodus
Now one of the failure modes is removed. Congratulations to the Ubuntu developers and to guiverc :-) I tested the current daily iso files cloned into USB drives #perms sizedatetimefile-name -rw--- 1,8G2020-07-17 17:09 "lubuntu/groovy-desktop-amd64

[Bug 1886148] Re: failure to boot groovy daily

2020-07-14 Thread sudodus
@guiverc, I think you have confused leok's boxes with my boxes. Please modify the summary @top. I have tested this bug with a USB drive *cloned* from a Groovy daily iso file in a + Dell Precision M4800 (and Dell Latitude E7240 - not reported before, but behaves like the other Dell) - work now +

[Bug 1886148] Re: failure to boot groovy daily

2020-07-13 Thread sudodus
Now that a new Lubuntu Groovy iso file is uploaded I tested it as well as the current Focal iso file, #perms sizedatetimefile-name -rw--- 1,8G2020-07-13 16:53 "focal-desktop-amd64.iso" -rw--- 1,8G2020-07-13 17:00 "groovy-desktop-

[Bug 1886148] Re: failure to boot groovy daily

2020-07-13 Thread sudodus
The boot performance of the Lubuntu Groovy iso file on my computers are the same with today's current daily iso file, #perms sizedatetimefile-name -rw--- 1,8G2020-07-12 16:56 "groovy-desktop-amd64.iso" as with the previous iso files. At least, I cou

[Bug 1886148] Re: failure to boot groovy daily

2020-07-10 Thread sudodus
The boot performance of the Ubuntu Groovy iso file on my computers are the same with today's daily iso file, #perms size date time file-name -rw--- 2,6G 2020-07-10 08:27 "groovy-desktop-amd64.iso" as with yesterday's iso file. At least, I could not see any difference. Most of my computers boo

[Bug 1886148] Re: failure to boot groovy daily

2020-07-10 Thread sudodus
Trying to explain better: The Lenovo V130 is set to boot in UEFI mode with secure boot. The problem is that it cannot boot from a USB drive *cloned* from the current Ubuntu Groovy iso file dated 2020-07-10 08:27. Instead it skips to the internal drive and its grub menu (even when I select the USB

[Bug 1886148] Re: failure to boot groovy daily

2020-07-10 Thread sudodus
The boot performance of the Ubuntu Groovy iso file on my computers are the same with today's daily iso file, #perms sizedatetimefile-name -rw--- 2,6G2020-07-10 08:27 "groovy-desktop-amd64.iso" as with yesterday's iso file. At least, I could not see

[Bug 1886148] Re: failure to boot groovy daily

2020-07-09 Thread sudodus
My Lenovo V130 does not boot from a cloned drive, and did not boot from a persistent live drive by mkusb-dus. But with today's iso file, there is progress. It boots into a persistent live system with the boot option 'upefi', usb-pack-efi, (and there is persistence). So another way to see what works

[Bug 1886148] Re: failure to boot groovy daily

2020-07-09 Thread sudodus
Let us continue like this: *You* make the images 'more like the ones from June', and *we* (iso-testers) test how it works in our computers. I have a good experience from booting USB drives via grub also in BIOS mode, so I think and hope that we can keep that feature. Via the link in comment #26 yo

[Bug 1886148] Re: failure to boot groovy daily

2020-07-09 Thread sudodus
Cloned Groovy USB drives boot again, at least in some of my computers :-) + I tested in my Dell Precision M4800 and it works as usual in UEFI mode (and via grub) in BIOS mode. - But the Lenovo V130 does not boot in UEFI mode and secure boot - When I select the USB drive from the temporary menu, i

[Bug 1886148] Re: failure to boot groovy daily

2020-07-08 Thread sudodus
I found another mode in which the current groovy iso files make bootable drives: 'grub-n-iso' alias isoboot. I can make a bootable USB drive that boots - both in UEFI and BIOS mode - both live-only and persistent live when booting into a 'grub template' and then into an iso file according to the

[Bug 1886769] Re: [ 0.000000] Initramfs unpacking failed: Decoding failed

2020-07-08 Thread sudodus
Do you think this bug is somehow related to the following bug? https://bugs.launchpad.net/bugs/1886148 For example, are there problems to boot into a live system from a USB drive in a real system, or booted from a virtual hard disk drive with the image in a virtual machine? (I know that it boots

[Bug 1886148] Re: failure to boot groovy daily

2020-07-07 Thread sudodus
I'm glad that there is work in progress, and I am willing to help testing, whenever you have something to test :-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1886148 Title: failure to boot groovy

[Bug 1883040] Re: groovy daily won't boot anymore on some older BIOS boxes

2020-06-14 Thread sudodus
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 f

[Bug 1883040] Re: groovy daily won't boot anymore on some older BIOS boxes

2020-06-13 Thread sudodus
@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

[Bug 1883040] Re: groovy daily won't boot anymore on some older BIOS boxes

2020-06-13 Thread sudodus
@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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribe

[Bug 1883040] Re: groovy daily won't boot anymore on some older BIOS boxes

2020-06-12 Thread sudodus
Item 3 above concerns cloned live drives, that I think you have been using. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1883040 Title: groovy daily won't boot anymore on some older BIOS boxes To

[Bug 1883040] Re: groovy daily won't boot anymore on some older BIOS boxes

2020-06-12 Thread sudodus
@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

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-06-10 Thread sudodus
@robert key, Please post a link here to that new bug report. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1863672 Title: The 'new' persistent live method starting in 19.10 no longer works To mana

[Bug 1860411] Re: The Startup Disk Creator is glitchy when I try to use non-Ubuntu iso files

2020-06-09 Thread sudodus
@Wolf Pichler, I understand that you write this comment because you want the Ubuntu Startup Disk Creator to be improved. But that you do not use it since the days of Trusty. At that time it was an extracting tool with ability to create persistent live drives, and I think it was buggy. In Ubuntu X

[Bug 1880394] Re: 20.10 iso syslinux menu screen unreadable

2020-05-28 Thread sudodus
I can confirm that the bug is squashed in the current daily Ubuntu desktop iso file -rw--- 1 nio nio 2,6G maj 28 08:40 /media/multimed-2/test/ubuntu /groovy-desktop-amd64.iso -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https:/

[Bug 1880394] Re: 20.10 iso syslinux menu screen unreadable

2020-05-27 Thread sudodus
@ Jean-Baptiste Lallement, Please explain what you mean by 'opinion': - Are you not affected by this bug? - Do you think that we should live with this bug? - Should we wait a few more days to let the bug-fix reach the iso files? - Or something else (in this case please specify)? -- You recei

[Bug 1880394] Re: 20.10 iso syslinux menu screen unreadable

2020-05-26 Thread sudodus
Today's daily iso files are still affected by this bug, for example $ ls -l /media/multimed-2/test/ubuntu/groovy-desktop-amd64.iso -rw--- 1 nio nio 2734686208 maj 26 11:28 /media/multimed-2/test/ubuntu/groovy-desktop-amd64.iso -- You received this bug notification because you are a member o

[Bug 1880394] Re: lubuntu 20.10 iso language selection screen unusable

2020-05-24 Thread sudodus
This bug affects me too, and I want Swedish, which is not easy unless a remember from previous versions 'where it is located genometrically'. For some reason the language selection screen of syslinux boot is rendered differently compared to what has been working for decades. -- You received this

[Bug 1875548] Re: Its not easy to determine how to skip the filesystem check

2020-05-23 Thread sudodus
1. Maybe the bugfix is only addressing Groovy, which has casper 1.447 now. 2. It seems that the bugfix is only an update of the casper manpage because the integrity check is still there for persistent live systems unless I add the boot option fsck.mode=skip (tested in Lubuntu Groovy). -- You r

[Bug 1851311] Re: loopback command hangs in 2.04 under UEFI

2020-05-06 Thread sudodus
@ C.S.Cameron, > I will fill out a separate bug report when I get time. Please post a link here to that separate bug report. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1851311 Title: loopback c

[Bug 1876950] Re: Lubuntu Calamares install fails if loop0 already in use

2020-05-05 Thread sudodus
I have succeeded doing what you try to do, when I booted with the two boot options 'toram' and 'nopersistent' (both at the same boot) with the other Ubuntu flavours that use Ubiquity. Installing with Calamares works for me (to install Lubuntu 20.04 LTS) without the boot option 'toram', for example

[Bug 1875548] Re: Its not easy to determine how to skip the filesystem check

2020-04-29 Thread sudodus
After testing older versions of Ubuntu, it seems that 'fsck.mode=skip' is simply ignored, and does not create any problem. So I have included it in some of the menu entries for persistence and 'live-only to RAM' created by mkusb version 12.4.7. -- You received this bug notification because you ar

[Bug 1875548] Re: Its not easy to determine how to skip the filesystem check

2020-04-28 Thread sudodus
@ Brian Murray, That is a good idea. I tested and it works with Focal Fossa :-) What happens when we use the boot option 'fsck.mode=skip' for older versions of Ubuntu (for example 18.04 LTS)? Will it cause some error or simply be ignored? -- You received this bug notification because you are a

[Bug 1875548] Re: Live USB disk check

2020-04-28 Thread sudodus
I can confirm this bug. It appeared with Focal Fossa (does not affect previous versions). I suggest to store a small file in the partition with the label 'writable' or 'casper-rw', that tells the system that the live USB disk check has been performed, and is no longer necessary. -- You received

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-04-26 Thread sudodus
@ C.S.Cameron (cscameron), I think I understand now. You can remove the boot option maybe-ubiquity from the 'linux line' of grub.cfg: from menuentry "Ubuntu - persistent live" { search --set=root --fs-uuid 2020-04-23-07-51-42-00 set gfxpayload=keep linux ($root)/casper/vmlinuz

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-04-25 Thread sudodus
@ Michael Hudson-Doyle, When booting a live system of Ubuntu 20.04 there is file and disk checking.. Not just with Live USB but with Persistent USB also. If not fast enough with ctrl-C it runs until over 80% complete. Very irritating. If it was just a run once it would not be so bad. Is there so

[Bug 1325801] Re: failed to boot from USB disk with error: gfxboot.c32: not a COM32R Image boot:

2020-04-25 Thread sudodus
The cloning version of usb-creator introduced with Ubuntu Xenial (16.04 LTS) should work also in Trusty. Other cloning tools work, so if you want to bother with this bug, I suggest that you port that version to Trusty. -- You received this bug notification because you are a member of Ubuntu Bugs

[Bug 1873950] Re: Calamares failed: command 'mount' returned non-zero exit status 32.

2020-04-21 Thread sudodus
After further testing several times I think I pinned the problem: The bug appears when booted 'toram'. With everything the same except the the boot option 'toram', Calamares can install Lubuntu. So this is an annoying glitch, but I think debugging it can wait until Lubuntu 20.04.1 LTS. -- You re

[Bug 1873950] Re: Calamares failed: command 'mount' returned non-zero exit status 32.

2020-04-20 Thread sudodus
** Description changed: Booting in my 'standard test computer' a Toshiba laptop, Calamares failed with the most basic mode, to use the whole drive for the new Lubuntu installation. http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/ Booted in BIOS mode. The par

[Bug 1873950] [NEW] Calamares failed: command 'mount' returned non-zero exit status 32.

2020-04-20 Thread sudodus
Public bug reported: Booting in my 'standard test computer' a Toshiba laptop, Calamares failed with the most basic mode, to use the whole drive for the new Lubuntu installation. http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/ Booted in BIOS mode. The partition table in t

[Bug 1873950] Re: Command 'mount' returned non-zero exit status 32.

2020-04-20 Thread sudodus
** Attachment added: "calamares-mount-failed.jpg" https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1873950/+attachment/5357383/+files/calamares-mount-failed.jpg ** Description changed: Booting in my 'standard test computer' a Toshiba laptop, Calamares failed with the most basic mo

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-04-09 Thread sudodus
The package casper version 1.445 is bundled with the current Lubuntu iso file dated 2020-04-09. I tested it (made a persistent live USB-connected SSD) in one of my computers that were affected by this bug, the Toshiba. Persistence works with the label 'casper-rw' :-) So my alert in comment #62 can

[Bug 1871869] Re: Nautilus copy task status is not accurate.

2020-04-09 Thread sudodus
Your observation is correct and I have seen it too. RAM is bigger and processes are buffering in RAM more aggressively in recent computers with recent versions of linux operating systems. Be aware that also Windows uses this feature and for that reason you must 'remove the USB drive safely' or your

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-04-09 Thread sudodus
By the way, today and during the weekend (Easter) 3 more persons are testing your 'hack', capeer-initrd.gz. We have found a few more computers that are affected by this bug, and your hack works in those computers. You find some results via https://ubuntuforums.org/showthread.php?t=2440260 So it l

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-04-09 Thread sudodus
It seems to me that the description of the bug-fix does not match this bug. Are you describing a fix for another bug, or is it only the description, that is wrong or difficult to understand? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubu

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-04-09 Thread sudodus
... or like asking the US to change the name of the 'dollar' to 'valuable' ;-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1863672 Title: The 'new' persistent live method starting in 19.10 no long

[Bug 1851311] Re: Grub 2.04 Out of memory error, No server error

2020-04-07 Thread sudodus
Affects Focal Beta and current daily iso file (2020-04-07) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1851311 Title: Grub 2.04 Out of memory error, No server error To manage notifications about

[Bug 1851311] Re: Grub 2.04 Out of memory error, No server error

2020-04-07 Thread sudodus
Please squash this bug before Ubuntu 20.04 LTS is released. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1851311 Title: Grub 2.04 Out of memory error, No server error To manage notifications about

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-04-07 Thread sudodus
I tested with the current casper-initrd with a current Lubuntu Focal persistent live system, and it works with a 'casper-rw' partition also in the computers where it did not work before as described in post #25: 1. a Toshiba laptop with an Intel i5 generaton 3 CPU (in BIOS mode and UEFI mode) htt

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-04-07 Thread sudodus
> I'm seeing "access beyond end of device" for /dev/sda and > "I/O error while writing superblock" for /dev/sda2 > (peristent partition) on powerdown/reboot. I can confirm this. I have tested in several computers and it happens in all of them. -- You received this bug notification because you ar

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-04-06 Thread sudodus
> So can we please revert support for 'writable' in 20.04, and use the next > release to try to fix the issues with trying to support 2 partition labels? ... > Again, unless you have confidence that you know precisely what the issue is, > and should be able to fix it right now, I would advocate a

[Bug 1863672] Re: The 'new' persistent live method starting in 19.10 no longer works

2020-04-06 Thread sudodus
I tried (and failed) with the current Focal iso files of Ubuntu and Lubuntu. Should I try with Ubuntu 19.10 or specifically with Ubuntu Focal Beta? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1863672

<    1   2   3   4   5   6   7   8   9   10   >