GRUB dual-boot with Ubuntu 22 won't remember Windows 7 as last used, chooses Windows 10 instead

[Java Jive]

Problem as per subject. I have a laptop triple booting into Ubuntu 22,
Windows 7, & Windows 10. GRUB has the correct settings to remember the
last boot choice and correctly does so for Ubuntu & Windows 10, but, if
I choose Windows 7, at the next boot it offers Windows 10 as the
default, not Windows 7. All I can find online is many different
explanations for how to set up dual-booting and have it remember the
last choice, not what to do if for some reason this doesn't work.

Can anyone advise?

The relevant settings are reproduced below, and yes I have remembered to
run update-grub, in fact I've done it twice, but despite everything
looking correct, the problem persists. Note that in the resulting
grub.cfg the two Windows sections are identical except where they should
differ in designating the relevant partition, and that the W10 section
has an extra penultimate line 'drivemap ...', but I don't know enough
about how GRUB works to know whether that would be relevant ...

/etc/default/grub:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""

[rest is commented out, until]

# Uncomment to get a beep at grub start
GRUB_INIT_TUNE="480 440 1"

/boot/grub/grub.cfg:

[...]

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows 10 (on /dev/sda1)' --class windows --class os
$menuentry_id_option 'osprober-chain-C00A7FAA0A7F9BDA' {
savedefault
insmod part_msdos
insmod ntfs
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 C00A7FAA0A7F9BDA
else
search --no-floppy --fs-uuid --set=root C00A7FAA0A7F9BDA
fi
parttool ${root} hidden-
drivemap -s (hd0) ${root}
chainloader +1
}
menuentry 'Windows 7 (on /dev/sda2)' --class windows --class os
$menuentry_id_option 'osprober-chain-C00A7FAA0A7F9BDA' {
savedefault
insmod part_msdos
insmod ntfs
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2
--hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 C00A7FAA0A7F9BDA
else
search --no-floppy --fs-uuid --set=root C00A7FAA0A7F9BDA
fi
parttool ${root} hidden-
chainloader +1
}

[...]

[In case it matters, but I don't think it does, this laptop is a Dell
Precision M6700 which I bought recently because the video card in my
best old Dell Precision M6300 died, which is the default manner for
those PCs to die - even though this new one also has a good 17"
screen, it's wider and shorter than the old one, which I preferred.
There are a couple of over-priced video cards on eBay for nearly the
same sort of price as you could get a working machine of the same model,
but it's just not worth spending that sort of money on such an old
machine. Sniff!]

[Theo]

Post by Java Jive
Problem as per subject. I have a laptop triple booting into Ubuntu 22,
Windows 7, & Windows 10. GRUB has the correct settings to remember the
last boot choice and correctly does so for Ubuntu & Windows 10, but, if
I choose Windows 7, at the next boot it offers Windows 10 as the
default, not Windows 7. All I can find online is many different
explanations for how to set up dual-booting and have it remember the
last choice, not what to do if for some reason this doesn't work.

I have very limited experience of dual booting Windows, but AIUI there are
two ways you can do it:

1. Install every Windows on a separate drive. Here each drive has its own
Windows bootloader. You can select which one to boot from in BIOS.
Alternatively, in Grub, you 'chainload' the Windows bootloader from a
specific drive, so you can pick between Windows installs

2. Install several Windows on the same drive, sharing a Windows bootloader.
Here you boot Grub, select you want to 'chainload' the Windows bootloader,
then you use the Windows bootloader to select which OS to boot. In this
case Grub doesn't know which Windows is selected - Windows will probably
remember the setting from last time or as configured from Windows.

So it's possible you need to explore how Windows lets you configure that.
It's also possible you have Grub entries for Windows 7 and 10 which both
point to the same thing (ie they both chainload Windows which remembers from
last time, not the setting from GRUB). There may be a way to tell Grub to
chainload a bootloader in a different partition, I'm not sure.

At least, that's my understanding of classic BIOS/MBR bootloaders. I think
UEFI is different - I haven't so much experience with Windows on that.

Post by Java Jive
[In case it matters, but I don't think it does, this laptop is a Dell
Precision M6700 which I bought recently because the video card in my
best old Dell Precision M6300 died, which is the default manner for
those PCs to die - even though this new one also has a good 17"
screen, it's wider and shorter than the old one, which I preferred.
There are a couple of over-priced video cards on eBay for nearly the
same sort of price as you could get a working machine of the same model,
but it's just not worth spending that sort of money on such an old
machine. Sniff!]

It does matter. The M6700 is an Ivy Bridge machine so that's probably
classic BIOS rather than UEFI.

Theo

[Java Jive]

Post by Theo

Post by Java Jive
Problem as per subject. I have a laptop triple booting into Ubuntu 22,
Windows 7, & Windows 10. GRUB has the correct settings to remember the
last boot choice and correctly does so for Ubuntu & Windows 10, but, if
I choose Windows 7, at the next boot it offers Windows 10 as the
default, not Windows 7. All I can find online is many different
explanations for how to set up dual-booting and have it remember the
last choice, not what to do if for some reason this doesn't work.

