The suggested size for Linux partition leaves the Chrome OS partition too small to use

[mrjohnc]

I have a Chromebook iwith 128GB ssd (Lenovo C630), when I use chrx it suggests 107gb is used for Gallium/Ubuntu/Fedora which seems reasonable, however if I accept this and try to use the Chrome partition it doesn't really work well at all, can't install apps, complains about lack of storage etc. I know this is easy to learn to give it a larger partition but it adds a whole other layer of complexity to installation (you end up having to do it twice with a recovery in the middle).

Would it be possible to suggest a few gb more for the ChromeOS partition on chromebooks with larger drives? I'm not sure if its calculating the number as a percentage of the drive size or a set number gb to give the ChromeOS partition.

Thanks

[reynhout]

Default ChromeOS size is "minimum + 1GB". This was chosen in the early days of 16GB devices (where ChromeOS required a minimum of 6GB) and not really revisited since.

Something like this might make sense:

storage device size	default ChromeOS partition size
< 32GB	min + 1GB
> 32GB	min + 4GB
> 64GB	min + 8GB

[mrjohnc]

Yes that would work for my case

[cuvtixo]

That's really strange because for several years Chromebooks and Chromeboxes were put out with 4GB. Unless Google is deliberately putting out did messages in their latest OS, you should not be having this trouble. I guess you're reinforcing my commitment to never buy the newer Chromebooks, so sorry for the lack of assistance.

[reynhout]

@cuvtixo We're talking disk/SSD/eMMC storage, not RAM.

Chromebooks with 4GB RAM are still common. 8GB and 16GB are available also.

[cuvtixo]

@cuvtixo We're talking disk/SSD/eMMC storage, not RAM.

Chromebooks with 4GB RAM are still common. 8GB and 16GB are available also.

Oh, right. I should never post on Friday nights. My brain was frazzled. ...and I guess I might as well consider another Chromebook then! ;)

[RedPCat]

I have a Chromebook iwith 128GB ssd (Lenovo C630), when I use chrx it suggests 107gb is used for Gallium/Ubuntu/Fedora which seems reasonable, however if I accept this and try to use the Chrome partition it doesn't really work well at all, can't install apps, complains about lack of storage etc. I know this is easy to learn to give it a larger partition but it adds a whole other layer of complexity to installation (you end up having to do it twice with a recovery in the middle).

Would it be possible to suggest a few gb more for the ChromeOS partition on chromebooks with larger drives? I'm not sure if its calculating the number as a percentage of the drive size or a set number gb to give the ChromeOS partition.

Thanks

Same thing happened to me on a Chromebook with 16GB of storage. It took 12GB for Linux and 4GB for Chrome OS

[mrjohnc]

One additional issue this causes which I have experienced which could really be a problem; the suggested partition size is so small that even when you uninstall everything you can ChromeOS still doesn't have enough space to create a recovery USB to restore the firmware.

I've had an issue where Gallium would not boot and I could not fix it because I couldn't start from scratch because I forgot to make a recovery USB before I started. I was able to make one on a second laptop but not everyone is fortunate enough to have multiple laptops.

[dragon788]

There is a way to make the recovery USB even if you have only a gig or two free, but it is tricky, you have to be in Developer Mode and download the Linux recovery script and do some editing on the fly.

With the advent of the Play Store and Linux apps I definitely think increasing the suggestion for ChromeOS makes sense, maybe 10GB+ at the very least, if not 50% until the target disk is over 64GB.

[mrjohnc]

There is a way to make the recovery USB even if you have only a gig or two free, but it is tricky, you have to be in Developer Mode and download the Linux recovery script and do some editing on the fly.

With the advent of the Play Store and Linux apps I definitely think increasing the suggestion for ChromeOS makes sense, maybe 10GB+ at the very least, if not 50% until the target disk is over 64GB.

Please could you point to instructions for making the recovery USB the fiddly way? I'm sure it would be very helpful for people in a pickle like I was (I could not find instructions anywhere).

I don't think 50% is a good idea as a default suggestion, it depends on the use case. Maybe there could be a bit of documentation giving use cases with storage suggestions

