Bug 717794 - systemd fails to boot if you use tmpfs
Summary: systemd fails to boot if you use tmpfs
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-29 21:35 UTC by d. johnson
Modified: 2012-12-23 00:36 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-06-07 14:54:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg from boot with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg" (148.06 KB, text/plain)
2011-06-30 02:14 UTC, d. johnson
no flags Details
/etc/fstab file after kluding it to work (926 bytes, text/plain)
2012-01-12 17:39 UTC, d. johnson
no flags Details

Description d. johnson 2011-06-29 21:35:14 UTC
Description of problem:

Adding tmpfs lines in /etc/fstab results in your system not booting with systemd.

Version-Release number of selected component (if applicable):

systemd-26-5.fc15.i686


How reproducible:

100%


Steps to Reproduce:
1. Add tmpfs mount point in /etc/fstab
2. Reboot.
3. ...

  
Actual results:

Systemd fails to boot, instead asking for root's password for recovery.


Expected results:

It should boot.

Additionally, /tmp should be a 500M tmpfs mount.


Additional info:

WORKS:

# mkdir /tmp/f
# mount -o size=500M,nr_inodes=1k,mode=1777,nosuid,nodev,fscontext=system_u:object_r:tmp_t:s0 -t tmpfs tmpfs /tmp/f
# ls -Zd /tmp/f
drwxrwxrwt. root root staff_u:object_r:tmp_t:s0        /tmp/f/


FAILS:

in /etc/fstab:
tmpfs                   /tmp                    tmpfs   size=500M,nr_inodes=1k,mode=1777,nosuid,nodev,fscontext=system_u:object_r:tmp_t:s0 


FAILS 2:

# cat /etc/systemd/system/tmp.mount 
[Unit]
Description=/tmp Directory
Before=local-fs.target

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=size=500M,nr_inodes=1k,mode=1777,nosuid,nodev,fscontext=system_u:object_r:tmp_t:s0


# systemctl reload tmp.mount
[ 1156.611069] EXT4-fs (sdb2): Unrecognized mount option "size=500M" or missing value

Comment 1 d. johnson 2011-06-30 02:14:36 UTC
Created attachment 510563 [details]
dmesg from boot with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg"

boot with "log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg"
mount -o remount,rw /
dmesg output attached.

[    7.114072] systemd[1]: Child 291 died (code=exited, status=32/n/a)
[    7.115071] systemd[1]: tmp.mount mount process exited, code=exited status=32

Suggestions on where to look next welcome.

Comment 2 Michal Schmidt 2011-06-30 11:31:00 UTC
A couple of suggestions:
 - add "StandardOutput=kmsg" to the tmp.mount unit file
 - boot with "enforcing=0"
See if there's some more information from mount in the dmesg then.

Comment 3 d. johnson 2011-07-02 21:34:58 UTC
Booting with "enforcing=0" did not help.  I will add StandardOutput=kmsg as well to see if it makes any difference.

Is there some shortcut to all those?

StandardOutput=kmsg log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg

Is a tad long for reboots just to enable logging.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 4 Michal Schmidt 2011-07-02 22:54:27 UTC
I usually keep them in my grub.conf.

Comment 5 d. johnson 2011-07-07 20:12:51 UTC
booting with enforcing=0 or selinux=0 makes no difference at all.

same messages generated.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 6 Michal Schmidt 2011-07-09 14:02:07 UTC
Have the line in /etc/fstab. Reboot (no special parameters needed this time). When you get the maintenance prompt, give the root password. Run "/bin/mount /tmp". Do you get an error?

Comment 7 d. johnson 2011-07-29 03:35:39 UTC
mounted fine manually.

automount process started by systemd went nuts however.

# df -h | wc -l
32786

no way to repair short of another reboot.  loadave was above 6 simply due to automount subsystem.




-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 8 Jóhann B. Guðmundsson 2011-08-05 17:27:56 UTC
Hum I'm unable to duplicate this with a test.mount unit.. 

# mkdir 'p /test

# cat /lib/systemd/system/test.mount
[Unit]
Description=/test TMPFS Directory
Before=local-fs.target

