After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 707192 - ostree-prepare-root fails when ostree=/path is last in cmdline
ostree-prepare-root fails when ostree=/path is last in cmdline
Status: RESOLVED FIXED
Product: ostree
Classification: Infrastructure
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: OSTree maintainer(s)
OSTree maintainer(s)
: 707312 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-08-31 18:33 UTC by Tobias Hunger
Modified: 2013-09-02 21:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
prepare-root: Fix ostree= kernel argument at end (glibc version specific?) (1.67 KB, patch)
2013-09-01 08:28 UTC, Colin Walters
none Details | Review

Description Tobias Hunger 2013-08-31 18:33:06 UTC
ostree-prepare-root fails whenever I have the ostree=/path parameter last in my kernel commandline.

It boots fine when appending *anything* manually.

The error message that gets reported claims that the ostree root could not be found, giving /path followed by a \n.

Appending anything to the kernel command line will remove the bogus \n from path and the installation boots fine.
Comment 1 Colin Walters 2013-09-01 08:28:03 UTC
Created attachment 253737 [details] [review]
prepare-root: Fix ostree= kernel argument at end (glibc version specific?)

Extracting the code for parse_ostree_cmdline() and running it on some
test input (on RHEL6.4 glibc), I can reproduce the odd behavior from
getline() where it apparently returns the size of the default malloc
buffer in the size output, and some non-zero value.

This behavior would be OK except that it breaks the logic for
stripping off the trailing newline, which in turn breaks booting
because we return "ostree=foo\n".

This has worked so far in gnome-ostree because syslinux apparently
injects initrd=/path/to/initrd as a final kernel argment.

Anyways, we don't handle NUL characters here in /proc/cmdline, so
let's just call strlen () to be safe.
Comment 2 Colin Walters 2013-09-02 21:08:07 UTC
*** Bug 707312 has been marked as a duplicate of this bug. ***