Bug 1318473

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.

More info

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.
otherwise
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.

Version tested.

Fedora-Workstation-netinst-x86_64-24-20160321.n.0.iso

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?

Hi Sephen

Here is what I wrote again

My system

/dev/sda Windows 
/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

Stephan

When I first create my user, on my initial logon I run the following script

#/bin/bash
if [ $UID != 1000 ]; then
	echo "You are not authorized to use this script"
	exit
fi
cd ~

DIRS="bin Documents Development Documents Downloads Music Pictures Public Videos " 
  cd ~
  for var in $DIRS 
  do
   rmdir ~/$var
   ln -s /scratch/$var $var
   echo ""
  done
  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.



Off topic

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]
system.journal

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

From that: 

...
Mar 23 20:44:56 F24Alpha.Mar23 systemd[1]: scratch.mount: Failed to check directory /scratch: No such file or directory
Mar 23 20:44:56 F24Alpha.Mar23 systemd[1]: Mounting /scratch...
Mar 23 20:44:56 F24Alpha.Mar23 audit[1]: 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[1033]: mount: mount point /scratch does not exist
Mar 23 20:44:56 F24Alpha.Mar23 systemd[1]: Starting Show Plymouth Boot Screen...
Mar 23 20:44:56 F24Alpha.Mar23 systemd[1]: Stopped target Emergency Mode.
Mar 23 20:44:56 F24Alpha.Mar23 systemd[1]: Stopping Emergency Shell...
Mar 23 20:44:56 F24Alpha.Mar23 systemd[1]: Stopped Emergency Shell.
Mar 23 20:44:56 F24Alpha.Mar23 systemd[1]: scratch.mount: Mount process exited, code=exited status=32
Mar 23 20:44:56 F24Alpha.Mar23 systemd[1]: Failed to mount /scratch.
Mar 23 20:44:56 F24Alpha.Mar23 systemd[1]: 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[620]: mount: mount point /scratch does not exist

mkdir /scratch 

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.

Ken
Perhaps there is confusion.  /scratch exists. I proved it exists because I am able to mount it and to oen R/W.

BUT 
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.
 
https://bugzilla.redhat.com/attachment.cgi?id=1140617-

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)
> Ken

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.

Hi Kevin

[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.

No worries. 
 
> 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.

http://forums.fedoraforum.org/showthread.php?p=1758091#post1758091

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
mkdir /scratch

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 /

A reminder
Prior to F24 it is and was not a requirement to preallocate a /somedir 
before the  UUID=xxxxxxxxxxxxxxxx /somedir  ..... was inserted into 
/etc/fstab entry 

I have tested with other distributions and they too, do not require a prior 
/somedir


Important 
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.

High vpavlin.  
vpavlin

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