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.
Is this bug still present in current cauldron?
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaud
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
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.
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 => RESOLVEDCC: (none) => marja11Resolution: (none) => INVALID
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 => REOPENEDResolution: INVALID => (none)
(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
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.
This did not happen to me in Mageia 6. I guess pterjan must have fixed it without closing this.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED