It used to use ntldr back in the days of WinXP.
I did dual boot XP with Debian, and I chainloaded fron ntldr to grub. I never had a problem with that setup.
I think it is no longer ntldr.
It used to use ntldr back in the days of WinXP.
I did dual boot XP with Debian, and I chainloaded fron ntldr to grub. I never had a problem with that setup.
I think it is no longer ntldr.
Correct. IIRC, that changed with the release of Windows Vista (XP was the last version to use ntldr) to using Windows Boot Manager (BOOTMGR).
That matches my understanding too: Vista moved the standard Windows boot path to BOOTMGR, while older systems used NTLDR. It’s a useful reminder that a dual-boot repair guide should identify the bootloader generation before suggesting commands; otherwise a technically correct fix can target the wrong files.
Thanks for your contribution look forward to seeing more from you, welcome to our forum
When I read that - my head pronounced “fix” the way a Kiwi would (i.e. f’x") which can sound like f–ks in another anglosphere dialect…
Good advice.
Thank you @HelenMarsh84 , and welcome to itsFOSS.
Like you say, interesting. Someone here mentioned cachyos, an Arch based OS. Never used Arch, so I gave it a spin, in a VM. Kind of like it, but got side tracked (common these days).
Today, I fired it up and told it to update (over 100 updates). It got part way through and a ton of red error lines appeard in the console. Then a “disk is getting full” dialog popped up. Before I could do anything the VM froze, never to run again. Must have taken a self destruct cycle. To recover, I did the chroot “trick”, failed. So, I tried to do an install with my own partitioning to save the root partition. Failed. From the error messages, too much was deleted in the upgrade process. Never seen such goings on. I have always seen “disk space getting low” after pausing. I tried to mount the disk, it seems to think it did but didn’t. Now it is stuck with the choice of umount the disk. Obviously corrupt. Fortunately nothing important was on there. Tomorrow, I will do a full reinstall. I don’t give up easily.
I have used Cachy os for 6 months and never got any problems but then i have it installed on my nvme ssd 1 tb disk. and i do like it very much, i hope you can get it to work right. Regards Mikael
Cachyos5 is fairly bloated. It might require more than the normal amount of virtual disk.
Also, check that the real disk space where you keep your VM files is not full.
True, but since Windows BOOTMGR arrived with Windows Vista in 2007, that’s nearly twenty years ago, so for the most part, ntldr is probably more of a historical note than a component of a running OS. While I know there are exceptions, those who are still running Windows XP or any earlier version of Windows should make it clear what they’re asking for help with, combines with helpers taking care to provide version-specific help … right?
Good deal! I was using CachyOS for a minute on my laptop until a fix for the Garuda grub with secure boot came to me earlier today. I installed Garuda in accordance with the distributions recommendations, and grub booted both Garuda and Windows 11 Pro 25H2 successfully. Since I dual-boot Windows with GNU/Linux, I want secure boot enabled if possible, and since their Secure Boot Setup Guide on the Cachy Wiki worked so well for me on that distribution, I decided to give it a try, albeit with a few minor modifications for Garuda, and now I have my distribution of choice back in action and working perfectly.
The CachyOS Secure Boot Guide enables secure boot with sbctl, using Microsoft’s OEM keys and certificates to enable secure boot on GNU/Linux. While I’m no expert on the topic, IIUC, using Microsoft’s own OEM keys should make for a more stable setup than shim (the traditional Linux-based secure boot solution) can offer. I guess I’ll see how things go going forward, but at least my system actually dual-boots successfully ![]()
Actually, using Cachy for a week or so inspired me to return to Garuda as a test (after creating a Rescuezilla backup image), and grub boots both Windows and Garuda just fine, so I used the Secure Boot Setup Guide on the Cachy Wiki with a few modifications to accommodate Garuda, and things are working perfectly. IIUC, the commands used in the CachyOS guide sign all required files using Microsoft’s own OEM keys and certificates, and that may be the difference from Garuda’s garuda-secureboot, and why things are working now …
IIRC, Cachy wanted me to set up a 4GB EFI partition too, because they keep their kernels and boot loaders there in addition to whatever else gets stored there
That means Cachy uses efi boot without grub, if it puts vmlinuz and initrd in EFI partition.
That is probably @louyo1 's problem. … no, hang on , he had it running , then it ran out of disk during an update … it must have run out of virtual disk space.
When he re-creates his VM, my suggestion is that he create a 4GB EFI partition with fat-32, then however much space he can afford to give his system. Like Garuda, CachtOS defaults to using btrfs, and I recommend it because you set up one partition for everything other than the EFI, and btrfs manages sub-volumes automatically. As I understand it, each sub-volume is something like a virtual partition. I’m uncertain whether there’s any advantage to virtual partitions, but btrfs does seem to be a very stable file system, and I like that I don’t have to figure out what size I want/need my root (/) partition to be when/if I separate my home space from the system tree it mounts onto.
So btrfs is both a partition table manager and a filesystem manager.
In a VM that is safe, but for a hard disk install it might difficult mixed with a multiboot. I know you do it, but newcomers should be careful.
Bare-metal installations is what it’s intended for. As an example, I have one half of my system drive for Windows, and I let the Windows installer handle the partitioning using the space it gets as it see;s fit. Then, for Garuda, the partition I created to prevent Windows from consuming my entire drive becomes my Garuda partition, and when it’s formatted with btrfs, as the filesystem fills with various files, each sub-volume gets additional space as needed, as if it was a virtual partition, and all the free space is in a pool, available as needed. As I said earlier, I have no idea whether there are any real advantages over the other file systems used in GNU/Linux, but it seems to be quite stable and reliable so far, and the snapshot feature that comes with it may be the best reason for using it of all, particularly with an Arch-based, rolling distribution like Garuda or Cachy, because if there’s an issue with a broken update, like when one package is updated, but one or more of its dependencies have not been updated yet, all that I have to do is reboot, and choose the most recent snapshot, prior to the update, and I’m back in business. Usually within a few days, all dependencies are updated, and my next update goes as expected. Snapshots really are a nice safety net against unexpected issues or my own stupidity during an experiment. They’re not quite as comprehensive as full system image backups, but they’re much faster and easier to implement when the issue doesn’t involve corruption of an exterior partition like I recently encountered with my EFI partition getting corrupted when I tried switching to using the rEFInd boot manager.
While I believe you are starting to sound a bit hysterical, you’re very likely correct in this statement.
Years ago I came to the same conclusion and discovered the wonderful world of refurbished, small format computers for the price of a nice dinner, including wine. Windows lives on a Windows-only machine and Linux plays nicely on a much smaller, less expensive box.
My solution is simple, only use linux and if its a programme that must have windows run it through wine, if that does not work use a linux alternative or just dont bother find a better solution.
With the AI data-center crunch, those days are gone … at least for the imminent future, and perhaps forever …