(In reply to Marja van Waes from comment #0)
> Created attachment 6456 [details]
> report.bug.xz
> 
> (haven't checked yet whether the problem persists when I run update-grub2
> and grub2-install, will report back after I checked)
> 

that fixes it (before having run any updates), so the packages on the iso seem ok.

Assignee: bugsquad => thierry.vignaud

You should not use grub2-install but /boot/grub2/install.sh instead.

BTW your logs show:

* running: sh /boot/grub2/install.sh with root /mnt
error: /dev/sda4: No such device or address

We see:
* don't know what to do with Mageia (Cauldron) (sda5)
* don't know what to do with Mageia (Cauldron) (sda8)

But we don't care as this is overwritten by update-grub2
Os-prober only reported Windows.

Can you attach your current /boot/grub2/grub.cfg for comparing?

Keywords: (none) => NEEDINFO

Created attachment 6457 [details]
/boot/grub2/grub.cfg

(In reply to Thierry Vignaud from comment #2)
> You should not use grub2-install but /boot/grub2/install.sh instead.

Doesn't give any errors, should I retry after removing /boot/grub2/grub.cfg ?

I can boot into the earlier install I did yesterday, and run it there. I assume first running update-grub2 was OK?

> 
> BTW your logs show:
> 
> * running: sh /boot/grub2/install.sh with root /mnt
> error: /dev/sda4: No such device or address

That confuses me, but I remember having seen the same error (only about a different sdX) in another ddebug log. In both cases, diskdrake didn't know sdX

(In reply to Thierry Vignaud from comment #3)
> We see:
> * don't know what to do with Mageia (Cauldron) (sda5)
> * don't know what to do with Mageia (Cauldron) (sda8)
> 
> But we don't care as this is overwritten by update-grub2
> Os-prober only reported Windows.
> 
> Can you attach your current /boot/grub2/grub.cfg for comparing?

attaching

parted does see sda4 though:


 4      106GB   252GB   146GB    extended

(In reply to Marja van Waes from comment #4)
> 
> (In reply to Thierry Vignaud from comment #2)

> > 
> > BTW your logs show:
> > 
> > * running: sh /boot/grub2/install.sh with root /mnt
> > error: /dev/sda4: No such device or address
> 
> That confuses me, but I remember having seen the same error (only about a
> different sdX) in another ddebug log. In both cases, diskdrake didn't know
> sdX
> 

That was most probably unrelated: that was on a gpt-partitioned disk (where sda2 had been wiped), in an EFI-install, while this was a legacy install on a msdos partitioned disk.

Keywords: NEEDINFO => (none)
Whiteboard: (none) => 5final

Maybe os-prober needed sg that wasn't present in the install chroot?
But what's strange is that if did found Windows but not Linux.
We'll see when my log patches land

Adding as a release blocker

Priority: Normal => release_blocker
Blocks: (none) => 14069

That cannot be a release blocker:
1) nothing is broken
2) Grub2 is only installed by default on UEFI machines
3) on first update, grub2.cfg will be updated

Am I misreading the report? It seems to say that with an installation using grub2 it does not identify existing Mageia installs (and possibly other linux installs too).

grub2 install to sda7 here included mageia 4 installed to sda1 so I guess so.

I just did a 5final install (legacy BIOS) using full x86_64 DVD (on USB) selecting grub2 as bootloader and did not reproduce this, all other Mga2,3,4 & 5 installs were found.

I should add that some were on sda and some including a btrfs based system was on sdb.

I tested booting one other from the new install's grub2 menu and it booted OK, however there was no plymouth displayed, which does work when I boot the same system (Cauldron on sda7) using it's core.img, from a dedicated grub2 partition on sda1 with:

menuentry 'Cauldron sda7' { 
search --no-floppy --label --set=root cauldron
multiboot /boot/grub2/i386-pc/core.img
}

Not a blocker but interesting.

Created attachment 6458 [details]
new report.bug.xz, with patches for better logging

added tv's patches

+ /usr/bin/patch -U -s -p1 -b --suffix .0001 --fuzz=0 -i /home/marja/home2/marja/svn/bug15857_drakx-installer-stage2/SOURCES/0001-log-grub2-install.sh-in-report.bug-mga15857.patch
+ /usr/bin/patch -U -s -p1 -b --suffix .0002 --fuzz=0 -i /home/marja/home2/marja/svn/bug15857_drakx-installer-stage2/SOURCES/0002-stop-logging-obsolete-grub2-drakboot.conf.patch
+ /usr/bin/patch -U -s -p1 -b --suffix .0003 --fuzz=0 -i /home/marja/home2/marja/svn/bug15857_drakx-installer-stage2/SOURCES/0003-always-log-update-grub2-output-mga15857.patch

hope report.bug.xz is more useful now

That's definitively an os-prober bug (ripping gpg-agent logs):

* update-grub2 logs: 
mesg: ttyname() is mislukt: Ongepaste ioctl() voor apparaat
Generating grub configuration file ...
Gevonden thema: /boot/grub2/themes/maggy/theme.txt
Linux-afbeelding is gevonden: /boot/vmlinuz-desktop
Initiële RAM-schijfafbeelding is gevonden: /boot/initrd-desktop.img
Linux-afbeelding is gevonden: /boot/vmlinuz-3.19.6-desktop-2.mga5
Initiële RAM-schijfafbeelding is gevonden: /boot/initrd-3.19.6-desktop-2.mga5.img
Windows 7 (loader) is gevonden op /dev/sda1
Windows 7 (loader) is gevonden op /dev/sda2
voltooid

which translates as:

* update-grub2 logs: 
mesg: ttyname () failed: Inappropriate ioctl () for device
Generating grub configuration file ...
Found theme: /boot/grub2/themes/maggy/theme.txt
Linux image is found: / boot / vmlinuz desktop
Initiation «le RAM disk image has been found: /boot/initrd-desktop.img
Linux image is found: /boot/vmlinuz-3.19.6-desktop-2.mga5
Initiation «le RAM disk image has been found: /boot/initrd-3.19.6-desktop-2.mga5.img
Windows 7 (loader) is found at / dev / sda1
Windows 7 (loader) is found at / dev / sda2
completed

Source RPM: drakx-installer-stage2 grub2 => drakx-installer-stage2 os-prober

commit 40a7f58772c65df23e49ad4f13d4d8b2029853fc
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Wed May 6 19:52:38 2015 +0200

    previous commits really were for mga#15857
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=40a7f58772c65df23e49ad4f13d4d8b2029853fc

Barry, any idea what could be missing in the chroot?
It's the full being-installed-OS with /dev, /sys, /proc & /run mounted.
See http://gitweb.mageia.org/software/drakx/tree/perl-install/fs/any.pm#n84

/dev & /run are bind mounted from the installer
/proc & /sys are regular mounts

BTW os-prober is broken by the the s/grub/grub2/ renaming (ie it looks for grub-probe & grub-mount instead of grub2-probe & grub2-mount)...

(In reply to Thierry Vignaud from comment #17)
> BTW os-prober is broken by the the s/grub/grub2/ renaming (ie it looks for
> grub-probe & grub-mount instead of grub2-probe & grub2-mount)...

What I don't understand is how it appears to have been working like this?

However it must be fixed so I am committing an updated os-prober with:

Index: SPECS/os-prober.spec
===================================================================
--- SPECS/os-prober.spec	(revision 821399)
+++ SPECS/os-prober.spec	(working copy)
@@ -1,7 +1,7 @@
 %define _libexecdir %{_exec_prefix}/lib
 Name:           os-prober
 Version:        1.65
-Release:        %mkrel 8
+Release:        %mkrel 9
 Summary:        Probes disks on the system for installed operating systems
 License:        GPLv1 and GPLv2+
 Group:          System/Boot and Init
@@ -45,6 +45,10 @@
 
 %apply_patches
 
+for i in os-probes/common/50mounted-tests linux-boot-probes/common/50mounted-tests common.sh; do
+sed -i 's/grub-/grub2-/g' $i
+done
+
 %build
 
 %make

This fixes the breakage, and does not seem to break anything else, although I did get a hang on one occasion in UEFI mode, but then later running it with strace and later again without, there was no hang on any further tests.

I had totally forgotten about this bug, until I saw it again just now when rebooting after a traditional 64bit iso install (QA iso from last week) on the same laptop.

The update-grub2 logs still show the same as in comment 15 (except for initrd and vmlinuz version now being 3.19.8-desktop-2.mga5, of course)

(In reply to Barry Jackson from comment #18)

>  Name:           os-prober
>  Version:        1.65
> -Release:        %mkrel 8
> +Release:        %mkrel 9

> This fixes the breakage, and does not seem to break anything else, although
> I did get a hang on one occasion in UEFI mode, but then later running it
> with strace and later again without, there was no hang on any further tests.

os-prober-1.65-9.mga5 was on the iso where I just tested, sorry :-(

Fixed

*** This bug has been marked as a duplicate of bug 5690 ***

Status: NEW => RESOLVED
Resolution: (none) => DUPLICATE

Wrong bug

Status: RESOLVED => REOPENED
Resolution: DUPLICATE => (none)

(In reply to Marja van Waes from comment #20)

> os-prober-1.65-9.mga5 was on the iso where I just tested, sorry :-(
 Oh dear - I too had forgotten it :\

@Thierry
I tested update-grub in a chroot with dev, proc, sys and run bind mounted which is how I would normally do it and it works OK.

However when only dev and run are bind mounted it fails:

----snip----
Failed to read /proc/cmdline, ignoring: No such file or directory
device node not found
Failed to read /proc/cmdline, ignoring: No such file or directory
device node not found
---snip--------

To be clear I ran this to chroot into a recent Mga5 (PC-BIOS) install:

#!/bin/bash
# mychroot
[[ ${#1} > 0 ]] && [[ -e /dev/$1 ]] && [[ $UID = 0 ]] ||\
{ echo "Usage (as root)  - # mychroot sdxy"; exit 0; }
mount /dev/$1 /mnt/
for i in dev run; do
mount --bind /$i/ /mnt/$i/
done
chroot /mnt/
umount -l /mnt
# End of mychroot

Normally I use:
...
for i in dev proc sys run; do
...

/proc is mounted under /mnt/proc in install

(In reply to Thierry Vignaud from comment #24)
> /proc is mounted under /mnt/proc in install

I added it like this (not sure if it is correct):

#!/bin/bash
# mychroot
[[ ${#1} > 0 ]] && [[ -e /dev/$1 ]] && [[ $UID = 0 ]] ||\
{ echo "Usage (as root)  - # mychroot sdxy"; exit 0; }
mount /dev/$1 /mnt/
mount -t proc /proc /mnt/proc/       <====================
for i in dev run; do
mount --bind /$i/ /mnt/$i/
done
chroot /mnt/
umount -l /mnt

Now I see the following when running update-grub:
-----snip---------
device node not found
device node not found
device node not found
Cannot find list of partitions!  (Try mounting /sys.)
device node not found
device node not found
-----snip---------

The theme and local system entries seem to be found OK.

Drakx also mount sysfs on /mnt/sys...

Ah OK :)

So using this I guess it should be similar to the installer chroot?

#!/bin/bash
# mychroot2
[[ ${#1} > 0 ]] && [[ -e /dev/$1 ]] && [[ $UID = 0 ]] ||\
{ echo "Usage (as root)  - # mychroot sdxy"; exit 0; }
mount /dev/$1 /mnt/
mount -t proc /proc /mnt/proc/
mount -t sysfs /sys /mnt/sys/
for i in dev run; do
mount --bind /$i/ /mnt/$i/
done
chroot /mnt/
umount -l /mnt


Using the above there seems to be no problem here (not sure what "mesg: ttyname failed: Success" is about)

[root@jackodesktop baz]# ./mychroot2 sdb18
[root@jackodesktop /]# update-grub
mesg: ttyname failed: Success
Generating grub configuration file ...
Found theme: /boot/grub2/themes/maggy/theme.txt
Found linux image: /boot/vmlinuz-desktop
Found initrd image: /boot/initrd-desktop.img
Found linux image: /boot/vmlinuz-3.19.8-desktop-2.mga5
Found initrd image: /boot/initrd-3.19.8-desktop-2.mga5.img
Found Mageia 4 (4) on /dev/sda3
Found Mageia 2 (2) on /dev/sda6
Found Mageia 3 (3) on /dev/sda7
Found Mageia 5 (5) on /dev/sda8
Found Mageia 5 (5) on /dev/sda9
Found Mageia 5 on /dev/sdb16
Found Mageia 5 (5) on /dev/sdf2
Found openSUSE 13.2 (x86_64) on /dev/sdf4
Found Mageia 5 (5) on /dev/sdf5
done


@marja
May be worth trying the above on your system that gave the problem?

(In reply to Barry Jackson from comment #27)
> Ah OK :)
> 
> So using this I guess it should be similar to the installer chroot?
> 
> #!/bin/bash
> # mychroot2
> [[ ${#1} > 0 ]] && [[ -e /dev/$1 ]] && [[ $UID = 0 ]] ||\
> { echo "Usage (as root)  - # mychroot sdxy"; exit 0; }
> mount /dev/$1 /mnt/
> mount -t proc /proc /mnt/proc/
> mount -t sysfs /sys /mnt/sys/
> for i in dev run; do
> mount --bind /$i/ /mnt/$i/
> done
> chroot /mnt/
> umount -l /mnt
> 
> 
> Using the above there seems to be no problem here (not sure what "mesg:
> ttyname failed: Success" is about)
> 
> [root@jackodesktop baz]# ./mychroot2 sdb18
> [root@jackodesktop /]# update-grub
<snip>
> 
> @marja
> May be worth trying the above on your system that gave the problem?

(LC_ALL=C doesn't work in chroot)
[root@DenkBlok2_cauldron /]# LC_ALL=C update-grub2
mesg: ttyname() is mislukt: Gelukt
Generating grub configuration file ...
Gevonden thema: /boot/grub2/themes/maggy/theme.txt
Linux-afbeelding is gevonden: /boot/vmlinuz-desktop
Initiële RAM-schijfafbeelding is gevonden: /boot/initrd-desktop.img
Linux-afbeelding is gevonden: /boot/vmlinuz-3.19.8-desktop-2.mga5
Initiële RAM-schijfafbeelding is gevonden: /boot/initrd-3.19.8-desktop-2.mga5.img
Windows 7 (loader) is gevonden op /dev/sda1
Windows 7 (loader) is gevonden op /dev/sda2
Mageia 5 (5) is gevonden op /dev/sda5
Mageia 4 (4) is gevonden op /dev/sda7
voltooid
[root@DenkBlok2_cauldron /]# 

Should I try to run update-grub2  during next install, right after the bootloader got installed? (So e.g. in the installUpdates step)

hitting this on another system, too (32bit, with dual iso install, last iso with DrakX v16.101), it would probably be good to add this to the errata

Whiteboard: 5final => 5final FOR_ERRATA

@Colin: os-prober uses util-linux's logger for its output.
Is there a way to save them in the /mnt chroot?
We should maybe include more systemd in stage2 and use it for logs and save them at end. WDYT?

In the meantime, Marja could you manually run the following commands:

chroot /mnt
vim /bin/os-prober 
# alter /bin/os-prober so that instead of piping to logger,
# it uses "tee -a /LOG.os-prober"
os-prober

Keywords: (none) => NEEDINFO

(In reply to Thierry Vignaud from comment #30)

> 
> In the meantime, Marja could you manually run the following commands:

As soon as I understand where, when and how exactly

> 
> chroot /mnt
> vim /bin/os-prober 
> # alter /bin/os-prober so that instead of piping to logger,
> # it uses "tee -a /LOG.os-prober"
> os-prober

(In reply to Marja van Waes from comment #31)
> (In reply to Thierry Vignaud from comment #30)
> 
> > 
> > In the meantime, Marja could you manually run the following commands:
> 
> As soon as I understand where, when and how exactly

I mean: there is no use to do anything outside installer, because outside installer the problem doesn't exist.

However, the times I tried to use vim in installer, it didn't work, so apparently you're not talking about running the below in tty2 during install

Ah, wait, with barjac's script from comment 27, there was no problem, but the following is _without_ all the addional directories he mounted.

I'll read the chroot man page and try
> 
> > 
> > chroot /mnt
> > vim /bin/os-prober 
> > # alter /bin/os-prober so that instead of piping to logger,
> > # it uses "tee -a /LOG.os-prober"
> > os-prober

You _can_ run vim in the installer if:
- installed system is mounted in /mnt
- vim is installed in it

You can then either run directly vim-{minimal,enhanced}
or chroot in /mnt and run vim (as said in comment #30)

what does "1>&-" mean? I removed it after it gave errors in tty2 on my first try

the log'll be useless, the problem didn't re-occur: on reboot, both Mageia installations are in the grub2 boot menu.

this install was with the 32bits QA iso, I'll try again with the dual

Didn't reproduce with the dual again, either, but know now that right after selecting grub2, in the drop-down menu in the next screen, it is already visible whether os-prober failed to detect another Mageia install. If so, it won't be listed and can't be chosen as default.

Will try one last time on that 32bit system

(In reply to Marja van Waes from comment #36)

> 
> Will try one last time on that 32bit system

Failed to reproduce, the "bootloader configuration" list contains the other Mga.  However, I will try one _last_last_ time (with one last parameter changed back to what was used for the comment 29 test)

Created attachment 6660 [details]
LOG.os-prober

There is not much in the log.

After remembering that on _this_ laptop I hit the bug after wiping partitions and creating new ones in the partitioning step, I wiped some partitions again (not entirely the same, though) to create space for the new install.

Now it occurred again.

Created attachment 6661 [details]
report.bug.xz of the LOG.os-prober 32bit install

On the 64bit laptop, report.bug.xz from comment 19 (not attached) shows that I had 10 partitions at the beginning of step `doPartitionDisks' and 11 at the end (I installed to sda11)

Keywords: NEEDINFO => (none)

and for the same 64bit laptop, attachment 6458 [details] show I had 11 partitions when starting the partitioning step, and 12 at the end, and installed to sda12

Summary: Grub2 in installer doesn't add existing Mageia installs to boot menu => Grub2 in installer doesn't add existing Mageia installs to boot menu when the new install is on a newly created partition or partitions

(In reply to Thierry Vignaud from comment #30)
> @Colin: os-prober uses util-linux's logger for its output.
> Is there a way to save them in the /mnt chroot?
> We should maybe include more systemd in stage2 and use it for logs and save
> them at end. WDYT?
> 

CC'ing coling

(I should have remembered 11 comments ago that he wasn't in the CC of this bug, yet :-/)

CC: (none) => mageia

In such case, can you compare /dev/sd* & /mnt/dev/sd*?

Keywords: (none) => NEEDINFO

(In reply to Thierry Vignaud from comment #30)
> @Colin: os-prober uses util-linux's logger for its output.
> Is there a way to save them in the /mnt chroot?
> We should maybe include more systemd in stage2 and use it for logs and save
> them at end. WDYT?

That would certainly be nice. In an ideal world everything would go to the journal (with appropriate metadata) and then we could display the logs on tty2/3 etc. simply by running a journalctl -f instance there with appropriate filtering... we'd get nice colour output and everything. One to look at for MGA6 for sure :)

(In reply to Thierry Vignaud from comment #43)
> In such case, can you compare /dev/sd* & /mnt/dev/sd*?

They look identical, including the timestamps and file permissions

brw------- root     root          8, 0 Fri May 29 17:19 /mnt/dev/sda
brw------- root     root          8, 1 Fri May 29 17:19 /mnt/dev/sda1
brw------- root     root         8, 10 Fri May 29 17:19 /mnt/dev/sda10
brw------- root     root          8, 2 Fri May 29 17:19 /mnt/dev/sda2
brw------- root     root          8, 5 Fri May 29 17:19 /mnt/dev/sda5
brw------- root     root          8, 6 Fri May 29 17:19 /mnt/dev/sda6
brw------- root     root          8, 7 Fri May 29 17:19 /mnt/dev/sda7
brw------- root     root          8, 8 Fri May 29 17:19 /mnt/dev/sda8
brw------- root     root          8, 9 Fri May 29 17:19 /mnt/dev/sda9
brw------- root     root         8, 16 Fri May 29 17:17 /mnt/dev/sdb
brw------- root     root         8, 17 Fri May 29 17:17 /mnt/dev/sdb1

(only remove "/mnt" for /dev/sd*, of course)

Keywords: NEEDINFO => (none)

added to errata
https://wiki.mageia.org/en/Mageia_5_Errata#Grub2_ignores_other_Mageia_installs_when_installing_to_a_freshly_created_partition

Whiteboard: 5final FOR_ERRATA => 5final IN_ERRATA

(In reply to Marja van Waes from comment #46)

Is not update-grub enough? 

I can't think why grub2-install would be needed - also specifying /dev/sda is dangerous for non-tech users as they may not be using sda.

Indeed.

You're right, just grub2-install is enough

(In reply to Marja van Waes from comment #49)
> You're right, just grub2-install is enough

s/grub2-install/update-grub2/

@marja
I made a minor edit as update-grub can be run as user and asks for root password.

Also the update-grub2 symlink was added for compatibility with some other distros who's users are used to it, however update-grub is more generic and in line with upstream.

Maybe we should just refer to 'update-grub' in docs to avoid confusion?

Thanks for all your work and testing on this one!

Barry

(In reply to Barry Jackson from comment #51)
> @marja
> I made a minor edit as update-grub can be run as user and asks for root
> password.

That's fine, thanks :-)
> 
> Also the update-grub2 symlink was added for compatibility with some other
> distros who's users are used to it, however update-grub is more generic and
> in line with upstream.

Ah, didn't know that
> 
> Maybe we should just refer to 'update-grub' in docs to avoid confusion?

Sounds reasonable, CC'ing docteam.

(However, I might keep using update-grub2, to avoid ending up running grub-install one day, when I really want to run grub2-install)

> 
> Thanks for all your work and testing on this one!
> 

Np, I wish I had come with more useful information that helps understand what causes this bug.

CC: (none) => doc-bugs

(In reply to Marja van Waes from comment #52)
> (In reply to Barry Jackson from comment #51)

> > Maybe we should just refer to 'update-grub' in docs to avoid confusion?
> 
> Sounds reasonable, CC'ing docteam.
> 
> (However, I might keep using update-grub2, to avoid ending up running
> grub-install one day, when I really want to run grub2-install)
> 

Well, yes that's a good point.

Maybe we should only refer to update-grub2 since all our grub2 tools use the grub2-* format. It would make sense. 

As regards my 'upstream' comment - that was not strictly correct. update-grub is not a grub2 thing at all, but a Debian tool.

We can really use whichever we want and on reflection I think update-grub2 is more in line with the other tools. Maybe it should have been 'grub2-update' - but better not go there just now ;)

Feel free to decide with doc team and change docs accordingly.

I did a minimal install *without* X earlier today, after deleting three former /, /home and swap partitions and letting diskdrake auto-allocate the free space.

To my suprise, the other Mageia installs were added to the grub2 boot menu.

see attachment 6687 [details] 

* update-grub2 logs: mesg: ttyname() is mislukt: Ongepaste ioctl() voor apparaat
Generating grub configuration file ...
Gevonden thema: /boot/grub2/themes/maggy/theme.txt
Linux-afbeelding is gevonden: /boot/vmlinuz-desktop
Initiële RAM-schijfafbeelding is gevonden: /boot/initrd-desktop.img
Linux-afbeelding is gevonden: /boot/vmlinuz-3.19.8-desktop-2.mga5
Initiële RAM-schijfafbeelding is gevonden: /boot/initrd-3.19.8-desktop-2.mga5.img
grub2-probe: fout: Kan geen GRUB-schijf vinden voor /dev/sdc1.  Controleer uw 'device.map'..
Windows 7 (loader) is gevonden op /dev/sda1
Windows 7 (loader) is gevonden op /dev/sda2
Mageia 5 (5) is gevonden op /dev/sda5
Mageia 5 (5) is gevonden op /dev/sda8
voltooid

I don't think the grub2-probe error has anything to do with the success: on an earlier install today the sdc device (with boot.iso on it) was the same as here, except it was maybe sdb then, but then I did a minimal install with X, after which the other Mageia's weren't detected as usual

now, on a different laptop where I hit the issue before, with an XFCE install from the 32bit (QA-final) DVD, I don't hit it either.

I'll remove it from the errata, but leave this report open for any others who might hit the issue.

Whiteboard: 5final IN_ERRATA => (none)

another proof that X or no X has nothing to do with it.

another minimal install without X (DrakX v16.103, all packages on local mirror up-to-date), and it occurred again.

Summary: Grub2 in installer doesn't add existing Mageia installs to boot menu when the new install is on a newly created partition or partitions => Grub2 in installer sometimes fails to add existing Mageia installs to boot menu when the new install is on new partition(s)

Still valid?

Keywords: (none) => NEEDINFO
Source RPM: drakx-installer-stage2 os-prober => os-prober

(In reply to Thierry Vignaud from comment #57)
> Still valid?

Assuming it is fixed.

I wiped two windows 7 partitions and replaced them with 3 partitions (/, swap and /home) for Mageia 6sta1.

After reboot, the already existing cauldron and Mga5 partitions are listed fine in the Grub2 boot menu.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED