[gentoo-user] file system failure after emerge -DuN @system

[gentoo-user] file system failure after emerge -DuN @system

[Mark Knecht]

Hi,
   An old machine hadn't been turned on in a few months. I decided I
try getting it up to date so I went through an emerge cycle to see if
I could get things going. It was a little picky about upgrading udev
but at the time I thought it had gone OK, but possibly not. emerge
-DuN @system completed without errors, running it again said there was
nothing to update, python-updater ran fine, as did revdep-rebuild.
However when I rebooted I see messages when starting udev:

inotify_init failed: fnction not implemented

and then

No /sbin/udevd found running; None killed

and then

* Checking root filesystem
fsck.ext3: No such file or directory while trying to open /dev/sda7

and then messages about the superblock being wrong. The machines
accepts me logging in and the file system seems to be there but the
machine is clearly not happy.

   Maybe this isn't worth the effort and I'd be better off doing a new
install, but before I go down that path I thought I'd see what actions
I might take first. The kernel hasn't been changed. (2.6.29 vintage so
not horribly old) I do think that gcc and glibc got upgraded with
@system.

   Note that before the @system update there were two drives in the
system, /dev/sda and /dev/hda. After the update it started showing
/dev/sda twice so I unplugged the second drive. (It was video storage
on on old MythTV backend and should be necessary at all.) Now the
system shows one drive but fails as above.

   Ideas?

Thanks,
Mark

[gentoo-user] Re: file system failure after emerge -DuN @system

[walt]

On 01/14/2010 01:33 PM, Mark Knecht wrote:
> Hi,
>     An old machine hadn't been turned on in a few months. I decided I
> try getting it up to date so I went through an emerge cycle to see if
> I could get things going. It was a little picky about upgrading udev
> but at the time I thought it had gone OK, but possibly not. emerge
> -DuN @system completed without errors, running it again said there was
> nothing to update, python-updater ran fine, as did revdep-rebuild.
> However when I rebooted I see messages when starting udev:
>
> inotify_init failed: fnction not implemented...

inotify_init is provided by glibc, so that seems to be important. That
machine seems to have some mismatched components, but which ones?

It's important that glibc be compiled with the kernel headers that are
actually installed on your machine, so the order of package upgrading
does matter, at least when system libs like glibc are involved.

E.g. if glibc was updated *before* the kernel-headers package then you
might expect such problems.  Of course, I have no idea if that's what
happened to you.

On my x86 I have linux-headers-2.6.27-r2 and glibc-2.10.1-r1. I see
that all of my linux-headers files are dated 2009-08-24, and glibc
was updated just this week.  You may want to check to see which of
those packages was installed earlier.

Does the machine run well enough that you can reinstall both glibc
and udev again?

Re: [gentoo-user] Re: file system failure after emerge -DuN @system

[Mark Knecht]

On Thu, Jan 14, 2010 at 6:10 PM, walt <w41ter@gmail.com> wrote:
> On 01/14/2010 01:33 PM, Mark Knecht wrote:
>>
>> Hi,
>>    An old machine hadn't been turned on in a few months. I decided I
>> try getting it up to date so I went through an emerge cycle to see if
>> I could get things going. It was a little picky about upgrading udev
>> but at the time I thought it had gone OK, but possibly not. emerge
>> -DuN @system completed without errors, running it again said there was
>> nothing to update, python-updater ran fine, as did revdep-rebuild.
>> However when I rebooted I see messages when starting udev:
>>
>> inotify_init failed: fnction not implemented...
>
> inotify_init is provided by glibc, so that seems to be important. That
> machine seems to have some mismatched components, but which ones?
>
> It's important that glibc be compiled with the kernel headers that are
> actually installed on your machine, so the order of package upgrading
> does matter, at least when system libs like glibc are involved.
>
> E.g. if glibc was updated *before* the kernel-headers package then you
> might expect such problems.  Of course, I have no idea if that's what
> happened to you.
>
> On my x86 I have linux-headers-2.6.27-r2 and glibc-2.10.1-r1. I see
> that all of my linux-headers files are dated 2009-08-24, and glibc
> was updated just this week.  You may want to check to see which of
> those packages was installed earlier.
>
> Does the machine run well enough that you can reinstall both glibc
> and udev again?

Not right now. After the boot complains that the super block isn't
right the disk is getting mounted read only. I cannot even edit a file
with vi.

Re: [gentoo-user] Re: file system failure after emerge -DuN @system

[Helmut Jarausch]

On 15 Jan, Mark Knecht wrote:
> On Thu, Jan 14, 2010 at 6:10 PM, walt <w41ter@gmail.com> wrote:
>> On 01/14/2010 01:33 PM, Mark Knecht wrote:
>>>
>>> Hi,
>>>    An old machine hadn't been turned on in a few months. I decided I
>>> try getting it up to date so I went through an emerge cycle to see if
>>> I could get things going. It was a little picky about upgrading udev
>>> but at the time I thought it had gone OK, but possibly not. emerge
>>> -DuN @system completed without errors, running it again said there was
>>> nothing to update, python-updater ran fine, as did revdep-rebuild.
>>> However when I rebooted I see messages when starting udev:
>>>
>>> inotify_init failed: fnction not implemented...
>>
>> inotify_init is provided by glibc, so that seems to be important. That
>> machine seems to have some mismatched components, but which ones?
>>
>> It's important that glibc be compiled with the kernel headers that are
>> actually installed on your machine, so the order of package upgrading
>> does matter, at least when system libs like glibc are involved.
>>
>> E.g. if glibc was updated *before* the kernel-headers package then you
>> might expect such problems.  Of course, I have no idea if that's what
>> happened to you.
>>
>> On my x86 I have linux-headers-2.6.27-r2 and glibc-2.10.1-r1. I see
>> that all of my linux-headers files are dated 2009-08-24, and glibc
>> was updated just this week.  You may want to check to see which of
>> those packages was installed earlier.
>>
>> Does the machine run well enough that you can reinstall both glibc
>> and udev again?
> 
> Not right now. After the boot complains that the super block isn't
> right the disk is getting mounted read only. I cannot even edit a file
> with vi.

Try booting by using a rescue CD (www.sysresccd.org)
fsck your root disk
chroot to your root disk
then try to repair your system (e.g. building/installing
a new kernel)

Helmut.

-- 
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

[gentoo-user] Re: file system failure after emerge -DuN @system

[Harry Putnam]

Helmut Jarausch <jarausch@igpm.rwth-aachen.de> writes:

>>> Does the machine run well enough that you can reinstall both glibc
>>> and udev again?
>> 
>> Not right now. After the boot complains that the super block isn't
>> right the disk is getting mounted read only. I cannot even edit a file
>> with vi.
>
> Try booting by using a rescue CD (www.sysresccd.org)
> fsck your root disk
> chroot to your root disk
> then try to repair your system (e.g. building/installing
> a new kernel)
>

Something similar has happened here in the past, it was related to
fsck being called inappropriately.  

At least a few times I was able to remount things after the initial
boot ended up with read only filesystem using the command:

    `mount -o remount,rw /dev/hda_whatever /'

Or maybe just:
    
        `mount -o remount,rw /'
  

To remount in place

After boot came up `read only' it worked apparently since the timing
wasn't a factor then.

But you might try that command first to see if you can do repairs that way.