This is apparently caused by something not in Chromium itself: it’s not reproducible in a VM running Oneiric, with 17.0.963.26 from ppa:chromium-daily/dev nor with Chrome 17.0.96356. It *is* reproducible in Precise with the latter too, but not reproducible with Firefox nor Epiphany. In Precise with Chromium 17, it’s reproducible with a temporary profile and a guest login also.

With Chromium 17, I can no longer drag ’n’ drop tabs to reorganize them in an existing window: the tabs area no longer lets me drop tabs onto it, so each tab I pick up gets a new window when dropped. Dragging the tab from the new window into the old won’t work either (cannot drop the tab into where the tabs area should be).

I left an old netbook to do an ”apt-get -y dist-upgrade” overnight, and when I returned to it the next morning, the upgrades were unfinished because libc upgrade was waiting for me to respond to ”Restart services during package upgrades without asking?”

It looks like the question is prioritized depending on whether the upgrade is done on desktop or not, and if it’s not, the priority is set critical. According to documentation [1], critical is for ”Items that will probably break the system without user intervention.” I don’t think restart-without-asking satisfies that condition.

* [1] http://www.debian.org/doc/packaging-manuals/debconf_specification.html#AEN101

With both 3.2.0-16 and 3.2.0-17, what I said in #8 still holds, with -16 and -17 behaving just as -15 did. 3.2.0-17 added something interesting though: booting 3.2.0-17-pae in recovery mode ”breaks” the -pae’s like (non-recovery booting) 3.2.0-14-pae does. To be sure, I tried recovery booting other kernels going back to 3.2.0-14, and couldn’t reproduce this with them (not even with 3.2.0-14-pae!) . Recovery booting 3.2.0-17 non-pae also doesn’t bring it on, it’s just recovery booting 3.2.0-17-pae.

The steps to reproducing this freeze with 3.2.0-17 are:
1. Boot 3.2.0-17-pae in recovery mode.
2. In the recovery menu, select ”root”.
3. From the root prompt, just reboot.
4. Boot 3.2.0-17-pae (normally).

The ”fix” also still holds: just boot a non-pae kernel once, and the pae’s again work.

After dozens and dozens of boots with the 3.2.0-14 and 3.2.0-15 kernels, here’s what I know.

1. This *is* tied to wistron_btns as I reported. Without it, boot never fails (the way I initially reported, though I’ll redefine what ”fails” means further below).
2. With non-pae kernels, boot never fails.
3. With 3.2.0-14-pae, the boot always fails.
4. A cold boot with 3.2.0-15-pae never fails.
5. A re-boot with 3.2.0-15-pae after a *non-failing* boot never fails.
6. A re-boot of 3.2.0-15-pae, after a *failing* boot (of 3.2.0-14-pae for instance), is *almost* sure to fail. I’d give it a 10% chance of not failing.

If you put it another way, this appears is pretty interesting:
1. You can ”break” 3.2.0-15-pae by booting 3.2.0-14-pae first.
2. You ”fix” a thus ”broken” 3.2.0-15-pae by booting a non-pae kernel.

I suspect this brokenness is actually hidden in the hardware, in something (the wifi key perhaps?) controlled by wistron_btns. Booting 3.2.0-14-pae puts the controller(?) in a ”broken” state from which 3.2.0-15-pae can’t recover, but a non-pae kernel can. And though 3.2.0-15-pae can’t recover a ”broken” controller, it also cannot put it into that ”broken” state (which is a good turn of development).

So now, about that ”fails” part.

I discovered by accident that although the system appears to freeze in boots I referred to as ”fails”, it has in fact been brought down to *almost* complete halt, but *just* almost. If I’m patient enough to wait, it does actually boot into LDM, from where I can switch to another VT and log in… slooooooowly.

Thus I was able to find out what’s going on that makes it so slow:

