Bug 29237

Summary:	failure to mount (cifs) NAS units following the update to Mga8
Product:	Mageia	Reporter:	Rod Goslin <rod>
Component:	Release (media or process)	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED INVALID	QA Contact:
Severity:	major
Priority:	Normal	CC:	davidwhodgins, sysadmin-bugs
Version:	8
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	Mga8 update from Mga7	CVE:
Status comment:

Description Rod Goslin 2021-07-07 23:42:18 CEST

Description of problem:

Version-Release number of selected component (if applicable): Mga8 updated from mha7

How reproducible:reproducible on boot-up and on a manual mount command

Steps to Reproduce:
1.re-boot the machine
2.In a terminal execute command mount -av
3.there is a response "unable to apply new capability set"

I recently purchased a Lenovo Think Station for the purpose, mainly, for the evaluation of the SSD which was the machines storage medium. To that end, I installed a fairly minimumal set of applications. However, since my LAN, through Drobo NAS units provides most of my data storage, mounting these units was of some importance. Under Mga7, I experienced no problems in mounting these Drobo units, and all worked well, at all times, as I had expected. The entries in /etc/fstab, and associated credential files are ones that I have used, unchanged on most of my installs on a variety of machines, for a number of years. Always without problems. However, on completing the Mga8 update, there was a total failure to mount any of the NAS units in fstab, either on boot-up, or manually, as root with the mount command. This problem has never happened before, and I am at a loss as to how to resolve it. I could begin again, with a clean install of Mga8, but this is somehat long-winded in the sharing aspect, since, as far as I can surmise. MCC functionality of SMB shares is still broken, and requires a totally manual editing of the fstab and associated files for a working solution to mounting external drives. I have been doing this through many versions, and have submitted bug reports on the subject, without result. I would stress that all was satisfactory right up to the apparently successful update to Mga8, and total failure thereafter.

Comment 1 Rod Goslin 2021-07-07 23:44:12 CEST

I have submitted this to the Mageia Forum, with the usual negative response.

Comment 2 Dave Hodgins 2021-07-08 00:39:29 CEST

Please open one terminal and (as root) run "journalctl --no-hostname -b -f",
then in another terminal run the "mount -av" command, then copy/paste the
journal entries here.

CC: (none) => davidwhodgins

Comment 3 Rod Goslin 2021-07-08 01:47:02 CEST

Dave, I'm afraid, that I have to offer an apology. As you suggested, I went back to the machine with the the suggestion that you had offered, but when it came to the mount -av command it worked completely. The machine was still running as when I gave up on attempts to mount the NAS units. Nothing had changed, but the command now worked. I had previously tried re-booting several times and applying the manual mount command far more times without success. Why the command now worked, I have no idea. I subsequently tried a re-boot, but that failed to mount the NAS units, but this was not unpecedented. When not used for a while, the NAS units (Drobo) tend to go into hibernation, and take some time to spin-up and become active. Seemingly, the boot progress has by that time moved on and the mount fails. This has been the case for a number of years, and it's a quick measure to simply log-in as root, in a terminal and manually mount the NAS units, which always works. Again, why in this case it did not work, giving the noted error message, I've no idea.
I shall be pursuing the completion of the build on this machine. Particulary since I note that Konqueror, my by far, favourite File Manager, has at last re-acquired it's sidebar, the loss of which has seen me retaining  Mga5, rather than upgrading to a deficient KDE environment.
Thank you for you very prompt attention to this problem. I'm very impressed and pleased with the response.

Cheers, Rod Goslin

Comment 4 Dave Hodgins 2021-07-08 02:30:28 CEST

Thanks for the update. Stuff happens, especially with networking. :-)
Closing as invalid.

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