# Description of problem: Online (CLI) upgrade from Mageia 4 to Mageia 5 over-wrote working /etc/exports file with a file empty of definitions. This machine is mostly used as a headless server, as a dual-core 64-bit 'muscle car', to my other motley collection of old machines, so NFS exports is central to application. Luckily I also backup system /etc configs as well as user /home data. # Version-Release number of selected component (if applicable): nfs-utils-1.3.0-6.mga5.src.rpm # How reproducible: Only need to upgrade Version 4 to 5 once, thus only appeared (a critical) once. 'rpm -qif /etc/exports' reports 'name: nfs-utils ........' So blank file is hard-coded into upgrade rpm, and will overwrite every time? I shall be doing another upgrade tomorrow on a different installation of Mageia 5 to Caldron(6) to see if same happens. # Steps to Reproduce: 1.Follow instructions near end of: https://wiki.mageia.org/en/Mageia_5_Release_Notes "Upgrading online, using urpmi (CLI)" 2. su urpmi.removemedia -a urpmi.addmedia --distrib --mirrorlist 'http://mirrors.mageia.org/api/mageia.5.x86_64.list' urpmi --replacefiles --auto-update --auto --download-all --test urpmi --replacefiles --auto-update --auto (the 'urpmi ... --download-all --test' line unnecessary to reproduce bug but I did it anyway to ensure some safety) 3. Then reboot: shutdown -r now Amazing! Everything comes back as before; including samba 'exports' tested via a Windows 7 netbook. So trouble free; but is it really running the new version? echo $MACHTYPE x86_64-mageia-linux-gnu ls -l /boot ....vmlinuz -> vmlinuz-3.19.8-desktop-3.mga5 So as far as simple checks it indeed is version 5 (Congratulations to team on their work!!) 4. However: Moving to another machine (a VIA C3 running Mageia 2, or VectorLinux 6) which previous to server upgrade was perfectly OK, with four mounted exports from server (plus a few more from a Raspberry Pi). Attempting: sudo mount [servername]:/[exported-tree] /[local-mount] -or using predefined /etc/fstab mount points: sudo mount -a -get response: 'servername:/export-tree Permission denied' # My fix, replace blank upgrade with working backup, and make NFSd reload it: su cp -vf [my-sys-backup]/etc/exports /etc/exports exportfs # Suggestions for proper fix: Remove /etc/exports from package so it cannot overwrite a good existing file. -Does NFSd (or exportfs) crash if /etc/exports not present? Or: If /etc/exports exists, backup somewhere, then restore at end of upgrade. -This should also be compatible with fresh installs to formatted partition. Or simply: Warn users to backup /etc system files AS WELL AS /home data Then give tips for restoration of some files. Or: What would be really nice would be to integrate upgrade/allow-retained-configs into a MCC sub-script module. Reproducible: Steps to Reproduce:
CC'ing all who touched nfs-utils between Mga4 and Mga5 release
CC: sysadmin-bugs => guillomovitch, luigiwalser, mageia, mageia, marja11Component: Release (media or process) => RPM Packages
Looking at the nfs-utils package, it's not apparent why it would have replaced the /etc/exports file. It shouldn't have. It's marked as %config(noreplace). Since the default one didn't change, it shouldn't have even created a .rpmnew file with the default contents. Since it's (noreplace), it shouldn't have moved the existing one to an .rpmsave file. It should have just left it alone.
(In reply to David Walser from comment #2) > Looking at the nfs-utils package, it's not apparent why it would have > replaced the /etc/exports file. It shouldn't have. It's marked as > %config(noreplace). Since the default one didn't change, it shouldn't have > even created a .rpmnew file with the default contents. Since it's > (noreplace), it shouldn't have moved the existing one to an .rpmsave file. > It should have just left it alone. Maybe something else caused the contents of the /etc/exports file to be deleted? I don't read anything about a .rpmnew, .rpmsave or so in the description. (In reply to donald taylor from comment #0) > So blank file is hard-coded into upgrade rpm, and will overwrite every time? > I shall be doing another upgrade tomorrow on a different installation > of Mageia 5 to Caldron(6) to see if same happens. > Did it, Donald? If so, does it still happen with an upgrade to cauldron(6)?
Keywords: (none) => NEEDINFOAssignee: bugsquad => guillomovitch
the --replacefiles option in the urpmi command line is suspicious, even if the option description in rpm man page seems quite harmless: Install the packages even if hey replace files from other, already installed, packages. I wouldn't use this kind of flag for an upgrade, especially without the evidence of a packaging issue requiring to bypass rpm integrity control mechanism. I don't have any evidence it is responsible for the configuration file overwrite, but it makes a perfect culprit here, given we can't blame systemd as usual :)
Status: NEW => ASSIGNED
No reproductible test case provided, and nobody reported a similar issue since initial submission, two years ago, hence closing.
Status: ASSIGNED => RESOLVEDResolution: (none) => OLD