Microsoft Windows 11 Update Fixes Dual-Boot Linux Compatibility Issues

In August 2024, Microsoft released security update KB5041585 for Windows 11, aiming to enhance system security by implementing Secure Boot Advanced Targeting (SBAT). This update inadvertently disrupted dual-boot configurations with Linux distributions such as Ubuntu, Debian, Mint, Zorin OS, and Puppy Linux. Users encountered errors like "Verifying shim SBAT data failed: Security Policy Violation," preventing Linux systems from booting. (bleepingcomputer.com)
The root cause was the SBAT feature, designed to block outdated or unsafe bootloaders by referencing the Secure Boot DBX, a blacklist of known vulnerable UEFI files. However, the update mistakenly flagged legitimate Linux bootloaders, leading to boot failures. Microsoft acknowledged that the SBAT update was not intended for systems with dual-boot configurations but failed to detect some customized dual-boot setups, applying the SBAT value incorrectly. (bleepingcomputer.com)
In response, Microsoft provided a workaround involving disabling Secure Boot, modifying registry settings, and deleting the SBAT policy. While effective, these steps were complex and posed challenges for users unfamiliar with such procedures. (bleepingcomputer.com)
To address the issue comprehensively, Microsoft released the May 2025 Patch Tuesday update KB5058405, which rectified the dual-boot problem. This update ensures that the SBAT feature no longer disrupts Linux bootloaders in dual-boot configurations, allowing users to boot into both Windows and Linux without errors.
Users are advised to install update KB5058405 promptly to resolve the dual-boot issue. For those who applied the previous workaround, it's recommended to re-enable Secure Boot and remove any temporary registry modifications to restore default security settings.
This incident underscores the importance of thorough testing for updates, especially in systems with diverse configurations. It also highlights the need for clear communication and user-friendly solutions when addressing such issues.

---

Source: Windows Report May 2025 Patch Tuesday update KB5058405 fixes Windows 11 Linux dual-boot issue

 

[ChatGPT]

For nine long months, a significant segment of the global tech community found themselves at odds with an unlikely adversary: the very systems they trusted to be their digital gateways. In August 2024, Microsoft released a security update intended to strengthen Windows PCs against a particularly dangerous vulnerability in the GRUB bootloader—the program responsible for launching Linux systems on dual-boot machines. Instead of merely plugging the security hole, the update triggered a widespread “Security Policy Violation” for users with Linux and Windows configured in dual-boot on systems with Secure Boot enabled. This not only locked affected users out of their Linux installations but also forced many to temporarily disable key security features or resort to complex workarounds. As of mid-May 2025, Microsoft has at last offered relief: patch KB5058385, a fix described by many as overdue but deeply necessary.

The Origins of the Secure Boot-Dual Boot Debacle​

To comprehend the depth of this issue, it helps to unpack the underlying technology. Secure Boot, part of the Unified Extensible Firmware Interface (UEFI) standard, was devised to protect systems from rootkits and other low-level threats that could load before an operating system. It operates by only allowing signed bootloaders to execute during startup, theoretically ensuring that all software loaded into memory has not been tampered with.
Linux support Secure Boot by adopting signed versions of its bootloaders, such as GRUB. But when security vulnerabilities are found (as happened in early 2024 with the infamous GRUB2 BootHole exploit and its siblings), both Microsoft and Linux vendors must coordinate revocation and re-issuing of bootloader signatures. In August 2024, Microsoft released an update which, according to advisories and corroborated by developer reports, inadvertently mishandled the Secure Boot Advanced Targeting (SBAT)—an evolving mechanism that tightens which software gets past Secure Boot’s checks.
Instead of blacklisting only compromised bootloaders, the update sometimes blocked all Linux bootloaders, even fully patched and re-signed ones. The net result: users would try to boot their carefully administered dual-boot systems, only to be presented with cryptic security violation errors or find themselves endlessly looping within their PC firmware screens.

The Real-World Impact​

This wasn't a minor annoyance confined to a handful of power users. According to community forums such as Ubuntu, Fedora, and the Windows Forum itself, thousands reported sudden breakages in previously stable setups. For many, their work or personal systems depended on seamless switching between Windows and Linux. The usual remedies—refreshing bootloaders, editing BIOS/UEFI settings, or rolling back updates—were inconsistent at best and intimidating for less technical users.
Enterprises running mixed environments felt the pinch as well. Some organizations, especially in educational and research contexts, rely on dual-boot systems for compatibility and software requirements. Disabling Secure Boot to regain Linux access was, for many, a non-starter due to IT policy or compliance standards.
Worse still, official communications from Microsoft took time to clarify matters. Documentation was sparse and, for months, users leaned on community-driven guides and discussion threads, pooling knowledge and troubleshooting collectively. Unsurprisingly, frustration mounted—particularly as Microsoft's resources remained focused on Windows-exclusive features and the AI-infused aspects of its OS, leaving mixed-environment users in limbo.

KB5058385: Finally, a Fix (But With Caveats)​

On May 13, 2025, without much fanfare, Microsoft rolled out KB5058385—a patch specifically targeting fallout from the August 2024 update. The fix refines how the Secure Boot Advanced Targeting (SBAT) mechanism recognizes and interacts with dual-boot arrangements, particularly in identifying valid, signed Linux bootloaders. According to Microsoft’s updated technical notes, the patch:

• Improves SBAT logic to better distinguish genuine, up-to-date Linux bootloaders.
• Reduces incidences of false positives that would previously trigger “Security Policy Violation” messages.
• Is designed to deploy automatically via Windows Update on affected installations.

The update targets a broad swath of systems, including Windows 11 (versions 23H2, 22H2, 21H2), Windows 10 (21H2), Windows Enterprise 2015 LTSB, and Windows Server editions from 2012 R2 through 2022. For systems running the very latest Windows 11 builds (such as 24H2), anecdotal reports and testing suggest the fix may already be included—even though Microsoft has remained non-committal on explicitly confirming this compatibility.

How Does the Fix Work?​

Technical deep-dives reveal that Microsoft, in collaboration with key Linux maintainers, adjusted the subset of revoked keys and rewrote parts of the SBAT verification pathway. Validated, signed Linux bootloaders that adhere to updated criteria now pass Secure Boot checks, while those matching known-compromised SBAT entries remain blocked. This approach minimizes collateral damage, but, as always with Secure Boot, it depends on each Linux distribution properly maintaining and distributing its own signed bootloaders.

Automatic Updates (Mostly)​

For the majority of users on supported operating systems, KB5058385 arrives via Windows Update, requiring no additional user interaction. Manual installation is possible for environments where automated updates are disabled or strictly curated—often the case for enterprise deployments. As always, users are encouraged to verify update status via Settings > Windows Update and consult their system’s update history.
One ambiguous facet is how future Windows updates, or different release channels (such as Insider Preview or Long-Term Servicing Channel), might interact with this fix. Microsoft’s official documentation has not conclusively clarified installation mechanics for every scenario. For some, notably Windows 11 24H2, the fix appears rolled into cumulative updates rather than a standalone patch, a detail that should motivate cautious optimism but continued vigilance.

Community Impressions: Relief Mixed With Frustration​

Reaction within the dual-boot and Linux communities has been a blend of gratitude and residual exasperation.
Strengths of the Fix:

• It restores critical functionality for thousands of Windows-Linux dual-boot users.
• KB5058385 demonstrates that, when sufficiently motivated, Microsoft can resolve complex cross-ecosystem technical conflicts.
• The fix highlights behind-the-scenes collaboration with Linux distribution maintainers and upstream UEFI projects.

Ongoing Risks and Concerns:

• The nine-month turnaround underscores a persistent vulnerability facing “edge case” users—those whose requirements extend beyond a single-OS experience.
• Microsoft’s often-opaque communications during the incident left many feeling unsupported. For months, there were no clear timelines, documentation, or direct engagement, leading to community dependence on unofficial workarounds.
• Secure Boot, while protective against real threats, remains a complex and sometimes brittle technology. Even this fix could be undermined by future UEFI or Secure Boot updates, especially if not coordinated across the Windows and Linux ecosystems.
• There are spaces—most notably enterprise fleets and heterogeneous infrastructure—where policy, compliance, or technical debt may delay or complicate patch adoption.

Lessons for the Ecosystem​

This episode is a case study in the trade-offs and growing pains of platform security. On one hand, Secure Boot does block entire classes of breaches, and both Microsoft and the Linux community must act rapidly when vulnerabilities are found. On the other, it shows the hazards when fixes are pushed without sufficient ecosystem-wide consultation, testing, and documentation.

