Multi-boot issue after installing Aquarius

FlexQ4 · 2026-09-15 11:01

Hello,
after installing Aquarius on an MBR-system on sda4 besides Windows (on sda1) and Q4OS-4 "Gemini" (on sda3):
In the boot-menu there are only the entrie for Q4os - os-prober states:

Found Debian GNU/Linux 11 (bullseye) on /dev/sda3

But what's missing/expected here would also be:

/dev/sda1:Windows 7:Windows:chain

Please, how can i get back Windows on my system??
Thank you!

Last edited by FlexQ4 (2026-09-15 11:11)

q4osteam · 2026-09-15 11:14

Please run:
$ sudo os-prober
and post the output

FlexQ4 · 2026-09-15 11:23

here it is:

[~\> sudo os-prober
[sudo] Passwort für me:
/dev/sda3:Debian GNU/Linux 11 (bullseye):Debian:linux

Weird enough: good (now old-old-old) Gemini still does find Windows:

[:~\> sudo os-prober
[sudo] Passwort für me:
/dev/sda1:Windows 7:Windows:chain
/dev/sda4:Debian GNU/Linux 12 (bookworm):Debian:linux

But for the moment (until the issue is claryfied) i won't run update-grub on Gemini...

q4osteam · 2026-09-15 11:38

Would you check, whether there is another setting:
$ grep -R "GRUB_DISABLE_OS_PROBER" /etc/default/grub /etc/default/grub.d/ 2>/dev/null

FlexQ4 · 2026-09-15 12:30

No, only the disabling of the "DISABLE_OS_PROBER":

# grep -R "GRUB_DISABLE_OS_PROBER" /etc/default/grub /etc/default/grub.d/ 2>/dev/null
/etc/default/grub:GRUB_DISABLE_OS_PROBER=false

/etc/default/grub.d is a directory which only contains an "empty" init-select.cfg file.

q4osteam · 2026-09-15 14:17

Two things decide this, please run on Aquarius:
$ [ -d /sys/firmware/efi ] && echo "UEFI boot" || echo "BIOS boot"
$ sudo os-prober
$ sudo grep -E "os-prober|50mounted-tests|20microsoft" /var/log/syslog | tail -30
$ sudo grub-mount /dev/sda1 /mnt && ls /mnt | head && sudo umount /mnt

Background: os-prober only reports Windows on a system booted in legacy BIOS mode -
its Windows detector exits immediately when /sys/firmware/efi exists, while Linux
systems are still listed. That alone produces exactly your output. If Aquarius
booted in UEFI mode and Gemini in BIOS mode, that is the answer, and a BIOS Windows
cannot be chainloaded from an EFI GRUB anyway - Windows then has to be started from
the firmware boot menu, or Q4OS's bootloader reinstalled in BIOS mode.

Otherwise the second possibility is that GRUB cannot read the NTFS partition:
os-prober mounts partitions only with grub-mount, and skips a partition silently if
that fails. The grub-mount line above shows it. In that case, mounting the Windows
partition before updating the menu works around it:
$ sudo mkdir -p /mnt/win && sudo mount -o ro /dev/sda1 /mnt/win
$ sudo update-grub
$ sudo umount /mnt/win

Your Gemini install is unaffected either way; running update-grub there is safe.

FlexQ4 · 2026-09-15 16:15

It's only Lagacy/BIOS here on my pc. The output of the first block:

me@flex:~\> [ -d /sys/firmware/efi ] && echo "UEFI boot" || echo "BIOS boot"
BIOS boot

me@flex:~\> sudo os-prober
/dev/sda3:Debian GNU/Linux 11 (bullseye):Debian:linux

me@flex:~\> sudo grep -E "os-prober|50mounted-tests|20microsoft" /var/log/syslog | tail -30
2026-09-15T17:01:30.434456+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/05efi
2026-09-15T17:01:30.448226+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/10freedos
2026-09-15T17:01:30.461908+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/10qnx
2026-09-15T17:01:30.475361+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/20macosx
2026-09-15T17:01:30.488883+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/20microsoft
2026-09-15T17:01:30.497188+02:00 flex 20microsoft: debug: /dev/sda8 is a NTFS partition
2026-09-15T17:01:30.681517+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/30utility
2026-09-15T17:01:30.690619+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/40lsb
2026-09-15T17:01:30.696828+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/70hurd
2026-09-15T17:01:30.702876+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/80minix
2026-09-15T17:01:30.708620+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/83haiku
2026-09-15T17:01:30.717956+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/90linux-distro
2026-09-15T17:01:30.759998+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/90solaris
2026-09-15T17:01:30.763762+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/efi
2026-09-15T17:01:30.780375+02:00 flex os-prober: debug: running /usr/lib/os-probes/50mounted-tests on /dev/sda9
2026-09-15T17:01:31.069083+02:00 flex 50mounted-tests: debug: mounted using GRUB ntfs filesystem driver
2026-09-15T17:01:31.071423+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/05efi
2026-09-15T17:01:31.077153+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/10freedos
2026-09-15T17:01:31.082767+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/10qnx
2026-09-15T17:01:31.088325+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/20macosx
2026-09-15T17:01:31.093991+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/20microsoft
2026-09-15T17:01:31.097497+02:00 flex 20microsoft: debug: /dev/sda9 is a NTFS partition
2026-09-15T17:01:31.226322+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/30utility
2026-09-15T17:01:31.231098+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/40lsb
2026-09-15T17:01:31.234279+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/70hurd
2026-09-15T17:01:31.237560+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/80minix
2026-09-15T17:01:31.240582+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/83haiku
2026-09-15T17:01:31.245326+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/90linux-distro
2026-09-15T17:01:31.268202+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/90solaris
2026-09-15T17:01:31.271715+02:00 flex 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/efi

The second solution then seems to work::

me@flex:~\> sudo mkdir -p /mnt/win && sudo mount -o ro /dev/sda1 /mnt/win

me@flex:~\> sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-53-amd64
Found initrd image: /boot/initrd.img-6.1.0-53-amd64
Found linux image: /boot/vmlinuz-6.1.0-44-amd64
Found initrd image: /boot/initrd.img-6.1.0-44-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
/usr/sbin/grub-probe: error: unknown filesystem.
Found Windows 7 on /dev/sda1
/usr/sbin/grub-probe: error: unknown filesystem.
Found Debian GNU/Linux 11 (bullseye) on /dev/sda3
done

me@flex:~\> sudo umount /mnt/win
me@flex:~\>

Please let me reboot...

Added later 30 min 16 s:
Many thanks for your support @q4osteam!

But it fails. The entry for Win7 in the boot menu is actually present, but when selecting it:

Settin partition type to 0x83
error: invalid signature

any key to continue

if i edit the entry, i can see the cause: the entry is far too less (as i saw it on a working system), even the partition uuid is missing!

Setparms 'Windows7 (on /dev/sda1)'
        insmod part_msdos
        parttool ${root} hidden-
        chainloader +1

This is disappointing, two steps at least back from Gemini tbh.

Should i try sudo /media/me/<uuid of beloved Gemini partition>/usr/bin/os-prober ?

Edit: tried it - no success neither, only Gemini is found...

Last edited by FlexQ4 (2026-09-15 16:48)

q4osteam · 2026-09-15 18:01

Nothing is wrong with your machine or Windows installation. os-prober detects Windows correctly, but grub-probe cannot identify the filesystem on sda1, so the generated entry lacks the required "set root" line. "chainloader +1" then targets the wrong partition, causing the "invalid signature" error. The same happens with sda3, so the Gemini entry is affected too.

This is a Debian bug, not a Q4OS one, reported in 2022 and apparently unchanged since 2023:
https://bugs.debian.org/1013203

If you want, we can investigate why GRUB cannot read those partitions.

FlexQ4 · 2026-09-15 21:10

Oh man, a big 'Thank you!' once again!!

I already was sure, that it would be a Debian bug - quite apparently - unfortunately Q4 is affected in this case.
And i'm wondering, how such a grave bug can persist in Debian - for years! (So frustrating that so many things go the total wrong direction these days...)
And instead that somebody would care, in contrary, the GRUB_DISABLE_OS_PROBER is activated by default to hide other OS's!

Another annoyance btw i observed: firstly i installed and started Synaptic to add some software to the installation, and it modified the kernel to a new version (.44 -> .53) - in the background - even without any explanation or information.

If you want, we can investigate why GRUB cannot read those partitions.

MANY THANKS again @team for your kind offer: only if you've really got nothing better to do, and if you are interested too wink
Of course i offer to test/verify the solutions you find.

I for my part will boot back into Gemini now, try to restore the grub from there, and will show Debian 12+ my back for a while...

SO frustrating...

Added later 3 h 34 min 49 s:
Now, this is really sad: back in Gemini i issued the sudo update-grub here again, an the output was quite promising:

...
Found Windows 7 on /dev/sda1
Found Debian GNU/Linux 12 on /dev/sda4
done

i even controlled the generated /boot/grub/grub.cfg: just perfect!

But: after reboot the bootmenu hadn't changed at all ! Aquarius was still the leading entry and the Win7-entry as poor as before.
That means: the bootmenu created with Debian12 had remained.

However, i was prepared and edited/completed the entry for Win7 (very painful with a german keyboard)... and was finally able to boot once into Windows.

So: Why the he__ the update-grub in Gemini does not take effect? Maybe because it's an older version of grub?
Unfortunately i know few about GRUB and the booting process (MBR, IPL and partition table) - hopefully someone can help me, to get control of my booting-situation here again...

Many thanks in advance!

Added later 3 h 43 min 29 s:
it seems that i do have to re-install grub on Gemini: https://askubuntu.com/questions/1069735 … -no-effect

Last edited by FlexQ4 (2026-09-16 00:44)

q4osteam · 2026-09-16 10:28

FlexQ4 wrote:

So: Why the he__ the update-grub in Gemini does not take effect? ... it seems that i do have to re-install grub on Gemini ...

Yes, you need to reinstall Grub prior update:
$ sudo grub-install
$ sudo update-grub

seb3773 · 2026-09-16 10:55

update-grub does not "update the boot menu" in the firmware/MBR sense, It mainly does the following:
/etc/grub.d/* --> grub-mkconfig --> /boot/grub/grub.cfg

However, it does not necessarily reinstall the bootloader in the MBR; grub-install is the tool that actually installs GRUB to the disk. The official documentation, for example, provides: grub-install /dev/sda for a bios installation on the first disk.
So, it’s possible to have:
Gemini : /boot/grub/grub.cfg (new)
but
MBR : old GRUB (still in use)
and end up with the situation where update-grub appears to work, but after rebooting, the menu has not changed.
(exactly what Q4OS Team described: "That alone produces exactly your output. If Aquarius booted in UEFI mode and Gemini in BIOS mode, that is the answer, and a BIOS Windows cannot be chainloaded from an EFI GRUB anyway - Windows then has to be started from the firmware boot menu, or Q4OS's bootloader reinstalled in BIOS mode.")

I would start by determining what actually boots the system:

sudo grub-install --version
grub-install --version

and then:

findmnt /boot
findmnt /boot/efi

because you need to know whether the machine uses BIOS+MBR or UEFI+GPT
If it is BIOS/MBR --> reinstall GRUB on the correct disk; if /dev/sda is the boot disk and gemini has the correct /boot:

sudo grub-install /dev/sda
sudo update-grub

*important: /dev/sda and not /dev/sda1, for a bios GRUB install, you install to the disk, not the partition.

But, I think it's the best solution: for windows 7 on an old machine, you can even completely bypass os-prober:
If /dev/sda1 = Windows partition

you don't need os-prober to understand its filesystem to chainload the boot sector, just create a manual entry: sudo nano /etc/grub.d/40_custom

with:

menuentry "Windows 7" {
insmod part_msdos
insmod ntfs
set root=(hd0,1)
chainloader +1
}

and then run again sudo update-grub

--> it will create an entry independent of (unreliable) result from os-prober.

Last edited by seb3773 (2026-09-16 11:34)

FlexQ4 · 2026-09-16 13:22

MANY thanks @seb3773 too,

that is exactly what i did and what gave me back access to my OSs: in Gemini/Bullseye issued:

$ sudo grub-install /dev/sda
$ sudo update-grub

Since - beside Win7 and Gemini - there is still a (bootable) Win-XP partition on my system, i have to rely on a MBR/legacy configuration.

So now, two days later, i''ve got a nice working quad-boot MBR situation here as planned wink - BUT:
i am extremely disappointed about the negligent manner, how Debian seems to let phase-out support for older OS's and boot-configurations.
How would have been it, if Gemini wouldn't still reside here? Tinker with 40_custom files in /etc/grub.d/ to get access to Windows back?
Hiding (more pricisely: making inaccessible Win7 in my case, see above: https://bugs.debian.org/1013203 ) is a manner that i knew only from MS so far.

Debian12 did a first 'update-grub' during installation, then a second after an unrequested kernel update (while installing few apps via Synaptic) - but for a convenient boot-menu i have to tweak the /etc/default/grub, 'update-grub' a third time (to regain access to Gemini), then boot back into it - to install/update (an older) grub a fourth time...

Puhh, i'm done for the moment. Seems that Gemini will still remain my daily driver for a wihile!

Edit: forgot to thank you too @q4os-team explicitely! wink

Last edited by FlexQ4 (2026-09-16 13:32)

Q4OS Forum

#1 2026-09-15 11:01

Multi-boot issue after installing Aquarius

#2 2026-09-15 11:14

Re: Multi-boot issue after installing Aquarius

#3 2026-09-15 11:23

Re: Multi-boot issue after installing Aquarius

#4 2026-09-15 11:38

Re: Multi-boot issue after installing Aquarius

#5 2026-09-15 12:30

Re: Multi-boot issue after installing Aquarius

#6 2026-09-15 14:17

Re: Multi-boot issue after installing Aquarius

#7 2026-09-15 16:15

Re: Multi-boot issue after installing Aquarius

#8 2026-09-15 18:01

Re: Multi-boot issue after installing Aquarius

#9 2026-09-15 21:10

Re: Multi-boot issue after installing Aquarius

#10 2026-09-16 10:28

Re: Multi-boot issue after installing Aquarius

#11 2026-09-16 10:55

Re: Multi-boot issue after installing Aquarius

#12 2026-09-16 13:22

Re: Multi-boot issue after installing Aquarius

Board footer