Announcement

**verndog** · Jan 17, 2010, 08:46 PM

Re: How to determine what is preventing bootup

Is this a "normal" install? Is this an encrypted install?.

Anything in your hardware that might be causing this. Can you give some more specs on your system.

You mentioned that you can get to the offending OS from another OS. Is that other OS on the same hardware or even same hard drive?

How about looking at some '/var/log' files. Also can you get in using Recovery Mode.
Since you can't get a prompt 'dmesg' will be of no help.

**doctordruidphd** · Jan 17, 2010, 08:59 PM

Re: How to determine what is preventing bootup

This is an upgrade. It has been working up until about 10 days ago. "Clean" install is not an option.

Whatever is in my hardware, is working fine with karmic, and was working fine with lucid until the "mesa" problem appeared. I am currently running kubuntu-karmic, Sidux and OpenSUSE-11.2 just fine on the same system. It's 64-bit.

I am not using crypto disks; this is not an encrypted install.. The same message appeared on lucid before this problem, and also appears on karmic.

Recovery mode dies in exactly the same place.

My guess is whatever follows the "crypto disk" stuff is killing bootup - that's what I am trying to determine. Right, no ability to use dmesg. The /var/log/dmesg file does not appear to be updating during this process; it's a dmesg file from the last successful boot.

**verndog** · Jan 18, 2010, 10:29 AM

Re: How to determine what is preventing bootup

I don't see any "crypto" outputs during my boot process.

Look up "/var/log/system, /var/log/messages, /var/log/udev also /var/log/kern"

**doctordruidphd** · Jan 18, 2010, 01:32 PM

Re: How to determine what is preventing bootup

Nothing is being written into /var/log. The last info in any file there is from the last pre-upgrade successful boot. I suspect the file system is not being mounted, but that usually results in a busybox error, which I am not getting. /etc/fstab is what it should be, and the file system fsck's OK from karmic.

Hmm. Maybe a problem with initramfs; I notice that update-initramfs does run several times during the upgrade, but I do not see any errors. Well, I don't even get a busybox prompt, just a hung system, so there isn't much I can do once I (fail to) boot. I did try booting with a pre-upgrade kernel and initrd.img, but wound up with exactly the same problem, so probably not the initramfs. (Just thinking while typing here)

OK, so the file system is not mounting. Or something before that, because there is no "can't mount file system" error. It appears this is not a problem with the upgraded kernel, because booting with an older kernel/initrd hangs in the same spot. It's with something in the system.

I am trying to figure out what is failing, as I don't know what to report a problem with. Reports of hangs and no further info are not really useful.

**verndog** · Jan 18, 2010, 01:49 PM

Re: How to determine what is preventing bootup

Maybe try chroot'ing to the file system from another OS and update that way.
I had to do that during jaunty testing.

**doctordruidphd** · Jan 18, 2010, 02:17 PM

Re: How to determine what is preventing bootup

Thanks for your replies, by the way. I'm kind of stumbling as I go with this.

I'm not sure how well chroot works for this kind of thing. I tried both apt-get update and update-initramfs -u, and both died with a boatload of errors.

I guess the next step is going to be to copy over my karmic system, and do the whole upgrade again. I've hesitated to do that as it's a whole day of downloading, but looks like that's all that's left, if the thing just refuses to boot.

**dibl** · Jan 18, 2010, 02:25 PM

Re: How to determine what is preventing bootup

Originally posted by doctordruidphd

I guess the next step is going to be to copy over my karmic system, and do the whole upgrade again. I've hesitated to do that as it's a whole day of downloading, but looks like that's all that's left, if the thing just refuses to boot.

Maybe I missed the reason -- it would seem that making a "daily" 10.04 CD and installing that would be easier.

**doctordruidphd** · Jan 18, 2010, 02:34 PM

Re: How to determine what is preventing bootup

Reinstalling from scratch is about 2 weeks worth of work, downloading and reconfiguring. I'll live forever on Karmic if it comes to that ...
But it shouldn't. The whole thing worked fine until the 8th, so there's probably nothing inherently wrong with the system.
I suppose that the priority for developers is to get things working first, and getting the upgrades to work is a later issue. So this may get ironed out eventually. Nonetheless, I like to keep ahead of the bleeding edge, if possible.

Edit: Oh yeah, I forgot to mention, the live cd's and alt cd's won't boot on my system, and haven't since jaunty. Have not been able to determine the reason. So it's upgrade or nothing.

**dibl** · Jan 18, 2010, 06:53 PM

Re: How to determine what is preventing bootup

Originally posted by doctordruidphd

the live cd's and alt cd's won't boot on my system

That's a pretty good reason!

**verndog** · Jan 18, 2010, 07:05 PM

Re: How to determine what is preventing bootup

Originally posted by doctordruidphd

I'm not sure how well chroot works for this kind of thing. I tried both apt-get update and update-initramfs -u, and both died with a boatload of errors.

The reason I'm suggesting chroot is since you can't boot the OS in question you need to chroot into that partition to update. How are you trying to do that now?

I've done this myself when jaunty died and was fixed with updates a few days later. In fact , chroot became a topic over at the ubuntu forums because of it.

**doctordruidphd** · Jan 21, 2010, 08:49 PM

Re: How to determine what is preventing bootup

I think I have made some progress in understanding what the problem is.

The file system is not mounting; this is why no logs are being written. I noticed in trying to do the karmic -> lucid upgrade that there was some problem with the mountall command, and that is sufficient reason for the file system to not mount. Now a quick look at 'man mountall' suggests that the eventual goal is to do away with mountall and move that functionality to init, which in the case of ubuntu, means upstart. And here my understanding of it fades.

So I do not know if mountall itself is failing, or if the transfer of functionality between mountall and init/upstart is failing, is not correctly implemented (yet), or what. But that's where the boot process is dying, and as of now I have no functional lucid system.

I am going to reload from backup and try the upgrade again. One thing I noticed is that during the upgrade process, which I always do from tty1 with kdm stopped, I got to a menu for a program's features ( I think it was loading the non-free libraries for rocksndiamonds), and when I tried to enter an answer for the menu, the whole thing dropped to a root prompt, and then rebooted -- right in the middle of the upgrade, which of course resulted in a useless system. So our old problem with two separate login processes on the same tty is, in fact, not fixed, and still with us.

**doctordruidphd** · Feb 16, 2010, 04:43 PM

Re: How to determine what is preventing bootup

[solved]

I found out what is keeping my system from booting.

I found this by installing plymouth. I wasn't getting the relevant boot messages without it. So I guess like it or not, splash is a necessary evil in lucid (at this stage).

In my /etc/fstab file, I have UUID entries for my removable drives, so that when I plug them in, they go where I want. That has worked fine up until now. Evidently, if lucid finds an entry in fstab, for which there is no drive, it just sits there forever. Commenting the relevant entries out brought the system right up.

Now I get to sort through all the other problems... But it's nice to have it working.

**Qqmike** · Feb 16, 2010, 04:58 PM

Re: [solved] How to determine what is preventing bootup

Sometimes, hitting Control+d gets past that UUID thing upon bootup, when it stops there.

**doctordruidphd** · Feb 16, 2010, 05:02 PM

Re: [solved] How to determine what is preventing bootup

Yeah, but in this case, it didn't. Only thing that would work is reboot.