(Please reply to the bug, not to me - if you just reply to me, other
maintainers can't see your reply. Quoting full-text here for the benefit
of other maintainers.)
On 10/05/12 14:22, Jürgen Kaiser wrote:
> Am Donnerstag, 10. Mai 2012, 13:48:05 schrieben Sie:
>> As far as I understand it, what dbus does (no explicit stop directives)
>> is meant to work [...]
>
> For run level 1 by my personal opinion dbus should be stopped, because I see
> this run level as pour maintance mode and I need no dbus services in this
> mode, may be I am wrong here, but this question has a more philosophic nature.
/etc/init.d/killprocs is run in runlevel 1, and should kill dbus, as far
as I can see; so we shouldn't need to run the script.
>> This might mean that something has changed in dbus and/or init more
>> recently, such that the way init kills it no longer works? (The same
>> dbus version worked fine last time I rebooted my laptop, though.)
>
> May be their is a change but that is beyond my time to check. I would also
> think of changing in basic kernel features called by halt. My squeeze on the
> notebook I talking about runs until this mature update with kernel 2.6.38.
>
>> Alternatively: what upgrade path did you use on the machine where init
>> stalls waiting for dbus?
>
> I have made bad experience with simple updating a debian system from an old
> to
> new version. So generally I do a complete new install process.
OK, so you're essentially using a new installation on both machines, and
in particular, the /etc on both machines is from wheezy and has not been
upgraded from squeeze?
> -Update from squeeze to wheezy has been done by clearly fresh installation on
> a fresh partition with debootstrap, partition cleaned before with mkfs.ext4.
> then manually added packages as I need.
> - Preparation has been done on desktop system and than, after system is
> working correct, this installation has been copied using rsync excluding
> nonstatic dirs like sys, proc, tmp, etc to the notebook and notebook specific
> changes are added.
>
> For Information: I have a lot of machines to care for, so I handle it over
> years in this way:
> - trying to have similar hardware (if possible) in processor type and graphic
> cards to minimalize special configurations
> - setup debian version on a single machine prepare it
> - copy this installation to all other machines and make miniaml modifications
> like hostname, fstab, etc
> - from this point on all machines run aptitude dist-upgrade periodically
> avoiding mixing of debian versions
>
>> Similarly, did you say you had a similar machine where init *does* kill
>> dbus properly without any intervention from you? If you do, what version
>> of Debian did you originally install on that machine, and what upgrade
>> path did you use there?
> See last remark for debian installation.
>
> The desktop system on which I have prepared the system do a shutdown.
> The notebook system on which prepared system is copied to from desktop system
> do not shutdown without stopping explicitely dbus.
Right, so either the problem is related to one of the changes you made
for the notebook, or it's hardware-specific.
> One remark about my expirience with linux on notebooks: The acpi bios is very
> often buggy, there is no help from manufactorer and we (running linux) have
> to
> live with this situation or do hard work in reenginiering. As I see kernel
> devoloper do here a hard work and fix a lot. Maybe the whole thing is a bios
> bug on my notebook invoked by dbus???
>
>> I'd be interested to hear what happens with the packaged Debian kernel
>> (linux-image-3.2.0-2-amd64 from unstable and/or
>> linux-image-3.3.0-trunk-amd64 from experimental), if those can boot on
>> your hardware.
> Sorry but I have spend now some days with get the notebook run with wheezy. I
> have not enough time to test some other debian kernels. I have send my bug
> report hoping I could help a little bit to people having similar problems.
>
> I see people on Ubuntu 12.04 have problems shutting down notebooks, then add
> INIT_HALT=POWEROFF to /etc/default/halt and after this modification they have
> success. It tried it and shutdown process succeded. But I think that this
> solution is not the right way, because halt then do not a poweroff so
> different hardware could be enabled after shutdown which is not a good
> solution if a notebook runs on battery.
What is in /etc/default/halt on each of your machines?
Are you absolutely sure that adding/removing stop symlinks for dbus, and
not changing anything else, made the notebook power off / not power off?
Might you have changed something else at the same time, like
/etc/default/halt or the difference between shutdown -h and shutdown -hP?
(I wouldn't be surprised if halt vs. poweroff matters on certain
notebook hardware, but that shouldn't be anything to do with
dbus-daemon, which is fundamentally just a message-passing daemon with a
Unix socket - it doesn't do anything to hardware-related itself.)
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
