LinHES Forums http://forum.linhes.org/ |
|
R5.5 locks hard on reboot after patcher runs http://forum.linhes.org/viewtopic.php?f=1&t=19561 |
Page 1 of 1 |
Author: | Grant_Edwards [ Sat Feb 21, 2009 9:30 pm ] |
Post subject: | R5.5 locks hard on reboot after patcher runs |
I'm trying to do an auto-install of 5.5 on a shuttle zen box that ran a couple different versions of KM for years with no problems. The box was recently used for something else for a few months, and now I'm trying to put it back into service as a KM fe/be machine. I boot from the CD, and do an auto install. That completes and the box reboots. X starts, an xterm asks if I want to use DHCP. I say yes, and it acquires an address. The patcher downloads something and says it must reboot. I press "enter". The xterm scrolls blue blocks and empty space for a few seconds, and then the machine locks hard. I've repeated this sequence several times, and it always acts exactly the same. If I hit the reset button, the LILO loads the zimage, the kernel uncompresses, prints INIT: version 2.86 booting and then hangs hard. Whatever the "patcher" is doing it appears to be a very bad thing. Any suggestions on how to troubleshoot this problem? |
Author: | tjc [ Sat Feb 21, 2009 11:00 pm ] |
Post subject: | |
Disconnect the upstream feed so it can't download the patch, then go through the patcher process manually. |
Author: | Grant_Edwards [ Sat Feb 21, 2009 11:37 pm ] |
Post subject: | |
tjc wrote: Disconnect the upstream feed so it can't download the patch That worked. Now I've got a mostly-working install -- just the usual brokeness in the setup screens: buttons completely off-screen, descriptions and values chopped off so badly you can't tell what they mean, etc. <rant> I've configured the GUI so it fits the screen perfectly, but it's sort of futile when the setup programs don't bother to keep all of the controls within the GUI. After all these years, I can't believe the myth setup programs are still so difficult to use. I've resorted to just typing SQL commands for most things -- it's something you have to learn to do when the default settings for the GUI make it unusable. Running the setup programs remotely never seems to work either. Either the X server crashes or the programs respond so slowly they're unusable. Isn't it about time we just admit that trying to do configuration on a standard-def analog TV screen is futile and switch over to a setup program that runs remotely and talk to the mysql server? </rant> Quote: then go through the patcher process manually.
I think I'll pass on that for now. Is there a list somewhere of what sorts of things the patcher process is going to do? |
Author: | tjc [ Sun Feb 22, 2009 1:06 pm ] |
Post subject: | |
Grant_Edwards wrote: just the usual brokeness in the setup screens: buttons completely off-screen, descriptions and values chopped off so badly you can't tell what they mean, etc. <rant> I've configured the GUI so it fits the screen perfectly, but it's sort of futile when the setup programs don't bother to keep all of the controls within the GUI. ... </rant> This is generally a theme issue which crops up when the designers don't check how well something scales to other resolutions. It dismays me too, but by their very visual/artsy/appearance obsessed nature theme designers tend to lack rigor. "Minor" details like correct ownership, permissions, usability, having things work correctly for people using different hardware or configurations, ... just fly right over their heads. They may notice the "whoosh" noise when this happens, but mostly they can't be bothered to figure out what causes it because they're trying to decide if they like the nearly invisible black drop shadows on the dark charcoal background 3 pixels wide or just 2 . Grant_Edwards wrote: Is there a list somewhere of what sorts of things the patcher process is going to do?
Human has a thread with all the fixes listed or you can download and read the script which has nice comments describing the intent of each of the fixes. With even minimal Unix-fu it should be obvious which fix causes your problems. I'd recommend the backup and restore fixes, RRD update, and the logrotate fix as very safe. Next I'd try the acpid fix and the updated PCI IDs fix. |
Author: | Grant_Edwards [ Tue Feb 24, 2009 5:08 pm ] |
Post subject: | |
Quote: Grant_Edwards wrote: Is there a list somewhere of what sorts of things the patcher process is going to do? Human has a thread with all the fixes listed or you can download and read the script which has nice comments describing the intent of each of the fixes. With even minimal Unix-fu it should be obvious which fix causes your problems. I'd recommend the backup and restore fixes, RRD update, and the logrotate fix as very safe. Next I'd try the acpid fix and the updated PCI IDs fix. Thanks! I'll put that on my list of things to do. |
Author: | Grant_Edwards [ Thu Feb 26, 2009 8:38 pm ] |
Post subject: | |
tjc wrote: Human has a thread with all the fixes listed or you can
download and read the script which has nice comments describing the intent of each of the fixes. With even minimal Unix-fu it should be obvious which fix causes your problems. I'd recommend the backup and restore fixes, RRD update, and the logrotate fix as very safe. Next I'd try the acpid fix and the updated PCI IDs fix. OK, here's the script: Code: #!/bin/sh
# Patcher for R5.5 NEED_TO_RESTART_X=0 NEED_TO_REBOOT=0 # 2008/09/12) backup/restore updates & RRD updates # 2008/09/14) makes the 6200 LE use the proper nVidia driver version # 2008/10/12) more RRD updates # 2008/10/12) Firefly remote detection fix # 2008/10/12) fixed a duplicate tuner device setup bug cd / wget -c ftp://ftp.knoppmyth.net/R5/R5.5/R5.5.patches.tar.bz2 tar xjf R5.5.patches.tar.bz2 # 2008/09/15) acpid fix update-rc.d acpid start 12 2 3 4 5 . stop 88 0 1 6 . # 2008/09/15) update PCI IDs for newer hardware update-pciids NEED_TO_REBOOT=1 # 2008/09/15) fix logrotate /bin/rm -f /etc/logrotate.d/hibernate-script # Reboot if any of the above fixes will only take effect after # a reboot. if [ $NEED_TO_REBOOT -eq 1 ]; then echo "*** The KnoppMyth patcher has made some changes that *** will not take effect until a reboot. After the reboot, you *** may be prompted to redo some steps. *** Press ENTER to reboot." read CONTINUE; reboot; fi # Restart X if any of the above fixes will only take effect after # X restarts. This has the side-effect of re-running KnoppMyth-run. if [ $NEED_TO_RESTART_X -eq 1 ]; then echo "*** The KnoppMyth patcher has made some changes to *** running programs and needs to restart them. *** You may be prompted to redo some steps. *** Press ENTER to continue." read CONTINUE; pkill xinit; fi OK, I see the comments describing the 9 fixes, but I only see code that runs the fixes for 3 of them: logrotate, acpid, and pci ids. ?? |
Author: | Grant_Edwards [ Thu Feb 26, 2009 8:48 pm ] |
Post subject: | |
Grant_Edwards wrote: OK, I see the comments describing the 9 fixes, but I only see
code that runs the fixes for 3 of them: logrotate, acpid, and pci ids. I think I get it: simply untarring the file applies the other fixes. That's sort of nasty. There's now way to tell which files go with which fixes and no way to apply them individually. |
Author: | tjc [ Thu Feb 26, 2009 11:39 pm ] |
Post subject: | |
Yeah, but nobody had the stomach for maintaining a whole swarm of separate tar files. Given that our rate limiting step is generally developer time... Well tradeoffs have to be made. <shrug> |
Author: | Grant_Edwards [ Thu Mar 12, 2009 11:26 am ] |
Post subject: | |
tjc wrote: Yeah, but nobody had the stomach for maintaining a whole swarm That's understandable.of separate tar files. Quote: Given that our rate limiting step is generally developer time... Fortunately, there's an unlimited supply of whinging. Quote: Well tradeoffs have to be made. <shrug>
|
Page 1 of 1 | All times are UTC - 6 hours |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |