Notice: Partition migration in v90 and v91
Pinned Featured
To closer align with Chromebooks, CloudReady will be changing the partition layout from 27 partitions to 12 partitions on v90 and onward. If you are on the dev channel, we recommend backing up any locally stored files and settings such as downloads and Linux (Beta). As is always the case on the dev channel, but especially in this case, there is a possibility that unstable builds will have bugs which necessitate a reinstall.
Version v90.1 is targeted to be released in early June to the dev channel.
Comments
53 comments
-
Ilya G could you describe how these partitions will be subsumed in the update process. I have the HD split into two different operating systems with two different EFI setups on a macbook using boot option at startup to choose the particular OS. TIA
-
Tony - One of two things should happen: first there is a check to see that the partition layout matches the known good CloudReady state, if it doesn't the update will abort. Second, if the layout matches the known good state, the partitions will be renumbered and the stubs partitions removed.
-
Ilya G will extra partitions next to the installed CloudReady partitions be flagged as not a known good CloudReady state?
-
This is my disk layout, will it be an issue or can the partition resizing handle it? Ilya G
-
Here's just my 2-¢ why does it matter? [I'm no Linux Expert by any means guy's] but why would one bother or asking how or how big a partition is? All I know is Chrome OS is Linux but it is A Hard Codded Based one. That's just my 2-¢ bc CR is just meant in my Eye's just a very lightweight Chrome OS but without the Play-Store thus I know if y'all go with the Play-Store that in itself would just cause too many issues as y'all had with the Dual-Boot WiN10 and the whole vm mess
-
I have the same feeling with Linux that I do Windows, if something goes wrong, it's probably 50/50 if it can be fixed by anyone. So far with Chrome OS problems just rarely arise, it's worth losing some functionality in return for reliability.
Saying that.... V90 took three weeks extra on my Chromebook because they were updating android, now I got that upgrade and the android side is as buggy as Windows. Play store is the modern Windows. Just load it up, it looks like a toddlers arcade.
-
JCloud, I completely agree with you about the Play Store. The front page is trash. Google must be making a lot of money annoying serious users.
-
By the way, was it explained why Cloudready (Chromium OS) needs 27 partitions ? Or even why Chrome OS requires 12 ?
Disk Format - The Chromium Projects
The normal EFI boot partition, your encrypted data partition (called "stateful"), one for OEMs to put their branding without modifying Google's updates, 5 partitions that are very tiny to allow future expansion if needed without impacting data, and then lastly there's a partition for the kernel and another for the actual OS (rootfs) which gets duplicated 2 times.
That's what allows updates to be so fast, when you get an update, it's installed to the other set in the background and when you reboot, it merely flips a toggle on which one is considered "active" to boot from. Otherwise you would be stuck in a situation like Windows where you often have to wait hours unable to use your machine while it installs. You are also less likely to suffer a failed update as it can just keep booting from the active partition instead of flipping it. Combine that with the OEM partition and companies can allow their customizations without slowing down or having updates never happen like what happens on Android.
tl;dr: Chrome OS really only needs 4 partitions but has an extra 3 to allow fast & safe updates and another 5 to allow future expansion without having to possibly wipe your data. -
Thanks Brandon. People bang on about these partitions as if there will not be a logical reason for them. Those reasons basically can be said to be these partitions make Chrome OS better than Windows. Don't want these partitions? go enjoy Windows updates again :-) along with your other hobby of watching paint dry.
-
Version v90.1 is targeted to be released in early June to the dev channel
...any update...TIA
-
Forrest Smith Tony Baloney Ilya G Milou Bidwell Ely JCloud SpacePiggy Makaba Ted Larson Wade M Fralic
--POSSIBLE BUG AND IMPORTANT INFO ON SCRIPT--
Updated today. Two things, one being a possible bug. Firstly, /dev/sda13 - /dev/sda27 are left behind on the GPT table as special block devices, with size 1024Kb, and no FS. It this expected behavior. The buggy thing is that it delegates boot to the chromeos-vhd entry in syslinux, which leads to the system still thinking it has verity disabled, but without being able to mount FS as +rw. A second disable_verity followed with reboot points the bootloader to the right thing. As far as I know, updates should only change which rootfs partition it boots from NOT whether it boots from the verified or unverified cmdline. Also, my trim and defrag script that I alluded to here >> https://neverware.zendesk.com/hc/en-us/community/posts/209473198/comments/1500001175742 and wrote it because of https://neverware.zendesk.com/hc/en-us/community/posts/1500001309602-SSD-Trim-and-maintenance will be changed to reflect the new partition layout, with the old one being renamed for use on <89.x.x releases. I will tag everyone that I already tagged in these posts so that they will know about this change if they don't already, and so that they DONT use my script on a >90.x.x CrOS system before updating. If anyone wants the script with info on usage it's here >> https://github.com/Alex313031/TrImLy
-
Alexander David Frick thanks for the description!
I believe what you're seeing is buggy behavior, but we decided not to solve it since
1) it is fixed by re-running the disable_verity command
2) It only impacts the small subset of (valued!) users running with verity off
3) It only impacts devices in legacy boot mode
4) It isn't new behavior. Based on our testing, this has been happening for a couple of major version (updating from v87 > v89 shows this same thing, in our testing)
Hopefully all this makes sense and (beyond the need to re-run disable_verity after update) there's not too much disruption or inconvenience for your anyone here.
If there's more to this issue, let me know. Otherwise - enjoy the new 12-partition life ;-)
-
Forrest Smith, it is good to hear from you!!! You are missed.
Tony Baloney your patience is fulfilled.
https://www.neverware.com/blogcontent/2021/06/17/cloudready-v901-released
https://support.google.com/chrome/a/answer/7679408#90&zippy=%2Cchrome
-
My macbook 4,1 goes through the motions of downloading the update but ends with your device is up to date. var/log/messages shows this when that occurs:
2021-06-18T19:36:27.410154Z WARNING kernel: [ 409.714955] applesmc: flushed 1 bytes, last value is: 231
2021-06-18T19:36:30.263130Z NOTICE temp_logger[4880]: 00:31C
2021-06-18T19:37:30.422047Z NOTICE temp_logger[4920]: 00:31C
2021-06-18T19:38:30.547891Z NOTICE temp_logger[4966]: 00:31C
2021-06-18T19:39:06.818460Z INFO kernel: [ 569.124128] perf: interrupt took too long (4938 > 4933), lowering kernel.perf_event_max_sample_rate to 40000
2021-06-18T19:39:26.145091Z INFO kernel: [ 588.450533] EXT4-fs (sda20): mounting ext2 file system using the ext4 subsystem
2021-06-18T19:39:26.196080Z INFO kernel: [ 588.501159] EXT4-fs (sda20): mounted filesystem without journal. Opts:
chronos@localhost / $Does this give any clue to what may be going wrong?
Should I be looking at a different log file? TIA
NOTE: Sent a report at 16:57 EDT on Friday June 18
-
Forrest Smith Glad to see you back Forrest. I have a new bug to report and this one IS somewhat of a problem. Did you guys update nouveau with this release? Because although not supported, I do generally override rendering list and enable gpu rasterization on most CrOS installs, which is disabled by default on nvidia (obviously, because ya'll Neverware magicians did the seemingly impossible lol and integrated the driver which has no support in any chromiumos source code, as no chromebooks have nvidia cards, and try as I might, I never got it to work after hacking around on my own overlays for chromiumos builds). I have been using cloudready since ver 68, and have had bugs and graphics glitches, but nothing major. But with the ver. 90.1.42 update, having changed nothing, the whole system will freeze randomly, keeping the last frame on screen, requiring a hard reset. Disabling all gpu flags fixes it, but this raises cpu usage about 15% as I often have literally hundreds of tabs across multiple windows, and making the cpu do all rasterization is bleh. It also disables video acceleration in chrome's built in player, and in vlc. This is a problem because I often deal with 4 and even 8k footage, with regular spikes to 100%. It can still play, but at ~35 fps and not being able to do anything else its eh. If this helps I'm using an AMD FX-8370 OC @4.6ghz and GTX 970. (Another props for expanding AMD support (like your humourous post about having it before google even did says), as chromiumos and brunch both boot loop on this machine and on my other bulldozer and phenom systems. On a positive note, the gallery is fixed and the chrome://media-app works well now.
-
From update engine log
[0618/165729.856800:INFO:libcurl_http_fetcher.cc(143)] Starting/Resuming transfer
[0618/165729.857733:INFO:libcurl_http_fetcher.cc(162)] Using proxy: no
[0618/165729.857811:INFO:libcurl_http_fetcher.cc(313)] Setting up curl options for HTTPS
[0618/165730.031908:INFO:libcurl_http_fetcher.cc(493)] HTTP response code: 200
[0618/165730.032590:INFO:libcurl_http_fetcher.cc(590)] Transfer completed (200), 177 bytes downloaded
[0618/165730.032657:INFO:omaha_request_action.cc(651)] Omaha request response: <?xml version='1.0' encoding='UTF-8'?>
<response protocol="3.0"><daystart elapsed_seconds="75451" /><app appid="{87EFFACE-864D-49A5-9BB3-4B050A7C227A}" status="ok" /></response>
[0618/165730.032895:INFO:omaha_request_action.cc(1347)] Rollback is not enabled for consumer devices.
[0618/165730.032944:INFO:omaha_request_action.cc(1391)] Rollback is disabled. Setting kernel_max_rollforward to -2
[0618/165730.033041:ERROR:omaha_request_action.cc(1400)] Failed to set kernel_max_rollforward
[0618/165730.033325:INFO:action_processor.cc(116)] ActionProcessor: finished last action OmahaRequestAction with code ErrorCode::kSuccess
[0618/165730.033376:INFO:update_attempter.cc(1222)] Processing Done.
[0618/165730.033442:INFO:update_attempter.cc(1102)] Error event sent.
[0618/165730.034754:WARNING:evaluation_context-inl.h(43)] Error reading Variable update_disabled: "No value set for update_disabled"
[0618/165730.035070:WARNING:evaluation_context-inl.h(43)] Error reading Variable target_version_prefix: "No value set for target_version_prefix"
[0618/165730.035123:WARNING:evaluation_context-inl.h(43)] Error reading Variable rollback_to_target_version: "No value set for rollback_to_target_version"
[0618/165730.035179:WARNING:evaluation_context-inl.h(43)] Error reading Variable release_channel_delegated: "No value set for release_channel_delegated"
[0618/165730.035230:WARNING:evaluation_context-inl.h(43)] Error reading Variable release_lts_tag: "No value set for release_lts_tag"
[0618/165730.035280:WARNING:evaluation_context-inl.h(43)] Error reading Variable quick_fix_build_token: "No value set for quick_fix_build_token"
[0618/165730.035341:INFO:official_build_check_policy_impl.cc(30)] Ignoring unofficial build status.
[0618/165730.035512:INFO:next_update_check_policy_impl.cc(48)] Periodic check interval not satisfied, blocking until 6/18/2021 21:33:36 GMT
chronos@localhost /var/log $ -
I just updated my HP Chromebook 14 (G1 FALCO) from 89.4.4 Stable to 90.1.42 (Home Build) dev-channel. Everything went well except when I checked the partitions it was still 27 not 12. I created a recovery USB with 90.1.42 and did a clean install. It now has just 12 partitions. I guess it makes sense that in order to go from 27 to 12 you will need CloudReady to erase and format the drive.
No bugs noticed, and very stable so far.
-
Forrest Smith After update, the crostini section in settings is blank!! And the icon for crostini is gone. Launching manually on the cmdline still tries to load the crostini container, meaning it is still there, but fails with the oft seen vmshell 5 error. This is not as big a deal for me because I sacrifice integration and support for speed and wider distros with crouton, so I only noticed today, but if this happens to someone who relies on crostini for workflow, or has important files in the container, this is a big deal. I will try a fresh install on a machine to see if it still happens and post update here.
-
Getting this error on the macbook 4,1.....any idea what that means Ilya G or Forrest Smith?
chronos@localhost / $ update_engine_client --channel=dev-channel -update
[0621/155454.214476:INFO:update_engine_client.cc(429)] Channel permanently set to: dev-channel
[0621/155454.214702:INFO:update_engine_client.cc(479)] Forcing an update by setting app_version to ForcedUpdate.
[0621/155454.214738:INFO:update_engine_client.cc(481)] Initiating update check.
[0621/155454.216502:INFO:update_engine_client.cc(510)] Waiting for update to complete.
[0621/160251.623636:ERROR:update_engine_client.cc(211)] Update failed, current operation is UPDATE_STATUS_IDLE, last error code is ErrorCode::kPostinstallRunnerError(5) -
Hey Tony -
I took a look through your update-engine logs (sent late last week I think).
I dont' see anything obvious there, except that
- Something's wrong with your device's update behavior even before you start requesting the update manually - there're log lines about a "backoff" period, indicating that background updates have been failing (for some reason) repeatedly, causing the device to go into a programmatic update wait period that's build into CrOS.
- Once you force the update interactively, the issue is occurring near or at the end of the post-install sequence, indicating that the payload is downloading and installing to new partitions fine, but that the process of validating the install and switching over which copy of the OS (old or new) is targeted for next boot is going wrong.
If we reproduced this issue in house, we'd probably do a reinstall of v89.4 and then check again to see if the issue is related to device state. Especially given that you have rootfs verification disabled, the issue could be caused by any deviations from the expected state you've added while tinkering with the device.
- Something's wrong with your device's update behavior even before you start requesting the update manually - there're log lines about a "backoff" period, indicating that background updates have been failing (for some reason) repeatedly, causing the device to go into a programmatic update wait period that's build into CrOS.
-
Appreciate your concern and the bug reports.
We're watching the metrics pretty closely here - our paid version, where disabling rootfs verification is impossible, has a 100% success rate so far. We're seeing a small error rate on the Home Edition, which so far seems to be tied to tampering with the file system.
If there's any indication that hardware type, but not device state or verity changes, can lead to update issues we'll be diving in deeply, but our pre-release testing of this didn't show anything troubling, so here's hoping.
Please sign in to leave a comment.
ChromeOS Flex is replacing CloudReady, so this community is no longer accepting new comments.
Please visit the ChromeOS Flex Help Community to post any new questions or thoughts! You can still link back to this or other pages in this community in order to reference past conversations.