Created attachment 752 [details]
ddebug.log

When I made this bug report, I didn't know that I should add /root/drakx/report.bug.gz. I don't have that file anymore, but I do still have ddbug.log1, install.log1 and stage1.log1, all from the day I installed Mageia rc.

I'll attach them

Created attachment 753 [details]
install.log

Created attachment 754 [details]
stage1.log

Today I wanted to see whether there is any difference between rc and Mageia, so I used the free space on Windows D for a second Mageia install, first I started with Mageia rc, I stopped when in the partitioning screen, then I installed Mageia 1 official.

I had already noticed, after installing rc in May, that the restore partition seemed to have shrunk, but I hadn't noticed yet that the free space of that partition had become an empty partition, size 949 MB, running from cylinder 30280 to 30400

Installer still checks the box before the worst option: to use this free space for install, there is no difference between Mageia 1 rc and Mageia 1 official in this respect.

This doesn't happen on 4 other systems with a rescue partition that we own, it only occurs with this ThinkPad SL510

and of course I started from the beginning, when installing Mageia 1 official ;)

If the later logfiles I uploaded don't show the original situation (before the free space on the recovery partition was converted into a very small empty partition), than I think this bug should be treated the same as bug 2610.

@ pterjan

Please set status to ASSIGNED or, if for work flow reasons you can't do that, put OK on the whiteboard instead.

Is there any additional information you'd like to have? I didn't install Mga2a2 on this laptop yet, but I don't mind doing that if that would help.

@ pterjan

I was going to offer you to make a copy of that recovery partition, while in Brussels, in case you need more information about such partitions to be able to tell installer to ignore them.

But did I corrupt it when adding the 1 GB that was taken from it?
It now has (according to diskdrake):

Volume label: Lenovo_Recovery
<snip>
Type: NTFS-3G
Size: 11GB (5%)

I don't understand the 5% after adding 1GB of empty space to a filled-to-the-brim partition.

Anyway, if you don't need it, I'll probably only take my old laptop with me.

It looks like I mixed up diskdrake percentages with df ones. In df the % means used space, and apparently diskdrake talks about available space. And the empty space I added back was a bit less than 1 GB, that brings it closer to that 5%.

No, that's 5% of your hard disk

Closing as old because I can't test whether this bug is still valid, this system runs 24/7

Besides, not one newbie reported having this issue and getting confused by it.

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