[dragon788]

Before resorting to these drastic measures, you should verify that you have NO other option, because these are definitely tricky at times. Places to start are opening Settings (Alt+Shift+S) and searching "Play" and disabling Android apps to give yourself a couple gigs back (on phones this can be 4GB-8GB, on a Chromebook likely less since it doesn't need all the bits for calling and texting but still likely 2-6GB). You can also search for Linux apps and disable/uninstall that if it is enabled to get a few gigs back.

If your back is up against the wall because you assumed (yeah, makes an ...) that Chrx had accounted for the explosion of space required by ChromeOS (never mind the Play Store and Linux apps) and you have discovered you were wrong and your footgun has gone off, you may be able to survive.

There are a couple ways to pull this off, the easiest is if you have ~2-3 GB available when you do a df -h /tmp, but if you don't and your system has 4GB (or more) of RAM you might be able to do a RAM disk, otherwise you will need one (or two) USB drives or microSD cards 4GB+ in size. The Chrome Recovery Tool will typically fail if you don't have approximately 3x the size of the recovery zip available because it needs to download the zip, store it in /tmp, extract the bin image, then write the image to USB. On a pretty new Chromebook that supports the Play Store and Linux apps (and Parallels for ChromeOS) the recovery zip is 1.3GB and the extracted file is 2.6GB. On an "old" Chromebook from 2015 that supports the Play Store and Linux apps the recovery zip itself is 1.1GB and the extracted bin file is 2.2GB. It seems that most of the images end up around 2.2GB unpacked except the newest systems, but the zip sizes range from ~600 to 1.3GB that I've seen for systems I own (some out of support).

The Chromebook Support page for Recovery has a link to the script we are modifying. https://support.google.com/chromebook/answer/1080595?hl=en

Expand 'Use a Linux computer' and download the linux_recovery.sh to the Downloads folder. If you are in Developer Mode you can use the Crosh shell to run shell and then cd Downloads and cp linux_recovery.sh /tmp then cd /tmp. We want to be in /tmp because this is where the script will put the files by default, but if you don't have enough room there you can do a fun switcheroo with your USB drive by formatting it FAT32, then using WORKDIR=/media/removable/YOURUSBNAME bash linux_recovery.sh which will download and unpack the recovery zip to the USB drive, then you can copy the bin somewhere visible from the Files app and write it to the USB yourself using the Chrome Recovery Tool and the "Use local image" option from the gear menu (or you could try your luck with dd from the command line).

You can't run the script unmodified because it looks for the unzip binary, but we can do a really fun trick thanks to some other tools Google has left for us and since it is a pretty safe bet that any Linux system (including ChromeOS) usually has some version of Python available so you can probably run these "upgrades" on most Linux systems as well.

You will need to remove one reference to unzip in the extern list (string list of utilities required) under require_utils() and add a new unzip() function (which I think fits logically by the roundup() function in the "Helper functions for the config file and image zipfile" block).

Here's the unzip() that I use:

# Use python to extract image instead of requiring user to install unzip
# Why doesn't it use destfile you ask? Python doesn't support requesting only a specific file,
# it would create the second argument as a directory instead and put the file in it if it wasn't . aka current directory
unzip() {
  local recoveryzip
  recoveryzip="$1"
  local destpath
  destpath="$2"
  python -m zipfile -e $recoveryzip $WORKDIR
}

You could use vi to edit the script or open it in Text in ChromeOS, or just run these commands to modify the script in the Crosh shell without needing another editor. You'll want to copy this whole code block and cd /tmp where your linux_recovery.sh should have been copied if you followed the directions above, and then paste this with Ctrl+Shift+V at the chronos@localhost /tmp $ prompt

grep -q 'unzip()' linux_recovery.sh && echo "unzip() function found" || echo "No unzip() function yet, updating script" && sed -i -e '/# Helper functions to handle the config file and image zipfile/a\
unzip() {\
  local recoveryzip\
  recoveryzip="\$1"\
  local destfile\
  destfile="\$2"\
  python -m zipfile -e \$recoveryzip $WORKDIR
}\
' -e 's/umount unzip wc/umount wc/' linux_recovery.sh

