bopscompare.blogg.se

• #GRUB THEME BREEZE RESOLUTION INSTALL#

You could be installing updates to your flatpak runtimes (1 GB each runtime!) if your flatpak was being actively developed and followed the latest (say) Gnome versions, and wondering how come your disk space was filling up so fast. You should see my posts in the dev team private board, heh.įirst I didn't like it because it didn't make clear what updateable packages came from the normal repos and which from flatpaks. Isn't muon supposedly obsoleted by discover ? I am certainly *not* asking for the inclusion of discover, but in an MX distro wouldn't it make more sense to just default to MXPI in the absence of synaptic ? (and not include muon either) As the installer did not touch the ESP or the NVRAM table, you can tidy up ESP grub loader an NVRAM entries to avoid the reordering. You need to look into the NVRAM table, this table is sometime re-orginzed the bootorder by UEFI firmaware itself.

And often there are more then one GRUB loader on the ESP.

#GRUB THEME BREEZE RESOLUTION INSTALL#

You install GRUB-loader onto the ESP and the remaingin part from one ot the /boot/grub folders. In UEFi, there is no one GRUB on /dev/xvz. unlike mbr installs, UEFI installs won't overwrite another distro's EFI stub, but they will change the boot order. I'll look into that but if it was UEFI you could have just selected whatever EFI stub you want to boot from the system's UEFI panel. I did fix it by booting into Buster from a REFInd flash key and reinstalling GRUB from there, but it shouldn't have been broken in the first place. It obviously did as reboot brought up a GRUB prompt, not its usual boot screen. If I deselect "Install GRUB", the installer should not touch the ESP or NVRAM table. I install OSs regularly and just boot to Buster on sda4 and run update-grub to include a new one in the boot menu. The pre-existing GRUB is on /dev/sda4 and was working perfectly prior to MX KDE install. You propaby just need to choose another valid grub-efi loader with the NVRAM table to get loaded.Įither by using efibootmgr or select at start up (by pressing e.g F12) another loader. When you now wipe out and reinstall on /dev/sda7, the existing grub圆4.efi loaded at boot, cannot find any grub-stuff on the new install on /dev/sda7. What could have happed, is this: You'r default grub圆4.efi was loading from /dev/sda7 and displays a nice grub menu.

The grub圆4-efi will load the remaining "grub-stuff" and the menu from the /boot folder on the /root (or boot partition, This grub圆4.efi would be register with the UEFI firmware's NVRAM-table as a valid or the first to choosen bootloader. The first would be the grub圆4.efi GRUB loader, which is placed with a subdir on the ESP.

On UEFI, GRUB comes within different players. It wasn't installed, but wiped out the existing GRUB. Almost at the end of the installation routine I recall text displaying "Installing GRUB" even though I unchecked the install GRUB box. According to the log, grub was not installed.