Tumbleweed: Bluetooth File Transfer is "Buggy"
Hello, I will not go to open another bug-report for this issue, since I guess it being spread away on many different systems around, independently of the specific hardware. Bluetooth file transfer in TW works only for an unidirectional way: from external device to the computer and not vice-versa. rpm -qa|grep blue NetworkManager-bluetooth-1.42.2-1.1.x86_64 bluez-auto-enable-devices-5.66-1.4.noarch kernel-firmware-bluetooth-20230210-1.1.noarch bluez-firmware-1.2-150.1.x86_64 libbluetooth3-5.66-1.4.x86_64 bluez-obexd-5.66-1.4.x86_64 bluez-5.66-1.4.x86_64 bluez-cups-5.66-1.4.x86_64 thunar-sendto-blueman-2.3.5-1.1.noarch blueman-lang-2.3.5-1.1.noarch bluez-qt-imports-5.103.0-1.1.x86_64 blueman-2.3.5-1.1.x86_64 How many users are having same issue? Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20230309 Kernel: 6.2.1-1-default - XFCE: (4.18.1)
In data sabato 11 marzo 2023 15:04:35 CET, Marco Calistri ha scritto:
Hello,
I will not go to open another bug-report for this issue, since I guess it being spread away on many different systems around, independently of the specific hardware.
Bluetooth file transfer in TW works only for an unidirectional way: from external device to the computer and not vice-versa.
rpm -qa|grep blue
NetworkManager-bluetooth-1.42.2-1.1.x86_64 bluez-auto-enable-devices-5.66-1.4.noarch kernel-firmware-bluetooth-20230210-1.1.noarch bluez-firmware-1.2-150.1.x86_64 libbluetooth3-5.66-1.4.x86_64 bluez-obexd-5.66-1.4.x86_64 bluez-5.66-1.4.x86_64 bluez-cups-5.66-1.4.x86_64 thunar-sendto-blueman-2.3.5-1.1.noarch blueman-lang-2.3.5-1.1.noarch bluez-qt-imports-5.103.0-1.1.x86_64 blueman-2.3.5-1.1.x86_64
How many users are having same issue?
Regards,
entropy@localhost:~> rpm -qa|grep blue bluez-obexd-5.66-1.4.x86_64 bluez-5.66-1.4.x86_64 bluez-qt-imports-5.104.0-1.1.x86_64 bluedevil5-lang-5.27.2-1.1.noarch NetworkManager-bluetooth-1.42.4-1.1.x86_64 bluedevil5-5.27.2-1.1.x86_64 bluez-qt-udev-5.104.0-1.1.x86_64 kernel-firmware-bluetooth-20230210-1.1.noarch libbluetooth3-5.66-1.4.x86_64 bluez-cups-5.66-1.4.x86_64 in this asset and with the following BT adapter and a Xiaomi Poco X3 Pro it "works for me". Bus 008 Device 004: ID 0b05:184c ASUSTek Computer, Inc. 802.11ac NIC Maybe your dongle? BT transfer fail if you go from one user to another user session in the meanwhile. In my experience the transfer does not support multiple users on the same machine at the same time using BT (probably because the active user steals the focus of the BT device). Operating System: openSUSE Tumbleweed 20230313 KDE Plasma Version: 5.27.2 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.4-1-default (64-bit) Graphics Platform: X11 Processors: 4 × AMD FX(tm)-4300 Quad-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon Pro W5500 Manufacturer: Gigabyte Technology Co., Ltd. in journalctl -r during transfer I have: mar 15 12:25:17 localhost systemd[3854]: app- org.kde.bluedevilsendfile-3dd5402740174ce7ad1424ad89ebd23e.scope: Consumed 3.182s CPU time. mar 15 12:25:17 localhost plasmashell[4084]: org.kde.plasma.notifications: Failed to determine mime type for QUrl("file:Pan Galactic Gargel Blaster") "Il file o la cartella Pan Galactic Gargel Blaster non esiste." where Pan Galactic Gargle Blaster is my phone. My take would be to check the dongle, I have a Cambridge Bus 008 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) which does not work well with Linux Bluez file transfer. I think it may be chip dependent. what does lsusb say about your BT device? Errors in journalctl -r?
In data sabato 11 marzo 2023 15:04:35 CET, Marco Calistri ha scritto:
Hello,
I will not go to open another bug-report for this issue, since I guess it being spread away on many different systems around, independently of the specific hardware.
Bluetooth file transfer in TW works only for an unidirectional way: from external device to the computer and not vice-versa.
rpm -qa|grep blue
NetworkManager-bluetooth-1.42.2-1.1.x86_64 bluez-auto-enable-devices-5.66-1.4.noarch kernel-firmware-bluetooth-20230210-1.1.noarch bluez-firmware-1.2-150.1.x86_64 libbluetooth3-5.66-1.4.x86_64 bluez-obexd-5.66-1.4.x86_64 bluez-5.66-1.4.x86_64 bluez-cups-5.66-1.4.x86_64 thunar-sendto-blueman-2.3.5-1.1.noarch blueman-lang-2.3.5-1.1.noarch bluez-qt-imports-5.103.0-1.1.x86_64 blueman-2.3.5-1.1.x86_64
How many users are having same issue?
Regards,
entropy@localhost:~> rpm -qa|grep blue bluez-obexd-5.66-1.4.x86_64 bluez-5.66-1.4.x86_64 bluez-qt-imports-5.104.0-1.1.x86_64 bluedevil5-lang-5.27.2-1.1.noarch NetworkManager-bluetooth-1.42.4-1.1.x86_64 bluedevil5-5.27.2-1.1.x86_64 bluez-qt-udev-5.104.0-1.1.x86_64 kernel-firmware-bluetooth-20230210-1.1.noarch libbluetooth3-5.66-1.4.x86_64 bluez-cups-5.66-1.4.x86_64
in this asset and with the following BT adapter and a Xiaomi Poco X3 Pro it "works for me".
Bus 008 Device 004: ID 0b05:184c ASUSTek Computer, Inc. 802.11ac NIC
Maybe your dongle? BT transfer fail if you go from one user to another user session in the meanwhile. In my experience the transfer does not support multiple users on the same machine at the same time using BT (probably because the active user steals the focus of the BT device).
Operating System: openSUSE Tumbleweed 20230313 KDE Plasma Version: 5.27.2 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.4-1-default (64-bit) Graphics Platform: X11 Processors: 4 × AMD FX(tm)-4300 Quad-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon Pro W5500 Manufacturer: Gigabyte Technology Co., Ltd.
in journalctl -r during transfer I have:
mar 15 12:25:17 localhost systemd[3854]: app- org.kde.bluedevilsendfile-3dd5402740174ce7ad1424ad89ebd23e.scope: Consumed 3.182s CPU time. mar 15 12:25:17 localhost plasmashell[4084]: org.kde.plasma.notifications: Failed to determine mime type for QUrl("file:Pan Galactic Gargel Blaster") "Il file o la cartella Pan Galactic Gargel Blaster non esiste."
where Pan Galactic Gargle Blaster is my phone.
My take would be to check the dongle, I have a Cambridge Bus 008 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) which does not work well with Linux Bluez file transfer. I think it may be chip dependent.
what does lsusb say about your BT device? Errors in journalctl -r? I forgot to put here the obvious "PEBKAK" issue in which I did run in the
In data mercoledì 15 marzo 2023 12:31:13 CET, Stakanov ha scritto: past: not enough space in receiving device. This happened because when Xiaomi updates the OS then the new OS does not take up the path of BT received files to the preexisting one, so it may be that you are directed with the transfer to the internal memory (which may be insufficient) while on the SD card may be a lot of space available. So maybe for precaution you check if your receiving device has the path correctly defined. (I would not wish this to appear "patronizing" far from it. Just to do brainstorming. Ambasciatore non porta pena per cosi dire.
In data sabato 11 marzo 2023 15:04:35 CET, Marco Calistri ha scritto:
Hello,
I will not go to open another bug-report for this issue, since I guess it being spread away on many different systems around, independently of the specific hardware.
Bluetooth file transfer in TW works only for an unidirectional way: from external device to the computer and not vice-versa.
rpm -qa|grep blue
NetworkManager-bluetooth-1.42.2-1.1.x86_64 bluez-auto-enable-devices-5.66-1.4.noarch kernel-firmware-bluetooth-20230210-1.1.noarch bluez-firmware-1.2-150.1.x86_64 libbluetooth3-5.66-1.4.x86_64 bluez-obexd-5.66-1.4.x86_64 bluez-5.66-1.4.x86_64 bluez-cups-5.66-1.4.x86_64 thunar-sendto-blueman-2.3.5-1.1.noarch blueman-lang-2.3.5-1.1.noarch bluez-qt-imports-5.103.0-1.1.x86_64 blueman-2.3.5-1.1.x86_64
How many users are having same issue?
Regards,
entropy@localhost:~> rpm -qa|grep blue bluez-obexd-5.66-1.4.x86_64 bluez-5.66-1.4.x86_64 bluez-qt-imports-5.104.0-1.1.x86_64 bluedevil5-lang-5.27.2-1.1.noarch NetworkManager-bluetooth-1.42.4-1.1.x86_64 bluedevil5-5.27.2-1.1.x86_64 bluez-qt-udev-5.104.0-1.1.x86_64 kernel-firmware-bluetooth-20230210-1.1.noarch libbluetooth3-5.66-1.4.x86_64 bluez-cups-5.66-1.4.x86_64
in this asset and with the following BT adapter and a Xiaomi Poco X3 Pro it "works for me".
Bus 008 Device 004: ID 0b05:184c ASUSTek Computer, Inc. 802.11ac NIC
Maybe your dongle? BT transfer fail if you go from one user to another user session in the meanwhile. In my experience the transfer does not support multiple users on the same machine at the same time using BT (probably because the active user steals the focus of the BT device).
Operating System: openSUSE Tumbleweed 20230313 KDE Plasma Version: 5.27.2 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.4-1-default (64-bit) Graphics Platform: X11 Processors: 4 × AMD FX(tm)-4300 Quad-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon Pro W5500 Manufacturer: Gigabyte Technology Co., Ltd.
in journalctl -r during transfer I have:
mar 15 12:25:17 localhost systemd[3854]: app- org.kde.bluedevilsendfile-3dd5402740174ce7ad1424ad89ebd23e.scope: Consumed 3.182s CPU time. mar 15 12:25:17 localhost plasmashell[4084]: org.kde.plasma.notifications: Failed to determine mime type for QUrl("file:Pan Galactic Gargel Blaster") "Il file o la cartella Pan Galactic Gargel Blaster non esiste."
where Pan Galactic Gargle Blaster is my phone.
My take would be to check the dongle, I have a Cambridge Bus 008 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) which does not work well with Linux Bluez file transfer. I think it may be chip dependent.
what does lsusb say about your BT device? Errors in journalctl -r? I forgot to put here the obvious "PEBKAK" issue in which I did run in the
Thanks for your feedback Stakanov.
I will provide further details as soon as possible.
BTW I'm using XFCE Desktop.
Regards,
Inviato da Outlook per Androidhttps://aka.ms/AAb9ysg
________________________________
From: Stakanov
Il 15/03/23 08:36, Stakanov ha scritto:
In data mercoledì 15 marzo 2023 12:31:13 CET, Stakanov ha scritto:
My take would be to check the dongle, I have a Cambridge Bus 008 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) which does not work well with Linux Bluez file transfer. I think it may be chip dependent.
what does lsusb say about your BT device? Errors in journalctl -r?
I forgot to put here the obvious "PEBKAK" issue in which I did run in the past: not enough space in receiving device. This happened because when Xiaomi updates the OS then the new OS does not take up the path of BT received files to the preexisting one, so it may be that you are directed with the transfer to the internal memory (which may be insufficient) while on the SD card may be a lot of space available. So maybe for precaution you check if your receiving device has the path correctly defined.
(I would not wish this to appear "patronizing" far from it. Just to do brainstorming. Ambasciatore non porta pena per cosi dire.
[Bus 002 Device 006: ID 0489:e00d Foxconn / Hon Hai Broadcom Bluetooth 2.1 Device dmesg|grep Blu [ 5.170118] usb 2-1.6: Product: Broadcom Bluetooth 2.1 Device [ 39.902692] Bluetooth: Core ver 2.22 [ 39.902723] Bluetooth: HCI device and connection manager initialized [ 39.902730] Bluetooth: HCI socket layer initialized [ 39.902733] Bluetooth: L2CAP socket layer initialized [ 39.902739] Bluetooth: SCO socket layer initialized [ 41.653644] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 41.653650] Bluetooth: BNEP filters: protocol multicast [ 41.653655] Bluetooth: BNEP socket layer initialized [ 41.657392] Bluetooth: MGMT ver 1.22 [ 101.433109] Bluetooth: RFCOMM TTY layer initialized [ 101.433121] Bluetooth: RFCOMM socket layer initialized [ 101.433125] Bluetooth: RFCOMM ver 1.11 mar 17 11:27:40 linux-turion64 blueman-manager[13486]: gi.repository.GLib.GError: g-io-error-quark: GDBus.Error:org.bluez.Err> mar 17 11:27:40 linux-turion64 blueman-manager[13486]: value = proxy.call_finish(result).unpack() mar 17 11:27:40 linux-turion64 blueman-manager[13486]: File "/usr/lib/python3.10/site-packages/blueman/bluez/Base.py", line> mar 17 11:27:40 linux-turion64 blueman-manager[13486]: Traceback (most recent call last): mar 17 11:27:40 linux-turion64 blueman-manager[13486]: blueman-manager 11.27.40 ERROR Manager:223 error_handler: Authenti> mar 17 11:27:40 linux-turion64 blueman-sendto[13581]: blueman-sendto 11.27.40 ERROR Client:26 on_session_failed: D8:9A:34:> mar 17 11:27:40 linux-turion64 obexd[2888]: Unable to find service record Ciao! -- Marco Calistri Build: openSUSE Tumbleweed 20230315 Kernel: 6.2.2-1-default - XFCE: (4.18.1)
In data venerdì 17 marzo 2023 15:35:39 CET, Marco Calistri ha scritto:
linux-turion64 obexd[2888]: Unable to find service record
Ciao carissimo. By the token of : https://www.spinics.net/lists/linux-bluetooth/msg01628.html and similar pages concerning the last line with "service record", and by looking at you output:
11.27.40 ERROR Manager:223 error_handler: Authenti> mar 17 11:27:40 linux-turion64 blueman-sendto[13581]: blueman-sendto 11.27.40 ERROR Client:26 on_session_failed: D8:9A:34:> mar 17 11:27:40 linux-turion64 obexd[2888]: Unable to find service record
this seems to be an error of authentication? Try to set you external (receiving) device to accept your incoming files without authorization. Does this work then? If it is character based: I had a look at the thread in the link and on others, they had a problem with libiconv not being present others with the character encoding. Libiconv does not seem to exist for opensuse. iconv itself is meant for character conversion (where AFAIU, libiconv is based on it). I ignore which library for your desktop environment should do this function under opensuse. Do the filename have special characters like "è, é, à" etc.? Question: when you did pair the device, which direction did you take? Did you request pairing from the external device or from the pc to the device originally. I had cases were one of the two direction of pairing caused troubles with authentication although the devices appeared paired, the other paring direction instead worked. I would therefore also suggest (besides the authorization issue) to unpair and to try then the pairing in the opposite direction of what you originally did, and to see whether this changes things.
Il 17/03/23 13:35, Stakanov ha scritto:
In data venerdì 17 marzo 2023 15:35:39 CET, Marco Calistri ha scritto:
linux-turion64 obexd[2888]: Unable to find service record Ciao carissimo.
By the token of : https://www.spinics.net/lists/linux-bluetooth/msg01628.html and similar pages concerning the last line with "service record", and by looking at you output:
Salve amico! 😁
11.27.40 ERROR Manager:223 error_handler: Authenti> mar 17 11:27:40 linux-turion64 blueman-sendto[13581]: blueman-sendto 11.27.40 ERROR Client:26 on_session_failed: D8:9A:34:> mar 17 11:27:40 linux-turion64 obexd[2888]: Unable to find service record this seems to be an error of authentication? Try to set you external (receiving) device to accept your incoming files without authorization. Does this work then?
I don't know if this setting is available/permitted, I never check it or being aware of this possibility.
If it is character based: I had a look at the thread in the link and on others, they had a problem with libiconv not being present others with the character encoding. Libiconv does not seem to exist for opensuse. iconv itself is meant for character conversion (where AFAIU, libiconv is based on it). I ignore which library for your desktop environment should do this function under opensuse. Do the filename have special characters like "è, é, à" etc.?
No, in my file-transfer attempt, the filename was not containing special characters
Question: when you did pair the device, which direction did you take? Did you request pairing from the external device or from the pc to the device originally. I had cases were one of the two direction of pairing caused troubles with authentication although the devices appeared paired, the other paring direction instead worked. I would therefore also suggest (besides the authorization issue) to unpair and to try then the pairing in the opposite direction of what you originally did, and to see whether this changes things.
I sincerely don't remember this particular, but I can try to delete the remote device and try pairing it again. Actually the not working direction is from computer to the remote device. Anyway I remember that Bluetooth did worked in the past, may be that the subsequent updates both in BT stack and/or kernel, did broke the functionality. Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20230315 Kernel: 6.2.4-1-default - XFCE: (4.18.1)
Il 17/03/23 13:35, Stakanov ha scritto:
In data venerdì 17 marzo 2023 15:35:39 CET, Marco Calistri ha scritto:
linux-turion64 obexd[2888]: Unable to find service record
Ciao carissimo.
By the token of : https://www.spinics.net/lists/linux-bluetooth/msg01628.html and similar pages concerning the last line with "service record",
and by looking at you output: Salve amico! 😁
11.27.40 ERROR Manager:223 error_handler: Authenti> mar 17 11:27:40 linux-turion64 blueman-sendto[13581]: blueman-sendto 11.27.40 ERROR Client:26 on_session_failed: D8:9A:34:> mar 17 11:27:40 linux-turion64 obexd[2888]: Unable to find service record
this seems to be an error of authentication? Try to set you external (receiving) device to accept your incoming files without authorization. Does this work then?
I don't know if this setting is available/permitted, I never check it or being aware of this possibility.
If it is character based: I had a look at the thread in the link and on others, they had a problem with libiconv not being present others with the character encoding. Libiconv does not seem to exist for opensuse. iconv itself is meant for character conversion (where AFAIU, libiconv is based on it). I ignore which library for your desktop environment should do this function under opensuse. Do the filename have special characters like "è, é, à" etc.?
No, in my file-transfer attempt, the filename was not containing special characters
Question: when you did pair the device, which direction did you take? Did you request pairing from the external device or from the pc to the device originally. I had cases were one of the two direction of pairing caused troubles with authentication although the devices appeared paired, the other paring direction instead worked. I would therefore also suggest (besides the authorization issue) to unpair and to try then the pairing in the opposite direction of what you originally did, and to see whether this changes things. I sincerely don't remember this particular, but I can try to delete the remote device and try pairing it again. Actually the not working direction is from computer to the remote device.
Anyway I remember that Bluetooth did worked in the past, may be that the subsequent updates both in BT stack and/or kernel, did broke the functionality.
Regards, Oh, I do not doubt that before it worked. BT had a lot of changes and some of
In data venerdì 17 marzo 2023 23:10:59 CET, Marco Calistri ha scritto: them came as a blessing, some others not. To be precise: BT did work with you with THIS specific device? Or was it with a different device? Does your device supports OBEX? I found out today that apparently iOS does not support OBEX file transfers. I am not really aware what phone or device that is, but if you go in the settings you can generally determine that incoming BT transactions are a) requiring a paired device and user interaction (authorization) b) not requiring a user authorization in case the device is known and trusted. c) accept all incoming BT transfers (which is unsafe, but would allow to exclude the authorization procedure as a source for your problem. The sequence of pairing (first phone or first PC) was a problem with some specific devices. This seems to be also a question of BT used in the paired device.
Il 17/03/23 19:27, Stakanov ha scritto:
Il 17/03/23 13:35, Stakanov ha scritto:
11.27.40 ERROR Manager:223 error_handler: Authenti> mar 17 11:27:40 linux-turion64 blueman-sendto[13581]: blueman-sendto 11.27.40 ERROR Client:26 on_session_failed: D8:9A:34:> mar 17 11:27:40 linux-turion64 obexd[2888]: Unable to find service record this seems to be an error of authentication? Try to set you external (receiving) device to accept your incoming files without authorization. Does this work then? There is not such option here, my device is a Lenovo Zuk Z2 plus smartphone. I don't know if this setting is available/permitted, I never check it or being aware of this possibility.
If it is character based: I had a look at the thread in the link and on others, they had a problem with libiconv not being present others with the character encoding. Libiconv does not seem to exist for opensuse. iconv itself is meant for character conversion (where AFAIU, libiconv is based on it). I ignore which library for your desktop environment should do this function under opensuse. Do the filename have special characters like "è, é, à" etc.? No, in my file-transfer attempt, the filename was not containing special characters
Question: when you did pair the device, which direction did you take? Did you request pairing from the external device or from the pc to the device originally. I had cases were one of the two direction of pairing caused troubles with authentication although the devices appeared paired, the other paring direction instead worked. I would therefore also suggest (besides the authorization issue) to unpair and to try then the pairing in the opposite direction of what you originally did, and to see whether this changes things. I sincerely don't remember this particular, but I can try to delete the remote device and try pairing it again. Actually the not working direction is from computer to the remote device.
Anyway I remember that Bluetooth did worked in the past, may be that the subsequent updates both in BT stack and/or kernel, did broke the functionality.
Regards, Oh, I do not doubt that before it worked. BT had a lot of changes and some of
In data venerdì 17 marzo 2023 23:10:59 CET, Marco Calistri ha scritto: them came as a blessing, some others not. To be precise: BT did work with you with THIS specific device? Or was it with a different device? Does your device supports OBEX? I found out today that apparently iOS does not support OBEX file transfers.
I am not really aware what phone or device that is, but if you go in the settings you can generally determine that incoming BT transactions are a) requiring a paired device and user interaction (authorization) b) not requiring a user authorization in case the device is known and trusted. c) accept all incoming BT transfers (which is unsafe, but would allow to exclude the authorization procedure as a source for your problem.
The sequence of pairing (first phone or first PC) was a problem with some specific devices. This seems to be also a question of BT used in the paired device.
The file-transfer now works! The main issues were: 1 - I had disabled the desktop notification on XFCE, then I was "blind" regarding auth request from the PC. 2 - The file you wish to transfer must have an extension: PNG, XLSX, TXT... otherwise the BT sends the error. I.E. "authy" file not transferred, "authy.txt" file transferred correctly! At the end the issue was caused by my improper usage of the Bluetooth and not by a system or kernel issue. Sorry for the noise raised so far! Best regards! -- Marco Calistri Build: openSUSE Tumbleweed 20230316 Kernel: 6.2.4-1-default - XFCE: (4.18.1)
In data sabato 18 marzo 2023 14:54:49 CET, Marco Calistri ha scritto:
At the end the issue was caused by my improper usage of the Bluetooth and not by a system or kernel issue.
Sorry for the noise raised so far!
Best regards!
Perfetto, ne sono molto contento che hai risolto. All the best!
Il 18/03/23 11:49, Stakanov ha scritto:
In data sabato 18 marzo 2023 14:54:49 CET, Marco Calistri ha scritto:
At the end the issue was caused by my improper usage of the Bluetooth and not by a system or kernel issue.
Sorry for the noise raised so far!
Best regards! Perfetto, ne sono molto contento che hai risolto.
All the best! Grazie Stak 😁
Have a great W.E.! -- Marco Calistri Build: openSUSE Tumbleweed 20230316 Kernel: 6.2.4-1-default - XFCE: (4.18.1)
On Fri, Mar 17 2023, Larry Len Rainey wrote:
I had to go back to vmlinuz-5.14.21-150400.24.46 to get video
Same here. The system freezes right after loading the kernel. My CPU: Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz Cheers, -- Peter
participants (4)
-
Larry Len Rainey -
Marco Calistri -
Peter Münster -
Stakanov