Now that we have a ChromeOS compatible script, there are a couple paths we can take, depending on how much free space you have.

If you have just enough for the recovery image zip file, you can download it using the script and it is OK if it fails during the extraction, because you should be able to move the zip file from /tmp to somewhere that Files or the Chrome Recovery Tool can access, and you can write the image directly to the USB without needing to unzip it (I believe the Recovery Tool has the ability to stream and write the file without unpacking it first).

If you really don't have any available space on the disk, you'll want to use a tmpfs RAM disk of ~1.5GB to hold the recovery zip, and mount that path somewhere that the Files app will be able to see it so you can use the Chrome Recovery Tool to write it.

If you don't have enough space or RAM to tmpfs for the recovery zip OR the bin, you'll need a USB drive that you can reformat using the Files app to act as a temporary working directory, but if you only have 1 USB drive you'll need to try and use a tmpfs RAM disk to hold the zip or bin file since you obviously can't read from the USB drive while it is being overwritten by the tool.

WORKDIR=/media/removable/YOURUSBNAME bash linux_recovery.sh

[mrjohnc]

Before resorting to these drastic measures, you should verify that you have NO other option, because these are definitely tricky at times. Places to start are opening Settings (Alt+Shift+S) and searching "Play" and disabling Android apps to give yourself a couple gigs back (on phones this can be 4GB-8GB, on a Chromebook likely less since it doesn't need all the bits for calling and texting but still likely 2-6GB). You can also search for Linux apps and disable/uninstall that if it is enabled to get a few gigs back.

If your back is up against the wall because you assumed (yeah, makes an ...) that Chrx had accounted for the explosion of space required by ChromeOS (never mind the Play Store and Linux apps) and you have discovered you were wrong and your footgun has gone off, you may be able to survive.

There are a couple ways to pull this off, the easiest is if you have ~2-3 GB available when you do a df -h /tmp, but if you don't and your system has 4GB (or more) of RAM you might be able to do a RAM disk, otherwise you will need one (or two) USB drives or microSD cards 4GB+ in size. The Chrome Recovery Tool will typically fail if you don't have approximately 3x the size of the recovery zip available because it needs to download the zip, store it in /tmp, extract the bin image, then write the image to USB. On a pretty new Chromebook that supports the Play Store and Linux apps (and Parallels for ChromeOS) the recovery zip is 1.3GB and the extracted file is 2.6GB. On an "old" Chromebook from 2015 that supports the Play Store and Linux apps the recovery zip itself is 1.1GB and the extracted bin file is 2.2GB. It seems that most of the images end up around 2.2GB unpacked except the newest systems, but the zip sizes range from ~600 to 1.3GB that I've seen for systems I own (some out of support).

The Chromebook Support page for Recovery has a link to the script we are modifying. https://support.google.com/chromebook/answer/1080595?hl=en

Expand 'Use a Linux computer' and download the linux_recovery.sh to the Downloads folder. If you are in Developer Mode you can use the Crosh shell to run shell and then cd Downloads and cp linux_recovery.sh /tmp then cd /tmp. We want to be in /tmp because this is where the script will put the files by default, but if you don't have enough room there you can do a fun switcheroo with your USB drive by formatting it FAT32, then using WORKDIR=/media/removable/YOURUSBNAME bash linux_recovery.sh which will download and unpack the recovery zip to the USB drive, then you can copy the bin somewhere visible from the Files app and write it to the USB yourself using the Chrome Recovery Tool and the "Use local image" option from the gear menu (or you could try your luck with dd from the command line).

You can't run the script unmodified because it looks for the unzip binary, but we can do a really fun trick thanks to some other tools Google has left for us and since it is a pretty safe bet that any Linux system (including ChromeOS) usually has some version of Python available so you can probably run these "upgrades" on most Linux systems as well.

You will need to remove one reference to unzip in the extern list (string list of utilities required) under require_utils() and add a new unzip() function (which I think fits logically by the roundup() function in the "Helper functions for the config file and image zipfile" block).

Here's the unzip() that I use:

# Use python to extract image instead of requiring user to install unzip
# Why doesn't it use destfile you ask? Python doesn't support requesting only a specific file,
# it would create the second argument as a directory instead and put the file in it if it wasn't . aka current directory
unzip() {
  local recoveryzip
  recoveryzip="$1"
  local destpath
  destpath="$2"
  python -m zipfile -e $recoveryzip $WORKDIR
}

You could use vi to edit the script or open it in Text in ChromeOS, or just run these commands to modify the script in the Crosh shell without needing another editor. You'll want to copy this whole code block and cd /tmp where your linux_recovery.sh should have been copied if you followed the directions above, and then paste this with Ctrl+Shift+V at the chronos@localhost /tmp $ prompt

grep -q 'unzip()' linux_recovery.sh && echo "unzip() function found" || echo "No unzip() function yet, updating script" && sed -i -e '/# Helper functions to handle the config file and image zipfile/a\
unzip() {\
  local recoveryzip\
  recoveryzip="\$1"\
  local destfile\
  destfile="\$2"\
  python -m zipfile -e \$recoveryzip $WORKDIR
}\
' -e 's/umount unzip wc/umount wc/' linux_recovery.sh

