Your message dated Sun, 17 Mar 2019 10:16:26 +0100
with message-id <[email protected]>
and subject line Re: rfkill state not restored after reboot
has caused the Debian Bug report #815934,
regarding rfkill state not restored after reboot
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
815934: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815934
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 215-17+deb8u3
Severity: normal
Dear Maintainers,
I noticed that rfkill state for both wifi and bluetooth is not restored
on reboots on Hummingboard and Cubox-i.
1) Let me focus on wifi first:
The behaviour I see is:
it always starts up soft-blocked no matter if I unblocked it before
rebooting, or not.
In /var/lib/systemd/rfkill a state-file is created which shows 1 if wifi
was blocked before last reboot, and 0 if it was unblocked.
So I conclude that saving the state works fine.
So I investigated the status of [email protected], and
found that its reported to have exited without error.
--> I guess that systemd tries to restore therfkill state too early,
that is before the actual rfkill device / wifi device is properly
initialized. (is this #809323 ?)
There is still a ghost around here, as I got the state restored properly
at least once now, without changing *anything* at all.
2) Bluetooth:
There is no state-file created in /var/lib/systemd/rfkill for the
bluetooth device.
But I should add that this specific bluetooth chip requires manualy
loading firmware from userspace, and only then it comes up.
br
Josua Mayer
-- Package-specific info:
-- System Information:
Debian Release: 8.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)
Kernel: Linux 3.14.60-fslc-imx6-sr (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-59
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1+b1
ii libblkid1 2.25.2-6
ii libc6 2.19-18+deb8u3
ii libcap2 1:2.24-8
ii libcap2-bin 1:2.24-8
ii libcryptsetup4 2:1.6.6-5
ii libgcrypt20 1.6.3-2+deb8u1
ii libkmod2 18-3
ii liblzma5 5.1.1alpha+20120614-2+b3
ii libpam0g 1.1.8-3.1+deb8u1
ii libselinux1 2.3-2
ii libsystemd0 215-17+deb8u3
ii mount 2.25.2-6
ii sysv-rc 2.88dsf-59
ii udev 215-17+deb8u3
ii util-linux 2.25.2-6
Versions of packages systemd recommends:
ii dbus 1.8.20-0+deb8u1
ii libpam-systemd 215-17+deb8u3
Versions of packages systemd suggests:
pn systemd-ui <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
On Mon, 29 Oct 2018 10:46:33 +0100 Michael Biebl <[email protected]> wrote:
> Control: tags -1 + moreinfo
>
>
> Hi
>
> On Thu, 25 Feb 2016 23:23:31 +0100 Josua Mayer <[email protected]>
> wrote:
> > Package: systemd
> > Version: 215-17+deb8u3
> > Severity: normal
> >
> > Dear Maintainers,
> >
> > I noticed that rfkill state for both wifi and bluetooth is not restored
> > on reboots on Hummingboard and Cubox-i.
> >
> > 1) Let me focus on wifi first:
> > The behaviour I see is:
> > it always starts up soft-blocked no matter if I unblocked it before
> > rebooting, or not.
> > In /var/lib/systemd/rfkill a state-file is created which shows 1 if wifi
> > was blocked before last reboot, and 0 if it was unblocked.
> >
> > So I conclude that saving the state works fine.
> > So I investigated the status of [email protected], and
> > found that its reported to have exited without error.
> >
> > --> I guess that systemd tries to restore therfkill state too early,
> > that is before the actual rfkill device / wifi device is properly
> > initialized. (is this #809323 ?)
> >
> > There is still a ghost around here, as I got the state restored properly
> > at least once now, without changing *anything* at all.
> >
> > 2) Bluetooth:
> > There is no state-file created in /var/lib/systemd/rfkill for the
> > bluetooth device.
> > But I should add that this specific bluetooth chip requires manualy
> > loading firmware from userspace, and only then it comes up.
> Is this problem still reproducible with recent version of systemd?
systemd-rfkill has seen considerable changes between v215 and v241 so
the original issue most likely no longer applies to a current systemd
version.
Since we had no further feedback I'm going to close this bug report.
Joshua, if it's still an issue today, please let us know.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