I have very limited experience of dual booting Windows, but AIUI there are
1. Install every Windows on a separate drive. Here each drive has its own
Windows bootloader. You can select which one to boot from in BIOS.
Alternatively, in Grub, you 'chainload' the Windows bootloader from a
specific drive, so you can pick between Windows installs
2. Install several Windows on the same drive, sharing a Windows bootloader.
Here you boot Grub, select you want to 'chainload' the Windows bootloader,
then you use the Windows bootloader to select which OS to boot. In this
case Grub doesn't know which Windows is selected - Windows will probably
remember the setting from last time or as configured from Windows.
So it's possible you need to explore how Windows lets you configure that.

Your analysis above is both correct, and, er, incorrect. For the legacy
MBR method of booting, I've produced an explanation on my website here
which somewhat agrees with what you have written above:

https://www.macfh.co.uk/JavaJive/PCHardware/PCBootProcess.html

However, where you are incorrect is that it's always been possible to
use GRUB to dual-boot between different versions of Windows ON THE SAME
DISK. My other remaining Dell Precision M6300 triple boots via GRUB
quite happily between Ubuntu 22, Windows XP, & Windows 10, and correctly
remembers the last choice whether it was Ubuntu or either version of
Windows. The partitions set up on this PC are as follows, where the OS
partitions are all primaries, while the two data partitions are logical
drives in an extended partition

Win 10 Pro | Win XP | Ubuntu 22 Root || Win Data | Ubuntu 22 Home ||

However, even though you are incorrect, there is truth in what you say,
although it is somewhat complicated to explain ...

When I first set up this new laptop, I decided to give it an extra
partition over the one it replaced, which had had 4 primary partitions
as follows ...

Windows 7 | Windows Data | Ubuntu 22 Root | Ubuntu 22 Home

... which I modified to be similar to the other machine above ...

Win 10 Pro | Win 7 | Ubuntu 22 Root || Win Data | Ubuntu 22 Home ||

However, after modifying the partition table and reimaging all the
partitions, W7 wouldn't boot, complaining that 'a device needed was
unavailable' or something similar. I tried fixing it using the W7 DVD,
which has always worked in the past, but the problem remained, so, as a
temporary fix, I ran a repair from the Windows 10 boot, which did allow
me to boot into Windows 7, but by a desperately convoluted process, viz:
choose the GRUB Windows 10 option, which almost completely boots W10
before giving an option to boot into W7, which if you choose reboots the
PC from scratch going straight into W7. And next time you want to boot
into W7 you have to go through the whole rigmarole again.

Obviously, it would be far more preferable just to boot straight into
W10 or W7 from GRUB itself, as with the other PC.

I worked out easily enough why the W7 DVD fix didn't work, because it's
been a long-standing historical problem going way back to the very
beginning that all such Windows tools work on THE PARTITION THAT HAS THE
BOOT FLAG SET, regardless of whether that's the partition which contains
the version of Windows that the tool belongs to, and here the W7
partition had moved from 1 to 2, but the boot flag had remained on 1.
Also, if there is more than one version of Windows on the PC, sometimes
running these fixes can take over the boot process of other Windows
partitions.

So I knew what to do, but just didn't have the time to do it at that
moment ...

However, yesterday evening, I backed up the W10 partition into an image
file, deleted it, created a blank partition in its place, moved the boot
flag to from 1 to 2 and ran the DVD tool again, this time successfully,
and thus was able to boot into W7 directly from GRUB. Next I moved the
boot flag back to 1, reinstated the W10 partition into that partition
from the image file backup, and reran GRUB, with the result that as of
now I can boot into either Windows directly from GRUB, the only problem
remaining being the one that is the subject of this thread.

Where you are correct in your incorrectness is that many people don't
have the knowledge to understand the above, and so follow the line of
least resistance and let the Windows boot process decide which version
of Windows to run, but, as explained, the result can be very
inefficient. What may be happening here to give me my problem,
particularly as that was the original configuration, is that part of
GRUB may be still assuming that Windows 7 is being booted via Windows
10, but it can't be all of GRUB that is working to that assumption,
because, in that case, why would it configure a W7 boot option at all?

Post by Theo
It's also possible you have Grub entries for Windows 7 and 10 which both
point to the same thing (ie they both chainload Windows which remembers from
last time, not the setting from GRUB). There may be a way to tell Grub to
chainload a bootloader in a different partition, I'm not sure.

No to first part and yes to second part, see the grub.cfg excerpt in my OP.

Post by Theo

Post by Java Jive
[In case it matters, but I don't think it does, this laptop is a Dell
Precision M6700 which I bought recently because the video card in my
best old Dell Precision M6300 died, which is the default manner for
those PCs to die - even though this new one also has a good 17"
screen, it's wider and shorter than the old one, which I preferred.
There are a couple of over-priced video cards on eBay for nearly the
same sort of price as you could get a working machine of the same model,
but it's just not worth spending that sort of money on such an old
machine. Sniff!]

