on several computer (laptops) with 13.2:
if I perform a software update with yast, then the next reboot will hang with an empty screen saying “GRUB”.
This can be avoided if I rewrite the bootloader “by hand” with yast->system->bootloader after a software update.
what has to be done to achieve that automatically after software installs as in earlier versions of OS?
is this a bug or a feature? meaning, why has that changed? I never had a problem like that with earlier versions.
On 2015-01-27 15:46, suse paul wrote:
>
> on several computer (laptops) with 13.2:
> if I perform a software update with yast, then the next reboot will hang
> with an empty screen saying “GRUB”.
If those are UEFI machines with secure boot enabled, that might be
related to a recent patch which requires you to accept some message box
on the next boot, once. It might have broken for some people.
It it happens always, not only now, it is a different thing.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
No, one of the laptops is an old one from the pre–UEFI era.
But where is that message box? during update?
On 2015-01-28 07:36, suse paul wrote:
> But where is that message box? during update?
No, on boot. One boot only, the next one after that particular update.
I have not seen it, so I only read the warning about its existence. I
can dig out the information later.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2015-01-28 12:33, Carlos E. R. wrote:
> I have not seen it, so I only read the warning about its existence. I
> can dig out the information later.
+++—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-
Subject: [security-announce] Upcoming update for shim requires confirmation on reboot
Hello,
we will release a security update for shim next week that fixes three
security issues, tracked in bnc#889332:
Because of those issues we update shim to version 0.7.318.81ee561d. This
version includes a patch that requires the user to confirm a dialog once
on the first boot after the update is installed. You will need to be able
to confirm this dialog, which appears before the bootloader, or your system
will not boot. This only affects users that are still on openSUSE 13.1 and
use a secure boot setup. You can check with ‘bootctl’ if you’re using a
secure boot configuration if you’re not sure.
—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-+±
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
How are you booting?
Are you using grub-legacy or grub2?
Where is grub installed?
I am not having the problem you describe. So I wonder what you are doing differently.
yast says GRUB2 (instead of GRUB2-EFI)
I selected to start from MBR
root partition was selected
there is no seperate boot partition
at least one of the laptops (the other I have to check) doesn’t have a separate boot partition - may that be related?
on one of the laptops the 32bit version is installed, on the other one 64bit
the strange thing is that I as well installed on a desktop with no problems
if I let yast write the bootloader, booting works - so the settings seem to work.
it seems to me that after a kernel update the bootloader is not written by the respective yast scripts - is it possible that there is a buggy yast module or a missing yast part?
Can you post the output from:
# cat /etc/default/grub_installdevice
e
/dev/disk/by-id/scsi-35002538844584d30
/dev/disk/by-uuid/e8e9c081-61d5-4af2-8464-0dea61915b88
activate
generic_mbr
I’m pretty sure that means that grub is not installed in the MBR. Rather, it is installed on a partition and the MBR contains generic bootcode.
Part of the run time code for grub is in the file “/boot/grub2/i386-pc/core.img”. When grub is installed on a partition, rather than the MBR, then the boot sector contains a block list – a list of disk blocks for core.img. That enables it to find the file “core.img” during boot.
If “core.img” is moved to different disk blocks, then you get the error message you are seeing.
For myself, I have never seen that happen. However, if you were to backup and restore the disk, it would cause that problem. If you run a disk defragger on a linux partition that could also cause the problem.
If you do something that moves “core.img”, you might not immediately see a problem. If the old disk blocks still contain the right data, it will still work. When you later do a major update, those disk blocks are now used for something else, and that is when you see a problem.
On 2015-01-29 17:36, nrickert wrote:
> Part of the run time code for grub is in the file
> “/boot/grub2/i386-pc/core.img”. When grub is installed on a partition,
> rather than the MBR, then the boot sector contains a block list – a
> list of disk blocks for core.img. That enables it to find the file
> “core.img” during boot.
>
> If “core.img” is moved to different disk blocks, then you get the error
> message you are seeing.
Are you sure of that?
Grub should have all it needs in the space at the start of the partition
that is before the filesystem itself starts. The reason that a file
backup/restore does not work is simply because it does not copy raw
sectors that are outside files.
You could test this by copying the file to another location and back
(with secure erase): the machine should boot happily.
Linux does not have unmovable files, as MsDOS has.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
thank you for the explanations.
strange that this happened, as it were fresh installs and the problem occurred with the first update.
what can I do to prevent further errors?
My knowledge of this does not reach the level of certainty.
Grub should have all it needs in the space at the start of the partition
that is before the filesystem itself starts.
That depends on the file system. Some file systems such as “btrfs” have space for a boot block at the start of the file system. But I don’t think “ext{2,3,4}” file systems reserve that space. And grub does complain about needing block lists, when installed at the partition boot record of such a file system.
You could test this by copying the file to another location and back
(with secure erase): the machine should boot happily.
You are right, that it still boots.[/QUOTE]
However, if I setup Windows boot manager to boot opensuse, using a copy of the boot sector, then that fails if grub is reinstalled but the windows file is not updated. And that’s consistent with the grub message about block lists. It must be something other than core.img that is accessed with block lists.
On 2015-01-29 20:46, nrickert wrote:
>
> robin_listas;2691982 Wrote:
>> Are you sure of that?
> My knowledge of this does not reach the level of certainty.
>
>> Grub should have all it needs in the space at the start of the partition
>> that is before the filesystem itself starts.
> That depends on the file system.
It does. For instance, years ago it destroyed XFS filesystems, they had to change something in XFS.
Try the “bootinfoscript” from arvidjaar.
On my system:
sdc3: __________________________________________________________________________
File system: ext2
Boot sector type: Grub2 (v1.99-2.00)
Boot sector info: Grub2 (v1.99) is installed in the boot sector of sdc3
and looks at sector 895143 of the same hard drive for
core.img. core.img is at this location.
Operating System:
Boot files: /grub2/grub.cfg /boot/grub2/grub.cfg
/grub2/i386-pc/core.img /boot/grub2/i386-pc/core.img
Telcontar:~ # mount | grep sdc3
/dev/sdc3 on /other/test_a2/boot type ext2 (rw,relatime)
Telcontar:~ #
Compared with:
sdc1: __________________________________________________________________________
File system: ext2
Boot sector type: Grub Legacy
Boot sector info: Grub Legacy (v0.97) is installed in the boot sector
of sdc1 and looks at sector 148545 of the same hard
drive for the stage2 file. A stage2 file is at this
location on /dev/sdc. Stage2 looks on partition #1
for /boot/grub/menu.lst.
Operating System:
Boot files:
Grub2 and grub1 are different. Grub2 looks for a file. I’m confused.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
two questions in this respect:
what are the command line commands that I would have to execute to achieve the same effect as yast -> system -> bootloader -> OK
how can I specify own commands that are executed after each software update with yast?