Upgrade 8.04->9.10 fails: crash to tty, claims can't mount rootfs

[Tom H]

Nils Kassube wrote:

> Dexter Filmore wrote:

>> So today I finally decided to upgrade to 9.10 from 8.04.

>> Now after rebooting the system crashed to a maintenance shell
>> claiming the system wasn't able to mount the root fs.
>> Funny thing here: / was mounted. could perfectly dive into the
>> system, run programs and so on. Perfectly mounted.

> Did you check that you really have your disk partitions mounted? The
> early startup part of the system uses the initrd which has a normal
> directory structure but it is located entirely in RAM without the disks
> mounted yet. And you have a very limited set of initial programs
> available which are also part of the initrd. I wouldn't expect a mounted
> disk partition if there is an error message that the system wasn't able
> to mount the root fs. The mount command should show the partitions used
> for /. If it isn't /dev/sda1 (or whatever your / partitions name is),
> then you aren't looking at your disk. I would try to mount the /
> partition and see if there is an error and what is is.

>> Next thing /home and /var (which I have on seperate partitions) were
>> mounted according to "mount", diving into the dirs however they were
>> empty.

> Same as above, probably no partition mounted but you see the directory
> structure of the initrd.

>> Checked blkid and compared to menu.lst (wasn't 9.10 supposed to
>> upgrade to grub2beta? No trace of grub.cfg there), all fine,
>> /proc/cmdline fine, but couldn't boot.

> If you can see menu.lst, it would of course contradict what I wrote
> above and your / partition may be mounted after all. Or do you also have
> a separate /boot partition? Anyway, during an upgrade the old grub
> should not be replaced by grub2 - that one is only used for a fresh
> install.

+1 to Nils' comments.

Like him, I do not understand how you can see menu.lst without / being
mounted (although a separate /boot would explain this; but why would
/boot be mounted and none of the other filesystems?). Perhaps it is a
function of the initrd (a topic that I unfortunately know nothing
about).


>> "runlevel" reports: unknown (scary, huh?)

> The runlevel concept is from sysvinit and upstart doesn't have it. From
> "man runlevel":

> | NOTES
> |  This tool is provided for compatibility with the traditional System V
> |  init(8). Upstart has no notion of runlevels itself, this and the
> |  telinit(8) tool are provided to emulate their behaviour.

> I don't think the runlevel command will give you any useful information
> on a 9.10 system.

"man runlevel" notwithstanding, "who -r" should output the usual
'buntu runlevel of 2.

You can still append a runlevel to the kernel/linux line in
menu.lst/grub.cfg to boot to a different runlevel. Some of the upstart
jobs have runlevels conditions. So the plan may be to deprecate
runlevels (hopefully with a replacement for single user boot!) but for
the time being it is still there.


>> I suspect an Upstart conflict here, maybe the cleanup left some old sysVinit
>> scripts or an initrd wasn't properly updated and Upstart mounted / and sysV
>> unmounted it after /home and /var where mounted, effectively breaking them.

initrd may not have been updated to reflect your upgrade but upstart
and sysv would not conflict this way. When you upgrade to KK (at least
to the beta version; I have not tried to upgrade to the actual
release), some upstart jobs will be in the new /etc/init and some will
still be in /etc/event.d but they will not conflict with the scripts
in /etc/init.d, at least not when you go from 9.01 to 9.10.


> Anyway, I have no idea what went wrong. But can you tell us how you did
> the upgrade from 8.04 to 9.10? The way you did it might be important to
> raise some ideas.

+1 again.