It does matter. The M6700 is an Ivy Bridge machine so that's probably
classic BIOS rather than UEFI.

It gives me the choice in the BIOS, but I have chosen legacy rather than
UEFI.

Writing the above prompted me to check the GRUB configuration of the
machine that works. The file /etc/default/grub is exactly the same, but
the resulting /boot/grub/grub.cfg is different in the specification of
the two menu options. Here, both have the drivemap option, and further
the GUIDs, as I presume they are, differ in the 'if' statements:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows 10 (on /dev/sda1)' --class windows --class os
$menuentry_id_option 'osprober-chain-C00A7FAA0A7F9BDA' {
savedefault
insmod part_msdos
insmod ntfs
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 C00A7FAA0A7F9BDA
else
search --no-floppy --fs-uuid --set=root C00A7FAA0A7F9BDA
fi
parttool ${root} hidden-
drivemap -s (hd0) ${root}
chainloader +1
}
menuentry 'Microsoft Windows XP Professional (on /dev/sda2)' --class
windows --class os $menuentry_id_option 'osprober-chain-64F43020F42FF2CA' {
savedefault
insmod part_msdos
insmod ntfs
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2
--hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 64F43020F42FF2CA
else
search --no-floppy --fs-uuid --set=root 64F43020F42FF2CA
fi
parttool ${root} hidden-
drivemap -s (hd0) ${root}
chainloader +1
}

[J.O. Aho]

Post by Java Jive
However, after modifying the partition table and reimaging all the
partitions, W7 wouldn't boot, complaining that 'a device needed was
unavailable' or something similar.  I tried fixing it using the W7 DVD,
which has always worked in the past, but the problem remained, so, as a
temporary fix, I ran a repair from the Windows 10 boot, which did allow
choose the GRUB Windows 10 option, which almost completely boots W10
before giving an option to boot into W7, which if you choose reboots the
PC from scratch going straight into W7.  And next time you want to boot
into W7 you have to go through the whole rigmarole again.

I would say your "fix" was in the win10 bootloader and the reason why
it's generally recommended to have each mswin on it's own HDD is that
you can disable it in the BIOS and do repairs on another mswin without
affecting the other installations.

Alternative would be use KVM or XEN, then you know the instance will not
see any other devices than those assigned to it, running the repair will
not affect any other installation and you don't have the risk of mswin
taking over mbr from GRUB. The other benefit is that you don't have to
dual boot, for hardware rendered 3D graphics you would need a dedicated
graphics card for the guest you want to be able to run at the same time
(if you have the cash there are those graphics cards that allow you to
have vGPU, which is a good thing if you have multiple guest needing
hardware rendered 3D graphics or CUDA).

Post by Java Jive
Writing the above prompted me to check the GRUB configuration of the
machine that works.  The file /etc/default/grub is exactly the same, but
the resulting /boot/grub/grub.cfg is different in the specification of
the two menu options.  Here, both have the drivemap option, and further

If you haven't cloned the partitions from the other computer (this tend
to work poorly with the closed source OS), then the UUID will be different.

I hope you don't have network drivers for the ms-winxp (EOL 2014-04-08)
and ms-win7 (EOL 2020-01-14), don't care if something happens to you,
just thinking of everyone else.

[Java Jive]

Post by J.O. Aho
I hope you don't have network drivers for the ms-winxp (EOL 2014-04-08)
and ms-win7 (EOL 2020-01-14), don't care if something happens to you,
just thinking of everyone else.

Of course I have network drivers for them, otherwise they would be near
useless to me. The XP machine still has working anti-virus, but even so
I don't take it on to the internet. W7 still receives security updates,
and is still my every day working OS, and is being used to post here.

[J.O. Aho]

Post by Java Jive

Post by J.O. Aho
I hope you don't have network drivers for the ms-winxp (EOL
2014-04-08) and ms-win7 (EOL 2020-01-14), don't care if something
happens to you, just thinking of everyone else.

Of course I have network drivers for them, otherwise they would be near
useless to me.  The XP machine still has working anti-virus, but even so
I don't take it on to the internet.  W7 still receives security updates,
and is still my every day working OS, and is being used to post here.

ESU run out last year, the extended one for Azure instances ran out
earlier this year, so not sure what "updates" you been installing
lately, maybe some ccp chinese or fascist russian ones.

[Java Jive]

Post by J.O. Aho
ESU run out last year, the extended one for Azure instances ran out
earlier this year, so not sure what "updates" you been installing
lately, maybe some ccp chinese or fascist russian ones.

Yet the fact remains that W7 is still receiving security updates from
the MS Website:

Security Intelligence Update for Windows Defender Antivirus - KB915597
(Version 1.409.256.0) - Current Channel (Broad)

