On Sun 21 Jul 2024 at 10:45:59 (+0000), David wrote:
> On Sun, 21 Jul 2024 at 09:46, Thomas Schmitt <scdbac...@gmx.net> wrote:
> > hede wrote:
>
> > > Technically it should be possible, as dmidecode can show the reason:
> > > Handle 0x0001, DMI type 1, 27 bytes
> > > System Information
> > > ...
> > > Wake-up Type: LAN Remote
> > > vs.
> > > Wake-up Type: Power Switch
> >
> > The statement in man dmidecode "DMI (some say SMBIOS)" caused me to search
> > for "GRUB SMBIOS" which yields:
> > https://www.gnu.org/software/grub/manual/grub/html_node/smbios.html
> >
> > This looks like a low-level user interface to
> > https://en.wikipedia.org/wiki/System_Management_BIOS
> >
> > Diving into
> > https://codesearch.debian.net/search?q=package%3Admidecode+Wake-up+Type
> > leads me to
> > https://sources.debian.org/src/dmidecode/3.6-1/dmidecode.c/?hl=4498#L4498
> > which lets me guess that your answer is in
> > smbios --type 1 --get-byte 24
> > with the possible values told by function dmi_system_wake_up_type()
> > https://sources.debian.org/src/dmidecode/3.6-1/dmidecode.c/?hl=513#L513
> >
> > Consider to explore this in the GRUB shell and (if needed) to find
> > somebody who can help to develop a smart configuration which makes use of
> > the result to offer different boot menus.
>
> Hi, well it looks like Thomas has done most of the work and provided most of
> the solution. Assuming that is the case, I suggest that an easy way to
> activate
> a different menu entry would be to use the value found by the above research
> to
> change the value of 'default' in grub.cfg
>
> So your manually written grub.cfg. would contain something like the below
> lines
> in addition to whatever other content you need to boot the machine.
>
> smbios --type 1 --get-byte 24 --set result
> if [ "${result}" == "REPLACEME" ] ; then
> default=1
> else
> default=2
> fi
>
> Hopefully all that remains is to use the above information to figure out
> the actual value needed to replace my REPLACEME placeholder.
> And change '1' and '2' to match whatever menuentry you would like to
> activate.
>
> Don't be discouraged by all the junk that the autogenerated grub.cfg
> contains these days, most of it is not necessary. I have never had any
> trouble ignoring it completely and just writing something simple in the style
> of grub1. That way you can take advantage of the very useful scripting
> language that grub2 provides, and hopefully make it do exactly what you want.
"All the junk" that you're ignoring will be the code that implements
properly what you're trying to do with Grub. Overall, it's a hack, but
you don't need to hack on top of the hack.
Edit /etc/default/grub and change:
GRUB_DEFAULT=0
to:
GRUB_DEFAULT=saved
and then regenerate your grub.cfg. Then type in:
# grub-set-default 0
This will write a file /boot/grub/grubenv containing:
# GRUB Environment Block
saved_entry=0
################# … … …
padded out to 1024 bytes. By default, Grub will boot the first
entry in grub.cfg as it does now. That's all designed into the
Grub infrastructure.
The hack is booting Windows after starting via the power button.
. determine the reason as already outlined in the thread.
. if you now require windows instead, the commands to run are:
# grub-reboot 'foo'
or:
# grub-reboot 'foo>bar'
and then:
# reboot
where foo is the $menuentry_id_option of a top-level menuentry,
and bar is the $menuentry_id_option of a menuentry under a submenu.
They are typically looong strings.
. if you require linux, you can either carry on running what you've
got (linux), or reboot in a similar manner to some other implementation.
IIRC (it's been many many years) Grub generates Windows entries as
top-level rather than in submenus, with some ?16-digit UUID as the
$menuentry_id_option.
How it works: grub-reboot adds 'next_entry=foo>bar' into grubenv,
which gets read and enacted when you reboot (and erased, of course).
Cheers,
David.
