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.

Ovatkohan Googlen maksullisen palvelun, jollainen yliopistolla kuvittelisin olevan, yksityisyysehdot samanlaiset kuin ilmaispalvelun? Voi olla että ovatkin, mutta toisaalta voisi kuvitella, että kun palvelusta jo kerran maksetaan, eikä siinä ole mainoksia (eihän?), ei ole myöskään syytä räätälöidä niitä mainoksia eikä näin ollen kyylätä käyttäjien sähköpostien sisältöä. Vähemmän turhaa dataa kerättävänä ja säilöttävänä = kustannussäästöjä.

Toisaalta jos se mainosinfra on jo olemassa, voidaan maksullisillekin asiakkaille tarjota mainoksia halvempaa hintaa vastaan, mikä sekin on kilpailuetu. Näkyykö yliopiston Gmailissa mainoksia?

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.