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: | 764 |
Nodes: | 10 (0 / 10) |
Uptime: | 43:10:19 |
Calls: | 527 |
Calls today: | 1 |
Files: | 46,973 |
Messages: | 13,255 |