Prior to F24 any addition of a mount point to /etc/fstab
resulted in the dynamic creation of that mount point on the system. This is broken in F24. You must now pre-define the mount point before enabling the new mount point entry within the /etc/fstab.
By the way, if the mount point pre-existed, it was used.
After removing that added entry from the /etc/fstab, the dynamically created mount point remained.
This has been the functionality of all Fedora versions up until Fedora 24.
Created attachment 1137265 [details]
fstab from F24 DVD version dated 16March
Description of problem:
Testing the new alpha kernel Tried to add partitions to fstab
I added three partitions to fstab as shown
# Created by anaconda on Wed Mar 16 17:13:28 2016
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
UUID=b2513f88-9fa0-487b-a1a3-2315fc1596a8 / xfs defaults,noatime 0 0
UUID=c260d1c0-1ece-41be-9290-9c345fc07d57 /boot xfs defaults,noatime 0 0
UUID=5ecc7a17-0f65-42e9-9a6c-35fd3fb338e0 /home xfs defaults,noatime 0 0
UUID=c8fb2ff4-0d3e-4497-950c-aec83c3fbb91 swap swap defaults,noatime 0 0
UUID=6e488205-8791-41c2-8043-5051f8d0b185 /scratch ext4 defaults 1 2 #/dev/sdb2
UUID=9f9d9bb3-2c94-4264-8604-1f887ee62696 /scratch2 ext4 defaults,noatime 1 2 #/dev/sdb3
UUID=e09c1a4b-142f-48e8-a538-60b27f169be2 /scratch1 ext4 defaults,noatime 1 2 #/dev/sdd2
The three additional partitions are not mountable during boot.
Attachment 1 [details] is the fstab from F24 Alpha
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 1137266 [details]
This attachment shows the fstab from Fedora 23 See comments below
The second attachment shows the fstab from Fedora23.
Note the UUIDs for /scratch, /scratch1 /scratch2.
I can mount the partitions using nautilus.
The system I am usng has 4 Linux disks (centos, fedora23 gnome, Fedora23 xfs and fedora24 /fedora 23 kde/ /dev/sda .... /dev/sde
Below is the fdisk from /scratch (/dev/sdb) It details the partition that I want mounted
Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B090B19F-46A7-4B80-9336-01AA33D1796A
Device Start End Sectors Size Type
/dev/sdb1 2048 4095 2048 1M BIOS boot
/dev/sdb2 1314658304 1933987839 619329536 295.3G Microsoft basic data
/dev/sdb3 665522176 1314658303 649136128 309.5G Linux filesystem
/dev/sdb4 4096 1028095 1024000 500M Linux filesystem
/dev/sdb5 1028096 519440383 518412288 247.2G Linux filesystem
/dev/sdb6 519440384 624297983 104857600 50G Linux filesystem
/dev/sdb7 640815104 665522175 24707072 11.8G Linux swap
/dev/sdb8 1933987840 1953523711 19535872 9.3G Linux filesystem
/dev/sdb9 624297984 640815103 16517120 7.9G Linux swap
Partition table entries are not in disk order.
Even removing the flag on /dev/sdb2 does not change the outome.
Created attachment 1137824 [details]
Version of Fedora 24 Alpha that were evaluated
Just to show the versions of Fedora 24 Alpha that I tested.
Also tested and it failed with
Fedora-Workstation-netinst-x86_64-24_Alpha-1.5.iso = 27476c85a6f6d6f0861aa3035aa8831f23f14499ce7206c8d0e7d549afada70a
If this ever gets recognized as a bug...
Refer to attachment 2 [details] or 3
The partition for /scratch is on /dev/sdb
If, with anaconda, I have /scratch added during the disk configuration,
Then /scratch is accepted within the fstab.
if it is not setup with anaconda and
If it is a manual adddition to /etc/fstab, then on a reboot the partitio will not be mounted.
Because it is mounted if anaconda created the fstab, I suspect that the problem may be with selinux or some other new feature.
Obvious question: did you `mkdir /scratch` before attempting to add the entry to fstab? Linux doesn't create the mount point for you if you add something to the fstab; a directory must already exist in the structure.
What does "I can mount the partitions using nautilus" mean, exactly? That the entries can be mounted to /run/media?
Here is what I wrote again
/dev/sdb Fedora Remix (xfce) and the /scratch and the commented items
/dev/sdc Fedora Remix (kde) and the /scratch and the commented items
/dev/sdd Scientific Linux and the /scratch and the commented items
/dev/sde Fedora Remix Gnome and the /scratch and the commented items
The attachment 1 [details] shows the F24 /etc/fstab
The attachment 2 [details] shows the F23 /etc/fstab
What I am reporting is that pre-exisitng /scratch, /scratch1, and so forth, that are the identical UUIDs in Fedora23 versions and in Scientific Linux.
And interestingly, if I setup /scratch and some other files with F24's anaconda,
then after the reboot, they are not rejected.
/scratch is shared with 4 distributions as are some other UUIDs (see commented out lines in the F24 fstab (attachment 1 [details] or 3)
The UUIDs are the identical common ones used by the other 4 distributions. They are shared.
Anaconda handles my extra partitions for F24 if they are included therein.
I have tested with all the alphas, and when each new alpha is posted, I wipe the space I have set aside for F24 and do a new install and test.
Comment 3 shows my /scratch as /dev/sdb2.
I also removed the flag for /dev/sdb2 and there was no differences.
I am prepared to test every new alpha (even 2 per day) if I see a posting here to fetch the next text version. By the way, I test with the net install version. Email me or post responses here.
Response to question two.
The fstab refused UUIDs (eg, /scratch) are visible with F24 Nautilus and I can mount that parttion using Nautilus.
When mounted, it's a suddirectory of /run/media/leslie/ and all files on that partition are available R/W
When I first create my user, on my initial logon I run the following script
if [ $UID != 1000 ]; then
echo "You are not authorized to use this script"
DIRS="bin Documents Development Documents Downloads Music Pictures Public Videos "
for var in $DIRS
ln -s /scratch/$var $var
echo ln -s /scratch scratch
ls -l ~
What I have on /scratch is the $DIRS files. Thus, no matter which other distribution I boot, my Documents, Development, etc are common.
Not related to this Bug, I have worked with SUSE to debug their os-prober. Their os-prober allows /boot to be on a btrfs subvolume. My /boot is a xfs partition. I don't know if F24's os-prober includes their patches.
I have many ideas for simple but useful anaconda improvement patches.
Can you attach a copy of the output of:
sudo journalctl -b -l
to this bug? That should show why it's not liking those entries. I am wondering if it's the # comments you have at the end of lines. 'man 5 fstab' says "Lines starting with '#' are comments" but doesn't say you can use # at the end of lines.
I just tested with
Fedora-Workstation-netinst-x86_64-24_Alpha-1.7.iso 2016-03-22 20:07 454M
and the problem persists
I can do a manual mount of the /dev/sdb2
A manual mount does not (to my knowledge) use the UUID
I will retry with the journal -b -l again
Kevin RE fstab with comments at end of line have worked since Core
I have and I am and was using it with F20,21,22,23. and F24 without problems.
I also tested without the EOL comments and experienced the same problem.
Lets see if I can get you the journal, as during the boot process I enter root (as opposed to ctl-D), I comment out the
UUID for /scratch. When I reviewed the journal myself, I saw nothing. I think it means that the issue I tackle did not get recorded.
I must exit for 4 hrs. When I return I will attach what I can from the journal.
If you have a second disk on your system, duplicate what I did,
Install on /dev/sdx and after booting, add a formatted partition from /dev/sdy
(on the same drive and a partition from a separate drive).
Other info: I am testing with REAL hardware, not VM, with 64bit system on a dual core system having 8gigs ram.
Created attachment 1139747 [details]
In case you can view this journal file with some viewer.
I can't seem to no, it doesn't load for me here. ;(
Created attachment 1139749 [details]
The most recent F24 fstab with /scratch commented out
Created attachment 1139750 [details]
The journal file after reboot
This is the journal file that I created when the boot process told me it could not mount the /scratch As a reminder, the /scratch UUID has been verified and matches the F23 fstab example shown
Created attachment 1139751 [details]
Journalctl after rebooting and asking for -1 version
journalctl -b -1 -l
Created attachment 1139752 [details]
Journalctl -b -l (with /scratch commented out
Mar 23 20:44:56 F24Alpha.Mar23 systemd: scratch.mount: Failed to check directory /scratch: No such file or directory
Mar 23 20:44:56 F24Alpha.Mar23 systemd: Mounting /scratch...
Mar 23 20:44:56 F24Alpha.Mar23 audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=emergency comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 23 20:44:56 F24Alpha.Mar23 mount: mount: mount point /scratch does not exist
Mar 23 20:44:56 F24Alpha.Mar23 systemd: Starting Show Plymouth Boot Screen...
Mar 23 20:44:56 F24Alpha.Mar23 systemd: Stopped target Emergency Mode.
Mar 23 20:44:56 F24Alpha.Mar23 systemd: Stopping Emergency Shell...
Mar 23 20:44:56 F24Alpha.Mar23 systemd: Stopped Emergency Shell.
Mar 23 20:44:56 F24Alpha.Mar23 systemd: scratch.mount: Mount process exited, code=exited status=32
Mar 23 20:44:56 F24Alpha.Mar23 systemd: Failed to mount /scratch.
Mar 23 20:44:56 F24Alpha.Mar23 systemd: Dependency failed for Local File Systems.
So indeed it seems as comment 6 suggests, the /scratch directory doesn't exist for it to mount the scratch drive/fs on.
Created attachment 1139753 [details]
journalctl -k -b -1
Man pages. Scan for scratch to investigate
As proof that there is nothing wrong with the UUID.... /scratch
[root@F24Alpha mnt]# mkdir scratch
[root@F24Alpha mnt]# mount /dev/sdb2 scratch
and I have RW access to /mnt/scratch
Created attachment 1140615 [details]
A cut and paste of fdisk, etc/fstab, and some test results
Please read the comments within this attachment,
The next attachment is a journalctl -xb
Created attachment 1140616 [details]
Journalctl -xb from F24 Alpha7
Please review along with the preceding attachment.
This is the same issue. You have to create the directory you want to mount the device on before you try and do so:
Mar 26 11:36:04 F24Alpha.Mar23 mount: mount: mount point /scratch does not exist
In comment #20, you mounted it on /mnt/scratch (which is not the same as /scratch).
Created attachment 1140617 [details]
ls /dev/disk/by-uuid/ -alh /From F23 and 2nd copy From F24 ALPHA7
The F24 UUIDS match the F23 UUIDs,
Comparing the two ls lists shows that the UUID manually inserted into the /etc/fstab is valid.
Perhaps there is confusion. /scratch exists. I proved it exists because I am able to mount it and to oen R/W.
when the /scratch UUID is added the F24 /etc/fstab, it is not recognized.
I presented proof that the UUID is the same for both F23 and F24 correct by using the above ultimate attachment.
The ultimate listing shows the same UUID value with using ls command from both F23 and F24, but I can't add it to F24 fstab as When I do, it is refected. I get Fedora 24 asking me to post journalctl -xb from F24 Alpha-7
Now I also included the fstab from F24, but in order for F24 to boot, the UUID corresponding to /scratch has to be commented out.
I also included a fstab that is in use and accepted by my F23 Fedora.
If we can not mount any partition that is shareable, between F23 and F24 (not both executing concurrently), then F24 has a blocker bug.
(In reply to Leslie Satenstein from comment #25)
Who is Ken?
> Perhaps there is confusion. /scratch exists. I proved it exists because I
> am able to mount it and to oen R/W.
But you didn't. In comment #20 you said:
> [root@F24Alpha mnt]# mkdir scratch
> [root@F24Alpha mnt]# mount /dev/sdb2 scratch
> and I have RW access to /mnt/scratch
/mnt/scratch is not /scratch
they are different directories.
[root@F24Live leslie]# cd /
[root@F24Live /]# mkdir scratch
[root@F24Live /]# mount /dev/sdb2 /scratch
[root@F24Live /]# cd /scratch
Kevin I am sorry I mistyped your name I wrote Ken instead of Kevin.
If you are in North America, we can talk on the phone and I can better explain the problem
Can you accept libreoffice.odt files or only text files?
I wanted to show that with the manual steps /scratch (my /dev/sdb2 ) gets mounted.
I have tested with Live and Network installation versions.
I showed using attachment 5 [details], that I have no error in the value of the UUID
I also showed that with Fedora23 and even with Scientific Linux, the same identical UUID line works.
Just to let you know, sha1sum on the ISOs returned OK
The self check on the USB flash versions are ok
By the way, all the partitions that are in the attachment 5 [details] listing experience the same problem. It only works with manual mounts (as shown herein) and also if for example the /sdev/sxx is setup within anaconda disk selection
(In reply to Leslie Satenstein from comment #27)
> Hi Kevin
> [root@F24Live leslie]# cd /
> [root@F24Live /]# mkdir scratch
> [root@F24Live /]# mount /dev/sdb2 /scratch
> [root@F24Live /]# cd /scratch
Yeah, but you made the /scratch dir there. If you reboot now does it mount ok from fstab? (assuming thats the installed Fedora instance)
> Kevin I am sorry I mistyped your name I wrote Ken instead of Kevin.
> If you are in North America, we can talk on the phone and I can better
> explain the problem
I'm not really a phone person.
If I'm unable to understand your issue correctly I'll bow out.
My PC config has 5 linux systems. [ partitions within [ ]below mount as UUID= for all but F24 ]
Gnome/dev-sde:/home/leslie->[/scratch, /scratch1 /Development on sdb sdc partns]
KDE /dev-sdb:/home/leslie->[/scratch, /scratch1 /Development on sdb sdc partns]
XFCE /dev-sdc:/home/leslie->[/scratch, /scratch1 /Development on sdb sdc partns]
Slin /dev/sdd: /home/leslie->[/scratch, /scratch1 /Development on sdb sdc partns]
F24 /dev/sdd: /home/leslie->[not one of above will work as UUID fstab entry ]
I Have used Centos, Suse and others at different times without any problems having those [partitions] added to the appropriate fstab.
Why do I do that? No matter which of the listed Linuxes (except F24),that I boot, I have access to one copy of my data
Here is one typical entry for one of my ~ folders
ln -s ~/Documents /scratch/Documents
What I attached was a ls command showing the UUID of each partition on my computer as attachment 5 [details], a journalctl -b -l , a journal -xb which explains part of the fstab mount problem. Look at comment 1. It shows the f24 fstab causing problems.
comment 9 is a script that I run once, on first boot, that creates soft links to /scratch
Here is what I can do from the command line. I can as root, mount each partition that the f24fstab rejects. (comment 26 example)
attachment 3 [details] is a fstab from one of my F23 systems. It shows that it and 3 other F23 systems have no problems to mount those partitions.
NOW HERE IS A WEIRD Situation. If I add some or all of those partitions while I am preparing Anaconda, those drives will be accepted all the time. But I cant manually add a fstab entry for another partition.
I hope this very entry clarifies the problem I am experiencing.
Summary, my fstab for any other release (from F20,F21,F22,F23,and third party) never encounters any rejects for a UUID line
To duplicate my problem, take a 1tb disk, divided into 2 partitions, put F24 on one partition, and make the other /scratch. After 1st boot, add the /scratch to fstab. Do not add /scratch within anaconda.
I believe that F24 has a flaw and the explanation follows.
All earlier Fedora Linux versions prior to F24 and all competing distributions allow you to put a mount point after the UUID code and to not require a matching name on the system. That name on the system is dynamically created.
NOT SO WITH F24.
With F24, the mount point following the UUID value must match a pre-existing name on the target system.
In other words, prior to F24, UUID=xxxxxxxx /scratch would dynamically create /scratch on a Linux distribution. It was not recommended to pre-create /scratch on the system
With F24 (as root) One must first
Then one can add the UUID-xxxxxxxxxxx /scratch
Which is the correct implementation? Are all distributions except F24 wrong, or is it F24 that is wrong?
My view F24 is wrong and here is why.
F24 method: Create /scratch, /scratch2 /scratch3 and then add the fstab UUID entries corresponding, everything is fine
At some point I remove the UUID entries for the /scratch2 and /scratch3
But some other person logs into the system, he could write into /scratch2 and scratch3, thinking it is his backup drives, but it is now the current folder on a partition. It is not what he intended to do and he has no clue that he is not writing to the mounted partitions.
Furthermore, If I reinstall the UUID=xxxxx /scratch2, it will mask the existing /scratch2 I could in fact have a backup failure if my backup was to /scratch2 and not the mounted physical partition that was removed from the fstab.
Two last points.
When we do an upgrade from F23 to F24 via dnf, what will be the outcome.
Thank you for tolerating my unreasonable number of comments. I did not at all the change in mount functionality.
Spelling correction for comment 32
Two last points.
When we do an upgrade from F23 to F24 via dnf, what will be the outcome?
Thank you for tolerating my unreasonable number of comments. I did not at all expect the change in mount functionality.
I have as yet, to test F23 ugrade to F24
Please ignore all comments prior to #29
We are getting close to the first Fedora 24 Beta,
Will the fix for this bug be incorporated into Fedora 24 beta?
Will it be deferred? If it is deferred
sudo dnf system-upgrade download --releasever=24
Will fail if they have a within /etc/fstab
UUID=xxxxxxxxxxxxxxxx /somedir .....
and /somedir does not pre-exist on /
Prior to F24 it is and was not a requirement to preallocate a /somedir
before the UUID=xxxxxxxxxxxxxxxx /somedir ..... was inserted into
I have tested with other distributions and they too, do not require a prior
If this return to previous practice is to be deferred, Information about requiring a folder to pre-exist should be included into the F24 release notes.
I'm being a nuisance but if you verify by checking out F23
(with no /somedir and then F24 with /nosomedir
the problem will become apparent.
I don't consider this bug to be a blocker for the kernel, but it is a blocker if you consider the upgrade with
sudo dnf system-upgrade download --releasever=24
A decision is required re F24 deviating in functionality.
With all versions of Fedora prior to F24 and other Linux systems.
if the mount point was placed into the /etc/fstab and did not exist, the system created the mount point and proceeded with the fstab mount to comple6te the boot.
When the line with the UUID was removed from the fstab,
The system created mount point remained as an empty directory
With Fedora 24,
if the mount point was placed into the /etc/fstab and the mount point did not exist on the system.
The system does not create the mount point and the boot process stalls, wanting a manual intervention, We have to enter root logon, and create the missing mount point in order for the boot to proceed
If the old way was the right way, then I am reporting a deviation of functionality as was practised as in the past.
If the new way is the correct way, then this report should be closed with "Not a Bug". If it is not a bug, then all other Fedora distributions and third party distributions (Centos, RH, etc) are in conflict.
Please review Comment 35
This issue has not been addressed.
There is a change in functionality between F24 and earlier Fedora Linux versions. If the change is permanent, please include it in the release notes.
This is still a difference between all earlier versions of Fedora and all other versions of Linux
please refer to comments 35 and 36
Was corrected before the go live