sys-boot/vboot-utils provides /usr/bin/crossystem. In order for crossystem to read data (at least on my C201), the program /usr/sbin/mosys is expected to exist (it is hardcoded in host/lib/crossystem.c around line 32). Mosys is not in portage, however (nor is the flashmap library, which mosys depends upon). If the correct course of action is to provide these programs in portage, they may be found at https://chromium.googlesource.com/chromiumos/platform/mosys/ and https://chromium.googlesource.com/chromiumos/third_party/flashmap/ respectively (the versions hosted on https://github.com/dhendrix/ are out of date and unusable). Ebuilds used in the Chromium OS tree may be found at https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/sys-apps/mosys/mosys-9999.ebuild and https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/sys-apps/flashmap/flashmap-9999.ebuild respectively. These programs need some minor patching before compiling (at least on a C201 using musl). In case they are useful for reference, I have placed sys-apps/flashmap and sys-boot/vboot-utils in http://repo.or.cz/sgilles-overlay.git (many aspects of the ebuilds are probably quite wrong, but they compile and allow crossystem to work). Reproducible: Always Steps to Reproduce: 1. Install Gentoo on an Asus C201 (or some other suitable CrOS device - I'm not sure which ones) 2. Install sys-boot/vboot-utils 3. Run `crossystem' as root Actual Results: Stderr is filled with `waitpid() or mosys error' lines. Many fields show only the value `(error)' Expected Results: There should be nothing printed to stderr, or two lines regarding FDT properties. No values should show (error). The hardware for reproduction might be a bit specific. I will try to test any patches, etc., provided I don't brick the device in the meantime.
I've experienced the same bug (I need it for Acer CB5-311). I've put my ebuilds to https://github.com/doughdemon/felix-overlay (didn't know about the ones from chromeos). We have identical musl fixes. flashmap is dual licensed. One license is GPL-2, the other looked like BSD to me. The flashmap description is stolen from you. sys-boot/vboot-utils has many other tools, which do not depend on mosys. Maybe it is worth looking into adding a use flag for sys-boot/vboot-utils controlling whether crossystem is shipped or not.
fixes to the projects themselves should be sent to the respective upstreams. not having the ebuilds in the Gentoo tree now doesn't prevent that from happening sooner.
That seems reasonable. Felix's patches seem superior to mine (I've tested them on my system) and limit the change to one package, so I'd prefer that those be submitted.
I've improved the patches and view them now as suitable for upstream. However I'm a bit put off by the setup required to get the patch to gerrit... So I would be very grateful if someone else could send them (maybe further improved) upstream.
The mosys patches are now upstream.
I see that we have 2 choices for flashmap: https://chromium.googlesource.com/chromiumos/third_party/flashmap/ https://github.com/dhendrix/flashmap They are identical except for the PRESUBMIT.cfg file added here: https://chromium.googlesource.com/chromiumos/third_party/flashmap/+/73aa0babd88c3693423c368a079b1aba5c83f8bf
Yeah, at the time I submitted the original report, dhendrix's mirrors on Github were several years out of date and (IIRC) didn't compile. It seems that's changed, however, and that both https://github.com/dhendrix/flashmap and https://github.com/dhendrix/mosys are being kept up to date (mosys a bit less so). Using those repos seems to work fine.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=725dfd42472b9daefacb0e56589227578cbea9d8 commit 725dfd42472b9daefacb0e56589227578cbea9d8 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2025-05-30 16:19:31 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2025-05-31 09:15:07 +0000 profiles: Mask sys-boot/vboot-utils for removal Bug: https://bugs.gentoo.org/590616 Bug: https://bugs.gentoo.org/625122 Bug: https://bugs.gentoo.org/675726 Bug: https://bugs.gentoo.org/721504 Bug: https://bugs.gentoo.org/833111 Bug: https://bugs.gentoo.org/875593 Bug: https://bugs.gentoo.org/937435 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+)
This package is essential for updating kernels on systems with depthcarge firmware. Please reconsider.
Zac, what alternative(s) can we refer users of vboot-utils to?
(In reply to Nick Bowler from comment #9) > This package is essential for updating kernels on systems with depthcarge > firmware. > > Please reconsider. Okay, I've added a fresh vboot-utils-138_p20250522 ebuild here so that we can continue to support depthcharge firmware: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=342785cfd5fdb34dd5eb741370dc3d79fecd310e (In reply to Andreas Sturmlechner from comment #10) > Zac, what alternative(s) can we refer users of vboot-utils to? Since there is no alternative, I've opted to resurrect the vboot-utils ebuild. I've dropped the old vboot-utils-80_p20200108 ebuild so that you are free to remove static-libs support from libzip: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b193699daf3ad6dea5092998cc1312eba321dd86
