Page 11 of 12

Re: Buster bug report thread

Posted: Thu Nov 21, 2019 2:07 pm
by ShiftPlusOne
yan wrote:
Tue Nov 19, 2019 8:46 pm
I can access the drive from the desktop shortcut and from the terminal.
If you update everything now and reboot, is the behaviour any better?

Re: Buster bug report thread

Posted: Thu Nov 21, 2019 3:06 pm
by yan
ShiftPlusOne wrote:
Thu Nov 21, 2019 2:07 pm
yan wrote:
Tue Nov 19, 2019 8:46 pm
I can access the drive from the desktop shortcut and from the terminal.
If you update everything now and reboot, is the behaviour any better?
Yes, the latest updates (libfm-data libfm-extra4 libfm-gtk-data libfm-gtk4 libfm-modules libfm4 lxplug-ejecter pcmanfm),
solved the problem .

Thanks!

Re: Buster bug report thread

Posted: Mon Nov 25, 2019 12:00 pm
by AmigaGamer
File Manager : when mounting SMB/CIFS shares via gvfs, either through the file manager "smb://server/share" or "gio mount smb://server/share" , the included pcmanfm file manager shows %20 instead of spaces in file names
eg "My Music" shows as "My%20Music".
This does not happen in Thunar. It also does not happen if the shares are mounted more traditionally to a folder with "mount -t cifs" or through fstab

Re: Buster bug report thread

Posted: Mon Nov 25, 2019 12:02 pm
by DougieLawson
It's not a bug, it's a feature. Simple fix is don't use spaces in file or directory names (as that's insane anyway).

Re: Buster bug report thread

Posted: Mon Nov 25, 2019 4:38 pm
by thatchunkylad198966
Just wondering if this is a bug or not...

Flashed Raspbian-Lite to a SDCARD, updated everything. disabled swap, rebooted.
Went into raspi-configs advance settings (number 7) and then enabled the first option for opengl driver, it says it's disabled.
Rebooted, Kodi stops working so the opengl driver is working but I don't know why it's not saying enabled?

Everything is much faster than the fake kms, just my OCD is kicking in with it saying it's not enabled. :oops: :lol:

Re: Buster bug report thread

Posted: Tue Nov 26, 2019 6:26 am
by Kan
Failed to fetch http://raspbian.raspberrypi.org/raspbia ... _armhf.def when I tried to apt-get install cmake.
I checked above link , this file is not there. How to fix it?
The image is 2019-09-26-raspbian-buster-lite, and the platform is Raspberry Pi 3 Model B+.

Thanks in advance for any help!

Re: Buster bug report thread

Posted: Tue Nov 26, 2019 11:40 am
by DirkS
Kan wrote:
Tue Nov 26, 2019 6:26 am
Failed to fetch http://raspbian.raspberrypi.org/raspbia ... _armhf.def when I tried to apt-get install cmake.
I checked above link , this file is not there. How to fix it?
Are you sure you got the name correct when you manually checked? Normal extension is '.deb', not '.def'.

And that version of the file is not in the repo, so I think you apt cache is not up to date. Did you run 'sudo apt update' before you tried to install?

DisplayLink Support broken

Posted: Fri Nov 29, 2019 12:10 am
by hippy
USB-DisplayLink which was working on a Pi 3B (non-plus) under Stretch no longer appears to be working under Buster.

Details of set-up and configuration previously done at link below, details of results on Buster a couple of posts down.

https://www.raspberrypi.org/forums/view ... 5#p1572897

Added : It may be "framebuffer_depth=16" being ignored in config.txt. After rebooting "fbset -i -v -fb /dev/fb0" shows depth still at 32...

Code: Select all

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'

mode "1920x1080"
    geometry 1920 1080 1920 1080 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

Re: Buster bug report thread

Posted: Sun Dec 01, 2019 11:52 am
by dkeppens
Standard grep now has serious issues in ksh93 with the default alias from /etc/skel/.kshrc : alias grep='command -x grep' and returns exit code "1" on match.
Changing the alias definition to the one bash uses for color matching : alias grep='grep --color=auto' solves the problem but the existing ksh alias seems to be required for handling long argument lists as the commentary line in the skel file indicates.
Please investigate.

Buster release is Linux ###### 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux

Re: Buster bug report thread

Posted: Sun Dec 01, 2019 12:25 pm
by smartpie
Just hit a bug (I am fairly certain) with Openbox Configuration Manager. I changed 2 things. I set my number of desktops back to 1 (from the default of 4) and I tried a few themes, and left it switched to Clearlooks.

I then found I could not resize or move windows anymore. Even after a reboot. Even after setting desktops back to 4 and theme back to PIXflat. The only cure I found was to remove the /home/pi/.config/openbox directory

I think the configuration editor stuffed up a setting somewhere.

Re: Buster bug report thread

