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 # # /etc/fstab # 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 A Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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