jani@amilo:~$ head dmesg.fail
stron_btns: Unknown key code 10
[ 1011.554522] wistron_btns: Unknown key code 10
[ 1011.554722] wistron_btns: Unknown key code 10
[ 1011.554921] wistron_btns: Unknown key code 10
[ 1011.555120] wistron_btns: Unknown key code 10
[ 1011.555320] wistron_btns: Unknown key code 10
[ 1011.555518] wistron_btns: Unknown key code 10
[ 1011.555717] wistron_btns: Unknown key code 10
[ 1011.555916] wistron_btns: Unknown key code 10
[ 1011.556134] wistron_btns: Unknown key code 10
jani@amilo:~$ grep wistron dmesg.fail | wc -l
2520

Note that this is unrelated to pressing any actual physical buttons. It’ wistron_btns misbehaving under the conditions I described above.

jani@amilo:~$ LC_ALL=C aptitude show linux-image-3.2.0-14-generic-pae | grep ”more then”
Geared toward 32 bit desktop systems with more then 4GB RAM.

I believe the fix is to ’s/more then/more than/’ in DEBIAN/control.

Hi komputes.

The difference between a normal boot and a recovery mode boot is (among other things) in the parameters that are passed on to the Linux kernel. A normal boot uses Kernel Based Mode-setting (KMS) whereas in recovery mode KMS is turned off by default to make sure it causes no problems in case recovery mode is needed.

From the Release Notes of Ubuntu 10.04:

”Ubuntu 10.04 LTS enables the new kernel-mode-setting (KMS) technology by default on most common video chipsets. While this is a major step forward for the graphics architecture in Ubuntu, in some rare cases KMS will prevent your video output from working correctly, or from working at all. If you need to disable KMS, you can do so by booting with the nomodeset option.” https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#Working_around_bugs_in_the_new_kernel_video_architecture

I believe the nomodeset parameter is behind the low graphics mode you’re seeing in recovery mode and therefore intentional, as visually unappealing as it may be.

I have two computers affected by this and one that is not, each running Precise. I’ve tracked down the cause, but I’m not sure which of the components involved (friendly-recovery, resolvconf, postfix and upstart) is the culprit, so I’ll file this for friendly-recovery which is at least severly affected. Feel free to correct the target with better insight.

Steps to reproduce:
0. Have the ’postfix’ and ’resolvconf’ packages installed.
1. Boot into recovery mode.

What happens:
The boot proceeds in nonsplash (text) mode, but in the end the recovery menu fails to show up. Instead the graphical greeter is brought up.

What I expect to happen:
For the recovery menu to show up so I can use it.

The cause:
For debugging this, I first enabled logging for friendly-recovery.conf. That log implicated resolvconf, so I enabled logging for resolvconf, and that in turn revealed this:

cp: cannot create regular file `/var/spool/postfix/etc/resolv.conf’: Read-only file system

So I checked, and indeed postfix wasn’t there on my laptop which wasn’t affected. It seems that due to the read-only file system, the resolvconf upstart job fails, which in turn leads to the resolvconf-dependent friendly-recovery job to also fail.

The workaround:
Uninstall postfix if you can afford to.

While waiting for this to reoccur, now that I came to think of it: I have radeon.audio=1 on my kernel parameters due to Bug #864735. Radeon audio is considered too buggy by developers to be enabled by default, so my force-enabling it definitely makes it a suspect here.

Hi David, thanks for responding. I tested fglrx just now and every time I launched VLC with audio, or in this case even Totem with audio, the X session went boom right before any sound came out. So if you meant ”does it work without tsched=0 when using fglrx”, I guess the answer is no. I’ll attach the X log, although this crash is probably unrelated to this report. (I only use the free drivers myself so I won’t bother to report this separately. It was pretty consistent and should be easily reproducible though.)

I didn’t know whether the radeon.audio=1 kernel parameter matters when fglrx is in use, so I tried both with it and without it, with the same result (X crash).

The only thing audiowise that didn’t crash the session was PA’s speaker test (from the audio settings). It didn’t make any sound either though.

Luckily, enabling Radeon audio in the kernel hasn’t given me any problems on this setup, at least such that I could link to it. I do have Bug #917668 filed in, but it’ll have to reoccur to get more data to see if that’s connected.