cannot connect to a bluetooth speaker
by Federico Bruni
Hi all
I've tried posting this message via the web interface yesterday, but I
don't see it in the archives. So I'm sending it again by regular email.
I have two speakers:
$ hcitool scan
Scanning ...
AC:89:95:DA:52:5E Beoplay M5_27502524
00:12:6F:3F:BD:D5 Mu-so Qb BT 7047
I can connect via bluetooth to both using my Android phone.
I can connect via bluetooth only to Mu-so using Fedora 27.
If I try the bluetooth connection using GNOME setting, I don't get much
information. I just see that it tries the connection and after a while
it fails.
On a terminal I get a timeout:
$ bt-device -c AC:89:95:DA:52:5E
Connecting to: AC:89:95:DA:52:5E
Error: Timeout was reached
Finally, journalctl seems to suggest that may be some kernel problem?!?
Mar 22 07:36:45 fedora kernel: Bluetooth: hci0: last event is not cmd
complete (0x0f)
I found the same error message in this bug report, which is for Fedora
28 though:
https://bugzilla.redhat.com/show_bug.cgi?id=1514836#c15
Thanks in advance for any suggestion
Federico
PS The bluetooth service is running fine:
$ systemctl status bluetooth
* bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled;
vendor preset: enabled)
Active: active (running) since Thu 2018-03-22 07:25:05 CET; 26min ago
Docs: man:bluetoothd(8)
Main PID: 759 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 4915)
CGroup: /system.slice/bluetooth.service
`-759 /usr/libexec/bluetooth/bluetoothd
Mar 22 07:25:05 fedora systemd[1]: Starting Bluetooth service...
Mar 22 07:25:05 fedora bluetoothd[759]: Bluetooth daemon 5.48
Mar 22 07:25:05 fedora bluetoothd[759]: Starting SDP server
Mar 22 07:25:05 fedora systemd[1]: Started Bluetooth service.
Mar 22 07:25:05 fedora bluetoothd[759]: Bluetooth management interface
1.14 initialized
Mar 22 07:25:19 fedora bluetoothd[759]: Endpoint registered:
sender=:1.69 path=/MediaEndpoint/A2DPSource
Mar 22 07:25:19 fedora bluetoothd[759]: Endpoint registered:
sender=:1.69 path=/MediaEndpoint/A2DPSink
Mar 22 07:42:45 fedora bluetoothd[759]: No cache for AC:89:95:DA:52:5E
2 years, 10 months
Thumb Drive Question
by Beartooth
All of / on my main machine will go easily onto even a
modest thumb drive -- "df -h /" says only 11 GB; meseems I've
heard of other people keeping back-ups on thumb drives.
But what about the OS? If I were to put, say, the current
release of Fedora onto the same stick, would I be able to use
that, while visiting in-laws for instance, as if it were a live
CD =with= all my data?
--
Beartooth Implacable, Neo-Redneck Linux Enthusiast
Freedom is my issue : I'm pro-choice, pro-right-to-die,
pro-gun, and pro-term-limits. Without defiance, no liberty.
2 years, 10 months
syncing ESP on UEFI computers, was: F19 RAID1 drive died - what if it
was sda that died?
by Chris Murphy
Upstream md/mdadm list ( linux-raid(a)vger.kernel.org ) archives have a
bunch of proscriptions on using mdadm to sync EFI System partitions.
Last time I checked circa Fedora 21, the installer would in fact let
you setup a raid1 and mark it for use as /boot/efi (i.e. the ESP).
There are a bunch of logical and domain violations by doing this, but
the biggest reason for not doing it is if there is a change to either
ESP, mdadm raid cannot resolve the ambiguity, and if it discovers
mismatches in sectors between the two drives, it can mix and match the
fixups: some sectors from A go to B, and some sectors from B go to A.
And that's because mdadm has no idea which one is correct, only that
they are different, and a resync just makes them the same again. So it
can end up corrupting both ESPs.
The firmware is allowed to modify the ESP even though this is probably
rare in practice.
Anyway, I think it's better to change the symlink in /etc/
grub2-efi.cfg -> ../boot/efi/EFI/fedora/grub.cfg
So that it points to /boot/grub2/grub.cfg just as it does on BIOS
systems. Then create a "forwarding" grub.cfg on /boot/efi that goes
and finds the real grub.cfg. The real grub.cfg is on either /boot or /
on some kind of RAID so getting GRUB to find it is actually pretty
easy: it will look for an md UUID (the mdadm raid volume ID) and then
it needs to look for a file system volume UUID. Since these things are
the same on all member volumes, so long as you have the minimum drives
needed for successful degraded operation, GRUB will find the real
grub.cfg.
And GRUB finds the forwarding one, just by the fact it's in the same
directory on /boot/efi/EFI/fedora as the bootloader.
It's possible to use the real grub.cfg as a template, and just chop it
down to a few lines needed to search for the two UUIDs. And then use
the configfile command to point to the path to the real grub.cfg.
The result is completely seamless jump from the ESP forwarding
grub.cfg, to the /boot real grub.cfg. And by changing the /etc
symlink, grubby will update the real grub.cfg. And this will survive
major version upgrades. And it's more compatible with upstream GRUB.
Effectively the contents of /boot/efi (the ESP) never get modified, so
they two ESPs are never out of sync.
Just, if for any reason you need to recreate the grub.cfg from scratch
you have to put it on /boot/grub2 rather than /boot/efi.
And in the event of shim or grub update, you'll want to sync the ESPs
with e.g. rsync which you can do manually, as a one time thing.
Blah.
Chris Murphy
2 years, 10 months
Kernel installed in wrong location
by CLOSE Dave
Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
the right place (/boot) and is not detected by GRUB. Why not?
For example, after installing the most recent new kernel, I see this.
[root@machine ~]# ls /boot
7725dfc225d14958a625ddaaaea5962b
config-4.14.11-300.fc27.x86_64
efi
extlinux
grub2
initramfs-0-rescue-7725dfc225d14958a625ddaaaea5962b.img
initramfs-4.14.11-300.fc27.x86_64.img
initrd-plymouth.img
loader
lost+found
System.map-4.14.11-300.fc27.x86_64
vmlinuz-0-rescue-7725dfc225d14958a625ddaaaea5962b
vmlinuz-4.14.11-300.fc27.x86_64
[root@machine ~]# ls /boot/7725dfc225d14958a625ddaaaea5962b
0-rescue 4.13.10-200.fc26.x86_64 4.13.9-200.fc26.x86_64
4.11.11-300.fc26.x86_64 4.13.11-200.fc26.x86_64 4.14.11-300.fc27.x86_64
4.12.11-300.fc26.x86_64 4.13.12-200.fc26.x86_64 4.14.4-200.fc26.x86_64
4.12.12-300.fc26.x86_64 4.13.13-200.fc26.x86_64 4.14.5-200.fc26.x86_64
4.12.13-300.fc26.x86_64 4.13.15-100.fc25.x86_64 4.14.6-200.fc26.x86_64
4.12.14-300.fc26.x86_64 4.13.15-200.fc26.x86_64 4.15.8-300.fc27.x86_64
4.12.5-300.fc26.x86_64 4.13.16-200.fc26.x86_64 4.15.9-300.fc27.x86_64
4.12.8-300.fc26.x86_64 4.13.16-202.fc26.x86_64
4.12.9-300.fc26.x86_64 4.13.4-200.fc26.x86_64
But RPM thinks the new kernel was installed correctly!
[root@machine ~]# rpm -V kernel-core-4.15.9-300.fc27
(no output)
--
Dave Close
2 years, 10 months
Razer laptop Caps-lock key of the death
by Jeandet Alexis
Hi all,
I'm an happy Fedora user, I changed my laptop last year for a Razer
sealth blade.
Fedora/Linux works well except for the known caps-lock key which just
crash the whole system when pressed:
https://github.com/rolandguelle/razer-blade-stealth-linux#caps-lock-
crash
I tried to add XKBOPTIONS="ctrl:nocaps" in /etc/default/keyboard.
The thing is that this solution doesn't seems to work on Fedora, not
easy to find what to search on Google, it looks like
/etc/default/keyboard isn't right config file.
I'm using Gnome with Wayland. Any idea?
This issue/feature is quite fun to show to friends(looks like an auto-
destruct key) but quite annoying when you press caps-lock by mistake
:).
Yes getting it solved by Razer would be the best! But last time I asked
them something, I got:
"
Hi Alexis,
Thank you for contacting Razer Support.
At this time, Razer does not officially support Linux. I am sorry for
the inconvenience this might cause you.
Have a nice Monday!
"
Best regards,
Alexis.
2 years, 10 months
Restart Xorg server and Noveau driver
by Javier Perez
Hi.
Xorg froze while playing a game with wine. Only the mouse worked (not even
the keyboard). I had to hard reboot.
Checking out the logs (journalctl) I saw repetitive nouveau errors.
(sorry, not at home, else I´d post them).
Other times I have been able to ssh into my machine and everything else is
working. I did not try this time (my secondary machine is down for the
moment).
My question is: How can I restart the Xorg server and/or the nouveau
driver?
If I could ssh into the system, I think I could just restart both and not
have to reboot the whole thing. It is more annoying that anything else
because the machine boots fast, but still I think it should not be
necessary.
Just polishing my skills.
Thanks
--
------------------------------
/\_/\
|O O| pepebuho(a)gmail.com
~~~~ Javier Perez
~~~~ While the night runs
~~~~ toward the day...
m m Pepebuho watches
from his high perch.
2 years, 10 months
sound problem
by François Patte
Bonjour,
When I log-in, sound is deactivated and I have to manually start it, doing:
1-
killall -9 pulseaudio
2-
start-pulseaudio-x11
3- open mixer go to "configation" tab and choose analogic stero duplex.
What is wrong in my sound config and how to correct this.
Thank you.
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
2 years, 10 months
[LEARNING OUTCOME] Wi-Fi WPA Hacking Tool is Totally Useless on New
Wireless Routers
by Turritopsis Dohrnii Teo En Ming
Hi,
I am sharing my learning outcomes.
Recently I downloaded Kali Linux 64-bit Version 2018.1 and ran it on
my HP laptop with the integrated Intel Dual Band Wireless-AC 8260
Wireless Network Card.
I wanted to test if I could hack the Wi-Fi WPA password on Ruckus R700
Access Point (AP) and the Aztech DSL8900GR(AC) Wireless Router. So I
started using the Reaver WPA cracking tool.
I understand that the Reaver tool works because there is a bug with
Wi-Fi Protected Setup (WPS).
I have no luck with Reaver on the Ruckus R700 Access Point. After
running Reaver, I found out that WPS is permanently disabled on the
Ruckus R700 AP with no option to turn it back on at all. Hence It is
not possible to hack the WPA password on Ruckus R700 AP.
Understanding that I couldn't do anything further with Ruckus R700 AP,
I proceeded to test Reaver on the Aztech DSL8900GR(AC) wireless
router. In this case, I also found out that WPS is disabled by default
on the Aztech wireless router. Reaver will not be useful at all if WPS
is disabled. But there is an option to enable WPS. So I enabled WPS in
the Aztech wireless router configuration page. And continued testing
with Reaver. But because Aztech wireless router has the rate limiting
security feature, brute force password attacks will be very slow and
probably take forever. The rate limiting security feature on the
Aztech wireless router is meant to slow you down when you are brute
forcing the WPS pin.
So here is my conclusion: Reaver Wi-Fi WPA hacking tool is totally
useless on new wireless routers which have the WPS disabled or have
implemented a fix for the WPS bug. Are there any other WPA cracking
tools which I can use in my educational learning journey? Please
advise.
Mr. Turritopsis Dohrnii Teo En Ming
Singapore
13 March 2018 Tuesday 4:28 PM Singapore Time
===BEGIN SIGNATURE===
Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 30 Oct 2017
[1] https://tdtemcerts.wordpress.com/
[2] http://tdtemcerts.blogspot.sg/
[3] https://www.scribd.com/user/270125049/Teo-En-Ming
===END SIGNATURE===
2 years, 10 months
Troubleshooting random hangs
by Suvayu Ali
Hi,
I have been having random hangs on my new Ryzen workstation (Ryzen 5
2400G + B350 mobo). My hardware is supposedly properly supported on
4.15+ kernels. But I have been unable to boot with any of the ones in
the repo.
That said, I can boot with older kernels, but the desktop hangs
randomly. When I say hang, I mean it freezes, and my only recourse is
to reset my computer. I have tried to login remotely, but then I get
"No route to host" from ssh. Looking at the journal, I can't figure
out what is causing these hangs. If someone could have a look, that
would be wonderful.
Logs from the last two hangs:
https://paste.fedoraproject.org/paste/8T~X8BYuVboAJK3Mkal72A
https://paste.fedoraproject.org/paste/qypJAnAKE01GD-OgC6n0SQ
TIA,
--
Suvayu
Open source is the future. It sets us free.
2 years, 10 months