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; }
commit 8c68a70170b31f93c287f29fd06c6c17edaf19ad
*** Bug 953094 has been marked as a duplicate of this bug. ***
http://cgit.freedesktop.org/systemd/systemd/commit/?id=fc6e6d245ee3989c222a2a8cc82a33475f9922f3 cgit.freedesktop.org/systemd/systemd/commit/?id=aea275c43194b6ac519ef907b62c5c995050fde0
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!
Did you report this to the upstream s390x maintainers?
Here: http://marc.info/?l=linux-s390&m=136629064229958&w=2
(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
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.
Thanks, our contacts in IBM are informed about the issue both via CC here and via direct email.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=bdd29249a882e599e5e365536372d08dee398cd4
systemd-202-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/systemd-202-2.fc19
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).
proposed s390 upstream kernel abi fix: http://marc.info/?l=linux-s390&m=136663315121464&w=2
systemd-202-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/systemd-202-3.fc19
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).
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.