Unable start as live cd Lucid Beta 2

in attach lshw output.

in attach bios output.

in attach cpuinfo output.

in attach syslog.

@Salvatore

This looks rather similar to the bug that's affecting me: bug 499399. Similar hardware and the boot process stops at the same point, according to syslog (just after network activation).

Therefore, I am interested to know: have you had the same problem with previous ISO images, or only with this version?

Thanks for this report.

How do you know that the startup has crashed?

Did you boot with the default boot options? (Normally, these ureadahead-other messages - which are non-fatal - would be hidden by the boot splash screen)

@Irihapeti, I had the same problem also with all alpha releases.

 @Langasek If I boot whit default options, I see plymouth logo and then my system freezes on it, if I boot without "splash" and "quiet" options I see the error lines which I wrote in the report.

Salvatore,

Ok, but how do you know that it has *crashed*? Do you get a flashing capslock key? Does the plymouth animation crash? Can you switch VTs with Alt+F1 / Alt+F7? Does Alt+SysRq+K have any effect?

Steve,

Capslock Led is off. Plymouth animation load for a while (the 5 points blink), then animation stops. Both CTRL+ALT+F1 and Alt+SysRq+K don't do anything.

Ok. Please boot without the 'quiet' and 'splash' options, and add '--verbose' to the boot options instead; if it hangs, please post the output before the hang.

This is the output:

Begin: grant administrative policykit privileges to default user ... ...
Done.

Begin: disabling gdm guest session functionality ... ...
Done.

Begin: set ubiquity favourite for une ... ...
Done.

Begin: running /scripts/init-bottom ...
Done.

init: ureadahead-other main process (1100) terminated with status 4
init: ureadahead-other main process (1101) terminated with status 4

* setting sensor limits [OK]

This is with --verbose? I would expect to see upstart output here if the argument was being parsed correctly.

This is the output:

init: plymounth-log state changed from running to stopping

init: rsyslog main process (1132) became new process (1139)

init: rsyslog state changed from spawnet to post-start

init: rsyslog state changed from post-start to running

init: udev state changed from starting to pre-start

init: udev state changed from pre-start to spawnet

init: udev main process (1140)

init: handling started event

init: handling stopping event

init: plymounth-log state changed from stopping to killed

init: plymount-log state changed from killed to post-stop

init: plymount-log state changed from post-stop to waiting

init: handling started event

init: handling stopped event

init: handling mounted event

init: handling all-swap event

init: handling mounting event

init: handling mounting event

init: mountall main process (1093) exited normally

init: mountall goal changed from start to stop

init: mountall state changed from running to stopping

init: handling stopping event

init: mountall state changed from stopping to killed

init: mountall state changed from killed to post-stop

init: mountall post-stop process (1141)

init: mountall post-stop process (1141) exited normally

init: mountall state changed to post-stop to waiting

init: handling stopped event

*setting sensor limits [OK]

@Steve Langasek
I'm following this bug because it seems to be very similar to (if not a duplicate of) bug 499399 which has affected me for several months.

I don't want to clutter up this report with extraneous attachments, so I have posted the output of the kernel line with --verbose to bug 499399 in case it's useful.

Ok, so we get as far as mountall running, apparently to completion; but the last events handled appear to be 'mounting' events, when we should see both 'mounted' events following this as well as the 'filesystem' events that will trigger starting gdm, the gettys, and a variety of other services. Assigning this to the mountall package, since this does appear to be something going wrong with the interactions between mountall and upstart.

I'm able to boot with 2.6.32-20 by adding "blacklist viafb" to blacklist.conf

Oh, huh.

Salvatore's lshw.txt appears to also include a card which matches the viafb framebuffer - which, indeed, is not one we want to have loaded. I'll get this fixed in module-init-tools.

(BTW, Salvatore, the output of 'lspci -nn' is a lot more parseable than lshw; in the future it would help if you could use that command instead in bug reports)

This bug was fixed in the package module-init-tools - 3.11.1-2ubuntu1

---------------
module-init-tools (3.11.1-2ubuntu1) lucid; urgency=low

  * Blacklist viafb; the only framebuffer drivers we want loaded by default
    on x86 are the drm framebuffers and vga16fb. LP: #558569.
 -- Steve Langasek <email address hidden> Tue, 13 Apr 2010 21:20:05 -0700

