General mild documentation oddities rollup

Site Feedback
1

Hi, I’m following your paper to the letter as I’m replicating it on my PHASER360.

So far I have identified a few issues of varying severity, so this is a rollup of a few of them (if i find more I’ll append them here instead of opening 15 more “topics”).

This would have links to the sections but Discourse doesn’t let me.

How to find your architecture and How to find your CPU model recommend ctrl+alt+t to open “crosh”, as do some other guides.

This doesn’t do anything, and ctrl+alt+→ (not the arrow key) is required, and gets me the normal getty.

I haven’t clicked through the OOBE, so maybe this is the difference. Either way.

How to find your CPU model recommends cat /proc/cpuinfo | grep "model name". This should be grep "model name" /proc/cpuinfo.

Types of Firmware, (UEFI) Full ROM says

The (UEFI) Full ROM firmware is the best option for all users who no longer need/want to run ChromeOS (ie, want to run Linux/Windows/macOS exclusively), and who don’t mind disabling write-protection on their device.

Unclear to me what “ie” means. Was this supposed to be “(i.e., want to run)” (“id est, want to run)” (“(that is, want to run)”))?

The sections appear to have completely random casing:

Firmware

  • Supported Devices
  • Finding System Info
  • Known Issues
  • Enabling Developer Mode
  • Disabling write protect
  • Using a SuzyQable
  • Unplugging the battery
  • Types of firmware
  • Flashing Firmware
  • Updating Firmware
  • Compiling Custom Firmware
  • Flashing Manually
  • Installing Ventoy with chromeOS

idk why or what that’s supposed to mean. This also mangles ChromeOS in the last one.

2

Flashing Custom Firmware says (pt. 3):

  1. Run MrChromebox’s firmware utility script within VT-2 (ctrl + alt + f2 (right arrow)).
    • Type cd; curl -LO mrchromebox.tech/firmware-util.sh && sudo bash firmware-util.sh and press Enter.

That says

IMPORTANT

Due to recent changes in ChromeOS’ security settings, you may need to use a new set of commands to run the Firmware Utility Script under ChromeOS. Running it under Linux can use the same old one-line command.
Also, you must execute these commands as a normal/non-root user. Running them as root will break things. DO NOT RUN ‘SUDO SU’ BEFORE RUNNING THE SCRIPT CMD BELOW.
…
To download and run this script under ChromeOS or Linux, from a terminal/shell type:
cd; curl -LO mrchromebox.tech/firmware-util.sh && sudo bash firmware-util.sh
and press enter.
…
REALLY READ THIS: Under ChromeOS, starting with R117, this script must be run from a VT2 terminal (from login screen: CTRL+ALT+F2, login ‘chronos’); it cannot be run from a crosh shell (CTRL+ALT+T when logged in) due to the removal of sudo, or from a crostini (penguin) terminal; […].

So: Are you supposed to run it as root under sudo? (seems like “yes”)

Run it as root straight from login? Or are you to not do that because it’ll break your system? (unclear how this is different from running it under sudo, except that you don’t have to enable “chronos” with the special recipe from /etc/issue)

How is it gonna flash anything as non-root? (It isn’t, it errors with “run me under sudo”)

If you log in as “chronos” are you supposed to drop the sudo it specs? (No, it errors with “run me under sudo”)

Why does Chrultrabook not comment on this at all and why does it not say which user you’re supposed to log in as if it matters?

Were I not to have read the upstream page, I would’ve run it down mid as root because Chrultrabook doesn’t spec anything to the contrary. Would that have bricked my computer? Probably not, but you’re in disagreement with upstream on that front.

3

