On Fri, Jun 26, 2020 at 2:08 AM cagsm <cumandgets0mem00f@gmail.com> wrote:
<https://forums.opensuse.org/showthread.php/538159-grub-not-booting-anymore-on-BIOS-machine-with-symbol-grub_file_filters-no-found/> <https://bugzilla.opensuse.org/show_bug.cgi?id=1156073> <https://bugzilla.opensuse.org/show_bug.cgi?id=1156351>
I am really trying to understand the situation here. What am I doing wrong or was some bootloader or grub2 package not properly tested for zypper dup usage? Why would previous kernel updates, grub2 updates etc on leap 15.1 and leap 15 and before work fine on this machine? what is the difference with leap 15.2 coming in via zypper dup? So at present there is an /etc/default/grub_installdevice file, probably altered or fixed with its settings currently displaying: /dev/sda /dev/disk/by-uuid/1111111-uuid-of-sda1-here activate generic_mbr This is the current content of this file after I chrooted into 15.2 net/iso image and booted up its rescue mode and ran yast2 bootloader screen from the installed 15.2 system. is this a proper file? I guess so as it boots now. Nothing inside bios settings of the machine/board was altered from 15.1 to 15.2 state. Why would a zypper dup with its perlbootloader, grub2, kernel and other boot-affecting packages not simply apply and install the current packages/grub2 stuff into all the places that it exists/existed before on 15.1 level? I fail to understand that? why would a 15.2 suddenly become nonbooting as some people explain that the newer grub2 2.04 or something works differently and some part got missed during update of the grub2 package? this is not something I can do anything about as end-user, or is it? can I? I have other systems. what would be the minimal lines in grub_installdevice for not rendering other 15.1 to 15.2 systems nonbooting? this situation forced me to drive across states and fix machine hands on :( I still do not really understand why this bug needs to happen in the first place? is this something the user deliberately or accidentally messes up maybe sometime in the past when initially installing a former opensuse release? so anyway, it didnt become corrupted with past leap upgrades. it did become corrupted now, so again the question, can the grub2 and related packages not be tested and made sure they use all the same places and install themselves to all the same places again over and over again where the previous (then still running) system comes from? I fail to understand the explanation that somhow it can not be possibly detected how the system actually boots in contrast to how the grub settings of bootconfig are set? there is something missing here in the explanation. there are too many of these problems that completely disable remote machines. I have experienced a lot of trouble in the past with open/suse, that is what I use. When i directly compare this to old and dated machines with windows, I dont have these essential and low level borkage and mess with such basic things as bringing up a machine into showtime state. windows has its own set of serious illnesses of course. as I said, nothing in these old, but robust bios style machines have changed in the past years. not tinkering with stuff. simple systems. single disk, sda, with two or threee partitions, swap, root and home and thats it. and then, there comes june of 2020 and a new upgrade of opensuse breaks down everything. one would think this is pretty decent and very simple setup. bios. machine. single disk, simple partitions, mbr, no uefi, no gpt no nothing. still the pain though. serious pain. :( thanks for helping to sort these kind of things out for the future. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org