• Coordinated Disclosure and Patch Timing: Microsoft’s initial mishandling reveals the danger of patching in isolation. Secure Boot, by design, interacts with every operating system on a PC—so updates must be staged with an eye for cross-compatibility.
• Community-Driven Support Loops: Without adequate vendor engagement, users flocked to help forums, subreddits, and how-to sites. The speed and effectiveness of peer support is laudable, but direct vendor assistance remains irreplaceable for urgent, global issues.
• Documentation Deficits: Clearer, ongoing documentation from Microsoft regarding Secure Boot’s SBAT processes, key revocation, and the interplay of dual-boot scenarios is overdue.

Broader Implications for the Future of Dual Booting​

Historically, running both Windows and Linux on the same hardware was a badge of technical prowess and flexibility. Today, with Secure Boot and platform-level cryptographic checks, what once was a matter of partitioning disks now involves digital signatures, firmware settings, and periodic review of compliance matrices. KB5058385’s release ensures continued viability for dual-booters, but it also signals a shift toward ever-stricter platform controls.

Will Windows Continue to be Dual-Boot Friendly?​

This incident has prompted renewed debate over Microsoft’s commitment to tech enthusiasts, developers, and administrators who tread outside the typical consumer experience.

Arguments in Favor:​

• The fix demonstrates Microsoft’s willingness to address complex, niche cases—even if belatedly.
• Windows continues to officially support Secure Boot policies compatible with Linux and other OSs.
• UEFI and Secure Boot standards, though largely vendor-driven, are influenced by active participation from open source leaders.

Counterpoints:​

• The lengthy gap between bug introduction and resolution suggests these use cases are not a high priority for Microsoft. Core Windows and AI-powered experiences tend to dominate engineering focus.
• The episodic nature of support (long silences, sparse communication) can erode user confidence.
• As security protocols grow more elaborate, the technical bar for successful dual booting rises, possibly deterring new or less technically-inclined users.

How to Verify and Apply KB5058385​

For affected users, ensuring the patch is both available and correctly applied remains paramount. Steps to check include:

• Windows Update: Go to Settings > Windows Update > Update history. Look for KB5058385 or cumulative updates from May 2025 onward.
• Manual Downloads: For environments where updates are staged or disconnected from Microsoft’s servers, KB5058385 is available for manual download from the Microsoft Update Catalog.
• Secure Boot Status: Post-patch, confirm Secure Boot remains enabled via UEFI settings. Attempting a dual-boot into Linux should no longer produce security errors.
• Linux Bootloader Freshness: Ensure the installed Linux bootloader—especially GRUB2—has the latest signatures and complies with updated SBAT requirements. Distribution vendor notes (Ubuntu, Fedora, openSUSE) often provide detailed advisories.

Recommendations and Best Practices for Dual-Boot Users​

• Stay Informed: Dual-booters should subscribe to update feeds from both their Linux distro and Microsoft’s Windows Update. Periodic review of changelogs can preempt headaches.
• Backup Bootloaders: Prior to major Windows or firmware updates, back up the working Linux bootloader and document Secure Boot configuration.
• Understand UEFI/SBAT Mechanics: As the technology underpinning Secure Boot advances, understanding SBAT and signature revocation helps users recover faster from future incidents.
• Engage Vendors: When critical bugs emerge, raising them through official support channels can accelerate fixes. Don’t underestimate the power of collective feedback.

SEO Takeaways: Secure Boot, Windows Updates, and Dual Booting in 2025​

For readers searching “Windows Linux dual-boot bug,” “Secure Boot KB5058385,” or “fix Security Policy Violation dual boot,” this saga underlines an enduring truth: evolving platform security means staying current is not optional. Updates like KB5058385 restore functionality, but the onus remains on users and administrators to follow best practices, monitor patch cycles, and remain minimally dependent on vendor timelines alone.

Final Thoughts​

The saga surrounding the August 2024 Secure Boot update and the eventual May 2025 fix will be remembered by Windows-Linux dual-booters as an instructive, if frustrating, chapter in cross-platform computing. While Microsoft’s KB5058385 represents a necessary correction and a symbolic renewal of “dual-boot friendliness,” critical questions about priority, communication, and the future of open dual-boot platforms remain.
As platform security continues to evolve, enthusiasts and enterprise users alike must adapt. The lesson is clear: flexibility is hard-won and must be protected—not just by vendors, but by an informed and proactive community. Whether you’re a dedicated dual-booter or simply value the freedom to choose your OS, vigilance remains the best defense against both digital threats and the unintended consequences of progress.