“[Flashing Firmware](Flashing Custom Firmware | Chrultrabook Docs” and “Updating Firmware” are in disagreement with the side-bar with their titles of “Flashing Custom Firmware” and “Updating Custom Firmware”.

Flashing Custom Firmware says both

TIP
If you unplugged the battery to disable write protect, you can plug it back in now. All subsequent flashing won’t require it from now on.

and

UEFI
It can take up to a minute for display to come up on first POST. Do not interrupt the first boot.

This is pretty much asking for trouble, especially given that the flasher said it won’t boot ChromeOS anymore. Maybe I’m weird, but I’m not a fan of flipping and fiddling with the laptop with a cord in and turned on, and it’s not gonna be pretty at any rate. This should IMO explicitly say “reboot now, give it a long time to POST, let it fail because it won’t boot (this is good!), then turn it off and plug the battery in”.

Also, the page uses “shutdown” as a verb, and it depends on how neologised you are, but I’d consider this an error which wants to be “shut down”.

4

That’s fair. Stop cat abuse!

That seems clear, “in example”.

Doesn’t really matter. Reason why Matt says that is most ChromeOS mountpoints have noexec flags and sadly most people aren’t very technical.
By telling them to login as chronos and escalate priviledges using sudo, it ensures that users stay within mountpoint that allows executing binaries.

You might as well just login as root, and:

mount -o remount rw /tmp
cd /tmp
curl [...]

etc.

This is different.
When you flash new SI_BIOS region, FSP needs to re-train the memory.
Until it’s done, you won’t see anything on the screen (in fact, you don’t see anything until EDK2’s GOP initializes the framebuffer).
You definitely shouldn’t interrupt it while it’s doing so, and display will come on after ~30 seconds and drop you into an UEFI shell.

5

It doesn’t because that’s not really english, just like you’d say “na przykład” instead of “w przykładzie”, you say “for example”, or you borrow exempli gratia.
The only “ie” (or “i.e.”) usage attested at all that I can find is “id est”.

I don’t know where you got this, but if you meant “e.g.” then you’ve missed the mark.

Yes, and I reproed this. But saying “reboot and play with the battery now but also don’t fucking touch it until it fully booted” is, well. Not great. Especially given that at least my laptop autoboots when you operate the lid. You are not yet done flashing until you actually let it train. This should be explicitly ordered as

DANGER
If flashing fails for UEFI, do not shutdown and immedietly attempt to restore stock firmware. Otherwise, shutdown without worry.

UEFI
If you flashed UEFI, boot the machine. It can take up to a minute for display to come up on first POST. Do not interrupt this first boot. After you boot (to an error or the EFI shell) you can safely power off or do whatever.

RW_Legacy
On the developer mode boot screen, press CTRL + L. If a selection appears, pick “Tianocore”.

TIP
If you unplugged the battery to disable write protect, you can plug it back in now. All subsequent flashing won’t require it from now on.

6

I haven’t clicked through the OOBE, so maybe this is the difference. Either way.

There is very little a typical user can do without going through the OOTB setup, and by far the most common occurrence is someone converting their existing Chromebook. You could always sign in as guest if you are ideologically opposed to signing in with a Google account. So that’s my two cents, I don’t think that part of the docs needs to be changed.

“[Flashing Firmware](Flashing Custom Firmware | Chrultrabook Docs” and “Updating Firmware” are in disagreement with the side-bar with their titles of “Flashing Custom Firmware” and “Updating Custom Firmware”.

Thanks for catching that.

7

I can’t post anything now because you’ve dubbed me a spammer. Here’s my final reply: paste .sr .ht/~nabijaczleweli/ 9cce0cbdf7a7874520cd8e3c08dde598a6c5e6be

8

I have no clue why you were marked as a spammer. Your criticism is valid.

9

Hi,
I believe you were automatically marked as a spammer by Discourse due to your large chunks of text.

I’ll take a look into the spam detection stuff, sorry for the inconvenience

10

You got flagged as a spammer because you created multiple posts with links to the same domain.

The following are automated messages generated by Discourse:

The new user nabijaczleweli tried to create multiple posts with links to docs.chrultrabook.com, 101010.pl, backports.debian.org, but those posts were blocked to avoid spam. The user is still able to create new posts that do not link to docs.chrultrabook.com, 101010.pl, backports.debian.org.

And also:

This new user tried to create multiple posts with links to the same domain. All posts from this user that include links should be reviewed.

We apologize for the inconvenience caused. The spam filters will be updated in the near future to ensure false positives like this do not happen again.

11

So: Are you supposed to run it as root under sudo? (seems like “yes”)
Run it as root straight from login? Or are you to not do that because it’ll break your system? (unclear how this is different from running it under sudo, except that you don’t have to enable “chronos” with the special recipe from /etc/issue)

you already answered this in the section you copy/pasted

Also, you must execute these commands as a normal/non-root user . Running them as root will break things. DO NOT RUN ‘SUDO SU’ BEFORE RUNNING THE SCRIPT CMD BELOW.

12

Bestie, I’m telling you this makes no sense. IF this is all about bypassing noexec, then not only does it fail because I got

firmware-util.sh: warning: firmware-util.sh: warning: script from noexec mount; see https://chromium.googlesource.com/chromiumos/docs/+/master/security/noexec_shell_scripts.md

but also this positions it as “you will brick your system if you don’t do it” and then immediately escalates to root. After telling you not to run it as root.

what are you intending to say with “DO NOT RUN ‘SUDO SU’ BEFORE RUNNING THE SCRIPT CMD BELOW.” because you’re specifically singling out sudo su, which is so esoteric there’s no reason to ever run it. is sudo -i okay? probably not

but this whole thing is completely moot because, as @elly said above, running as root is okay, and this is about noexec bypass. in that case… just say “log in as root (directly or with sudo -i), and run cd ~chronos && curl -LO mrchromebox.tech/firmware-util.sh && bash firmware-util.sh”

or, since the noexec bypass doesn’t even work, just spec “run sudo bash -c "$(curl -L mrchromebox.tech/firmware-util.sh)" or if you have broken certs then sudo bash -c "$(curl -kL mrchromebox.tech/firmware-util.sh)"” which is smaller and simpler?

and delete the whole section which, right now, goes back and forth and back and forth about running as root or not running as root

the program itself immediately changes directories, so it doesn’t matter for the program itself

but as for the text in “Flashing Custom Firmware” and “Updating Custom Firmware”, which is the distribution text this “topic” is concerned about:

  1. Run MrChromebox’s firmware utility script within VT-2 (ctrl + alt + f2 (right arrow)).
    • Type sudo bash -c "$(curl -L mrchromebox.tech/firmware-util.sh)" and press Enter.
    • If you encounter certificate related errors when downloading the script from ChromeOS, then add -k to the curl and script command to bypass SSL certificate checking as so:
      • sudo bash -c "$(curl -Lk mrchromebox.tech/firmware-util.sh)"

and

  1. Run MrChromebox’s firmware utility script.
    • In case you forgot, type sudo bash -c "$(curl -L mrchromebox.tech/firmware-util.sh)" and press Enter.

and this cleanly solves the issue and makes the whole step of setting a passphrase for some random user obsolete, and the actual way the program runs is unaffected

13

the whole reason to not run as root isn’t related to noexec, not sure where that came from; the noexec warning has been around for at least a year, and is just that - a warning (not an error). It’s to ensure that under ChromeOS, the script is downloaded to a place that the user has write permission. The chronos/crosh user has write permission in their home directory; the root user does not. It also allows the same exact command to be used under ChromeOS and Linux.

14

absent real documentation,

I cannot reproduce this on my ChromeOS, and root can write to ~chronos. Maybe MLS gets stricter in newer releases.

But that’s neither here nor there, really; if you spec sudo bash -c "$(curl -L mrchromebox.tech/firmware-util.sh)" then the same thing works under ChromeOS and Linux, regardless of the working directory, and it’s smaller, and you can delete the rest of that weird block

15

of course root can write to ~chronos, that’s not the command though is it? cd; changes to the user home dir, and works for all non-root users under both ChromeOS and Linux

no idea what you mean by ‘rest of that weird block.’ And I surely don’t want bash to execute (as sudo!) a partial, failed, or typoed curl command. It’s as bad as curl | bash which we’ve known to not do for a long time. curl && sudo bash at least has some failure handling

16

that’s not an “of course” with MLS but whatever

can root not write to its home directory? if this is all about being able to save the file, why do you explicitly spec

Also, you must execute these commands **as a normal/non-root user**. Running them as root will break things. DO NOT RUN ‘SUDO SU’ BEFORE RUNNING THE SCRIPT CMD BELOW.

what will it break? because it sure as hell looks like it wouldn’t break a thing. also, what’s sudo su doing there?

17

no, it can’t - / is mounted RO.

as before, the download will fail if you run the script commands as written, because cd; changes the working dir to / which is mounted RO.

the warning comes from YEARS of posts/emails/msgs asking why curl is failing to download the script.

18

Using ectool (or “Using Ectool”) appears to reference an ectool but doesn’t link to it, and it doesn’t appear to be distributed under that name. Is it the ectool from coreboot-utils or an internal program with the same basename?

No links again since I can’t link to docs chrultrabook com again.

19

it should be fixed now. the default settings clearly were not great lol

2 Likes