-
-
Save DennisLfromGA/6690677 to your computer and use it in GitHub Desktop.
#!/bin/sh -e | |
##!! PLEASE USE THIS SCRIPT WITH CAUTION - AND AT YOUR OWN RISK !!## | |
##!! IT HAS BEEN KNOWN TO CAUSE RESETS AND WIPE DATA ON SOME CHROMEBOXES !!## | |
APPLICATION="${0##*/}" | |
ANSWER='' | |
SUDO='' | |
USAGE=" | |
$APPLICATION [no options] | |
### A script that asks the user to make the root filesystem | |
##+ read-writable for subsequent changes and additions by the user. | |
" | |
## Exits the script with exit code $1, spitting out message $@ to stderr | |
error() { | |
local ecode="$1" | |
shift | |
echo "$*" 1>&2 | |
exit "$ecode" | |
} | |
if [ $# -gt 0 ]; then error 0 "$USAGE"; fi | |
## Check for bootcache fix ... | |
checkbootcache () { | |
ret=$(grep -iq bootcache /usr/share/vboot/bin/make_dev_ssd.sh; echo $?) | |
if [ $ret -gt 0 ]; | |
then echo "$ret: No 'bootcache' fix appplied yet. :(" | |
echo "Not safe to continue, exiting..." | |
exit $ret | |
else echo "$ret: The 'bootcache' fix has been appplied - yay. :)" | |
echo "You can now run 'rw-rootfs' safely." | |
fi | |
} | |
## Report dev_boot_legacy and dev_boot_usb flags | |
## Check and set dev_boot_signed_only flag if needed. | |
checkflags() { | |
boot="$($SUDO crossystem dev_boot_usb dev_boot_legacy dev_boot_signed_only)" | |
echo -n "## " | |
echo "$boot" | |
echo " ##" | |
# db_usb and db_legacy can be off, db_signed_only should be off. | |
echo "$boot" | { | |
read -r usb legacy signed | |
suggest='' | |
if [ "$usb" = 1 ]; then | |
echo "NOTE: USB booting <Ctrl+U> is enabled." 1>&2 | |
else | |
echo "WARNING: USB booting is disabled." 1>&2 | |
suggest="$suggest dev_boot_usb=1" | |
fi | |
if [ "$legacy" = 1 ]; then | |
echo "NOTE: Legacy booting <Ctrl+L> is enabled." 1>&2 | |
else | |
echo "WARNING: Legacy booting is disabled." 1>&2 | |
suggest="$suggest dev_boot_legacy=1" | |
fi | |
if [ -n "$suggest" ]; then | |
echo "To enable, you can use the following command: $SUDO crossystem$suggest" 1>&2 | |
sleep 3 | |
fi | |
if [ "$signed" = 1 ]; then | |
# Only disable signed booting if the user hasn't to ensure booting unverified kernels | |
echo "WARNING: Signed boot verification is enabled; disabling it to ensure booting unverified kernel." 1>&2 | |
echo "You can enable it again using: $SUDO crossystem dev_boot_signed_only=1" 1>&2 | |
$SUDO crossystem dev_boot_signed_only=0 || true | |
sleep 3 | |
else | |
echo "NOTE: Signed boot verification is disabled, you're good to go..." 1>&2 | |
fi | |
sleep 2 | |
} | |
} | |
## | |
## If we're not running as root, restart as root. | |
if [ ${UID:-$(id -u)} -ne 0 ]; then | |
echo "...elevating $USER to superuser via 'sudo'..." | |
SUDO='sudo' | |
fi | |
if $SUDO mount -i -o remount,rw / 2>/dev/null; then | |
echo "*** $(mount | grep ' / ') ***" | |
error 0 "Your rootfs is already mounted read-write ..." | |
fi | |
echo -n "Perform REMOVAL of rootfs verification (Y/n/q) ? " 1>&2 | |
read ANSWER | |
case ${ANSWER:-y} in | |
[yY]*) checkbootcache | |
checkflags | |
echo | |
if grep -q CHROMEOS_RELEASE_BOARD=chromeover64 /etc/lsb-release | |
then | |
echo "...using CloudReady, disabling verity." | |
echo "$SUDO disable_verity" 1>&2 | |
$SUDO disable_verity || ret=$? || true | |
else | |
echo "$SUDO /usr/libexec/debugd/helpers/dev_features_rootfs_verification" 1>&2 | |
$SUDO /usr/libexec/debugd/helpers/dev_features_rootfs_verification || ret=$? | |
fi | |
if [ $ret -gt 0 ]; then | |
error 2 "Sorry but REMOVAL of rootfs verification failed." | |
else | |
echo | |
echo "*** Rebooting in 10 seconds to make changes effective ***" 1>&2 | |
read -t 10 -p "... ENTER 'a' TO ABORT! " GO | |
if [ -n "${GO}" ]; then error 0 "Okay, ABORTING ..."; fi | |
$SUDO reboot && exit $ret | |
fi | |
;; | |
[nN]*) error 0 "Skipping REMOVAL of rootfs verification for now..." | |
;; | |
[qQ]*) error 0 "Quitting - no changes made..." | |
;; | |
*) error 1 "Not a valid choice, exiting..." | |
;; | |
esac |
Wanted to confirm @smax48's comment - I had the same experience on a ChromeBox.
Updated the script to handle devices that end with a number (e.g. mmcblk0) - borrowed from @drinkcat - and made some other small improvements.
This should address @ezaron's device and other similar ones.
I apologize to @smax48, @craigglennie and any others where the script bombed and caused data loss.
I have just a couple of Chromebooks and haven't tested the script on all the platforms unfortunately.
Actually, I believe just running the command 'make_dev_ssd.sh' would have given the same disastrous results. I did add a warning, maybe a little too late... :-(
**##!! PLEASE USE THIS SCRIPT WITH CAUTION - AND AT YOUR OWN RISK !!##
!! IT HAS BEEN KNOWN TO CAUSE RESETS AND WIPE DATA ON SOME CHROMEBOXES !!##**
After running the script I got no errors but now how do you actually access the files for editing?
Confirmed that this script as warned definitively wipes and resets my 2015 toshiba chromebook2 . Tried twice and had to recover from backup to reload the OS :( Not sure why.
No biggy as I do run crouton with an encrypted chroot and loving it. As I'm aware this script won't be useful anyhow with an encrypted fs, thought it would be interesting to try out. At least settinng chrome to start with the last open tabs, re-opens the crhromium shell where I just need to enter shell then start my chroot
Updated script to unset 'dev_boot_signed_only' if it is set to ensure booting an unverified rootfs.
When 'dev_boot_signed_only' is set (1) and rootfs verification is removed, it has been reported to "enter in to recovery mode" as noted by some Chromebox users.
Also, it reports the status of 'dev_boot_usb' and 'dev_boot_legacy'.
@Dilbert66 does the latest version work on your Toshiba? I am not sure if mine is a 2013/2014 or 2015, It is intel, 13" FHD, 4GB. Thanks.
Hey i have a problem, whenever i use the command :
curl -Lk --connect-timeout 60 -m 300 --retry 2 "https://gist.github.com/DennisLfromGA/6690677/download" | tar -xzO > ~/Downloads/rw-rootfs
it says the following
"gzip: stdin has more than one entry--rest ignored
tar: Child returned status 2
tar: Error is not recoverable: exiting now"
and so whenever i try to do:
sudo sh ~/Downloads/rw-rootfs
The prompts never show up. i am Stuck and any help would be greatly appreciated.
@david, Sorry for the late reply.
That command 'broke' on github for some reason so I've updated it.
Try this instead:
curl -Lk --connect-timeout 60 -m 300 --retry 2 "https://gist.githubusercontent.com/DennisLfromGA/6690677/raw/7b6c0fa49e9840f5bc090b94f42537494eacc2bb/rw-rootfs" -o ~/Downloads/rw-rootfs
i know this maybe a stupid question but im kinda new to this stuff i have a samsung chromebook 3 and it runs on intel my question is "do i just copy the whole thing and paste it into crosh?"
Sorry, just now saw your question.
Yes, but in a bash shell session, not a crosh session.
I run a bunch of different checks in the script but the devs have greatly simplified this in two ways -
- After a powerwash or recovery at the first sign-in screen enable 'Debugging Features' and you'll get a r-w rootfs plus other features.
- Just run: sudo /usr/libexec/debugd/helpers/dev_features_rootfs_verification
So you have more choices now.
How you you undo this if you want to revert back to read-only after making some changes?
I'm not sure you can revert it, at least I don't know of a way short of changing channels/versions or doing a full recovery. I don't think even a powerwash will do it since it just wipes the stateful_partition.
The next time I get a chance I'll ask about it on the chromium-os-discussion forum.
EDIT:
I got a reply to my/our question about reverting the removal of rootfs verification, long story short -
if the rootfs has been modified, then practically speaking, it's not revertable.
Hey Dennis thank you very much for your script, I have been looking for a way to automatically load Linux on 30 Samsung Chrome Books
this should do it. Russ Campbell
Glad this'll work for you, that's great.
It's basically just a wrapper for /usr/libexec/debugd/helpers/dev_features_rootfs_verification
that does some pre-checks to make sure certain things are in order before it's executed.
The dev_features_rootfs_verification
script is now part of the 'Debugging Features' that you can choose on the first sign-in screen after a powerwash or recovery. The problem with enabling them that way is it's all or none, since I don't need all of those features I just run the ones I want. Here are all of the debugging features as individual scripts -
-rwxr-xr-x. 1 root root 15K Aug 29 04:01 /usr/libexec/debugd/helpers/dev_features_chrome_remote_debugging*
-rwxr-xr-x. 1 root root 35K Aug 29 04:01 /usr/libexec/debugd/helpers/dev_features_password*
-rwxr-xr-x. 1 root root 27K Aug 29 04:01 /usr/libexec/debugd/helpers/dev_features_rootfs_verification*
-rwxr-xr-x. 1 root root 31K Aug 29 04:01 /usr/libexec/debugd/helpers/dev_features_ssh*
-rwxr-xr-x. 1 root root 51K Aug 29 04:01 /usr/libexec/debugd/helpers/dev_features_usb_boot*
In addition to disabling rootfs verification I usually run the ssh & usb_boot scripts too.
Just letting you know in case you need some but not all of these too.
~Dennis
Revision #9:Updated for newer /usr/libexec/debugd/helpers/ method.
Revision #10: added CloudReady detection.
Revision https://gist.github.com/Blaisorblade/9c9e7b24407ea58bab76cd7a3dc30596/8217cacfa63b9bb8a41e85181f44b068fa330b74 (sorry, fixed URL) proposes a fix, to prevent the -gt
error:
/home/chronos/user/Downloads/rw-rootfs: line 101: [: -gt: unary operator expected
The error seems in fact harmless, but when I saw it it worried me enough to fix it. The fix is simply to ensure that ret
is always set.
Fixed, thanx.
I think this script is mostly superfluous now with the new debugd/helpers script but I'll hang on to it since it does some other checks too.
@DennisLfromGA: Cool! I used it because it's linked on https://github.com/dnschneid/crouton/wiki/Autostart-crouton-chroot-at-ChromeOS-startup — and it worked great. FWIW, that document also links to specific (and old) versions of your other gists (I used the latest versions of each piece).
@DennisLfromGA I'm afraid your last change does not fix the right problem: if you write foo || ret=$?
and then use $ret
, when commands succeed, ret
is not set; as a consequence, the if
that uses $ret
becomes syntactically incorrect.
I only added || true
to make sure that line doesn't fail when ret is false, but it's probably redundant.
Added --force option.