Bug 953217 - systemd does not boot to real root
systemd does not boot to real root
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
: 953094 (view as bug list)
Depends On:
Blocks: ZedoraTracker fedora19rtt
  Show dependency treegraph
 
Reported: 2013-04-17 12:13 EDT by Harald Hoyer
Modified: 2013-04-26 23:11 EDT (History)
19 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Harald Hoyer 2013-04-17 12:13:47 EDT
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 12:14:49 EDT
commit 8c68a70170b31f93c287f29fd06c6c17edaf19ad
Comment 3 Harald Hoyer 2013-04-17 12:17:53 EDT
*** Bug 953094 has been marked as a duplicate of this bug. ***
Comment 4 Harald Hoyer 2013-04-18 05:46:04 EDT
http://cgit.freedesktop.org/systemd/systemd/commit/?id=fc6e6d245ee3989c222a2a8cc82a33475f9922f3

cgit.freedesktop.org/systemd/systemd/commit/?id=aea275c43194b6ac519ef907b62c5c995050fde0
Comment 5 Kay Sievers 2013-04-18 08:41:12 EDT
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 08:44:59 EDT
Did you report this to the upstream s390x maintainers?
Comment 7 Kay Sievers 2013-04-18 09:14:52 EDT
Here:
  http://marc.info/?l=linux-s390&m=136629064229958&w=2
Comment 8 Dan Horák 2013-04-19 06:32:43 EDT
(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 08:03:54 EDT
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 08:28:17 EDT
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 08:53:32 EDT
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 12:47:38 EDT
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 08:30:35 EDT
proposed s390 upstream kernel abi fix:
  http://marc.info/?l=linux-s390&m=136663315121464&w=2
Comment 15 Fedora Update System 2013-04-24 09:08:50 EDT
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 12:33:33 EDT
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-26 23:11:58 EDT
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.