I've recently used synaptic to update SuSE 9.2 system. I thought all went well, until I rebooted the machine this morning. It no longer boots after getting past kernel initialization. I can see the compiled-in modules loading, however the system stops with:

I'm fairly certain that this has to do with the recent updates that were made.

Some questions:
- Has anyone encountered this before?
- Is there anyway to restore the system to a previous state?

Pre-emptive answers to questions:
- The filesystem on /dev/hda2 is intact and well. I can boot the system from a special rescue disk that I was smart enough to build a long time ago, and mount the partitions and even chroot into /dev/hda2 and start using it for internet browsing, etc. Obviously this is not an ideal setup.

- Equally important to note is that I already tried installing an RPM version of the 2.6.8-24 default kernel that came with suse 9.2 disks. This didn't fix the problem.

- I also edited the udev.conf and made sure that the defaults were 0666 just as a test (obviously not ideal operations).

Thanks for any help,
Aaron

Try booting from your boot disk. Do not mount /dev/hda2. If it mounts, then umount /dev/hda2.

Then run 'fsck -N /dev/hda2' (run fsck on /dev/hda2 but do not change anything, just show what would be done).

Study the output carefully. If it doesn't look like any major damage will be done, then run 'fsck /dev/hda2' to see if it fixes anything. You may have to run the command more than once for error corrections to take place.

Reboot after each fun of fsck without the -N option. It's the only way I know to see if it worked.

Since you can still access the partition after booting from rescue disk, it's a fair bet that fsck can fix the problem.

it wasn't an fsck, or corrupt HD issue. That was the first thing I suspected, and under my first bullet, I should have mentioned that I fsck'd it already. Sorry about that.

Actually, I solved it. Apparently, synaptic updated to mkinitrd-1.2-28, which for some reason can't properly create an initrd image for me. Perhaps this is a known issue, or just a localized problem to me. I'm going to investigate it further, and see what the problem is.

I fixed it by re-installing mkinitrd-1.1-7 off of my installation CD, and using that to re-create an initrd. After that, it booted fine.

Thanks,
Aaron

Odd. I thought the initrd shipped as part of the kernel package. If that was the case, then the mkinitrd package shouldn't have mattered at all. Maybe it builds the initrd locally? Odd. Something to think about.

actually, it seems that when the kernel rpm installs, it runs mkinitrd, to create a more tailored initial ramdisk.

-Aaron

Uh, that's what I meant by locally. It is interesting to think about, though.