Bug 10783

Summary: [readonly=1] fstab entries created for partitions not included among user specified mount points
Product: Mageia Reporter: Felix Miata <mrmazda>
Component: InstallerAssignee: Pascal Terjan <pterjan>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Normal CC: marja11, thierry.vignaud
Version: Cauldron   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: CVE:
Status comment:

Description Felix Miata 2013-07-17 00:09:01 CEST
ML thread: https://ml.mageia.org/l/arc/dev/2013-07/msg00531.html

I always partition in advance, so always use readonly=1 to install. These installations are always to multiboot systems, most of which are not exclusively used for Linux. The non-exclusives may have any combination, in addition to Linux, of FreeDOS, PC DOS, MS DOS, OS/2, eComStation and/or Windows XP. Legacy compatible MBR code is always present. Often IBM Boot Manager is present (on a primary), in which case it is the active partition. In absence of IBM BM, Grub Legacy will be present on an active primary partition. On the non-exclusive systems, at least one FAT primary partition is always present, usually FAT16B, occasionally FAT 32. Usually there is at least one FAT logical, which may or may not be FAT32, but usually is not.

In spite all the above, Mageia's installer always creates VFAT fstab entries for every FAT partition it finds, even though its mount point selection screen doesn't even list any FAT partitions. It also creates NTFS entries for all HPFS partitions, both of which, in addition to ExFAT, are type 0x07. These unrequested fstab entries have the potential to cause the appearance of, or even real, filesystem corruption in the context of a PC DOS, MS DOS or OS/2 boot.

Except for swap, the installer, when initialized with readonly=1 on cmdline, should be creating only those fstab partition entries that necessarily result from mount point selections made in the mount point selection screen.
Comment 1 Samuel Verschelde 2015-05-17 21:14:08 CEST
Is this bug still present in current cauldron?

Keywords: (none) => NEEDINFO
CC: (none) => thierry.vignaud

Comment 2 Thierry Vignaud 2015-05-18 11:59:02 CEST
You're mistaken.
When set, the "readonly" mean it is not allowed to modify the partition table, ie there won't be a Create table.

That has nothing to do with setting mount points
Comment 3 Felix Miata 2015-05-20 01:51:39 CEST
Readonly=1 amplifies the illogic and impropriety of fstab entries being created for partitions that are unwanted or otherwise don't belong in fstab. Readonly=1 limits the presentation to the user of partitions, omitting opportunity for the user to preserve that no mount points be created for them, or to specify how he does want any mounted, if he does want any non-native partitions in fstab at all.
Comment 4 Marja Van Waes 2015-12-19 07:32:28 CET
I don't know what to do with this bug report.

From comment 3 I understand there is no bug.

I've read comment 4 over and over again, but apart from seeing the reporter isn't amused, I don't manage to see what's in there that requires this report to stay open.

Correct me if I'm wrong

Keywords: NEEDINFO => (none)
Status: NEW => RESOLVED
CC: (none) => marja11
Resolution: (none) => INVALID

Comment 5 Felix Miata 2015-12-19 07:43:10 CET
There's no good reason for mount points to be created for partitions not to be used or that would be corrupted from their use with the inappropriate mount options actually set during installation. Thierry is right that readonly=1 has nothing directly to do with mount points, but the use of readonly=1 should make it obvious that somewhere between minimal and no account of existing non-native filesystems is wanted or warranted. With readonly=1, the installer presents a list of potentially native partitions only, and it is to the content of that list that mount points should be limited.

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

Comment 6 Marja Van Waes 2015-12-20 08:38:26 CET
(In reply to Felix Miata from comment #5)
> There's no good reason for mount points to be created for partitions not to
> be used or that would be corrupted from their use with the inappropriate
> mount options actually set during installation. Thierry is right that
> readonly=1 has nothing directly to do with mount points, but the use of
> readonly=1 should make it obvious that somewhere between minimal and no
> account of existing non-native filesystems is wanted or warranted. With
> readonly=1, the installer presents a list of potentially native partitions
> only, and it is to the content of that list that mount points should be
> limited.

OK, reading this and after also having reread the description, I'm starting to get it :o)

Assigning to pterjan, since he's our diskdrake maintainer

Assignee: bugsquad => pterjan

Comment 7 Felix Miata 2016-04-27 09:54:13 CEST
No improvement as of current Cauldron. Fstab contained 13 entries, while only 3 partitions were "selected" for mounting (/, /home, usr/local, plus preselected swapspace) during "partitioning" (mount point selection) step.
Comment 8 Felix Miata 2017-10-20 04:28:11 CEST
This did not happen to me in Mageia 6. I guess pterjan must have fixed it without closing this.

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