---

Source: It's FOSS News 9 Months Later, Microsoft Finally Fixes Linux Dual-Booting Bug

 

[ChatGPT]

Nine months ago, a routine Windows security update upended the delicate balance that allows users to dual-boot between Windows and Linux—a scenario familiar to power users, developers, and privacy advocates the world over. Now, after sustained concern and mounting pressure from the open-source community, Microsoft has at last released a patch designed to correct the issue and restore peace to dual-boot systems worldwide. This development invites not only relief but careful scrutiny: How did a well-intentioned security update fracture the interoperability between two giants of the operating system world, and why did the fix take so long?

Understanding the August 2024 Windows Update: Good Intentions, Unintended Consequences​

In August 2024, Microsoft rolled out a security update incorporating a patch for CVE-2022-2601—a highly publicized vulnerability involving the circumvention of the Secure Boot mechanism. Secure Boot is central to modern system security, designed to prevent unauthorized code, especially rootkits and bootkits, from loading during the boot process. However, while crucial, Secure Boot has long presented compatibility challenges for non-Windows operating systems, particularly Linux distributions.
Microsoft’s update aimed squarely at hardening Secure Boot by “locking the vulnerable Linux boot loader that affects the Windows security system.” At the time, Microsoft explicitly stated that dual-boot configurations would remain unaffected. But almost immediately, users across forums and support channels reported a different reality: Many found themselves unable to boot into Linux after installing the update. The underlying issue was that the logic used to determine which boot loaders were “vulnerable” was overly aggressive, failing to discern legitimate Linux boot loaders from potentially malicious or unsupported ones.

The Fallout: A Community in Disarray​

The backlash was swift and intense. Linux enthusiasts and multi-boot aficionados took to Reddit, GitHub, and Windows support forums, detailing various symptoms:

• Linux partitions vanished from boot menus.
• Ubiquitous ‘Bootloader Not Found’ errors.
• OEM systems (often used in educational and enterprise environments) rendered unable to access Linux environments, disrupting work and hampering productivity.

For dual-boot users, being sidelined for the sake of Windows security felt like collateral damage. Complicating matters was Secure Boot’s implementation: With most modern hardware enforcing Secure Boot in UEFI mode, options for circumvention without significant risk or loss of system integrity were limited.

Microsoft’s Response: Nine Months in the Waiting​

Technical issues of this scale and sensitivity rarely lend themselves to instant fixes, but few could have anticipated a nine-month wait. The lack of an immediate, authoritative solution spurred third-party workarounds—some risky, others excessively technical for everyday users. This absence of clear guidance fueled frustration and speculation about Microsoft’s commitment to open-source interoperability.
The May 2025 security update—released as KB5058385—finally addresses the issue. According to official release notes, “improvements have been applied to Secure Boot Advanced Targeting (SBAT) to detect Linux systems.” Though succinct, this line belies the complexity of the patch. Independent coverage, notably by IT'S FOSS NEWS, confirms that Microsoft refined its logic for identifying boot loaders. Legitimate Linux boot loaders—such as modern versions of Shim and GRUB2—are no longer flagged as security violations. The update also covers a broad swath of operating systems, including:

• Windows 11 releases 23H2, 22H2, 21H2
• Windows 10 21H2
• Enterprise and Server lines: 2015 LTSB, Server 2022, 2019, 2016, 2012, and 2012 R2

Notably, Windows 11 24H2 is omitted from the official list, but reports suggest its fix was implemented preemptively during development.

The Technical Anatomy of the Fix​

At the heart of Secure Boot’s mechanism is a validation process: When a device starts up, the Unified Extensible Firmware Interface (UEFI) inspects the digital signatures of boot loaders. Only those with valid, unrevoked signatures load successfully. The August 2024 update expanded Microsoft’s Secure Boot Revocation List (DBX) to include a broader swath of potentially vulnerable Linux boot loaders, aiming to preclude flaws associated with CVE-2022-2601. Unfortunately, the revocation was implemented too broadly, ensnaring many up-to-date, secure Linux boot loaders.
KB5058385 adjusts this by enhancing SBAT (Secure Boot Advanced Targeting) logic. SBAT itself—a mechanism recently adopted by both Microsoft and the Linux community—is designed to allow granular revocation of specific vulnerable components without wholesale bans. Instead of blanket revocation, the new logic better distinguishes between outdated and up-to-date boot loaders, only blocking those genuinely at risk.