Installation date: ‎14/‎04/‎2024 17:16

Installation status: Successful

Update type: Important

Install this update to revise the files that are used to detect viruses,
spyware, and other potentially unwanted software. Once you have
installed this item, it cannot be removed.

More information:
https://go.microsoft.com/fwlink/?linkid=2007160

Help and Support:
https://go.microsoft.com/fwlink/?LinkId=52661

Security Intelligence Update for Windows Defender Antivirus - KB915597
(Version 1.409.186.0) - Current Channel (Broad)

Installation date: ‎11/‎04/‎2024 10:32

Installation status: Successful

Update type: Important

Install this update to revise the files that are used to detect viruses,
spyware, and other potentially unwanted software. Once you have
installed this item, it cannot be removed.

More information:
https://go.microsoft.com/fwlink/?linkid=2007160

Help and Support:
https://go.microsoft.com/fwlink/?LinkId=52661

Windows Malicious Software Removal Tool x64 - v5.123 (KB890830)

Installation date: ‎10/‎04/‎2024 10:18

Installation status: Successful

Update type: Important

After the download, this tool runs one time to check your computer for
infection by specific, prevalent malicious software (including Blaster,
Sasser, and Mydoom) and helps remove any infection that is found. If an
infection is found, the tool will display a status report the next time
that you start your computer. A new version of the tool will be offered
every month. If you want to manually run the tool on your computer, you
can download a copy from the Microsoft Download Center, or you can run
an online version from microsoft.com. This tool is not a replacement for
an antivirus product. To help protect your computer, you should use an
antivirus product.

More information:
http://support.microsoft.com/kb/890830

Help and Support:
http://support.microsoft.com

... etc, etc.

[J.O. Aho]

Post by Java Jive

Post by J.O. Aho
ESU run out last year, the extended one for Azure instances ran out
earlier this year, so not sure what "updates" you been installing
lately, maybe some ccp chinese or fascist russian ones.

Yet the fact remains that W7 is still receiving security updates from
Security Intelligence Update for Windows Defender Antivirus - KB915597
(Version 1.409.256.0) - Current Channel (Broad)

You know this is just an anti virus application update, not an OS
update, even if it would be able to detect most viruses and malware, it
will not fix the issue that causes you to potentially get them in the
first place. your ms-win7 is EOL and even if it had been run on Azure,
it wouldn't get any OS updates.

[Java Jive]

Post by J.O. Aho

Post by Java Jive
Security Intelligence Update for Windows Defender Antivirus - KB915597
(Version 1.409.256.0) - Current Channel (Broad)

You know this is just an anti virus application update, not an OS
update, even if it would be able to detect most viruses and malware, it
will not fix the issue that causes you to potentially get them in the
first place. your ms-win7 is EOL and even if it had been run on Azure,
it wouldn't get any OS updates.

Sure, but, like any product beyond the lifetime of its guarantee, W7
doesn't suddenly become useless because Microsoft have stopped
maintaining it. I've not had an issue over the 10 years I've been using
it - nor for that matter the 15 or so that I've been using XP - and
as the most likely source of problems is a browser, which *is* being
updated and my browsing habits have not changed, why should I suddenly
have a problem now? As long as I can keep the most vulnerable
applications such as AV and browsers updated, then I have no fear in
using W7 - on the other hand, for XP I can't do this, which is why I
don't take it on to the internet.

[J.O. Aho]

Post by Java Jive

Post by J.O. Aho

Post by Java Jive
Security Intelligence Update for Windows Defender Antivirus -
KB915597 (Version 1.409.256.0) - Current Channel (Broad)

You know this is just an anti virus application update, not an OS
update, even if it would be able to detect most viruses and malware,
it will not fix the issue that causes you to potentially get them in
the first place. your ms-win7 is EOL and even if it had been run on
Azure, it wouldn't get any OS updates.

Sure, but, like any product beyond the lifetime of its guarantee, W7
doesn't suddenly become useless because Microsoft have stopped
maintaining it.  I've not had an issue over the 10 years I've been using
it  -  nor for that matter the 15 or so that I've been using XP  -  and
as the most likely source of problems is a browser, which *is* being
updated and my browsing habits have not changed, why should I suddenly
have a problem now?  As long as I can keep the most vulnerable
applications such as AV and browsers updated, then I have no fear in
using W7  -  on the other hand, for XP I can't do this, which is why I
don't take it on to the internet.

Sure, it will not magically stop working just for ms decide to
discontinue an operating system, but you also will lack fixes like for
Downfall which an anti-virus program wouldn't protect against nor will
the latest browser.
Just for you have a vulnerability of course don't make you prime target,
but could happen you just happen to visit your regular site and it's
been compromised and could be serving a bit different traffic than
usually which could lead to ...

[Java Jive]

Post by J.O. Aho
If you haven't cloned the partitions from the other computer (this tend
to work poorly with the closed source OS), then the UUID will be different.