(In reply to Marja van Waes from comment #11)
> Closing as old because I can't test whether this bug is still valid, this
> system runs 24/7
> 
> Besides, not one newbie reported having this issue and getting confused by
> it.

Well, it is still valid, I justed started to test using free space on a windows partition, to see whether bug 15589 is valid on non-gpt disks, too.

However, the doPartitionDisk screen shows the little free space on the recovery partition as chosen to install Mageia to, instead of the ample amount of free space on the main windows partition.

So I continued with custom partitioning, instead.

I'll attach screenhots of the doPartitionDisk screen + new report.bug.xz after finishing install

Status: RESOLVED => REOPENED
Resolution: OLD => (none)
Source RPM: drakx-installer-stage2-13.53 => drakx-installer-stage2-16.78 or 16.79
Whiteboard: (none) => 5RC

Created attachment 6215 [details]
report.bug.xz with DrakX v. 16.79

Attachment 752 is obsolete: 0 => 1
Attachment 753 is obsolete: 0 => 1
Attachment 754 is obsolete: 0 => 1

Created attachment 6216 [details]
screenshot of free space on rescue partition selected

Created attachment 6217 [details]
only 2,9GB on a 7,2GB partition selected (screenshot)

I have also reported this same problem as part of:
https://bugs.mageia.org/show_bug.cgi?id=15482
(UEFI installer makes bad partition choices with "use free space" option)

CC: (none) => zen25000

Maybe installer just selects the windows partition on the highest partition number?

This morning, when I installed to a system with the rescue partition on sda1, installer selected the correct partition (sda2 in this case).

(In reply to Marja van Waes from comment #17)
> Maybe installer just selects the windows partition on the highest partition
> number?
> 
> This morning, when I installed to a system with the rescue partition on
> sda1, installer selected the correct partition (sda2 in this case).

report.bug.xz for this _correct_ selection is attachment 6226 [details] of bug 15663

(In reply to Marja van Waes from comment #17)
> Maybe installer just selects the windows partition on the highest partition
> number?
> 

If so, then not with Live installer (KDE LiveDVD  from april 10 2015): there the normal windows partition was chosen

(which is on a partiton with a lower partition number)

Reading the code:

1/ Partitions get ignored if after resizing there will not be enough space to install (650MB)
2/ The installer computes the suggested new size ($part->{req_size}) for each window partition. That means removing 10% of the windows partition, up to 6G, or less if there is not enough space.
3/ The installer selects the one with the largest $part->{req_size}, which means the one where windows will have most space left if selecting default resizing.

If you have one 100G partition with 1G free and one 50G partition with 40G free, we will select the first one as req_size will be 99G vs 44G for the second one.

We probably want to use the one with most space that can be used instead ($part->{size} - $part->{min_win}).

I might misunderstand 
> 2/ The installer computes the suggested new size ($part->{req_size}) for each
> window partition. That means removing 10% of the windows partition, up to 6G,
> or less if there is not enough space.
https://bugs.mageia.org/attachment.cgi?id=6217
2,9GB of a 7,2GB rescue partition got selected
the windows partition was 286,7GB At least 186,7 GB, but probably over 200GB had been Mageia 4 and Mageia cauldron partitions that were re-added to the windows partition before install.... so at least 186,7 GB was unused space on a windows partition.

Or does, what is shown in the doPartitionDisks screen, no longer reflect which windows partition will be resized (and how much)?

How much time would it take to probe how much free space is really available on a windows partition _before_ the doPartitionDisks screen shows the options?

On a different system, with text installer, I found that the probing is only done afterwards. I deliberately agreed with the default there to resize a huge windows partition to only a few MBs, to see what would happen. Only then was the probing started, it errored out, because windows needed more space than that.

cc'ing lebarhon, because this is also about bug 15589

CC: (none) => lebarhon

(In reply to Marja van Waes from comment #12)
> However, the doPartitionDisk screen shows the little free space on the
> recovery partition as chosen to install Mageia to, instead of the ample
> amount of free space on the main windows partition.

Your recovery partition isn't detected as such b/c it uses a regular NTFS. partition type

Created attachment 6255 [details]
detect Lenovo recovery as such

this should help

Created attachment 6256 [details]
we should ignore ESP too for that matter...

(In reply to Marja van Waes from comment #22)
> I might misunderstand 
> > 2/ The installer computes the suggested new size ($part->{req_size}) for each
> > window partition. That means removing 10% of the windows partition, up to 6G,
> > or less if there is not enough space.
> https://bugs.mageia.org/attachment.cgi?id=6217

Wow that's bad, we should not to scroll and there are ugly separators between partitions. I can't see the one to resize on the screenshot.

> 2,9GB of a 7,2GB rescue partition got selected
> the windows partition was 286,7GB At least 186,7 GB, but probably over 200GB
> had been Mageia 4 and Mageia cauldron partitions that were re-added to the
> windows partition before install.... so at least 186,7 GB was unused space
> on a windows partition.

That is strange, it should have selected the large, even if it had less space than the samll one.

> Or does, what is shown in the doPartitionDisks screen, no longer reflect
> which windows partition will be resized (and how much)?
>
> How much time would it take to probe how much free space is really available
> on a windows partition _before_ the doPartitionDisks screen shows the
> options?

The partitioning wizard uses the space that will really be available after resize.

I believe text mode is different and just gives you the list of partitions to select from, without sorting them inany way or checking how much they can be shrunked.
 
> On a different system, with text installer, I found that the probing is only
> done afterwards. I deliberately agreed with the default there to resize a
> huge windows partition to only a few MBs, to see what would happen. Only
> then was the probing started, it errored out, because windows needed more
> space than that.
> 
> cc'ing lebarhon, because this is also about bug 15589

Thanks, Thierry, this  bug is fixed :-)

now really closing

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

Bug still valid with Mageia-5-RC-LiveDVD-KDE4-i586-DVD round 8

(In reply to André DESMOTTES from comment #29)
> Bug still valid with Mageia-5-RC-LiveDVD-KDE4-i586-DVD round 8

pterjan's fixes are included in round 9

If that doesn't fix bug 15589 for you, then please reopen that report.

If you are talking about a not correctly identified recovery partition: please reopen this report if that's a Lenovo_Recovery partition. 

If it's a recovery partition with a different label, then please tell which label it has.

Summary: installer chooses too little free space on wrong partition => installer chooses too little free space on wrong partition (on the recovery partition)