failure while starting a maintenance shell

I forget: this is on an up-to-date feisty.

Thank you for your bug report. But with the information you gave us are we unable to fix the problem. Could you please give some more information like the /var/log/fsck/ceckfs file?

2007/3/4, Sense <email address hidden>:
> Thank you for your bug report. But with the information you gave us are
> we unable to fix the problem. Could you please give some more
> information like the /var/log/fsck/ceckfs file?

nop.
The maintenance shell started after a problem with fsck
and *only "/" was mounted*, as should be mentioned in the bug report -
I have "/var" in a different partition, that was not mounted-.
The problem with the maintenance shell is that a number of executable
could not be found - I have "/usr" mounted on a different partition.

(there is an other problem with fsk, that requires manual intervention,
but that will be for an other bug report I guess.

> ** Changed in: Ubuntu
> Assignee: (unassigned) => Sense
> Status: Unconfirmed => Needs Info
>
> --
> failure while starting a maintenance shell
> https://launchpad.net/bugs/89595
>

O, of course is it impossible to post a log if /var isn't mounted. But I didn't know because the only thing I knew was that only / was mounted.
Dis you mention all of the partitions that have to be mounted?
But isn't it impossible to run fsck(and almost every other program) if /usr isn't mounted?

I forgot /sbin
fsck is located in /sbin, so it should be possible to run fsck without error messages I suppose.
I've got a lot to learn.

my "/sbin" in mounted with "/".
The error I am reporting is with the maintenance shell
(that appears to depend on executables in "/usr").
[There is something else with fsck, but one problem at a time ;-) ]

2007/3/4, Sense <email address hidden>:
> I forgot /sbin
> fsck is located in /sbin, so it should be possible to run fsck without error messages I suppose.
> I've got a lot to learn.
>
> --
> failure while starting a maintenance shell
> https://launchpad.net/bugs/89595
>

What is the version of bash you're using?
Is there anybody else with the same problem? If anybody else has the same problem, the bug is confirmed. But I don't think anyone want to risk a broken filesystem to reproduce this bug.

pretty much the same version anyone running feisty has I guess:

GNU bash, version 3.2.10(1)-release (i486-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.

The problem is simple (and there is no need to risk a filesystem).
What happens was:

- fsck started after a forced reboot (libata is sometimes having
trouble... but this is an other reported bug)
- fsk should only check unmounted directoryl: everything but / root is unmounted
(in my case, that's /var, /usr/, /usr/local, /tmp ).
- when checking 'fsck' found things to fix, and because of the default
configuration in
ubuntu stops there (rather than automatically trying to fix the problem).
- fsck stopping causes a start of the maintenance shell, but nothing
that was unmounted
for the fsck is mounted back.
- the maintenance shell missing things in /usr, the show stops here.

It was possible for me to fix my disk, but what happened was not
something I wished
to a less experienced user.

Cheers,

Laurent

2007/3/14, Sense Hofstede <email address hidden>:
> What is the version of bash you're using?
> Is there anybody else with the same problem? If anybody else has the same problem, the bug is confirmed. But I don't think anyone want to risk a broken filesystem to reproduce this bug.
>
> --
> failure while starting a maintenance shell
> https://launchpad.net/bugs/89595
>

Excuse me for the long time to response. I think it's almost confirmed, but we need to know the package so the right person is noticed. Does anyone knows which program is responsible for mounting and unmounting things around the fsck check?

I think it has at least partially to do with fsck, and maybe the (un)mount scripts are included in fsck, so lets confirm.

I confirm this, it still exists on Gutsy Gibbon (as of now Tribe 5). This was fsck'ing a drive mounted as /media/sda4 as ext3. fsck fails every time on this, therefore it could be another bug as well. However one behaviour of this bug is that It does not seem to locate any packages at all. It recommends installing it through "sudo apt-get install less" however it fails to find both the sudo and apt packages.

When fsck fails on the root filesystem, the checkroot init script runs /sbin/sulogin which takes care of launching the maintenance shell. This happens at a point before any other filesystem is mounted.

All /sbin/sulogin does is basically determine the root users default shell (normally /bin/bash) plus a few other things, then it spawns the shell. It doesn't do anything else and it doesn't read anything from /usr.

Because of this, I'm assigning this bug to bash.

Thanks

> Because of this, I'm assigning this bug to bash.

we cannot control what the user adds to the .profile and .bashrc scripts. afaics everything in the profile scripts shipped with hardy (and later) is guarded. reassigning to base-files. I don't think this is a problem; if users do change the files in /root/ they should be aware of this. proposing to close as won't fix.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[Expired for base-files (Ubuntu) because there has been no activity for 60 days.]