parted missing

[westerman]

This is on an Acer chromebook 11 but might affect other new models. From what I can read on the 'net 'parted' is no longer bundled in Chrome and instead '/usr/sbin/partx' is to be used. I believe that this lack of 'parted' will only pop up if partitioning a removable drive -- USB or SD.

[reynhout]

Thank you for the report, I will get it fixed soon!

[reynhout]

A question for you -- your device is the Acer Chromebook 11 C740 (Broadwell, hardware ID PAINE), right? Not the Acer Chromebook 11 (CB3-111) (Bay Trail, hwid GNAWTY), right?

Did you have to flash the firmware before installing?

Thanks again!

[westerman]

No flashing. Just into dev mode, get network running, then into VT2.

As per chrx/go:

Hardware ID: GNAWTY_C2A-ESN-Q21 Model: Acer Chromebook 11 (CB3-111) / C730 Released: 2014 CPU family: Intel Bay Trail

A find / -name 'parted' 2>/dev/null shows nothing Same only with 'partx' shows /usr/sbin/partx

Thanks for the fix. I am about to sign out of email for a while thus will not be able to give any more responses for a while.

On 11/19/2015 4:45 PM, reynhout wrote:

A question for you -- your device is the Acer Chromebook 11 C740 (Broadwell, hardware ID PAINE), right? Not the Acer Chromebook 11 (CB3-111) (Bay Trail, hwid GNAWTY), right?

Did you have to flash the firmware before installing?

Thanks again!

— Reply to this email directly or view it on GitHub https://github.com/reynhout/chrx/issues/4#issuecomment-158207242.

Rick Westerman westerman@purdue.edu

Bioinformatics specialist at the Genomics Facility. Phone: (765) 494-0505 FAX: (765) 496-7255 Department of Horticulture and Landscape Architecture 625 Agriculture Mall Drive West Lafayette, IN 47907-2010 Physically located in room S049, WSLR building

[reynhout]

Much appreciated.

[reynhout]

Oops, autoclosed by my commit message.

This should fix the issue you're seeing, but I expect you'll run into another issue when trying to boot.

GNAWTY is Bay Trail, which does not have legacy boot capability in the stock firmware. I think you will need to flash your firmware to run any Linux distro. See https://johnlewis.ie/custom-chromebook-firmware/rom-download/ for more info.

If you're up for some experimentation, please do give it a try before flashing, and let me know how things go. I'd love to hear that my understanding is wrong...but be aware that you might have a few more steps in front of you.

Thank you again!

[westerman]

The new chrx does not have a problem with parted being missing. Thanks for the fix.

However I am running out of room when trying to do an install of galliumos onto an SD card. It seems like chrx is writing to /tmp and to /var which, on my system, is less than 1.5 GB. The chromebook has 2 GB SDRAM (16 GB flash). /tmp should map to the 2 GB and I think /var may do so as well via VT2. At about 50% of the download files then /tmp and /var gets full.

I have tried several ways to get around this limitation. Unfortunately chrx does not have a command line option as to where to put the install files and it seems like the shell variables are hard-wired into install programs so I have been changing the install scripts. My latest venture is to change CHRX_INSTALL_ROOT to point to a USB drive but I think I have manged to royally screw up the script since the files are now being downloaded but not able to be permission changed properly. That problem maybe my screwup or just a problem of installing from USB. I am letting it run (it takes a while to download the files) but do not have high hopes.

Basically the USB stick is mounted called something like "Removable USB" (with space) and the install scripts do not have quotes, for the most part, around the $CHRX_INSTALL_ROOT, so I had to do a bunch of insertions of quotes. In retrospect I should have made a symlink without spaces and used that. Will try that if the current process fails.

I might also go to just wiping out ChromeOS and installing Gallium directly.

On 11/19/2015 10:05 PM, reynhout wrote:

Oops, autoclosed by my commit message.

This should fix the issue you're seeing, but I expect you'll run into another issue when trying to boot.

GNAWTY is Bay Trail, which does not have legacy boot capability in the stock firmware. I think you will need to flash your firmware to run any Linux distro. See https://johnlewis.ie/custom-chromebook-firmware/rom-download/ for more info.

If you're up for some experimentation, please do give it a try before flashing, and let me know how things go. I'd love to hear that my understanding is wrong...but be aware that you might have a few more steps in front of you.

Thank you again!

— Reply to this email directly or view it on GitHub https://github.com/reynhout/chrx/issues/4#issuecomment-158265716.

Rick Westerman westerman@purdue.edu

Bioinformatics specialist at the Genomics Facility. Phone: (765) 494-0505 FAX: (765) 496-7255 Department of Horticulture and Landscape Architecture 625 Agriculture Mall Drive West Lafayette, IN 47907-2010 Physically located in room S049, WSLR building

[reynhout]

Interesting. Yes, chrx does write to hardcoded paths in /tmp and /var/cache. And I don't quote those variables everywhere because I "know" that they will be safe.

The initial core image download isn't actually saved directly to disk, it's piped to tar which extracts it inside /tmp/chrxroot.. The filesystem mounted at /tmp/chrxroot is the target device partition for the new OS -- you should have plenty of space there.

But the core image is about 1GB for GalliumOS. I think that's the problem. curl buffers the file in memory if the pipe isn't ready to consume it. Very large files (1GB probably counts) and very fast network connections (does this apply?) plus relatively slow media (SD card) might fill up the buffers, then zram, possibly swap to disk, and create a cascade of failures.

The other OSes that chrx can install have much smaller core image files. While I've installed GalliumOS dozens of times without problems, it's possible that my net connection (theoretically 50Mb/s, but I get ~20Mb/s) just hasn't overwhelmed my Acer C720's internal SSD.