No User Action Required—A Welcome Simplicity​

For most users, the fix arrives as part of regular Windows Update cycles. No special recovery steps or command-line interventions are demanded:

• Plug in, update, reboot—Linux dual-boot should be restored.
• Users on affected Server and Enterprise systems receive the same seamless remediation, an especially important consideration for institutional deployments.

Safety Nets: What If It Still Doesn’t Work?​

Despite the comprehensiveness of KB5058385, edge cases may persist—especially on custom or legacy systems. Standard advice remains:

• Ensure UEFI firmware and all OSes are fully updated.
• Check that boot order prioritizes the correct loader (e.g., Shim for Linux).
• For enthusiasts, the UEFI/BIOS Secure Boot database can be cleared and re-enrolled, but this is rarely necessary post-patch.

Critical Analysis: Strengths and Lingering Risks​

While Microsoft’s eventual fix restores key functionality, several underlying themes demand further attention.

Strengths:​

1. Commitment to Security Without Permanent Lockouts​

The original intent—to protect against Secure Boot circumvention—was well-founded, and Microsoft’s rapid inclusion of the CVE patch demonstrates diligence in addressing newly discovered threats.

2. Adoption of Advanced Targeting Techniques​

The refinement of SBAT logic signals a maturing partnership between proprietary and open-source security. By moving beyond blanket revocations, Microsoft recognizes the legitimacy and technical rigor of open-source boot loaders. This marks a shift from the company’s historically rocky relationship with Linux interoperability.

3. Transparent, Universal Deployment​

The resolution being pushed via standard Windows Update provides users broad, low-friction access to remediation. Coverage across both consumer and enterprise systems is extensive, minimizing the risk of fragmentation.

Potential Risks and Ongoing Challenges:​

1. Communication Gaps​

The timeline—nine months from the documented onset of issues to a broad fix—suggests a disconnect in prioritizing dual-boot scenarios within Microsoft’s risk triage. While enterprise customers may have enjoyed priority support, community reports suggest consumer and enthusiast feedback was slow to prompt public response.

• Future risk: In the absence of rapid, clear communication channels, similar incompatibilities could again catch users off-guard.

2. Over-Dependence on Secure Boot Blacklists​

Security models that rely on revocation lists inevitably lag behind the pace of vulnerability discovery and patching. Each revision risks collateral impact and compatibility breakage, especially in complex, multi-OS environments.

• Mitigation: Greater transparency and collaboration between Microsoft, hardware vendors, and open-source projects like the Linux Foundation are critical.

3. User Trust and Technical Overhead​

Enthusiasts and system integrators forced to spend months troubleshooting or implementing risky workarounds may see this episode as validation of long-standing skepticism about Microsoft’s open-source bona fides. Millions depend on robust dual-boot for development, data recovery, and privacy reasons.

• Recovery: Ongoing, proactive engagement with upstream projects—such as the Shim reviewers or GRUB maintainers—must become standard, not exceptional.

4. Edge Case Exclusions​

Complex server and embedded environments, which often use customized boot chains, may not be fully covered by the broad strokes of KB5058385. The risk persists that a “one patch fits all” philosophy could unintentionally sideline niche but critical systems.

• Best practice: Organizations should complement system updates with deep images and backups, along with careful review of Secure Boot logs post-update.

Broader Implications for Windows & Linux Interoperability​

This dual-boot debacle reflects the intricate dance between security and accessibility in modern computing. Microsoft, now an open-source contributor and Azure Linux kernel developer, faces the ongoing challenge of balancing rapid vulnerability responses with the diversity of user workflows.

Secure Boot: Friend and Foe​

Secure Boot's evolution remains contentious, especially as supply chain threats become more sophisticated. With every layer of security comes the risk of overreach, and the episode underscores demands by the open-source community for more modular, transparent, and collaborative approaches.
Table: Frequently Affected Scenarios

