Automount partition at boot

Thanks for reporting @Giorgio. This looks like a bug. A regression of some kind.

https://issues.openmandriva.org/show_bug.cgi?id=2628

So to work around this user needs to add the partition to file /etc/fstab. OpenMandriva by default recognizes storage devices by UUID. To find the UUID of the partition you run this command ‘sudo blkid’. On this system I already had 3 storage partition so for the newly created ntfs partiton I’ll call it “Data4”. It is located at ‘/dev/nvme0n1p16’. That is similar to something like /dev/sda16 except that the storage drive is an nvme device. Anyway the output of that command looks like this for me:

$ sudo blkid
[sudo] password for ben79: 
/dev/sda1: UUID="20fec382-4f07-40aa-b16f-97d7493e5fda" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ea18feb9-e2be-43cb-b431-ca7a5e6e094d"
/dev/sda2: UUID="c1a61bf9-5753-45f0-be3a-cab62d55ce62" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="de1f4434-1823-46e5-bf95-55a9c40ea908"
... 
/dev/nvme0n1p16: BLOCK_SIZE="512" UUID="3A6AEA22581D5FA6" TYPE="ntfs" PARTUUID="f530326b-cf0c-ed47-bce1-7b2bfbf44b7f"

So the UUID for /dev/nvme0n1p16 is 3A6AEA22581D5FA6. Now I add that to my /etc/fstab file so it looks like this:

Then reboot and the ntfs partition is mounted as Data4. This takes 2 minutes or less plus reboot time. This takes less time to do than it takes to read this post. I have done this many, many, times.

You can check if you were successful after you reboot by opening KDE Partition Manager:

Note: It would be perfectly OK for a user to use “default” option only if you have any reason to think “noatime” should not be used on your system. See options defined here.

Post-edited to simplify a little bit 2020-05-22.

All the smart kids out there will know how to create entries for all your custom partitions in Dolphin.

If it’s not clear for you sure is not easy for normal user. GUI is almost necessary to avoid big mistakes.

You are confusing something being ideal with being wrong. I published something that works, I know it works because I have tested this multiple times. Don’t see how that qualifies as being a mistake. My comment was meant to express that there may be better (or just different) options one could use. But the options used in the example are very generic.

Using a GUI may be a way to avoid mistakes but it is also a way to avoid learning.

If you absolutely have to use a GUI then ignore what I wrote.

So just to be specific about the options I used:

Default : This is a shorthand way of specifying a set of common settings: rw, suid, dev, exec, auto, nouser, and async.

Noatime: – The noatime option fully disables writing file access times to the drive every time you read a file. This works well for almost all applications, except for those that need to know if a file has been read since the last time it was modified. The write time information to a file will continue to be updated anytime the file is written to with this option enabled. This can help performance on old hardware.

These are very commonly used options for mounting partitions at boot (ie. /etc/fstab) on Linux systems. Not at all likely to cause problems.

It would be perfectly OK for a user to use “default” option only if you have any reason to think “noatime” should not be used on your system.

Half OffTopic still evergreen

it’s not always as obvious as it may seem.

1 Like

WORKAROUND for Plasma5 users
or solution for GNOME users.

as root:

dnf install gnome-disk-utility

then
again as root in terminal:

gnome-disks

Now select partition and click on partition options, now select “modification of mount options” and disable default settings and create new one, select mount at boot. Save and reboot.
Should works (at least works for me).

I installed gnome-disks and tried few days ago but:

  1. I don’t opened as root, my fault. But given that is a GUI I expect a small window asking for a root password.
  2. partition I’m interested in isn’t visible, I have to enlarge gnome disks window to see it. But is 537 GB in 1 TB disk, more than 50 % !!!

I don’t see “partition options” sorry.

Dear Rugyada this is an old subject, may be you remember …
Please note my “almost”. What I mean is that command line is wonderful but … if you forgot a comma or a an hyphen you’re stuck.
GUI limit you possibility but help you also.

Sure. But a “normal user”, perhaps coming from Windows world, cannot be forced to became an IT specialist just to use his ntfs partition.

Finally I would expect that a bug like 2628 be solved quickly not postponed to next OMLx version.

I don’t see that either in OM Lx 4.1.

No, this is so not true. I can assure you that developers and code writers make mistakes all the time. When they realize they made a mistake they correct it. No different than a mathematician or scientist making a mistake and then correcting it. Happens many times every day.

OK I’m throwing a penalty flag here. This post is more informational for other users than it is meant for @Giorgio. Anyone using Linux since Mandriva should have learned this long ago.

No one is forcing anyone to be an IT specialist to do things like this. If there is no GUI tool available to do what you want you do an internet search of the problem, find the solution, and resolve the problem in an hour or less majority of the time. This is literally copying and pasting a few commands and then copying pasting one line in one file. Rocket science? IT specialist? Balderdash.

I see newbies doing this all the time. And that includes people coming from Windows. For one thing the process is exactly what those users would do in the same circumstances in Windows.

I was a newbie just come from Windows the first time I did this myself. The fact is I can teach a 12 year old normal user coming from Windows world how to do this in 5-10 minutes. Hardly work requiring an IT guy. Normal inexperienced Linux users (even newbies) have been adding or changing things in /etc/fstab almost since the beginning of Linux in 1992.

It is easy to plan the time of other people, in this case people that are unpaid and are volunteering their time with OpenMandriva.

For the record all developers and QA team members would like to see every bug report addressed if not fixed within 24 hours. If we could it would be done. This bug after being fixed in Cooker would then require many 100’s of packages to be backported to OM Lx 4.1. We simply don’t have any people with the time to do this.

Of course, I remember very well :grin:

I could reply that you are more likely to get stuck when the only way you know how to do things is GUI.
I can assure you that I have learned more on how to solve my problems with CLI than passively rely on whatever graphic tool.

It’s just like to wait for someone to gift you with a fish, or learning how to catch your own fishes by yourself, so to say… :wink:

1 Like

Anyway it appears the issue with KDE Partition Manager is an upstream issue. This is a report against Arch Linux version:

Partition Manager doesn’t actually edit fstab

Note the report was filed 2019-09-12 about 4 1/2 before Lx 4.1 was released. So it is unfortunate that no one caught the bug sooner but that is life.

Our bug report on this: Change to mount point in KDE Partition Manager are not written to /etc/fstab

Searching better than before I found it and it works. Thanks.

openSuse has its own partition manger, as Mandrake had :sob:, but I installed KDE Partition Manager and it works, then the problem is in openMandriva. And may be in other distros.

— Comment #5 from Andrius Štikonas —

No, it’s definitely fine to report other distros. Don’t pay too much attention
to that distro combobox, it’s just distro that initial reported used but
clearly this bug is not distro specific.

Andrius is the package maintainer for KDE Partition Manager. I speculate the bug occurred when this happened. To give perspective that was over a year ago. Not all bugs are fixed rapidly even in organizations like KDE with all the developers they have. Organizations like KDE, openSUSE, and Fedora all have some bugs in existence for over a year or multiple years. So do Windows and Apple.

I keep trying to explain this. If we could fix all bugs quickly we would have already done so. Why wouldn’t we? :thinking:

1 Like

Hiya ben
Just to say I cheat MERCILESSLY, as i keep a copy of fstab on another volume, so if I have to reimage the root drive I just copy the uuid entry to the backup file, and as the rest stays the same I have a working fstab up and running in no time ( after putting in the mount points into the root partition…then it just a case of reinstalling the software used on the panel…so watchword for me is BACK IT UP or loose it.Copy the altered backup with the new UUID to /etc/fstab and away we go !!!

1 Like