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.
[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!]
In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:
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.
[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.
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.
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:
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.
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?
On 15/04/2024 15:34, J.O. Aho wrote:
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.
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!]
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!]
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.
On 15/04/2024 21:05, J.O. Aho wrote:
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)
On 15/04/2024 15:34, J.O. Aho wrote:
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
On 15/04/2024 22.46, Java Jive wrote:
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.
Remember - these things have folders in ESP, a "Ubuntu" folder, a "Windows" folder.
On 2024-04-16 00:29, Paul wrote:
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.
On 16/04/2024 12:50, Carlos E.R. wrote:
On 2024-04-16 00:29, Paul wrote:
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.
On 2024-04-16 14:32, Java Jive wrote:
On 16/04/2024 12:50, Carlos E.R. wrote:
On 2024-04-16 00:29, Paul wrote:
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
On 16/04/2024 06:43, J.O. Aho wrote:
On 15/04/2024 22.46, Java Jive wrote:
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.
On 16/04/2024 14:05, Carlos E.R. wrote:
On 2024-04-16 14:32, Java Jive wrote:
On 16/04/2024 12:50, Carlos E.R. wrote:
On 2024-04-16 00:29, Paul wrote:
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
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.
On 4/16/2024 9:46 AM, Java Jive wrote:
On 16/04/2024 14:05, Carlos E.R. wrote:
On 2024-04-16 14:32, Java Jive wrote:
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
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)
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 ...
Sysop: | Luis Silva |
---|---|
Location: | Lisbon |
Users: | 763 |
Nodes: | 10 (0 / 10) |
Uptime: | 180:05:07 |
Calls: | 111 |
Files: | 46,971 |
Messages: | 11,239 |