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.

Note to others here suffering from this with Radeon HDMI only as I am: as per @David’s comments, I’ve just filed Bug #927323 about this.

Bug #751265 describes the symptom: when VLC uses Pulseaudio for audio output, the sound from it becomes garbled after playing for a while, with heavy digital artefacts and echoing. Comment #23 in that report suggests modifying /etc/pulse/default.pa so that load-module module-udev-detect is followed by tsched=0. I’ve done that, and with it VLC seems to work fine with Pulseaudio. Furthermore, in comment #30 @David Henningsson prompted us suffering from this and with the tsched=0 workaround working to file our own reports for each specific hardware. This is my report.

I believe apport adds data about the hardware automatically. I’ll add to that that for me this only occurs with the Radeon HDMI output; through the analog output (via headphones) the audio works fine. As Bug #864735 describes, Radeon audio is off by default in recent kernels, but I’ve re-enabled it by passing the radeon.audio=1 kernel commandline parameter.

If I switch to ALSA output for VLC (without tsched=0), VLC audio goes mute after a while. After some time of silence it sort of fast forwards itself to get up to sync with the video again. This keeps repeating, so it’s not really a workaround.

After selecting netroot from the friendly menu, I do get root but no network: only the loop interface is up. This happens even though the laptop has in fact both wired and wireless net, both of which do work on the system after a normal boot.

If I run ifconfig eth0 up and dhclient eth0 on the prompt, the wired interface comes up fine, so that’s a workaround.

Bug #572426 seems to have been repurposed for something that could make this a duplicate of that. Bug #868748 also describes something similar, but this isn’t just about not getting an IP address; the interfaces (apart from lo) aren’t brough up automatically at all.

(My previous comment was after trying 3.2.0-14.)

Alright, I will. Thanks Bryce.

Reopening, there’s more to this than I thought.

I thought 3.2.0-14 brought with it a regression, but it turns out it’s now the -pae kernels that freeze during boot as I initially described. The thing is, I could’ve sworn I already ruled this out and also that I did most of yesterday’s successful boots with 3.2.0-13-pae, since that was the topmost and default in the Grub menu. So I’m not yet ruling out some funky hardware fault, but for now I’ll update the title to reflect how it presently seems: the wistron_btns problem lies with -pae. Non-pae kernels all the way back to 3.2.0-12 now boot fine.

I’m currently running memtest on the laptop just to be sure, although I’ve done it multiple times before with no issues.

3.2.0-13.22 fixed this! Just did three consequtive reboots and a cold boot with wistron_btns. Each booted just fine and the wireless was there, working. To be sure, I also tried 3.2.0-12 again and it still hung during boot. Back to 3.2.0-13 and again no problems. Excellent!