Posted: Sun Dec 01, 2019 4:01 pm
by PeterO
I just tried to enable systemd's "predictable network names" while trying to help with this question https://www.raspberrypi.org/forums/view ... 6&t=258195

raspi-config's option to do this no longer seems to work. Is this a regression or is it no longer supported (in which case the option should be removed from raspi-config).

PeterO

Re: Buster bug report thread

Posted: Sun Dec 01, 2019 5:59 pm
by DougieLawson
PeterO wrote:
Sun Dec 01, 2019 4:01 pm
I just tried to enable systemd's "predictable network names" while trying to help with this question https://www.raspberrypi.org/forums/view ... 6&t=258195

raspi-config's option to do this no longer seems to work. Is this a regression or is it no longer supported (in which case the option should be removed from raspi-config).

PeterO
It's a regression. That piece should work in plain DebIan's udev stuff. There's some code added by the RPF folks that breaks it (as the plain DebIan stuff allows other predictable names).

https://wiki.debian.org/NetworkInterfaceNames

I've not looked at whether it's possible to hack that DebIan stuff back into Raspbian.

I'll try
/etc/systemd/network/99-default.link

Code: Select all

[Match]
OriginalName=*

[Link]
NamePolicy=mac
MACAddressPolicy=persistent
next time I boot my systems.

Re: Buster bug report thread

Posted: Sun Dec 01, 2019 6:13 pm
by PeterO
DougieLawson wrote:
Sun Dec 01, 2019 5:59 pm

I've not looked at whether it's possible to hack that DebIan stuff back into Raspbian.

I'll try
/etc/systemd/network/99-default.link

Code: Select all

[Match]
OriginalName=*

[Link]
NamePolicy=mac
MACAddressPolicy=persistent
next time I boot my systems.
I did some diging to try and work out why it did't work as expected. I found
there is already a populated 99-default.link in /lib/systemd/network/ which I assumed took over when the link to /dev/null was removed by raspi-config ?
PeterO

Re: Buster bug report thread

Posted: Mon Dec 02, 2019 3:20 pm
by ShiftPlusOne
AFAIK, persistent names aren't broken, it's just that the default looks like this:
/lib/systemd/network/99-default.link

Code: Select all

#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Link]
NamePolicy=keep kernel database onboard slot path
MACAddressPolicy=persistent
Creating the /dev/null symlink in /etc just overrides that file.

That's probably not a sane default, because it doesn't guarantee that the internal wifi will come up as wlan0. If a USB device is loaded first, that will have the predictable (mac based) name, but the internal interface will come up as wlan1. That causes grief when people set up the pi as a wifi range extender, for example.

I'll take a look at moving it over to a mac based policy for all devices.

Re: Buster bug report thread

Posted: Mon Dec 02, 2019 3:33 pm
by DougieLawson
ShiftPlusOne wrote:
Mon Dec 02, 2019 3:20 pm
I'll take a look at moving it over to a mac based policy for all devices.
Thanks. I'll willingly beta test your changes (until 12th Dec - when I get to be 14,500Km from home).

Re: Buster bug report thread

Posted: Mon Dec 02, 2019 3:44 pm
by PeterO
ShiftPlusOne wrote:
Mon Dec 02, 2019 3:20 pm
AFAIK, persistent names aren't broken, it's just that the default looks like this:
It's not "persistent" names that we are talking about.... It's "predictable" names.

The issue I saw was that enabling "predictable network interface names" with raspi-config caused nothing to change. Wifi was still wlan0, on board ehternet was still eth0. Maybe this is the correct behaviour but it isn't what I expected to happen given that a device naming option had been changed.

PeterO

Re: Buster bug report thread

Posted: Mon Dec 02, 2019 4:13 pm
by ShiftPlusOne
PeterO wrote:
Mon Dec 02, 2019 3:44 pm
ShiftPlusOne wrote:
Mon Dec 02, 2019 3:20 pm
AFAIK, persistent names aren't broken, it's just that the default looks like this:
It's not "persistent" names that we are talking about.... It's "predictable" names.

The issue I saw was that enabling "predictable network interface names" with raspi-config caused nothing to change. Wifi was still wlan0, on board ehternet was still eth0. Maybe this is the correct behaviour but it isn't what I expected to happen given that a device naming option had been changed.

PeterO
Yup, I think we're on the same page.
DougieLawson wrote: Thanks. I'll willingly beta test your changes (until 12th Dec - when I get to be 14,500Km from home).
I don't think it will be happening soon since I don't like pushing changes before going away. I'll be going home for Christmas (15,500km, so I win) and will be completely off the grid for some of that time, so I think it will have to wait.

Re: Buster bug report thread

