Link to blog & comments: 

- Beta Channel Update for Chrome OS - https://chromereleases.googleblog.com/2018/08/beta-channel-update-for-chrome-os.html#gpluscomments

Also reported here on peppy in the Chromebook Central forum:

- Update not working - https://productforums.google.com/forum/#!topic/chromebook-central/v8HAMSm5jKc


Possibly related to this issue on scarlet reported here:

- Check for update goes to 100% then says "Your Chromebook is up to date" - https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-discuss/9_I6G6F_XA8

And associated  crbug.com/870816  - Update Failure on Scarlet

We had the same issue of the update not installing on Acer C720s. We had the Chrome device Auto Update Settings Policy with No Restriction. After Restricting the AutoUpdate to version 67 the Chromebooks were able to apply the updates again

Over the last 7 days, we've received 29 reports from Peppy devices running 68.0.3440.76 beta or 67.0.3396.99 saying that they can't update.

Example Reports:
https://listnr.corp.google.com/report/85591095549
https://listnr.corp.google.com/report/85590643541
https://listnr.corp.google.com/report/85590377866
https://listnr.corp.google.com/report/85590084434
https://listnr.corp.google.com/report/85586721977

The first one looks like it succeeded and needs a reboot.

The second one failed with kOmahaUpdateDeferredForBackoff which I think means it will just update later.

The third one look like it succeeded and needs a reboot.

So far I don't see anything alarming from update_engine itself...

OTOH the eventlog scares me.

From the third one, the first one is similar:
...
203 | 2018-08-07 20:42:12 | Kernel Event | Clean Shutdown
204 | 2018-08-07 20:42:13 | System boot | 5500
205 | 2018-08-07 20:42:13 | System Reset
206 | 2018-08-07 20:42:13 | System boot | 5501
207 | 2018-08-07 20:42:13 | System Reset
208 | 2018-08-07 20:42:14 | System boot | 5502
209 | 2018-08-07 20:42:14 | System Reset
210 | 2018-08-07 20:42:15 | System boot | 5503
211 | 2018-08-07 20:42:15 | System Reset
212 | 2018-08-07 20:42:16 | System boot | 5504
213 | 2018-08-07 20:42:16 | System Reset
214 | 2018-08-07 20:42:17 | System boot | 5505
215 | 2018-08-07 20:42:17 | System Reset
216 | 2018-08-07 20:42:18 | System boot | 5506
217 | 2018-08-07 20:42:18 | System Reset
218 | 2018-08-07 20:51:30 | Kernel Event | Clean Shutdown
219 | 2018-08-07 20:51:31 | System boot | 5507
220 | 2018-08-07 20:51:31 | System Reset
221 | 2018-08-07 20:51:31 | System boot | 5508
222 | 2018-08-07 20:51:31 | System Reset
223 | 2018-08-07 20:51:32 | System boot | 5509
224 | 2018-08-07 20:51:32 | System Reset
225 | 2018-08-07 20:51:33 | System boot | 5510
226 | 2018-08-07 20:51:33 | System Reset
227 | 2018-08-07 20:51:34 | System boot | 5511
228 | 2018-08-07 20:51:34 | System Reset
229 | 2018-08-07 20:51:35 | System boot | 5512
230 | 2018-08-07 20:51:35 | System Reset
231 | 2018-08-07 20:51:36 | System boot | 5513
232 | 2018-08-07 20:51:36 | System Reset
233 | 2018-08-07 21:04:29 | Kernel Event | Clean Shutdown
234 | 2018-08-07 21:04:30 | System boot | 5514
235 | 2018-08-07 21:04:30 | System Reset
236 | 2018-08-07 21:04:31 | System boot | 5515
237 | 2018-08-07 21:04:31 | System Reset
238 | 2018-08-07 21:04:32 | System boot | 5516
239 | 2018-08-07 21:04:32 | System Reset
240 | 2018-08-07 21:04:32 | System boot | 5517
241 | 2018-08-07 21:04:32 | System Reset
242 | 2018-08-07 21:04:33 | System boot | 5518
243 | 2018-08-07 21:04:33 | System Reset
244 | 2018-08-07 21:04:34 | System boot | 5519
245 | 2018-08-07 21:04:34 | System Reset
246 | 2018-08-07 21:04:35 | System boot | 5520
247 | 2018-08-07 21:04:35 | System Reset
...

