5:03 a.m.
Hi,
Something has gone wrong which means I can't start my main linux box and it's
no fun!
When I did an update to the current testing kernel, I had the error that
/proc/partitions couldn't be opened and as such, a conversion couldn't be
done. grubby then gave a fatal error.
When I do a reboot, the bootloader fires up, but when I choose a kernel, all I
get it that the kernel can't be found (file not found)
I have /boot on /dev/hda2
Any ideas on getting this working?
TTFN
Paul
--
Get your free @ukpost.com account now
http://www.ukpost.com/
6:01 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 05 December 2004 11:03, Paul F. Johnson wrote:
Hi,
Something has gone wrong which means I can't start my main linux box and
it's no fun!
When I did an update to the current testing kernel, I had the error that
/proc/partitions couldn't be opened and as such, a conversion couldn't be
done. grubby then gave a fatal error.
When I do a reboot, the bootloader fires up, but when I choose a kernel,
all I get it that the kernel can't be found (file not found)
I have /boot on /dev/hda2
Any ideas on getting this working?
Without actually knowing what the problem is, the first move would be to boot
off your first install CD and select the sort of "recovery mode" boot.
The boot filesystem must be accessible to grub otherwise it cannot show you
the stuff from /boot/grub/grub.conf. I would boot into the recovery install
kernel and look carefully at my /boot/grub/grub.conf to see if it is giving
the correct partition to boot from.
- -Andy
- --
http://www.addintelligence.co.uk -- we design custom hardware and software for
your products
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBsvimjKeDCxMJCTIRAjKGAJ4oimElnmcd9DSP8s6P24var1AfhgCfaVpm
JbzUbqc6EiM15jqnGqcMFjQ=
=b+Ru
-----END PGP SIGNATURE-----
6:21 a.m.
Hi,
Without actually knowing what the problem is, the first move would
be to boot off your first install CD and select the sort of
"recovery mode" boot.
Will try that
The boot filesystem must be accessible to grub otherwise it cannot
show you the stuff from /boot/grub/grub.conf. I would boot into the
recovery install kernel and look carefully at my
/boot/grub/grub.conf to see if it is giving the correct partition to
boot from.
I'm starting to wonder if there has been something in the latest rawhide. The
system was installed with FC 2.91 (IIRC, FC3t2) and has been kept up to date
with rawhide since then. It isn't formatted to be using VolGroup00/LogVol00,
but to be using the more conventional /dev/hdax.
It's either that or when I asked someone else to install the kernel, they used
rpm -Uv and ignored the postun (etc) errors... Now that will have screwed
things up!
I doubt the MBR is shafted as the machine is booting to grub, though I have
noticed that /dev/hda1 does have a very old version of the system files in it,
which makes me wonder if something is getting a wee bit confused.
Anyway, more when I know - thanks for this much.
TTFN
Paul
--
Get your free @ukpost.com account now
http://www.ukpost.com/
6:46 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 05 December 2004 12:21, Paul F. Johnson wrote:
Hi,
> Without actually knowing what the problem is, the first move would
> be to boot off your first install CD and select the sort of
> "recovery mode" boot.
Will try that
> The boot filesystem must be accessible to grub otherwise it cannot
> show you the stuff from /boot/grub/grub.conf. I would boot into the
> recovery install kernel and look carefully at my
> /boot/grub/grub.conf to see if it is giving the correct partition to
> boot from.
I'm starting to wonder if there has been something in the latest rawhide.
I am tracking rawhide on this machine, have been since before FC1. It's
possible I missed some poison pill since it does not update every day. There
was an ugly kernel a month or two back that trashed filesystems: I was lucky
and an fsck under a later kernel repaired it for me.
The system was installed with FC 2.91 (IIRC, FC3t2) and has been kept
up to
date with rawhide since then. It isn't formatted to be using
VolGroup00/LogVol00, but to be using the more conventional /dev/hdax.
It's either that or when I asked someone else to install the kernel, they
used rpm -Uv and ignored the postun (etc) errors... Now that will have
screwed things up!
I installed the kernel you posted about and I did not get any errors on
install, plus I am running it right now just fine. What I DID get was for
some reason /boot was not mounted at that time, the kernel files were instead
copied into the mountpoint itself (ie, the /boot in the root filesystem that
should be an empty mountpoint "covered over" by the actual mounted /boot
filesystem). I had to mount the boot filesystem elsewhere and copy over the
files from /boot into it, adjust /boot/grub/grub./conf and then reboot and it
worked fine. I think this was to do with recent initscripts troubles at the
time I installed the new kernel.
I doubt the MBR is shafted as the machine is booting to grub, though
I have
noticed that /dev/hda1 does have a very old version of the system files in
it, which makes me wonder if something is getting a wee bit confused.
What system files?
- -Andy
- --
http://www.addintelligence.co.uk -- we design custom hardware and software for
your products
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBswM6jKeDCxMJCTIRAjYrAKCKIbKK63qvfp4fsRl9jYnwCsMxwQCePg7F
ZqTzjPbbWcLuY9VYzocfalQ=
=Q1dK
-----END PGP SIGNATURE-----
7:34 a.m.
Hi,
> It's either that or when I asked someone else to install the
kernel, they
> used rpm -Uv and ignored the postun (etc) errors... Now that will have
> screwed things up!
I installed the kernel you posted about and I did not get any errors
on install, plus I am running it right now just fine. What I DID
get was for some reason /boot was not mounted at that time, the
kernel files were instead copied into the mountpoint itself (ie, the
/boot in the root filesystem that should be an empty mountpoint
"covered over" by the actual mounted /boot filesystem). I had to
mount the boot filesystem elsewhere and copy over the files from
/boot into it, adjust /boot/grub/grub./conf and then reboot and it
worked fine. I think this was to do with recent initscripts
troubles at the time I installed the new kernel.
That sounds like what I'm having. Exactly how did you get things back again (a
step by step would be nice).
One thing I've noticed - I've run the rescue, chroot to /mnt/sysimage and run
yum -y --exclude=swig update. I'm getting a lot of post error 255s. Not on
every package though.
Looks like something is seriously snarled :-(
TTFN
Paul
--
Get your free @ukpost.com account now
http://www.ukpost.com/
11:06 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 05 December 2004 13:34, Paul F. Johnson wrote:
Hi,
> > It's either that or when I asked someone else to install the kernel,
> > they used rpm -Uv and ignored the postun (etc) errors... Now that will
> > have screwed things up!
>
> I installed the kernel you posted about and I did not get any errors
> on install, plus I am running it right now just fine. What I DID
> get was for some reason /boot was not mounted at that time, the
> kernel files were instead copied into the mountpoint itself (ie, the
> /boot in the root filesystem that should be an empty mountpoint
> "covered over" by the actual mounted /boot filesystem). I had to
> mount the boot filesystem elsewhere and copy over the files from
> /boot into it, adjust /boot/grub/grub./conf and then reboot and it
> worked fine. I think this was to do with recent initscripts
> troubles at the time I installed the new kernel.
That sounds like what I'm having. Exactly how did you get things back again
(a step by step would be nice).
I think it is a different situation from yours. My problem was caused by the
filesystem for /boot not being mounted somehow (not by my actions) at the
time that the kernel was installed. So it installed the kernel files that
should have gone on the /boot filestystem directly on the /boot mountpoint
directory itself instead of the filesystem that should have been mounted
there. When I rebooted, I DID get my normal and proper /boot filesystem
coming up, just not with those new kernel files in it. I realized what had
happened and unmounted /boot by hand, mounted it on a temporary mountpoint
and copied the files over. This behaviour is different to what you have been
saying.
One thing I've noticed - I've run the rescue, chroot to
/mnt/sysimage and
run yum -y --exclude=swig update. I'm getting a lot of post error 255s. Not
on every package though.
Hum not sure I would be doing anything until I understood what had happened
with /boot. If you mount the partition that contains your /boot filesystem
by hand, what is in there? Your old, previously installed kernel files or
just the new ones, or nothing, or what?
Looks like something is seriously snarled :-(
Could be... doing a yum with the thing in its current state does not sound
like the right way forward until you can trust your system...
- -Andy
- --
http://www.addintelligence.co.uk -- we design custom hardware and software for
your products
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBs0AKjKeDCxMJCTIRApTXAKCEg0nxT1QsUm0poxa2/ArvSoBj4QCdEKb7
xNvlzNUQORXZeZdlYJVDs90=
=T8MB
-----END PGP SIGNATURE-----
12:32 p.m.
"Paul F. Johnson" <paul(a)all-the-johnsons.co.uk> writes:
I doubt the MBR is shafted as the machine is booting to grub, though
I have noticed that /dev/hda1 does have a very old version of the
system files in it, which makes me wonder if something is getting a
wee bit confused.
What do you mean by system files?
You mentioned having /boot on /dev/hda2
Do you have a /boot directory on both /dev/hda1 and /dev/hda2
If so, that may be the source of your trouble.
7079
days inactive
7079
days old
6 comments
3 participants
participants (3)
-
Andy Green -
Harry Putnam -
Paul F. Johnson