Now that we have a ChromeOS compatible script, there are a couple paths we can take, depending on how much free space you have.

If you have just enough for the recovery image zip file, you can download it using the script and it is OK if it fails during the extraction, because you should be able to move the zip file from /tmp to somewhere that Files or the Chrome Recovery Tool can access, and you can write the image directly to the USB without needing to unzip it (I believe the Recovery Tool has the ability to stream and write the file without unpacking it first).

If you really don't have any available space on the disk, you'll want to use a tmpfs RAM disk of ~1.5GB to hold the recovery zip, and mount that path somewhere that the Files app will be able to see it so you can use the Chrome Recovery Tool to write it.

If you don't have enough space or RAM to tmpfs for the recovery zip OR the bin, you'll need a USB drive that you can reformat using the Files app to act as a temporary working directory, but if you only have 1 USB drive you'll need to try and use a tmpfs RAM disk to hold the zip or bin file since you obviously can't read from the USB drive while it is being overwritten by the tool.

WORKDIR=/media/removable/YOURUSBNAME bash linux_recovery.sh

Thank you very much for writing this, I hope it helps someone in a pickle.

[dragon788]

It was good to get it written down, since I'd done it once quite a while ago, and I ended up discovering several bugs and oddities in the script, so I'll be publishing one with a few fixes soon, and maybe some additional improvements.

[mrjohnc]

It was good to get it written down, since I'd done it once quite a while ago, and I ended up discovering several bugs and oddities in the script, so I'll be publishing one with a few fixes soon, and maybe some additional improvements.

I wonder where would be best to put it, its a great resource to have if you're in that situation

[dragon788]

I forked the Google "repo" where the recovery script seemed to live, though interestingly the version there does NOT match the one you get when downloading the linux_recovery.sh linked in the Chromebook Support Recovery page.

I updated the script in the linux folder using the one downloaded from Google support but with my fixes for running it from a Crosh shell on ChromeOS (and probably ChromiumOS aka CloudReady).

https://github.com/ComputerPhreaks/chromiumos_user-recovery-tools/blob/master/linux/recovery.sh

I'll probably be making some more improvements to the script as there were a couple strange behaviors I ran into when running the script repeatedly for different Chromebook models that I think could be improved upon.

[mrjohnc]

I forked the Google "repo" where the recovery script seemed to live, though interestingly the version there does NOT match the one you get when downloading the linux_recovery.sh linked in the Chromebook Support Recovery page.

I updated the script in the linux folder using the one downloaded from Google support but with my fixes for running it from a Crosh shell on ChromeOS (and probably ChromiumOS aka CloudReady).

https://github.com/ComputerPhreaks/chromiumos_user-recovery-tools/blob/master/linux/recovery.sh

I'll probably be making some more improvements to the script as there were a couple strange behaviors I ran into when running the script repeatedly for different Chromebook models that I think could be improved upon.

Wonderful