Fails to Boot after Grub Customizer Background Image Changed

[NoWorries]

I have a png background image defined in Grub Customizer and I decided to improve the image using GIMP. When I saved the changes and installed the MBR, 21.04 would hang. No cursor or keyboard response.

I have 19.10 installed on the same SSD and I was able to recover with Grub Customizer and the old png. Since the new png was about 15MB I thought that I would reduce its size from 3840x2160 to 2560x1440 using Gimp. I then used Grub Customizer to change the background image.

After rebooting my system, both 19.10 and 21.04 would not boot. No cursor or keyboard response.

As I have a zoom meeting tonight and I am on projection this Sunday, I wanted to get my system working without having to do a re-installation. I still have my "Sacrificial" laptop working so I downloaded the latest 21.04. To install it on a USB, I decided to use usb-creator-kde which failed. Instead I used usb-creator-gtk which worked.

After doing this, I then decided to install 21.04 on a 64 GB USB connected to my Laptop. I then found that my system is now all working and I then installed the old png file using Grub Customize. All I have to do now is remove my USB without crashing my system.

I am therefore wondering if the source of my time consuming problem is Gimp or Grub Customizer. Does anyone have any ideas?

[GreyGeek]

All you did with grub-customizer is point it to either a jpg or a png image. That shouldn't cause g-c any problems.
GIMP, on the other hand, has changed the way it saves images. The default file type and native file format in GIMP is the .XCF file type. You now have to "EXPORT" your file from GIMP's .XCF format to either jpg or png for g-c's purposes.

You also have to set the "Quality" level when you "EXPORT" an image. Perhaps g-c can't handle compression? You might want to try to EXPORT it with 100% "Quality", instead of the standard 90%.

[NoWorries]

All you did with grub-customizer is point it to either a jpg or a png image. That shouldn't cause g-c any problems.
GIMP, on the other hand, has changed the way it saves images. The default file type and native file format in GIMP is the .XCF file type. You now have to "EXPORT" your file from GIMP's .XCF format to either jpg or png for g-c's purposes.

You also have to set the "Quality" level when you "EXPORT" an image. Perhaps g-c can't handle compression? You might want to try to EXPORT it with 100% "Quality", instead of the standard 90%.

I have found that g-c will only display png files. When editing a file with Gimp, I use the overwrite option. Export gave the same output. With 0 compression level on png file I get a larger file. Now my system is totally knackered and I will have to start over again to recover.

[GreyGeek]

I have found that g-c will only display png files. When editing a file with Gimp, I use the overwrite option. Export gave the same output. With 0 compression level on png file I get a larger file. Now my system is totally knackered and I will have to start over again to recover.

Do you still get a grub menu? If so, can you log into a root console and fix things manually? Or, boot with a LiveUSB, and mount your sda drive and edit it from the LiveUSB.

[NoWorries]

Do you still get a grub menu? If so, can you log into a root console and fix things manually? Or, boot with a LiveUSB, and mount your sda drive and edit it from the LiveUSB.

I can enter grub from the boot up menu but because I have not logged into any particular distribution, I have found access to grub details difficult. I would emphasise that I am not familiar with grub details and options to fix things.

When I boot with a LiveUSB, I find that I am user 1000 and this prevents me from editing any files on my system even though I can see them and launch them.

I am not sure if you are aware that it is not recommended that ubuntu users upgrade to 21.04. You can find the reason for this at: https://www.omgubuntu.co.uk/2021/04/...-21-04-for-now. I am not sure if my problems are related to the current bugs in shim which is installed on my system.

The way I fix my problems is to install Kubuntu 21.04 on a USB and I can then log-in and start both 20.10 and 21.04 on my SSD. So that I do not have the Kubuntu 21.04 USB attached to my Laptop when I take it out for use elsewhere, I use Grub-Customizer to remove all the installed packages on my USB. I have to do this on both 20.10 and 21.0 before removing the USB.

I do not plan to do anything to test Gimp editing the png image file again until next week.

[GreyGeek]

Ya, I saw that news. I never go through an upgrade to get to the next release. I ALWAYS do a fresh install to the bare silicon.

I've been running BTRFS as my main FS since 16.04 and since then I've never had an accident lock me out of my system. IF my system fails to boot, which has happened on occasions after I do my experimentation, I boot my LiveUSB, mount the drive to my LiveUSB /mnt directory, and roll back to the previous snapshot, which I take either every day, or before I do an experiment which I suspect may bork my system. With other problems I just mount the <ROOT_FS> to /mnt and use mc to copy the damaged file or directory from the previous snapshot to my running system.

Since I have combined my @ & @home subvolumes into just @ (by copying my home account folder to @/home and erasing the line in fstab that mounts @home to /home) then rebooting, snapshotting and rolling back is easy-peezy, not that it was very hard before. (Note: @/home and @home are not the same locations)

[jlittle]

When I boot with a LiveUSB, I find that I am user 1000 and this prevents me from editing any files on my system even though I can see them and launch them.

If you use a command line from an Ubuntu Live USB, one can use sudo and there's no password. Or run sudo -i to get a root shell.

[jlittle]

I am not sure if you are aware that it is not recommended that ubuntu users upgrade to 21.04. You can find the reason for this at: https://www.omgubuntu.co.uk/2021/04/...-21-04-for-now. ...shim ...

checking this Kubuntu,,,

$ sudo efibootmgr -v | grep ubuntu                                   
Boot0001* ubuntu        HD(1,GPT,93ad1ab4-012e-43be-8eae-eb14dbfe42f2,0x800,0x82000)
/File(\EFI\ubuntu\[B][SIZE=5][COLOR="#ff6600"]shim[/COLOR][/SIZE][/B]x64.efi)

@&$#!

[GreyGeek]

I take it that "@&$" means you didn't know your install was with EFI?

[jlittle]

I take it that "@&$" means you didn't know your install was with EFI?

The last time I looked, and on my home Kubuntu, it was GRUBX64.EFI. (On my home Kubuntu I control /boot/efi, and I don't let grub updates muck it up.) Because my work Kubuntu has "secure boot" disabled, I was hoping that shim was not used.

[GreyGeek]

Ah, I see.

In the past when I installed Kubuntu to the bare silicon with BTRFS all I had to do was create a single partition, SDA1, and assign BTRFS to it as "/", and the bootloader I put on SDA. That appears to no longer work.

[claydoh]

I believe that this is needed on MBR setups, standard GPT uefi ones do not. The MBR is too small to hold all the code/executables used to support all this 'new' stuff., if I am reading things correctly.