Posted: Mon Dec 02, 2019 4:20 pm
by DougieLawson
ShiftPlusOne wrote:
Mon Dec 02, 2019 4:13 pm
DougieLawson wrote: Thanks. I'll willingly beta test your changes (until 12th Dec - when I get to be 14,500Km from home).
I don't think it will be happening soon since I don't like pushing changes before going away. I'll be going home for Christmas (15,500km, so I win) and will be completely off the grid for some of that time, so I think it will have to wait.
You must be headed to the other side of Oz or NZ. I'm only going as far as Outer Pomgolia Perth, WA.

Re: Buster bug report thread

Posted: Mon Dec 02, 2019 4:26 pm
by ShiftPlusOne
Yup, Melbourne, so there's a lower risk of running into disgruntled, baseball bat wielding raspberry pi users.

Re: Buster bug report thread

Posted: Mon Dec 02, 2019 5:03 pm
by DougieLawson
ShiftPlusOne wrote:
Mon Dec 02, 2019 4:26 pm
Yup, Melbourne, so there's a lower risk of running into disgruntled, baseball bat wielding raspberry pi users.
I'd have a really hard job getting my educational bat past airport security these days. It was hard enough bringing it through JFK (before 9/11). It was boxed and sealed with security tape and had to go behind the cockpit door.

I liked Melbourne when I went there for a whole week. The 11 hour TZ switch is a little bit taxing. The flight from LHR (21:00 Friday night) via SIN (laid over for 1 3/4 hours) to Melbourne Tullamarine (MEL) at 04:00 Monday could have been shorter. The market is a treat - all good cities have good markets.

We're heading to Perth via HKG this time.

Re: DisplayLink Support broken

Posted: Tue Dec 03, 2019 12:59 am
by hippy
hippy wrote:
Fri Nov 29, 2019 12:10 am
USB-DisplayLink which was working on a Pi 3B (non-plus) under Stretch no longer appears to be working under Buster ...
Just an update on this - still not working after trying driver "fbdev" instead of driver "fbturbo", same results; flashing screens. Tried other people's examples of once working configs and they behave the same. Tried with three DisplayLink adapters and all the same, so I'm discounting my hardware having failed.

But, if I pull the DisplayLink USB cable out while booted, the main HDMI TV then displays as it normally would, but displaying a 'username, password, shutdown/login' pop-up rather than having logged in to the desktop automatically.

With Option "Xinerama" "1" commented out from '/etc/X11/xorg.conf' it works a little better. Both screens flash for a few seconds, both show my usual background colour / black, HDMI TV flashes desktop icons, DisplayLink then goes black, HDMI TV shows a desktop but only the toolbar and mouse cursor, the main desktop black, no icons. Mouse works, as do menu and pop-ups. Same, with libxinerama-dev purged.

That may be what another user reporting a DisplayLink issue is also seeing, but I can't confirm that -

https://www.raspberrypi.org/forums/view ... 0#p1574943

Don't know if any of the above helps but hopefully does. I still suspect it may be that "framebuffer_depth=16" being ignored on booting which may be the culprit.

Re: Buster bug report thread

Posted: Mon Dec 09, 2019 12:27 pm
by daniel.araujo.twa
The current version of wpa_supplicant does not seem to respect the freq_list option. I wanted to limit WiFi connections to 2.4 GHz channels but it would connect to 5 GHz channels on networks that use the same SSID for both 2.4 GHz and 5 GHz bands.

I checked the version number:

Code: Select all

$ wpa_supplicant -v
wpa_supplicant v.2.8-devel
And found odd that wpa_supplicant was reporting itself as a development version. So I downloaded the sources for the latest stable version at the time of writing this post, which is 2.9, and the freq_list option began working properly. It was no longer connecting to 5G networks.

Here's the download link for the sources of 2.9 http://w1.fi/releases/wpa_supplicant-2.9.tar.gz if you want to try it for yourself.

Re: Buster bug report thread

Posted: Mon Dec 09, 2019 1:29 pm
by ShiftPlusOne
Thank you. I've added the wpa update to my todo list.

Re: Buster bug report thread

Posted: Wed Dec 11, 2019 11:14 am
by crofter
hi
can it be possible to add shutdown to the top bar

thanks
crofter

Re: Buster bug report thread

Posted: Wed Dec 11, 2019 12:40 pm
by beta-tester
AmigaGamer wrote:
Mon Nov 25, 2019 12:00 pm
File Manager : when mounting SMB/CIFS shares via gvfs, either through the file manager "smb://server/share" or "gio mount smb://server/share" , the included pcmanfm file manager shows %20 instead of spaces in file names
eg "My Music" shows as "My%20Music".
DougieLawson wrote:
Mon Nov 25, 2019 12:02 pm
It's not a bug, it's a feature. Simple fix is don't use spaces in file or directory names (as that's insane anyway).
i can see that same behavior. see File Manger shows spaces as %20 on network shares.

@DougieLawson: i hope that is a joke. what kind of feature should it be?
usually the computer has to submit to the human. for what else do we have computers ;)