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.

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!

Okay, I’ve tested 3.2.0-13.22 and the results are… annoyingly varied. Mostly the boots ended in a black, nonresponsive screen. On a couple of such boots, I was able to ssh in and get some logs. I’ll attach them.

On one boot, there was a Trace different from the panic I reported. I’ll attach a picture.

On yet another boot, the same panic was there just as in my shots above, just after ”Starting CUPS” this time. I’ll attach a picture of that too just for completeness’ sake.

So the issue is definitely still there, either it just now manifests itself in slightly more random ways or is clouded by others. I tried -12 again too and that immediately produced the panic, so it’s more consistent in that respect.

On a positive note, fbdev still Just Works.

@Bryce, this really is a messy one: I’ve so far dissected three overlapping issues ((Bug #926007, Bug #926012 and Bug #926028) which have hindered my attempts to assist in debugging the one I originally laid down in this report. :)

Due to Bug #926007, I’m forced to use fbdev on this laptop in order to use X. In normal use it works okay, but when I boot in recovery mode, the resume normal boot option fails to launch X. Instead it launches the low graphics mode dialog, and if I switch to VT-1, the screen becomes garbled.

Xorg log says the problem is it can’t open /dev/fb0: No such file or directory. I’ll attach the log below.

It doesn’t matter whether or not I use the other options the recovery ncurses menu offers; X won’t start properly unless I reset and boot normally (i.e. not in recovery mode).