After some further thought, I thought this the most helpful thing you'd
said. On the problem PC, the Win 10 Pro partition is actually the Win 7
Ultimate partition in-place upgraded to Win 10 Pro, so of course they
have the same partition GUIDs, whereas on the PC where everything is
working as it should, the GUIDs of the two Windows partitions are different.

So, in order to get GRUB to work properly, I decided that I needed to
change the partition GUID on one of the partitions, choosing the
Win10Pro partition as the newest, the interloper, as it were. In my
researches of the problem online, I'd seen instructions for doing this
in Linux using DD, but felt a bit nervous about doing it that way, being
unsure whether & how there might be some undesirable consequences within
Windows itself, say preventing booting into that partition, though
subsequently these fears appeared to be unfounded. I'd not seen
anything about how to do it, as it were 'legally', from within Windows
itself, or using an accepted and approved tool such as Ghost Walk, until
eventually I found this:

https://www.diskgenius.com/editions.php

I downloaded the Free version, installed it on a USB stick as I didn't
want it permanently in a build, booted into W7 so that the W10 could be
unlocked, used it to change the Win 10 Pro GUID*, and then rebooted into
Linux and ran update-grub. Now all the GRUB choices, including W7, are
correctly remembered on next boot.

* I created another pseudo-random hex number by pasting the existing one
into Calculator in programmer view, converted it to decimal, multiplying
it by an arbitrarily chosen prime number, and converted the result back
to hex.

So thank you for pointing out about the GUIDs.

[J.O. Aho]

Post by Java Jive

Post by J.O. Aho
If you haven't cloned the partitions from the other computer (this
tend to work poorly with the closed source OS), then the UUID will be
different.

After some further thought, I thought this the most helpful thing you'd
said.  On the problem PC, the Win 10 Pro partition is actually the Win 7
Ultimate partition in-place upgraded to Win 10 Pro, so of course they
have the same partition GUIDs, whereas on the PC where everything is
working as it should, the GUIDs of the two Windows partitions are different.

That explain it, nice to be able to help.

Post by Java Jive
So, in order to get GRUB to work properly, I decided that I needed to
change the partition GUID on one of the partitions, choosing the
Win10Pro partition as the newest, the interloper, as it were.  In my
researches of the problem online, I'd seen instructions for doing this
in Linux using DD, but felt a bit nervous about doing it that way

Yeah, I would too, for partition UUID tools like parted and fdisk could
work, for the ntfs I would have looked at the ntfslabel from the ntfs-3g
tools, but for sure a backup would have been wise to take before using
it, sure not supporting encrypted ntfs.

[Carlos E.R.]

Problem as per subject.  I have a laptop triple booting into Ubuntu 22,
Windows 7, & Windows 10.  GRUB has the correct settings to remember the
last boot choice and correctly does so for Ubuntu & Windows 10, but, if
I choose Windows 7, at the next boot it offers Windows 10 as the
default, not Windows 7.  All I can find online is many different
explanations for how to set up dual-booting and have it remember the
last choice, not what to do if for some reason this doesn't work.
Can anyone advise?

I'm no expert in this area, but I noticed something in your grub.cfg file:

Windows 10

parttool ${root} hidden-
drivemap -s (hd0) ${root}
chainloader +1

vs

Windows 7

parttool ${root} hidden-
chainloader +1


Is it intentional, or accidental?
Perhaps the section has been generated by os-prober, automatically.

It occurs to me that maybe W10 has been designed to play nice, while W7
has not.

[bad sector]

Problem as per subject.  I have a laptop triple booting into Ubuntu 22,
Windows 7, & Windows 10.  GRUB has the correct settings to remember the
last boot choice and correctly does so for Ubuntu & Windows 10, but, if
I choose Windows 7, at the next boot it offers Windows 10 as the
default, not Windows 7.  All I can find online is many different
explanations for how to set up dual-booting and have it remember the
last choice, not what to do if for some reason this doesn't work.
Can anyone advise?
The relevant settings are reproduced below, and yes I have remembered to
run update-grub, in fact I've done it twice, but despite everything
looking correct, the problem persists.  Note that in the resulting
grub.cfg the two Windows sections are identical except where they should
differ in designating the relevant partition, and that the W10 section
has an extra penultimate line 'drivemap ...', but I don't know enough
about how GRUB works to know whether that would be relevant ...
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
#   info -f grub -n 'Simple configuration'
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
[rest is commented out, until]
# Uncomment to get a beep at grub start
GRUB_INIT_TUNE="480 440 1"
[...]
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows 10 (on /dev/sda1)' --class windows --class os
$menuentry_id_option 'osprober-chain-C00A7FAA0A7F9BDA' {
    savedefault
    insmod part_msdos
    insmod ntfs
    set root='hd0,msdos1'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  C00A7FAA0A7F9BDA
    else
      search --no-floppy --fs-uuid --set=root C00A7FAA0A7F9BDA
    fi
    parttool ${root} hidden-
    drivemap -s (hd0) ${root}
    chainloader +1
}
menuentry 'Windows 7 (on /dev/sda2)' --class windows --class os
$menuentry_id_option 'osprober-chain-C00A7FAA0A7F9BDA' {
    savedefault
    insmod part_msdos
    insmod ntfs
    set root='hd0,msdos2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2
--hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2  C00A7FAA0A7F9BDA
    else
      search --no-floppy --fs-uuid --set=root C00A7FAA0A7F9BDA
    fi
    parttool ${root} hidden-
    chainloader +1
}
[...]
[In case it matters, but I don't think it does, this laptop is a Dell
Precision M6700 which I bought recently because the video card in my
best old Dell Precision M6300 died, which is the default manner for
those PCs to die  -  even though this new one also has a good 17"
screen, it's wider and shorter than the old one, which I preferred.
There are a couple of over-priced video cards on eBay for nearly the
same sort of price as you could get a working machine of the same model,
but it's just not worth spending that sort of money on such an old
machine. Sniff!]