User Profile	Reported Issue	Fix Status
Dual-boot enthusiasts	Linux fails to load	Resolved with KB5058385
Enterprise/education IT	Labs lost access to Linux	Resolved (patch via WSUS & Intune)
Custom server deployments	Boot loops, authentication errors	Patch applies; manual validation may be required

Looking Ahead: Lessons and Recommendations​

For Microsoft, the challenge is twofold: maintaining an uncompromising standard of security while guaranteeing system interoperability for a diverse, demanding user base. The KB5058385 update demonstrates lessons learned—but also that technological fixes must be paired with organizational agility.

Recommendations for Users​

• Stay updated: Enable automatic updates for both Windows and Linux.
• Diversify recovery options: Keep bootable USB media for both OSes, just in case.
• Monitor official channels: For complex setups, subscribe to Microsoft Security Response Center (MSRC) and relevant Linux distro advisories.

Recommendations for Microsoft​

• Shorten communication cycles: Even a “we see you” acknowledgment, early on, buys goodwill.
• Expand test coverage: Simulate real-world multi-OS boot chains in pre-release cycles.
• Sustain open standards: Continue to improve SBAT and related tooling together with upstream maintainers.

Closing Thoughts​

The patching of the broken Windows-Linux dual-boot bridge will be greeted with relief and perhaps some remaining anxiety by the global tech community. While KB5058385 restores interoperability, it simultaneously surfaces perennial questions about the complexity of multi-OS security and the responsibilities of platform stewards like Microsoft. Users, administrators, and developers have reason to celebrate—but also to remain vigilant, prepared, and vocal in ensuring that tomorrow’s security updates do not come at yesterday’s expense. The uneasy truce between flexibility and safety continues, and only ongoing collaboration and communication will keep it from breaking once again.

---

Source: GIGAZINE Microsoft delivers patch to fix Windows and Linux dual boot problem, 9 months after issue

 

[Tek2go]

Even the latest update didn't help!

 

[ChatGPT]

Thanks for the update! Just to clarify, when you say "the latest update didn’t help," do you mean:

• You applied the newest Windows 11 update but still can't access Linux Mint at boot?
• Or did you try the GRUB reinstallation steps and it didn't resolve the issue?

Could you let me know exactly what's happening?

• Are you seeing any error messages, or does your computer just boot straight into Windows with no boot menu?
• Have you tried booting from a Linux Mint Live USB and checking if your Mint partition still exists?
• Any recent error screens or strange behavior?

If you’ve tried any of the steps I suggested before, let me know where you got stuck or what result you saw. The more detail, the better—I want to help you get dual-boot working again!
If you’ve uploaded any logs or screenshots, let me know if there’s something specific you want me to review in them.

 

[Tek2go]

I applied the latest update but still can't access Linux Mint at boot!

 

[ChatGPT]

Thanks for clarifying! Since applying the Windows update didn't restore dual-boot access, you'll almost certainly need to repair the GRUB bootloader manually—Windows updates typically don't restore Linux boot entries, even if the update notes mention "Linux compatibility."
Here's how to proceed:

1. Boot from a Linux Mint Live USB/DVD​

You'll need to boot your computer from a Linux Mint live USB or DVD (the same way you did when first installing Mint).

2. Open a Terminal​

Once in the live session, open the terminal (Ctrl+Alt+T).

3. Reinstall/Repair GRUB​

Follow these steps (let me know if you need clarifications on any step!):

1. Identify your Linux root partition:
   sudo fdisk -l
   Look for the partition labeled "Linux filesystem" (e.g., /dev/sda2).
2. Mount your Linux root partition:
   sudo mount /dev/sdaX /mnt
   Replace /dev/sdaX with the partition you found.
3. Mount necessary system directories:
   for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
4. Chroot into your Linux installation:
   sudo chroot /mnt
5. Reinstall GRUB to your main disk (not a partition):
   

   grub-install /dev/sda
   update-grub

6. Exit and reboot:
   

   exit
   for i in /run /sys /proc /dev/pts /dev; do sudo umount /mnt$i; done
   sudo umount /mnt
   sudo reboot

Remove the USB/DVD when the system restarts and see if the boot menu is restored.

---

If you tried these steps and it still boots straight to Windows, let me know what happened at each step, and if there were any error messages.
Also, if you’d like, I can check your recent uploads for logs or details that might hint at something unusual with your partitions or boot setup—just let me know!
Let’s get you back to dual-booting!