Bug 953217 - systemd does not boot to real root
Summary: systemd does not boot to real root
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd   
(Show other bugs)
Version: 19
Hardware: Unspecified Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 953094 (view as bug list)
Depends On:
Blocks: ZedoraTracker fedora19rtt
TreeView+ depends on / blocked
 
Reported: 2013-04-17 16:13 UTC by Harald Hoyer
Modified: 2013-04-27 03:11 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 953430 (view as bug list)
Environment:
Last Closed: 2013-04-27 03:11:51 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Harald Hoyer 2013-04-17 16:13:47 UTC
systemd-200

systemd-fstab-generator does not generate units from the kernel command line, because is_temporary_fs() fails to recognize RAMFS_MAGIC in statfs.f_type.

fix:

 static int is_temporary_fs(struct statfs *s) {
         assert(s);
-        return s->f_type == TMPFS_MAGIC ||
-                (long)s->f_type == (long)RAMFS_MAGIC;
+        return (unsigned) s->f_type == TMPFS_MAGIC ||
+                (unsigned) s->f_type == RAMFS_MAGIC;
 }

Comment 1 Harald Hoyer 2013-04-17 16:14:49 UTC
commit 8c68a70170b31f93c287f29fd06c6c17edaf19ad

Comment 3 Harald Hoyer 2013-04-17 16:17:53 UTC
*** Bug 953094 has been marked as a duplicate of this bug. ***

Comment 4 Harald Hoyer 2013-04-18 09:46:04 UTC
http://cgit.freedesktop.org/systemd/systemd/commit/?id=fc6e6d245ee3989c222a2a8cc82a33475f9922f3

cgit.freedesktop.org/systemd/systemd/commit/?id=aea275c43194b6ac519ef907b62c5c995050fde0

Comment 5 Kay Sievers 2013-04-18 12:41:12 UTC
The above workaround canot be shipped. This should be fixed in the kernel,
not worked around in userspace tools.

Architectures cannot use int and expect magic constants lager than INT_MAX
to work correctly. The kernel header needs to be fixed.

Even coreutils cannot handle it:
  #define RAMFS_MAGIC  0x858458f6
  # stat -f -c%t / 
  ffffffff858458f6 

  #define BTRFS_SUPER_MAGIC 0x9123683E
  # stat -f -c%t /mnt
  ffffffff9123683e

Please sort out this mess in the kernel or in glibc, systemd does not want
to work around such a broken behaviour.

Thanks!

Comment 6 Josh Boyer 2013-04-18 12:44:59 UTC
Did you report this to the upstream s390x maintainers?

Comment 7 Kay Sievers 2013-04-18 13:14:52 UTC
Here:
  http://marc.info/?l=linux-s390&m=136629064229958&w=2

Comment 8 Dan Horák 2013-04-19 10:32:43 UTC
(In reply to comment #5)
> The above workaround canot be shipped. This should be fixed in the kernel,
> not worked around in userspace tools.
> 
> Architectures cannot use int and expect magic constants lager than INT_MAX
> to work correctly. The kernel header needs to be fixed.
> 
> Even coreutils cannot handle it:
>   #define RAMFS_MAGIC  0x858458f6
>   # stat -f -c%t / 
>   ffffffff858458f6 
> 
>   #define BTRFS_SUPER_MAGIC 0x9123683E
>   # stat -f -c%t /mnt
>   ffffffff9123683e
> 
> Please sort out this mess in the kernel or in glibc, systemd does not want
> to work around such a broken behaviour.
> 
> Thanks!

I understand the correct place for the fix is kernel and glibc, but can we get a workaround in the downstream systemd package until the proper fix is proposed? It blocks further work on F-19 and RHEL-7.

Thanks, Dan

Comment 9 Kay Sievers 2013-04-19 12:03:54 UTC
It should be fixed in the headers, yes, to avoid these pretty confusing
casting issues, like we see in coreutils and have in systemd.

Glibc seems not to be directly affected, as s390 implements the interface
differently from what is documented in man 2 statfs.

In the meantime we found a sane way to work around the issue in systemd;
taking back the bug, until we ship this.

Comment 10 Dan Horák 2013-04-19 12:28:17 UTC
Thanks, our contacts in IBM are informed about the issue both via CC here and via direct email.

Comment 12 Fedora Update System 2013-04-19 12:53:32 UTC
systemd-202-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/systemd-202-2.fc19

Comment 13 Fedora Update System 2013-04-19 16:47:38 UTC
Package systemd-202-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-202-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-6070/systemd-202-2.fc19
then log in and leave karma (feedback).

Comment 14 Kay Sievers 2013-04-22 12:30:35 UTC
proposed s390 upstream kernel abi fix:
  http://marc.info/?l=linux-s390&m=136663315121464&w=2

Comment 15 Fedora Update System 2013-04-24 13:08:50 UTC
systemd-202-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/systemd-202-3.fc19

Comment 16 Fedora Update System 2013-04-24 16:33:33 UTC
Package systemd-202-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-202-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-6488/systemd-202-3.fc19
then log in and leave karma (feedback).

Comment 17 Fedora Update System 2013-04-27 03:11:58 UTC
systemd-202-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


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