Have you tried manual booting from the grub shell?

It's not that complicated and and might in the long run be more robust.

rough examples

set root=(hd0,gptX)
linux /boot/vmlinuz
initrd /boot/initrd
boot

insmod part_gpt
insmod chain
set root=(hd0,gpt1)
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
boot

I've never booted w10 this way but there's lotsa guidance on the net.

Some other stunts I tried in another life where grub-legacy ruled the
underworld were config-file and partition table switcharoos just before
issuing a restart command, in essence deciding the next booted system
before the restart. I actually had buttons like "boot partition X" :-)

My initial suggestion is the manual approach, it might even reveal
possible future edits of grub configs but I'm not knowlegable with
respect to grub2 (hate it like the plague).

[Paul]

Problem as per subject.  I have a laptop triple booting into Ubuntu 22, Windows 7, & Windows 10.  GRUB has the correct settings to remember the last boot choice and correctly does so for Ubuntu & Windows 10, but, if I choose Windows 7, at the next boot it offers Windows 10 as the default, not Windows 7.  All I can find online is many different explanations for how to set up dual-booting and have it remember the last choice, not what to do if for some reason this doesn't work.
Can anyone advise?
The relevant settings are reproduced below, and yes I have remembered to run update-grub, in fact I've done it twice, but despite everything looking correct, the problem persists.  Note that in the resulting grub.cfg the two Windows sections are identical except where they should differ in designating the relevant partition, and that the W10 section has an extra penultimate line 'drivemap ...', but I don't know enough about how GRUB works to know whether that would be relevant ...
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
#   info -f grub -n 'Simple configuration'
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
[rest is commented out, until]
# Uncomment to get a beep at grub start
GRUB_INIT_TUNE="480 440 1"
[...]
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows 10 (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-chain-C00A7FAA0A7F9BDA' {
    savedefault
    insmod part_msdos
    insmod ntfs
    set root='hd0,msdos1'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  C00A7FAA0A7F9BDA
    else
      search --no-floppy --fs-uuid --set=root C00A7FAA0A7F9BDA
    fi
    parttool ${root} hidden-
    drivemap -s (hd0) ${root}
    chainloader +1
}
menuentry 'Windows 7 (on /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-chain-C00A7FAA0A7F9BDA' {
    savedefault
    insmod part_msdos
    insmod ntfs
    set root='hd0,msdos2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2  C00A7FAA0A7F9BDA
    else
      search --no-floppy --fs-uuid --set=root C00A7FAA0A7F9BDA
    fi
    parttool ${root} hidden-
    chainloader +1
}
[...]
[In case it matters, but I don't think it does, this laptop is a Dell Precision M6700 which I bought recently because the video card in my best old Dell Precision M6300 died, which is the default manner for those PCs to die  -  even though this new one also has a good 17" screen, it's wider and shorter than the old one, which I preferred. There are a couple of over-priced video cards on eBay for nearly the same sort of price as you could get a working machine of the same model, but it's just not worth spending that sort of money on such an old machine. Sniff!]

If the Windows Boot Manager intercepts your chainload, it might
well boot the "default" OS selection. Instead of going "GRUB --> Windows 7",
it might well be going "GRUB --> Windows Boot Manager --> (Default selection, currently Windows 10).

Remember - these things have folders in ESP, a "Ubuntu" folder, a "Windows" folder.
There is no "Windows 7" folder and "Windows 10" folder. I would be more hopeful
for your mission, if the storage in ESP was separated. The other guys who suggested
separate disks (as a means to get "unique"/"single" boot entries), are basically
trying to do the same thing. They're trying to create entries that cannot
foul up. Now, the problem with this, is the motherboard UEFI, does not "Well Tolerate"
finding multiple Windows Boot Manager folders on the computer during the UEFI scan. It can
easily throw a hissy fit - this especially happens when two disks are the same
model (I have lots of WDC Black 1TB scratch drives, select SATA1, and SATA2 boots!).

You shouldn't be booting that way anyway :-)

You should be using Popup Boot. On my Asus machine, that's F8.
Then I see the blue-bordered rectangle, with entries like...

1) "some ubuntu choice" ( for which there is a folder in ESP ) -- then the GRUB menu appears and you select a Linux OS

