| Summary: | Installer proposes mount point without drive letter (/media/win_) for FAT32 partition | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Martin Whitaker <mageia> |
| Component: | Installer | Assignee: | Thierry Vignaud <thierry.vignaud> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | Keywords: | PATCH |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
simplify (cherry-picked from mga6 branch)
map fat32 as returned by libparted to vfat |
||
|
Manuel Hiebel
2015-05-20 08:48:31 CEST
Assignee:
bugsquad =>
thierry.vignaud Created attachment 6589 [details]
simplify (cherry-picked from mga6 branch)
(needed for next patch)
Created attachment 6590 [details]
map fat32 as returned by libparted to vfat
Fixed in my local git Resolution:
(none) =>
FIXED commit 072e482acfa92d02045cf90a34c51d4d7b3f85b9
Author: Thierry Vignaud <thierry.vignaud@...>
Date: Wed May 20 02:58:47 2015 -0400
libparted: map 'fat32' to 'vfat' (mga#15987)
fix fs returned by libparted
thus fixing mount point for FAT partitions on GTP (mga#15987)
this also fix setting the proper GUID for FAT partitions on GPT
---
Commit Link:
http://gitweb.mageia.org/software/drakx/commit/?id=072e482acfa92d02045cf90a34c51d4d7b3f85b9
|
The installer (both classic and live) is correctly identifying that I have two Windows partitions, one NTFS, one FAT32. It suggests a mountpoint of /media/win_c for the first (NTFS) partition, but a mountpoint of /media/win_ for the second. This is happening because in partition_table::assign_device_numbers, the call to isnormal_Fat_or_NTFS($_) for the second partition returns false because {fstype} is set to 'fat32', but in fs::mount_point::suggest_mount_points_always the call to isnormal_Fat_or_NTFS($_) returns true because {fstype} is set to 'vfat'. This could be fixed by changing isnormal_Fat_or_NTFS() to also recognise 'fat32', but I don't think this is the right thing to do, as 'fat32' is not used anywhere else in fs::types.pm. I've not yet tracked down what is setting the fstype to 'fat32'. This behaviour is also mentioned in bug #15636, but as that bug is mostly concerned with other issues, I've started a new one. For reference, fdisk -l for my disk gives Device Start End Sectors Size Type /dev/sda1 2048 616447 614400 300M Windows recovery environment /dev/sda2 616448 821247 204800 100M EFI System /dev/sda3 821248 1083391 262144 128M Microsoft reserved /dev/sda4 1083392 202409983 201326592 96G Microsoft basic data /dev/sda5 202409984 210798591 8388608 4G Microsoft basic data /dev/sda6 210798592 244353023 33554432 16G Microsoft basic data /dev/sda7 244353024 277907455 33554432 16G Microsoft basic data /dev/sda8 277907456 286296063 8388608 4G Linux filesystem /dev/sda9 286296064 294684671 8388608 4G Microsoft basic data /dev/sda10 294684672 328239103 33554432 16G Microsoft basic data /dev/sda11 328239104 462542847 134303744 64G Microsoft basic data /dev/sda12 462542848 479320063 16777216 8G Microsoft basic data sda4 and sda5 are the two Windows partitions.