Leo adding vmalloc=268435456 to the line with "quite splash" was what I wanted, thanks. But your syslog missed any reference to viafb even the startup message (probably it didn't get written to disk prior to freeze) so I didn't see anything in there.
Anyway by using the fact that
- the very same IGP works for some people
- the crash happens very early (even when the module refuses to work) but seems to also happen if it would likely work (with the vmalloc option)
I can think only of one code area, the I2C code, that could cause this as the rest are fairly simple PCI commands. Maybe the manufacturers of your boards did some strange things as is done in OLPC (where this just causes half a minute delay). But maybe I'm just missing something obvious here.
However debugging this and finding the right fix will be something that takes a while (and a lot of help from people who experience this bug). There is a slight chance (although relatively low) that this will be fixed in 2.6.35-rc2 as Jon posted some changes to the I2C code (not explicitly labled as fixes so don't expect too much).
It also could be helpful if somebody would test Harald's old tree, located at
http://git.gnumonks.org/cgi-bin/gitweb.cgi?p=linux-2.6-via.git;a=shortlog;h=refs/heads/via-viafb
but I do not expect it to work any better (although it did sometimes in the past). If I knew that this does not work I could ask him for help as he has better connections to VIA and is more experienced than me. So if you want to give it a try this might be a starting point
https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
I won't provide any help in compiling and installing your own test kernel as my advice would likely lead to screwing your system up.
Sorry that I can't be a big help but there is not much I can do without knowing what exactly goes wrong and therefore prefer to concentrate on the things I can actually do without too much guesswork.

Given that this fb is (and is meant to be) blacklisted by default, I don't think a kernel fix for this video driver is urgent for lucid. If and when it gets fixed in maverick, the fix can be considered for lucid.

I have the same problem in my HP notebook...

I upgraded my Beta install, removed the blacklisting that I had created manually and I confirm it boots fine. I will confirm later on that it also works for the ISO daily build.

@Steve: Of course. I added the package and upstream project, together with the assigned-to when I marked my own bug a duplicated of this.

@Florian: Indeed the only reference to viafb on my syslog came when I tried to load viafb manually, and not during boot. I could help testing, as time allows. I think of opening a bug reprot at the kernel bugzilla, so that the tests get documented there and other users/developers can continue the work. Should I do it?

I've tested the ISO image of 14 April, and I'm pleased to say that it boots successfully.

I tested 15 April's ISO with following md5:

84a36ba155718d24646eaf2a2f7b11d5

and it worked!

I confirm the bug is fixed. Thanks for making ubuntu everyday better.

This problem remain.. I tryed install latest (16.4.) alternate ubuntu 10.04 (http://cdimage.ubuntu.com/daily/current/lucid-alternate-i386.iso), but not success. First screen after booting install CD is OK, next (Install Ubuntu) is blank screen and no activity..

I, too, am experiencing trouble with Ubuntu 10.04 with a 2.6.32-21-generic-based installer on:

01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03)

I am doing a text mode netboot install and not setting up X. The installer is unusable with distorted broken dialogs and unreadable font. I tried booting the kernel with video=vga16fb:off,viafb:off, but that did not fix the broken screen.

I understand this is still an open issue, but I am at least looking for a workaround to be able to netinstall machines in text mode.

Youssef Eldakar
Bibliotheca Alexandrina

This does not sound like the issue discussed here. As far as I understand Ubuntu blacklisted viafb and therefore no issues you currently experience can be related to it. Your issue sounds like you can at least figure out where characters are. It would be interesting whether anything is shown correctly during boot process (removing "quiet splash"?). I suggest you look for another bug report that looks like the issue you have or to open one if none exists.

For the issue discussed here:
Thanks to Leo it was possible to narrow it down to the I2C area. As it does not look like a general issue (some of these IGPs do work) I assume that something on the board where it occurs is wired differently. I do not push the (debug) patch to mainline because it can cause regressions and would forbid any auto-detection (of available resolutions and the like). I am trying to improve the code to auto-detect where devices are connected and plan to query only connected devices via I2C (and hope that this will automatically solve this issue) but that takes a while especially as there exists nearly no documentation for older chipsets.

@Salvatore -- you indicated that the 14th april CD booted ok. That would have been prior to the Lucid release I believe. Could you confirm which version this was fixed for you, was Lucid or Maverick good for you? Please report back here. Thanks.