2) "some Windows Boot Manager choice" (for which there is a folder in ESP labeled Windows)

When you select (2), you end up in a dialog like this.

Windows 10

Windows 7

The dialog can either have two tiles ("wrong") or the window
can have a black background and two lines of text like it
is Windows XP ("right"). The reason the legacy mode is right,
is it only required one boot cycle to get into any OS in that sub-menu.
If you allow the stupid Microsoft default way to rule (tile interface), it takes
two boot cycles to get into the non-default Windows OS.

To enable the legacy boot menu in the Windows Boot Manager on a single disk, try

administrator terminal:

bcdedit /set {bootmgr} displaybootmenu True

I think the notion of chainloading directly, on the four partition legacy MSDOS disk,
that makes more sense. That's more likely to work the way you expected, but considering
the "litter" that Windows brings with it, it's a bit harder to manage the Extended/Logical
and keep everybody happy in there. I don't like having to fool around with
resizing Extended/Logical to add OSes to a multiboot. That's why it is GPT, Popup Boot,
two stage selection. I have had a shitload of OSes on an Extended/Logical, just
for the experience, but I deleted that drive content as it was getting
on my nerves.

If you take hands-off-keyboard, turn on system power, Microsoft set up that UEFI spec
and ESP, to benefit themselves. The Windows Boot Manager is likely to boot, even after
GRUB is installed. There is some utility for changing that behavior (long string of letters,
list of bootable things), but for the user who doesn't know about it, Microsoft may appear
to have the upper hand.

https://www.linuxbabe.com/wp-content/uploads/2016/09/efibootmgr.webp

(https://www.linuxbabe.com/command-line/how-to-use-linux-efibootmgr-examples)

I would start by displaying what is in there. And see whether the deck is stacked
to help you or not. That page doesn't have the example I would want to use.

Paul

[Carlos E.R.]

Post by Paul
Remember - these things have folders in ESP, a "Ubuntu" folder, a "Windows" folder.

I think he is booting in traditional model aka legacy, ie, no ESP.

[Java Jive]

Post by Carlos E.R.

Post by Paul
Remember - these things have folders in ESP, a "Ubuntu" folder, a "Windows" folder.

I think he is booting in traditional model aka legacy, ie, no ESP.

Correct.

As indicated in another post, I have solved the problem, which was
caused by the two partitions having identical GUIDs, the W10 being an
in-place upgrade of the W7 one. Changing the partition GUID of the W10
partition resolved the problem.

[Carlos E.R.]

Post by Java Jive

Post by Carlos E.R.

Post by Paul
Remember - these things have folders in ESP, a "Ubuntu" folder, a "Windows" folder.

I think he is booting in traditional model aka legacy, ie, no ESP.

Correct.
As indicated in another post, I have solved the problem, which was
caused by the two partitions having identical GUIDs, the W10 being an
in-place upgrade of the W7 one.  Changing the partition GUID of the W10
partition resolved the problem.

I should have noticed it:

search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 C00A7FAA0A7F9BDA

search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2
--hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 C00A7FAA0A7F9BDA

[Java Jive]

Post by Java Jive

Post by Carlos E.R.

Post by Paul
Remember - these things have folders in ESP, a "Ubuntu" folder, a "Windows" folder.

I think he is booting in traditional model aka legacy, ie, no ESP.

Correct.
As indicated in another post, I have solved the problem, which was
caused by the two partitions having identical GUIDs, the W10 being an
in-place upgrade of the W7 one.  Changing the partition GUID of the
W10 partition resolved the problem.

      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  C00A7FAA0A7F9BDA
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2
--hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2  C00A7FAA0A7F9BDA

Arguably, so should I! However, at the time of my OP I didn't know
enough about GRUB to realise those numbers were the GUIDs of the
partitions. It was J.O.Aho's remark, on first reading apparently
insignificant, that later came back to me, causing me to investigate
further and so realise that they were the GUIDs of the partitions involved.

[Paul]

Post by Java Jive

Post by Carlos E.R.

Post by Paul
Remember - these things have folders in ESP, a "Ubuntu" folder, a "Windows" folder.

I think he is booting in traditional model aka legacy, ie, no ESP.

Correct.
As indicated in another post, I have solved the problem, which was caused by the two partitions having identical GUIDs, the W10 being an in-place upgrade of the W7 one.  Changing the partition GUID of the W10 partition resolved the problem.

       search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  C00A7FAA0A7F9BDA
       search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2  C00A7FAA0A7F9BDA

Arguably, so should I!  However, at the time of my OP I didn't know enough about GRUB to realise those numbers were the GUIDs of the partitions.  It was J.O.Aho's remark, on first reading apparently insignificant, that later came back to me, causing me to investigate further and so realise that they were the GUIDs of the partitions involved.

And is that really a GUID ?

I've seen several lengths of disk identifier Linux uses
from Windows stuff, and it's not clear how it
parses or understands things like that. Or for that
matter, what generic term we should use for the identifier.

To me, it seems Linux does not get 128 bit numbers from Legacy Windows
for identifiers, the numbers tend to be 64 bit or 32 bit (DiskID).
At least I can understand the DiskID one, because I've seen it
in a hex editor.

With GPT, both the partition type and the partition identifier,
they could be 128 bit numbers (disktype can show you those, maybe
gparted as well). Then the formatting would look like a GUID.

Partition 3: 118.7 GiB (127481675776 bytes, 248987648 sectors from 239616)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7) <=== fixed declaration
Partition Name "Basic data partition"
Partition GUID 6A16D60B-3608-4140-891C-792DF2C72ABD <=== random assignment of some sort
NTFS file system
Volume size 118.7 GiB (127481675264 bytes, 248987647 sectors)