I think we are applying the update ok, but failing to boot with the new image, and falling back. 

We probably need to repro this here, I am out of time to debug at the moment but I am curious if we somehow changed firmware here?

Nothing at the end of the ramoops looks bad, but we might not be getting the one we want here.

Danny, can the test team help get a repro for this?

Agreed with Bernie's assessment that the new image is getting applied but it's not able to come up successfully and we run out of try attempts.

ansar will try to repo and report back.

issue reproduced, after successful auto update, reboot the device but device rollback to old version.

attached device logs and update_engine logs.

Note: Device booting is failed after successful recovery install.

Deleted: update_engine.20180809-162401.txt 62.8 KB

update_engine.20180809-162401.txt 62.8 KB View Download

AUed from : CROS:10718.63.0 => 10718.71.2

Recovery image: 10718.71.2

10718.71.2 contain one fix https://chromium-review.googlesource.com/c/chromiumos/third_party/bluez/+/1159837 from 71.1
71.0 AU test is fine, not sure if that broke it. 

Not reproduced on Cyan, successfully updated to 10718.71.2.

Same on my C720. Tried update twice, still on 67.0.3396.99 after reboot. No errors displayed. Never had such problem before.

crosh> dmesg
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.11 (chrome-bot@cros-beefy246-c2) (gcc version 4.9.x 20150123 (prerelease) (4.9.2_cos_gg_4.9.2-r185-2cdcfd30c27f0d836cc477f2ae9f456287fd6b1b_4.9.2-r185) ) #1 SMP Fri Jun 22 18:18:57 PDT 2018
[    0.000000] Command line: cros_secure console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 2539520 verity payload=PARTUUID=459d6454-e947-3f41-8517-4c3420f87f2a/PARTNROFF=1 hashtree=PARTUUID=459d6454-e947-3f41-8517-4c3420f87f2a/PARTNROFF=1 hashstart=2539520 alg=sha1 root_hexdigest=f0f1a8b500b4f0b53c9c0472330bf70df0975596 salt=52b9783e68feededa423b7f10d14a1423c2244eceae22a9d96b10bf8937ef242" noinitrd vt.global_cursor_default=0 kern_guid=459d6454-e947-3f41-8517-4c3420f87f2a add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic iTCO_vendor_support.vendorsupport=3  
...
[    0.000000] DMI: Acer Peppy, BIOS Google_Peppy.4389.117.0 03/02/2017
...[    0.000000] ACPI Error: Gpe0Block - 32-bit FADT register is too long (32 bytes, 256 bits) to convert to GAS struct - 255 bits max, truncating (20121018/tbfadt-201)
[    0.000000] ACPI BIOS Bug: Warning: 32/64X length mismatch in FADT/Gpe0Block: 256/255 (20121018/tbfadt-567)
...
[    0.000000] Kernel command line: cros_secure console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 2539520 verity payload=PARTUUID=459d6454-e947-3f41-8517-4c3420f87f2a/PARTNROFF=1 hashtree=PARTUUID=459d6454-e947-3f41-8517-4c3420f87f2a/PARTNROFF=1 hashstart=2539520 alg=sha1 root_hexdigest=f0f1a8b500b4f0b53c9c0472330bf70df0975596 salt=52b9783e68feededa423b7f10d14a1423c2244eceae22a9d96b10bf8937ef242" noinitrd vt.global_cursor_default=0 kern_guid=459d6454-e947-3f41-8517-4c3420f87f2a add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic iTCO_vendor_support.vendorsupport=3
...
    0.119607] ------------[ cut here ]------------
[    0.119615] WARNING: at ../../../../../tmp/portage/sys-kernel/chromeos-kernel-3_8-3.8.11-r709/work/chromeos-kernel-3_8-3.8.11/arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2d9/0x31e()
...
[    0.119628] Pid: 1, comm: swapper/0 Not tainted 3.8.11 #1
[    0.119630] Call Trace:
[    0.119638]  [<ffffffffbaefbdb0>] warn_slowpath_fmt+0x65/0x90
[    0.119643]  [<ffffffffbaef1e20>] __ioremap_caller+0x2d9/0x31e
[    0.119648]  [<ffffffffbaef1ea9>] ioremap_nocache+0x17/0x19
[    0.119654]  [<ffffffffbaede883>] snb_uncore_imc_init_box+0x7c/0xb1
[    0.119659]  [<ffffffffbaedd084>] uncore_box_init+0x2f/0x31
[    0.119664]  [<ffffffffbaedd258>] uncore_pci_probe+0x102/0x158
[    0.119671]  [<ffffffffbb09773e>] pci_device_probe+0x73/0xb5
[    0.119676]  [<ffffffffbb0976cb>] ? pci_device_remove+0x94/0x94
[    0.119682]  [<ffffffffbb17b7e6>] driver_probe_device+0xa5/0x1e6
[    0.119687]  [<ffffffffbb17b987>] __driver_attach+0x60/0x82
[    0.119692]  [<ffffffffbb17b927>] ? driver_probe_device+0x1e6/0x1e6
[    0.119697]  [<ffffffffbb17a996>] bus_for_each_dev+0x8b/0xae
[    0.119702]  [<ffffffffbb17b32e>] driver_attach+0x1e/0x20
[    0.119706]  [<ffffffffbb17af71>] bus_add_driver+0x114/0x211
[    0.119713]  [<ffffffffbb6dd2e9>] ? uncore_cpu_setup+0x13/0x13
[    0.119718]  [<ffffffffbb17bef9>] driver_register+0x8c/0xfb
[    0.119723]  [<ffffffffbb6dd2e9>] ? uncore_cpu_setup+0x13/0x13
[    0.119728]  [<ffffffffbb096fd4>] __pci_register_driver+0x60/0x63
[    0.119733]  [<ffffffffbb6dd3a8>] intel_uncore_init+0xbf/0x31b
[    0.119738]  [<ffffffffbb6dd2e9>] ? uncore_cpu_setup+0x13/0x13
[    0.119744]  [<ffffffffbaec8636>] do_one_initcall+0x84/0x13c
[    0.119749]  [<ffffffffbb6d5c69>] kernel_init_freeable+0x112/0x194
[    0.119754]  [<ffffffffbb345f6b>] ? rest_init+0x6f/0x6f
[    0.119759]  [<ffffffffbb345f79>] kernel_init+0xe/0xd6
[    0.119765]  [<ffffffffbb35789c>] ret_from_fork+0x7c/0xb0
[    0.119769]  [<ffffffffbb345f6b>] ? rest_init+0x6f/0x6f
[    0.119775] ---[ end trace 1b3b406a8eff6442 ]---
...
[    1.226236] cryptohome[106]: segfault at 8 ip 00007f2175ac1a3b sp 00007fffa36a7c10 error 4 in cryptohome[7f2175a9b000+ce000]
...

I'm afraid my problem with this update (C720, beta channel, dev mode but system partition unmodified, otherwise same as above reports) is even worse. I attempted to reboot into the new version and my device is now bootlooping; Ctrl+D at the boot screen just results in a brief black screen followed by a return to the same screen. I don't know if there's any diagnostic data I can gather without wiping my machine, but I'd be happy to help out if I can.

How to switch between Chrome OS stable, beta, and development channels
Log into your Chromebook with the account associated with the owner
Click on the account photo located on the bottom right corner of the display
Select the Settings gear icon
Click on the hamburger menu icon
Scroll down and locate About Chrome OS
Within, select Detailed build information
Click Change channel next to the “Channel” section
Pick your desired channel
Click on Change Channel
If you’re changing to a more experimental channel, your Chromebook will download an update and reboot
If you’re changing to a more stable channel, you will have to click Relaunch and Powerwash after the update is installed. This will wipe your Chromebook’s memory.

Force-Boot Into Recovery Mode
If you’d like to reinstall Chrome OS and you don’t see the “Chrome OS is missing or damaged” message on your screen, you can force your Chromebook to boot into recovery mode.
First, turn off your Chromebook. Next, press Esc + Refresh on the keyboard and hold down the Power button. (The Refresh key is located where F3 would be on a typical PC keyboard.) Your Chromebook will boot straight to recovery mode.

I'm also bootlooping.Sun Aug 12 2018 03:11am PDT

Before reboot:
Version 68.0.3440.76 (Official Build) beta (64-bit)

Power cycle

5 failed starts with CTRL-D, 6th succeeds.

After:
Version 68.0.3440.76 (Official Build) beta (64-bit)


I don't know how to find any of the information I'm seeing reported by other users re: logged reboot times and versions and I don't know how to capture a syslog for the failed boots during the bootloop, or I'd post that.  I do see the same kernel backtrace as reported above, for the running version, it seems harmless.

I do have development and bug reporting experience and I'm happy to help out in debugging this if I'm provided with some docs to follow to debug this issue.  

Some things i did, perhaps this can help

1. my version: 67.0.3396.99 (Official build) (64-bits)
2. I tried to update several times but no luck (this is well known)
3. I then tried to get into beta channel several times, but also no luck
4. again I switched to dev channel, and after the Powerwash this worked finally
5. afterwards I tried to get back to stable channel, but again no luck
6. then I forced a recovery, and i'm back on stable 67.0.3396.99, so far so good
7. as you can guess the whole update process is starting over again from point 1

is there a way to stop temporarily the update process until this bug is fixed?

cheers

J
   ust don't turn off your computer! Close the lid to put it in sleep mode
   only.

exactly what i do, but that's no answer to my question

ASAIF, there is nothing forcing you to update. The update process occurs
only if you boot or reboot.  If you don't do either of those, then it won't
update and you can wait until this is fixed, no?

If you glance up at the top of this thread, you'll see I'm the one who
opened this report in the first place! Sorry if you've taken my suggestions
for a temporary solution to your problem the wrong way, but I have said
nothing in the way of criticism towards you or anyone else.







ᐧ

You're right I took you out of context.

I'd rather not just wait until this is fixed though.  I'd prefer one of the Chromium developers, or someone else with some experience debugging the A/B startup process, pipes up with some pointers to debugging it so we can contribute to a faster fix

Hopefully, this is a glitch in only this release, and new releases come
along fairly regularly, I'm no developer. Fingers crossed.

In a related matter, has anyone else been experiencing the VPN issue I also
reported here?  The native L2TP client on my system was connecting to VPN
servers OK, but in actuality no network traffic was being tunneled, and
thus my public IP was unchanged. This was very misleading because from all
outward appearance, the system said "VPN connected."  It was only when some
location-sensitive websites were still refusing connections that I started
to feel something was wrong. After a little research, I learned others were
experiencing the same issue, and not just on Acer C720s, and I reported
this bug.  Turns out there is a simple fix of "forgetting" your Wi-Fi
connection and then reconnecting to it.  After that, the VPN actually works
as it should. Don't know yet how persistent this fix may be.

Bernie, Josafat, should we pin Peppy to 67 on beta / stable till we have debugged this issue? 

It is done, we are no longer serving M68 on Peppy (stable) until this is resolved 

Looking now.

***
Je Chromebook is up-to-date.
Versie 67.0.3396.99 (Officiële build) (64-bits)
***

Thanks for blocking the update process!

So looking at some of the Omaha dashboard queries, the good news is that this does not appear to be a problem going forward into 69/70, as we have many users on much newer versions than 68 (10820, 10866.1, etc).

https://omahadashwiki.corp.google.com/custom/?active_days=28&app=%7BE6710DFC-3EC0-42AE-8095-733FDEA6AF18%7D&app_pretty=%7BE6710DFC-3EC0-42AE-8095-733FDEA6AF18%7D&asterisk_date=2018-08-12&breakout=tag_and_version&bv=*&completion_ratio=0.98000&count=unique&data_category=update_checks&display_name=Peppy+dev+channel+versions&height=350&is_crx=false&limit=20&line_filter=dev-channel&num_days=365&sort_order=recent_high&start_day=*&style=gviz&width=800

If we look at just R68 versions, we seem to have stopped updating around 10718.63, we have a few there and enough to say it must be working, though most are still back on 10718.50.

https://omahadashwiki.corp.google.com/custom/?active_days=28&app=%7BE6710DFC-3EC0-42AE-8095-733FDEA6AF18%7D&app_pretty=%7BE6710DFC-3EC0-42AE-8095-733FDEA6AF18%7D&asterisk_date=2018-08-12&breakout=tag_and_version&completion_ratio=0.98000&count=unique&data_category=update_checks&display_name=Peppy+R68+channel+versions&height=350&is_crx=false&limit=20&line_filter=10718&num_days=365&sort_order=recent_high&start_day=*&style=gviz&width=800

Spot checking other Haswell systems they don't seem to have any problem going forward, this seems unique to Peppy itself.

The CL delta here is not that big, nothing specific to Peppy either, moreover I don't believe anything in here is not already in ToT, so if anything broke it the fix is already out there.

https://crosland.corp.google.com/log/10718.63.0..10718.71.2

https://chromium.googlesource.com/chromium/src/+log/68.0.3440.76..68.0.3440.87?n=10000

Based on the above, my current working theory is that something is corrupted in this particular build for Peppy, and that a subsequent build might 'just work'. 

GOOD News! I can able to auto update peppy from ChromeOS:10718.63.0(public build) => 10718.82.0(beta).

Well I am no longer seeing the arrow to update my c720.
So I went into settings and clicked Check For Updates,
And it says ..
Your Chromebook is up to date
Version 67.0.3396.99 (Official Build) (64-bit)
So I guess you turned the update arrow off. :)

Not reprod on M69(Chrome OS 10895.21.0, 69.0.3497.35) too.

Not reproducible on M69 with build 69.0.3497.34/10895.21.0. 

Re: #41 - Recovered DUT with USB stick. 

OK Bernie is spot-on with his theory in #37.  I applied 10718.71.2 to my peppy with the command

cros flash peppy xbuddy://remote/peppy/R68-10718.71.2/test

on a device in dev mode, and now peppy reboots immediately.  (Does not go into recovery, just reboots.)  So the image is bad.

As Bernie pointed out, this image didn't pass any test.  IIUC, the tests didn't report failures, they just didn't run (maybe because the provisioning failed?), and again IIUC, this caused some human or automated part of the system to attribute the missing results to a bad lab run rather than a bad image.  Thus the image was pushed live.

The 71.2 image has already been taken out of AU.  We already have evidence that subsequent images are working fine, so I don't think this needs further action.  A post-mortem may be useful.  The 71.2 image should have never been pushed and it would be good to prevent further occurrences (also understand how/why the image was bad---although it will take a servo

Also, I don't see anything being pushed live after 71.2 (except maybe for Jetstream) but there's really no urgency in pushing something live.

Thanks for your analysis, at this point unless we intend on doing more debug on why this specific build was corrupted, we can probably close this, and we will just pick up Peppy on the next 68 release.

I have another bug filed internally to try to avoid pushing out images failing in this way in the future.

I'll close it shortly, I want to see if I can get a stack trace first.

OK---just ran an experiment by booting off USB with the bad image 71.2, observing the reboot, then booting off of internal disk with good image 81.0 (10718.81.0).  This shows that the kernel crashes even before it gets to set up console-ramoops.  The content of console-ramoops is that of the last good session before attempting to boot 71.2 (so yes, it's preserved across 2 reboots!)

Closing, as finding the root cause is deemed not to be worth our time.  Please reopen if not agreed.

I'm sure I don't understand how these versions are rolled out but according to the cros-updates site ( https://cros-updates-serving.appspot.com/)  only version 10718.71.2 / 68.0.3440.87 is *available* for peppy *not* version 10718.81.0 that semenzato@ tested with. 

My question is how is a normal user able to successfully update the beta channel to version 10718.81.0 without running into this issue?

"Closing, as finding the root cause is deemed not to be worth our time." seems a little premature to me but again, I don't understand all the nuances.

Deleted: Screenshot 2018-08-13 at 9.58.06 PM.png 65.3 KB

	Screenshot 2018-08-13 at 9.58.06 PM.png 65.3 KB View Download

My chromebook is still downloading the latest version every time it reboots and offering to update (up arrow) however it still fails every time.  The arrow doesn't appear immediately - only because it's busily slurping bandwidth in the background downloading the same failing update over and over and over again.

What I guess I mean to say is that if the update is going to keep failing, how about removing the update so that we're not all pointlessly downloading the same gigs of data over and over and burning those pointless gigs of data to our SSDs over an over? 

And how about letting us opt out of the update so we can reboot without it wearing out drives out?

And how about showing the version number of the update so we know when a newer one than the failing one is available so we can choose to apply the update when there's a non-zero chance of success?

Congrats to the team for finding the root cause of this issue, but your
solution to leave the status quo ,, at leat on the beta channel, is
unsound. There are a lot of unhappy people on the beta channel who don't
want to have to deal with this update loop while waiting for you to push
the next qualified update (when can we expect that, anyway?).

To clarify, when we say the root cause is not worth the time to investigate, we mean it appears to be a random glitch in the build, the first we have noted in several years with dozens of device builds every month.

The stable channel will pick up a future 68 release, likely in the next week or so, until then there will be no update.

The beta channel should have an update within the next couple days that brings it to 69 and clears out any issues (this should happen tomorrow if no issues are found in testing). In the interim, I would just not bother rebooting for the next day or so if on the beta channel.

The dev channel should already be cleared and running the version that should go to beta tomorrow.

Thank you, this is exactly what I hoping to hear.

bht:  I love your "do nothing because nothing will ever go wrong ever again" attitude.  I wish that, as a software developer myself, I also had the courage and balls to say that to my customers.

Please consider the 2 suggestions I made:  

1) allow users to opt out of updates.
2) when an update is available, make it *possible* to see which update it is so the user can make an informed decision whether they wish to apply it.

I'm not saying that these options should be easily visible for average users of stable who could care less and expect everything to just work.  I'm saying that for your beta / dev channel users, there's real value to these options.  TBH I think there would be real value to beta / dev channel users being given an option of picking 1 of N recent updates so they can bisect failures and tell you "this failure occurred between release X and Y" which would provide YOU some value as well.

When I say "allow users to opt out of updates" I mean allow a user to issue a command at the shell to flag a preference to reboot without applying the pending downloaded update.

We are planning to make a change to the release system to avoid this particular type of failure going out, so you should not see this sort of failure again if all goes as intended. 

I am very much interested in how this actually broke, but we do have to prioritize the problems we have to deal with.

Since that's the second time you've refused to respond to suggestions which would enable your beta testers to contribute to troubleshooting, and which would empower beta users to keep their machines usable, I am left with no choice but to believe that you have no desire/respect for beta user input... so I'll be leaving Beta channel.

Thanks for helping us... sad you won't allow us to help you or help ourselves.

#58, sorry for any misunderstanding.  We appreciate the suggestion (about the update-blocking persistent flag) and will consider it.  However, AFAICT this is a one-off.  Normally you get updated to the next version, then if you discover problems, it's too late to go back (that's because we don't support backward compatibility of file formats).  If you ran into other cases where this would have been useful, please let us know.

In the history of the beta channel, since I purchases this peppy device, there's been more than one occasion that releases have affected usability.  The move to Wayland comes to mind, where I had the console flashing at 30hz with the browser on some occasions.  There's been others where I've put the chromebook aside and used my VAIO and sat on my hands waiting for the problem to just go away.  

This time I would have liked to contribute by at least being able to bisect the releases to identify the one that broke things.  I don't think it's too much to ask for beta users to be given enough control over their system to do that.  I'm hoping you agree and make that an option for us.  It will make less people leave Beta and it will reduce Googler workload if Beta users can provide higher quality bug reports.

#60 you're right, except that this may be harder than it seems.  I've opened crbug.com/874278 to discuss it.

ty, I'll subscribe it.

Just successfully auto-updated to Version 69.0.3497.35 (Official Build) beta (64-bit) from 68.0.3440.76 (Official Build) beta (64-bit).  All is well. ;)