[Mount]
What=tmpfs
Where=/test
Type=tmpfs
Options=size=500M,nr_inodes=1k,mode=1777,nosuid,nodev,fscontext=system_u:object_r:tmp_t:s0

# systemctl start test.mount && systemctl status test.mount && df -h | grep test
test.mount - /test TMPFS Directory
	  Loaded: loaded (/lib/systemd/system/test.mount)
	  Active: active (mounted) since Fri, 05 Aug 2011 17:02:44 +0000; 25ms ago
	   Where: /test
	    What: tmpfs
	 Process: 32700 ExecMount=/bin/mount tmpfs /test -t tmpfs -o size=500M,nr_inodes=1k,mode=1777,nosuid,nodev,fscontext=system_u:object_r:tmp_t:s0 (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/test.mount
tmpfs                 500M     0  500M   0% /test

Works for me wondering if this is somehow related to the /tmp directory? 

d.johnson can you duplicate this with a simple test directory ?

Comment 9 Fedora Admin XMLRPC Client 2011-10-20 16:28:25 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 d. johnson 2012-01-12 17:03:36 UTC
Adding to /etc/fstab directly, and removing the unit created above makes a different error appear.

"Starting File System Check on /test aborted because of a dependency failed.
Starting /test aborted because a dependency failed.
Starting Relabel of all filesystems, if necessary aborted because a dependency failed.
Starting Mark the need to relabel after reboot aborted because a dependency failed.
Welcome to emergency mode.  Use "systemctl default" or ^D to activate default module.
Give root password for maintenance"

And then refuses root password.

Also fails on f16.

commenting this fstab line out makes it boot normally again.




-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 11 Michal Schmidt 2012-01-12 17:22:48 UTC
Could you please put the whole fstab here as an attachment?

Comment 12 d. johnson 2012-01-12 17:39:03 UTC
Created attachment 552452 [details]
/etc/fstab file after kluding it to work

Retained entry in /etc/fstab, but appended the option "noauto".  Then added a
mount statement to rc.local.  Boots normally now, but this is an extremely
hackish solution.

Moved mountpoint to /var/lib/mock, so that it is useful.

Comment 13 Michal Schmidt 2012-01-12 17:50:31 UTC
Why "2 2" for the tmpfs? Try changing it to "0 0" so that fsck is not attempted on it.

Comment 14 d. johnson 2012-01-12 20:15:01 UTC
Removed "noauto" and replaced "2 2" with "0 0".  Reboot.

The tmpfs mount point was not mounted, but mounts fine manually or from rc.local.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 15 Kay Sievers 2012-01-12 20:17:56 UTC
Hmm, I have:
  tmpfs  /tmp      tmpfs   defaults    0 0

which works totally fine.

Comment 16 Michal Schmidt 2012-01-13 11:24:59 UTC
(In reply to comment #14)
> The tmpfs mount point was not mounted

Did it just silently skip the mount and booted otherwise normally, or did you get dropped into the emergency shell again?

What did "systemctl status var-lib-mock.mount" say?

Was there anything logged from mount in dmesg or /var/log/messages?

Comment 17 d. johnson 2012-01-30 00:03:23 UTC
Silently skipped, but does mount fine from rc.local or from command prompt post-bootup.  Nothing really noteworthy in dmesg or messages.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 18 Michal Schmidt 2012-01-30 10:42:26 UTC
Please update systemd to the latest version from updates-testing and capture a new debug log with it (booting with "log_buf_len=1M systemd.log_level=debug
systemd.log_target=kmsg", then saving the output of dmesg).

Comment 19 Michal Schmidt 2012-06-07 14:54:56 UTC
tmpfs works fine for other users. The requested log has not been provided. Closing.

Comment 20 Sebastien Pasche 2012-12-05 16:27:13 UTC
Hello, I am experimenting the same bug :/

How can I provide more data to help your to resolve this ?

Comment 21 Sebastien Pasche 2012-12-05 16:28:31 UTC
I will create a VM to try to run with the correct argument to make the logs asked on comment 19 :)


Note You need to log in before you can comment on or make changes to this bug.