Paul

[Java Jive]

Post by Paul

Post by Java Jive
As indicated in another post, I have solved the problem, which was caused by the two partitions having identical GUIDs, the W10 being an in-place upgrade of the W7 one.  Changing the partition GUID of the W10 partition resolved the problem.

       search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  C00A7FAA0A7F9BDA
       search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2  C00A7FAA0A7F9BDA

Arguably, so should I!  However, at the time of my OP I didn't know enough about GRUB to realise those numbers were the GUIDs of the partitions.  It was J.O.Aho's remark, on first reading apparently insignificant, that later came back to me, causing me to investigate further and so realise that they were the GUIDs of the partitions involved.

And is that really a GUID ?
I've seen several lengths of disk identifier Linux uses
from Windows stuff, and it's not clear how it
parses or understands things like that. Or for that
matter, what generic term we should use for the identifier.
To me, it seems Linux does not get 128 bit numbers from Legacy Windows
for identifiers, the numbers tend to be 64 bit or 32 bit (DiskID).
At least I can understand the DiskID one, because I've seen it
in a hex editor.

As far as I can tell, nomenclature varies, not just between OSs, but
also between different utilities supplied with or third party programs
running on a single OS, and between different people discussing the same
thing in the same online forum ...

In grub.cfg, we have seen that the hex strings under discussion are
effectively some sort of partition or volume ID. In many sources
online, they are referred to as partition IDs, however ...

In GPartEd, rt-clicking a partition and choosing Information describes
it as a UUID, so that is what I will call it/them henceforth. Once that
is understood, it then becomes apparent that rt-clicking a partition
gives a further choice of New UUID which can be chosen to change it far
more easily than the rigmarole that I went through.

However, in DiskPart, listing the details of neither a partition nor a
volume shows anywhere by any name the UUIDs shown in Linux utilities ...

DISKPART> select disk 0
Disk 0 is now the selected disk.

DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 Primary 64 GB 1024 KB
Partition 2 Primary 64 GB 64 GB
Partition 3 Primary 32 GB 128 GB
Partition 0 Extended 287 GB 160 GB
Partition 4 Logical 143 GB 160 GB
Partition 5 Logical 143 GB 303 GB

DISKPART> select part 1
Partition 1 is now the selected partition.

DISKPART> detail part
Partition 1
Type : 07
Hidden: No
Active: Yes
Offset in Bytes: 1048576

Volume ### Ltr Label Fs Type Size Status
Info
---------- --- ----------- ----- ---------- -------
--------- --------
* Volume 1 C Win10Pro NTFS Partition 64 GB Healthy


DISKPART> select volume 1
Volume 1 is the selected volume.

DISKPART> detail volume
Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
* Disk 0 Online 447 GB 1024 KB

Read-only : No
Hidden : No
No Default Drive Letter: No
Shadow Copy : No
Offline : No
BitLocker Encrypted : No
Installable : Yes

Volume Capacity : 63 GB
Volume Free Space : 9 GB

... while, just to cause further confusion, DiskPart's SETID command
change the partition *TYPE* ID, not any sort of volume or partition UUID
or label.

In DiskGenius, the UUID is called a 'Volume ID'.

No wonder so many of us are confused in life ...

Post by Paul
With GPT, both the partition type and the partition identifier,
they could be 128 bit numbers (disktype can show you those, maybe
gparted as well). Then the formatting would look like a GUID.
Partition 3: 118.7 GiB (127481675776 bytes, 248987648 sectors from 239616)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7) <=== fixed declaration
Partition Name "Basic data partition"
Partition GUID 6A16D60B-3608-4140-891C-792DF2C72ABD <=== random assignment of some sort
NTFS file system
Volume size 118.7 GiB (127481675264 bytes, 248987647 sectors)

Yes, but not strictly relevant to my original problem.