Does that sound plausible to you? How fast is your net connection?

We can test the idea by adding an option to curl to limit the download rate. You can add it to line 599 of chrx-install, or I can create a dev build for you if that's easier.

I think we should try --limit-rate 1m. That's 1 megabyte per second, or 8 megabits per second. It'll take about 20 mins to download the GalliumOS core image at that rate, if I've done the math right.

Let me know if I can make a dev build. If that's not the problem, there are a few other things we can try.

Thanks!

[westerman]

My internet connection is fast -- I am doing this at work (during my spare time) at a major US university -- but the download speeds are slow enough (it takes about an hour) that I just can't imagine I am outracing the SD. After reading your message -- if I have it correct -- about how the new file system on the SD is mounted as /tmp/chrxroot my feeling is that the new file system is not being correctly mounted and so instead of something like:

ln -s SD_partition /tmp/chrxroot

The command fails and the real "/tmp" is being used with the consequence that it gets filled up.

During the past hour while I was talking to one of my users the install finished. So I am looking into how successful the install was. I can not boot up into Gallium but I think that is the firmware issue you mentioned earlier. I'll give that a try and then, if the OS wasn't installed, I can try out your test and/or double check on the status of the new file system.

Thanks for the help, -- Rick

On 11/20/2015 2:02 PM, reynhout wrote:

Interesting. Yes, chrx does write to hardcoded paths in /tmp and /var/cache. And I don't quote those variables everywhere because I "know" that they will be safe.

The initial core image download isn't actually saved directly to disk, it's piped to tar which extracts it inside /tmp/chrxroot.. The filesystem mounted at /tmp/chrxroot is the target device partition for the new OS -- you should have plenty of space there.

But the core image is about 1GB for GalliumOS. I think that's the problem. curl buffers the file in memory if the pipe isn't ready to consume it. Very large files (1GB probably counts) and very fast network connections (does this apply?) plus relatively slow media (SD card) might fill up the buffers, then zram, possibly swap to disk, and create a cascade of failures.

The other OSes that chrx can install have much smaller core image files. While I've installed GalliumOS dozens of times without problems, it's possible that my net connection (theoretically 50Mb/s, but I get ~20Mb/s) just hasn't overwhelmed my Acer C720's internal SSD.

Does that sound plausible to you? How fast is your net connection?

We can test the idea by adding an option to curl to limit the download rate. You can add it to line 599 of chrx-install, or I can create a dev build for you if that's easier.

I think we should try |--limit-rate 1m|. That's 1 megabyte per second, or 8 megabits per second. It'll take about 20 mins to download the GalliumOS core image at that rate, if I've done the math right.

Let me know if I can make a dev build. If that's not the problem, there are a few other things we can try.

Thanks!

— Reply to this email directly or view it on GitHub https://github.com/reynhout/chrx/issues/4#issuecomment-158495742.

Rick Westerman westerman@purdue.edu

Bioinformatics specialist at the Genomics Facility. Phone: (765) 494-0505 FAX: (765) 496-7255 Department of Horticulture and Landscape Architecture 625 Agriculture Mall Drive West Lafayette, IN 47907-2010 Physically located in room S049, WSLR building

[westerman]

It does look like a firmware modification is needed for my Acer Baytrail. Furthermore, as per John Lewis, only the 'boot_stub' option is possible. That will lose the ability to run ChromeOS natively. So I won't be able to use chrx. :-( After the firmware mod the install that I did do with chrx is not coming up as I feared. So I'll just go with a Linux-only system from Distroshare. Thanks a bunch for your help. chrx looks to be fun project to work on.

On 11/20/2015 2:02 PM, reynhout wrote:

Interesting. Yes, chrx does write to hardcoded paths in /tmp and /var/cache. And I don't quote those variables everywhere because I "know" that they will be safe.

The initial core image download isn't actually saved directly to disk, it's piped to tar which extracts it inside /tmp/chrxroot.. The filesystem mounted at /tmp/chrxroot is the target device partition for the new OS -- you should have plenty of space there.

But the core image is about 1GB for GalliumOS. I think that's the problem. curl buffers the file in memory if the pipe isn't ready to consume it. Very large files (1GB probably counts) and very fast network connections (does this apply?) plus relatively slow media (SD card) might fill up the buffers, then zram, possibly swap to disk, and create a cascade of failures.

The other OSes that chrx can install have much smaller core image files. While I've installed GalliumOS dozens of times without problems, it's possible that my net connection (theoretically 50Mb/s, but I get ~20Mb/s) just hasn't overwhelmed my Acer C720's internal SSD.

Does that sound plausible to you? How fast is your net connection?

We can test the idea by adding an option to curl to limit the download rate. You can add it to line 599 of chrx-install, or I can create a dev build for you if that's easier.

I think we should try |--limit-rate 1m|. That's 1 megabyte per second, or 8 megabits per second. It'll take about 20 mins to download the GalliumOS core image at that rate, if I've done the math right.

Let me know if I can make a dev build. If that's not the problem, there are a few other things we can try.

Thanks!

— Reply to this email directly or view it on GitHub https://github.com/reynhout/chrx/issues/4#issuecomment-158495742.

Rick Westerman westerman@purdue.edu

Bioinformatics specialist at the Genomics Facility. Phone: (765) 494-0505 FAX: (765) 496-7255 Department of Horticulture and Landscape Architecture 625 Agriculture Mall Drive West Lafayette, IN 47907-2010 Physically located in room S049, WSLR building

[reynhout]

Yes, this is where I figured we'd end up. :)

I wish we had been able to figure out the issue you were having, but ultimately you'll need to flash your firmware anyway.

I added some error checking to make sure the mount of the new device succeeds. Hopefully that will catch any future related issues. Good luck with the GNAWTY.