I haven't had time to do much investigation on this yet, but last night I genned FC5 from the DVD, it came up OK, then I downloaded all the latest updates which got me to 2.6.17-1.2157 and now the boot never seems to finish - it just stops printing messages really early (possibly around the time it normally switches to the graphical boot which I hadn't yet turned off). The disk doesn't seem to be running anymore and a reasonable amount of waiting didn't change anything. It isn't totally frozen - I can still hit return, and the cursor moves down one line, and Ctrl-Alt-Del reboots it.
Sound familiar to anyone?
I plan to boot in rescue mode and set the runlevel to 3 and turn off the graphical boot and see if there is anything useful laying around in dmesg or the X log. Anything else be good to poke?
This is on a asus P4C800-E with the disk on the onboard promise controller (the faster intel sata ports are already used up with another OS).
tomhorsley@adelphia.net schrieb:
I haven't had time to do much investigation on this yet, but last night I genned FC5 from the DVD, it came up OK, then I downloaded all the latest updates which got me to 2.6.17-1.2157 and now the boot never seems to finish - it just stops printing messages really early (possibly around the time it normally switches to the graphical boot which I hadn't yet turned off). The disk doesn't seem to be running anymore and a reasonable amount of waiting didn't change anything. It isn't totally frozen - I can still hit return, and the cursor moves down one line, and Ctrl-Alt-Del reboots it.
Sound familiar to anyone?
If you search the list archive of the last 1 or 2 weeks: yes. Reports about hanging boot at nash. There are bugzilla tickets about it.
I plan to boot in rescue mode and set the runlevel to 3 and turn off the graphical boot and see if there is anything useful laying around in dmesg or the X log. Anything else be good to poke?
This is on a asus P4C800-E with the disk on the onboard promise controller (the faster intel sata ports are already used up with another OS).
Do you use dm-raid?
Alexander
On Fri, 21 Jul 2006 07:16 -0400, tomhorsley@adelphia.net wrote:
I haven't had time to do much investigation on this yet, but last night I genned FC5 from the DVD, it came up OK, then I downloaded all the latest updates which got me to 2.6.17-1.2157 and now the boot never seems to finish - it just stops printing messages really early (possibly around the time it normally switches to the graphical boot which I hadn't yet turned off). The disk doesn't seem to be running anymore and a reasonable amount of waiting didn't change anything. It isn't totally frozen - I can still hit return, and the cursor moves down one line, and Ctrl-Alt-Del reboots it.
Sounds very familiar to me. I was about to post the following when I saw your message:
I've been a UNIX admin (mostly Solaris) for many years, but am relatively new to Linux and need some pointers from the old hands. We have three 1u servers running FC5 that are used as name servers. All three machines are identical hardware:
Intel SCB2 Motherboard 1200 Chassis BIOS 8CB20.86B.0065.P19.0208221005 Dual Pentium III 1.2 GHz 2 GB RAM 2 80 GB IDE drives Promise FastTrack 100 Controller configured for RAID 1
I recently updated one of the machines from Fedora Core 2.6.16-1.2133_FC5smp to 2.6.17-1.2157_FC5smp.
Quiet mode is disabled in grub.conf. Under 2.6.16-1.2133_FC5smp, reboots occasionally (maybe 1 time out of 10) hang at "Making device-mapper control node". It's annoying, but not crippling. However after the update to 2.6.17-1.2157_FC5smp, reboots *always* hang at that point.
For the time being I have reverted to 2.6.16-1.2133_FC5smp, but I don't like the prospect of not being able to update the kernel beyond that version. Any ideas on what might be causing this and what I can do to get around it will be greatly appreciated.
On Wed, 2006-07-26 at 16:00 -0400, Chip Old wrote:
For the time being I have reverted to 2.6.16-1.2133_FC5smp, but I don't like the prospect of not being able to update the kernel beyond that version. Any ideas on what might be causing this and what I can do to get around it will be greatly appreciated.
I eventually got 2157 to boot by editing the init script in the initrd image to utterly eradicate all references to the Windows XP raid that I don't want to access from linux (but which linux insisted on trying to access anyway). If you are actually trying to boot from a raid you need to be able to access, the solution isn't as simple. My bugzillas with more details about what I did are:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199793 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199831
The bigger bugzilla that has lots of details is:
On Wed, 26 Jul 2006 19:13 -0400, Tom Horsley wrote:
I eventually got 2157 to boot by editing the init script in the initrd image to utterly eradicate all references to the Windows XP raid that I don't want to access from linux (but which linux insisted on trying to access anyway). If you are actually trying to boot from a raid you need to be able to access, the solution isn't as simple. My bugzillas with more details about what I did are:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199793 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199831
The bigger bugzilla that has lots of details is:
Thanks Tom. In this case FC5 is the only OS on the box, and we're booting from the raid array. Apparently Linux kernel 2.6.17.7 has just been released. This is a production box (one of our DNS servers) so rather than fool around with 2.6.17-1.2157_FC5smp any more I'll wait for the new kernel to show up in yum and see what happens with that.
On Wed, 26 Jul 2006 16:00 -0400, Chip Old wrote:
On Fri, 21 Jul 2006 07:16 -0400, tomhorsley@adelphia.net wrote:
I haven't had time to do much investigation on this yet, but last night I genned FC5 from the DVD, it came up OK, then I downloaded all the latest updates which got me to 2.6.17-1.2157 and now the boot never seems to finish - it just stops printing messages really early (possibly around the time it normally switches to the graphical boot which I hadn't yet turned off). The disk doesn't seem to be running anymore and a reasonable amount of waiting didn't change anything. It isn't totally frozen - I can still hit return, and the cursor moves down one line, and Ctrl-Alt-Del reboots it.
Sounds very familiar to me. I was about to post the following when I saw your message:
I've been a UNIX admin (mostly Solaris) for many years, but am relatively new to Linux and need some pointers from the old hands. We have three 1u servers running FC5 that are used as name servers. All three machines are identical hardware:
Intel SCB2 Motherboard 1200 Chassis BIOS 8CB20.86B.0065.P19.0208221005 Dual Pentium III 1.2 GHz 2 GB RAM 2 80 GB IDE drives Promise FastTrack 100 Controller configured for RAID 1
I recently updated one of the machines from Fedora Core 2.6.16-1.2133_FC5smp to 2.6.17-1.2157_FC5smp.
Quiet mode is disabled in grub.conf. Under 2.6.16-1.2133_FC5smp, reboots occasionally (maybe 1 time out of 10) hang at "Making device-mapper control node". It's annoying, but not crippling. However after the update to 2.6.17-1.2157_FC5smp, reboots *always* hang at that point.
For the time being I have reverted to 2.6.16-1.2133_FC5smp, but I don't like the prospect of not being able to update the kernel beyond that version. Any ideas on what might be causing this and what I can do to get around it will be greatly appreciated.
FWIW, the issue still exists with Fedora Core 2.6.17-1.2174. On reboot the box still hangs at "Making device-mapper control node".
On 23/08/06, Chip Old fold@bcpl.net wrote:
FWIW, the issue still exists with Fedora Core 2.6.17-1.2174. On reboot the box still hangs at "Making device-mapper control node".
These reports could all be manifestations of this bug that I reported quite a while ago:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196590
basically, when the installonlyn yum plugin is enabled, a transaction that requires the installation of a new kernel and removal of an old kernel, and also upgrades package foo, it may erroneously remove and install foo during the transaction, rather than updating it. This has the effect of nuking any config files which are associated with package foo (moving them to .rpmsave files). If foo happens to be initscripts, you could end up with an unbootable system - see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197906
This is a pretty horrible state of affairs - I now resort to forcing kernel upgrades into their own transaction to avoid this. I am quite surprised this bug hasn't received more developer time and been resolved - having a bug in the wild which renders FC5 systems unbootable is pretty serious. Progress seems to have stalled with the maintainer of rpmlib.
Jonathan.
Jonathan Underwood wrote:
resolved - having a bug in the wild which renders FC5 systems unbootable is pretty serious. Progress seems to have stalled with the maintainer of rpmlib.
I read the Bugzillas but I didn't see anything about progress stalling with the maintainer of rpmlib... is there more to the story?
There are some serious politics going on around "the maintainer of rpmlib" at the moment
http://lwn.net/Articles/196523/
(subscribers-only for a week I'm afraid)
-Andy
On 23/08/06, Andy Green andy@warmcat.com wrote:
I read the Bugzillas but I didn't see anything about progress stalling with the maintainer of rpmlib... is there more to the story?
There are some serious politics going on around "the maintainer of rpmlib" at the moment
I wasn't making a political statement - just that the latest progress on bug 196590 seems to point towards a problem in rpmlib, and that's as far as the problem has got - I probably shouldn't have used the term "stalled", just that there's been no update on that.
-
Alexander Dalloz -
Andy Green -
Chip Old -
Jonathan Underwood -
Tom Horsley