[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ibook troubles after dist-upgrade

After moving from woody to sid (using the very same kernel, some 2.4.18-benX, which has worked flowlessly for more than 1 year, including power management, sound, etc), I face the following problems on an ibook 1 (it's one of these dual-colored almost round plastic boxes, this one is orange).

(Sorry for not-quoted error messages, I don't have the machine in front of me right now)

1) Bootstrap

Although I didn't touch any init script or /etc/fstab, during the init phase for runlevel 2 many scripts complain about an empty /proc directory. Indeed, after "Mounting local filesystems" it prints "/proc is already mounted" - but after logging in, I see that /proc is really empty. mounts states

proc on /proc type proc (rw)

A following mount /proc does not complain about /proc already being mounted, and voila- I see the contents on ls /proc.

In fstab, I have (like on all my x86 machines)

proc     /proc    proc   defaults   0    0

What the heck...?


ALSA worked fine with 0.9.0beta10. Now I updated to 0.9.3 (or whatever is current in sid), and it does not work at all. In fact, it modprobes some i2c modules and presumably snd-powermac, but the machine freezes solid when restoring the volumes. I have to press the power button for over 10 seconds to make it reboot. All config files were produced by debconf, no manual changes.

3) Power management

This one might be related to ALSA, but since I put an "exit 0" in init.d/alsa, perhaps not... However: snooze, which worked perfectly previously, now also freezes the machine. The display goes dark, and that's it. Hard lock. No syslog entries (and a horrible fsck on reboot, which I also have problems with because of a totally skrewed keymap during the phase of the fsck)

4) XFree strangeness

Altough I use the same XF86Config-4 like before with Woody, X failed to come up with sid. lspci revealed that the VGA adapter has PCI ID 0:10.0, while my old XF86Config-4, which - as said - has worked over a year, states 0:16.0. How is it possible that the PCI ID changed?! (That's not a real problem, since I simply need to adapt my XF86COnfig-4, but - coming from the x86 world - I'm somewhat puzzled...)

Has anyone ever heard of these problems? Can anyone help?

Logs and further info can be provided tonight.


Thomas Winischhofer
thomas AT winischhofer DOT net          *** http://www.winischhofer.net/
twini AT xfree86 DOT org

Reply to: