When attempting to boot the 2006.0 minimal installation cd on a compaq dl360g2, several errors occur when cause hard lockups on the machine. I was able to circumvent all errors except one with the following boot options: gentoo-nofb noapm nopcmcia nobladecenter acpi=off ide=nodma noapic nodetect nofirewire nolapic nosata nosound nousb nogpm nodhcp nodmraid noscsi nohotplug nosmp nosound docache nodevfs noevms2 nolvm2 nox Booting would proceed up until shortly after hdparm was run during the system init on /dev/hda (the installation cdrom), after which a driveseekready error occurs and lots of SQUASHFS errors prevents the boot from proceeding further. At this point a hard recycle is required to reboot the box. Manually editing the hdparm script in the image.squashfs to not run (exit immediately) fixes the problem. There needs to be an option that can be passed as a boot parm that prevents hdparm from attempting to run in situations like this.
$ grep -C 5 IDEDMA autoconfig GPM="yes" PCMCIA="no" HOTPLUG="yes" APM="no" ACPI="no" IDEDMA="yes" ALSA="yes" X11="yes" get_config() { CMDLINE="$(cat /proc/cmdline)" -- acpi=on|acpi=force) APM="no" ACPI="yes" ;; ide=nodma) IDEDMA="no" ;; nohotplug) HOTPLUG="no" ;; nosound) -- list_services() { get_config local svcs="$(check_svc ${APM} apmd)" svcs="${svcs} $(check_svc ${ACPI} acpid)" svcs="${svcs} $(check_svc ${IDEDMA} hdparm)" svcs="${svcs} $(check_svc ${PCMCIA} pcmcia)" svcs="${svcs} $(check_svc ${GPM} gpm)" svcs="${svcs} $(check_svc ${HOTPLUG} coldplug hotplug)" svcs="${svcs} $(check_svc ${ALSA} alsasound)" -- eend else [ "${ismips}" = "no" ] && ewarn "Not Loading ACPI support ..." fi if [ "${IDEDMA}" = "yes" ] then if [ "${ismips}" = "no" ]; then [ -x /etc/init.d/hdparm ] && start_service hdparm fi fi It honestly should not be running hdparm, at all, since IDEDMA *should* be getting set to "no". I'm reassigning this to the livecd team, sicne it is a problem in livecd-tools. Will reassign back to release once it is fixed and in a released evrsion of livecd-tools until the next release is made.
(In reply to comment #1) > It honestly should not be running hdparm, at all, since IDEDMA *should* be > getting set to "no". I'm reassigning this to the livecd team, sicne it is a > problem in livecd-tools. Will reassign back to release once it is fixed and in > a released evrsion of livecd-tools until the next release is made. hdparm is set to run in the default runlevel within image.squasfs: spanky default # pwd /etc/runlevels/default spanky default # ls -l total 6 lrwxrwxrwx 1 root root 22 Feb 21 18:45 autoconfig -> /etc/init.d/autoconfig lrwxrwxrwx 1 root root 18 Feb 21 18:45 hdparm -> /etc/init.d/hdparm lrwxrwxrwx 1 root root 17 Feb 21 18:45 local -> /etc/init.d/local lrwxrwxrwx 1 root root 17 Feb 21 18:45 pwgen -> /etc/init.d/pwgen lrwxrwxrwx 1 root root 18 Feb 21 18:45 splash -> /etc/init.d/splash lrwxrwxrwx 1 root root 21 Feb 21 18:45 syslog-ng -> /etc/init.d/syslog-ng
...and this is exactly why sometimes another pair of eyes solves the problem. I've updated catalyst CVS for this. When 2.0_rc40 is released, this will be fixed. Reassigning to there until the fix is in a released version of catalyst.
(In reply to comment #3) > ...and this is exactly why sometimes another pair of eyes solves the problem. > I've updated catalyst CVS for this. When 2.0_rc40 is released, this will be > fixed. Reassigning to there until the fix is in a released version of > catalyst. Thanks Chris... I have a stupid question about bugzilla. Am I supposed to change the resolution of this bug at this point, or is that up to the developers?
You don't change it, at all. The developers should always do the chages on those, especially as this bug is *not* "RESOLVED-FIXED" until a new CD comes out. I am reassigning this to release@gentoo.org until either a 2006.0-r1 or 2006.1 is released. (Yes, it is very weird that I reassign this stuff between myself, myself, and myself, being the head of release@ livecd@ and catalyst@ but it helps me track where a bug belongs)
(In reply to comment #5) > You don't change it, at all. The developers should always do the chages on > those, especially as this bug is *not* "RESOLVED-FIXED" until a new CD comes > out. I am reassigning this to release@gentoo.org until either a 2006.0-r1 or > 2006.1 is released. (Yes, it is very weird that I reassign this stuff between > myself, myself, and myself, being the head of release@ livecd@ and catalyst@ > but it helps me track where a bug belongs) Thats cool. I was just scratching my head wondering why bugzilla even gave me the option to set the resolution ;)
*** Bug 126063 has been marked as a duplicate of this bug. ***
FYI: i am seeing the same thing on Compaq dl580. your workaround worked fine
*** Bug 129031 has been marked as a duplicate of this bug. ***
My father-in-law gave me his old DEC laptop (p 200, 32MB RAM, 2GB HD) yesterday, so I just hit the same bug myself.
2006.1 is out, so this is FIXED now.
