If you have problems with simultaneous usage of Wi-Fi on 2.4 GHz and bluetooth on Intel combo chips, I suggest to set an option for iwlwifi
kernel module.
Run in a terminal:
sudo tee /etc/modprobe.d/iwlwifi-opt.conf <<< "options iwlwifi bt_coex_active=N"
and reboot.
The command creates /etc/modprobe.d/iwlwifi-opt.conf
file that sets an option for iwlwifi
kernel module. It disables buggy "bluetooth coexistence" technology.
You can give the file a more meaningful name like intel-btfix.conf
. The only requirement is to have .conf
at the end. You can also add commentary to the file like
#Manually created file to fix bluetooth issues
if you forget where this file came from in the future.
You can revert this setting by removing this file:
sudo rm /etc/modprobe.d/iwlwifi-opt.conf
Regarding proprietary drivers for this chip. It is not required if the chip is supported by in-tree kernel module.
Additional information on this issue:
Nowadays Bluetooth and Wi-Fi are in most cases handled by one combo chip. In your case it is Intel 9560.
The problem is that 2.4 GHz Wi-Fi and bluetooth are working on the same frequency. That's why Wi-Fi kernel module in your case iwlwifi
has built-in technology that handles (badly) conflicts between Wi-Fi and BT. It can be enabled or disabled by a kernel option.
iwlwifi
has this option bt_coex_active
enabled by default and it gives priority to Wi-Fi. That's why users have problems with BT. Generally the coexistence technology used by Intel in their module looks really ugly, because in most cases BT is unusable for audio streaming from Wi-Fi.
Another example of this problem is in Qualcomm Atheros older chips (ath9k), that is not that noticeable.
There is an option for the same purpose btcoex_enable
in ath9k
that is disabled by default. If you stream audio from 2.4 GHz Wi-Fi same problems may appear. In this case the option should be enabled. But QCA option gives priority to bluetooth and there may be packet drops on Wi-Fi even if you are not using bluetooth at all. So it is recommended to enable it only if badly needed.
New ath10k
QCA chips don't have this option and it looks like they solved the problem perfectly because I never met any complaints.
Anyway it is highly recommended to switch to 5 GHz Wi-Fi if you are using bluetooth streaming.
EDIT: I misread the original question, but everything still applies. Using /dev/mmcblk0p2
below is for installing to the microSD card. To install to an external SSD/HD the device will likely be /dev/sda2
. Use the appropriate device when editing cmdline.txt
, crypttab
, and booting for the first time via (initramfs)
.
The latest Ubuntu image includes cryptsetup, so you can convert the "writeable" (root) partition to LUKS using your desktop PC. I began with the 20.10 64-bit Server image.
Prepare your SD card but do not install into the RPi. Keep it on your desktop PC.
Unmount the SD card (/dev/sdc2 is my "writeable" (root) partition - yours may be different).
sudo umount /dev/sdc2
Check the partition... sudo e2fsck -f /dev/sdc2
Shrink the partition... sudo resize2fs -M /dev/sdc2
Encrypt the partition (RPi does not have hardware AES support, Adiantum seems to perform better)...
sudo cryptsetup-reencrypt --new --reduce-device-size=16M --type=luks2 -c xchacha12,aes-adiantum-plain64 -s 256 -h sha512 --use-urandom /dev/sdc2
Decrypt the LUKS partition... sudo cryptsetup luksOpen /dev/sdc2 rootfs
Expand the partition... sudo resize2fs /dev/mapper/rootfs
Mount the partition... sudo mkdir mnt; sudo mount /dev/mapper/rootfs mnt;
Edit etc/crypttab... sudo vim mnt/etc/crypttab
- Add
rootfs /dev/mmcblk0p2 none luks
Edit etc/fstab... sudo vim mnt/etc/fstab
- Change the first line to
/dev/mapper/rootfs / ext4 defaults,noatime 0 0
On the system-boot partition, edit cmdline.txt
...
- change
root=LABEL=writable
to root=/dev/mapper/rootfs
- remove
splash
(so it prompts for the passphrase on boot)
- add
cryptdevice=/dev/mmcblk0p2:sdcard
to the end of the line
It should look like this...
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mapper/rootfs rootfstype=ext4 elevator=deadline rootwait fixrtc quiet cryptdevice=/dev/mmcblk0p2:sdcard
Unmount the microSD card and install into the Raspberry Pi. It will fail to boot and enter (initramfs) because initramfs hasn't been updated yet.
Manually decrypt from initramfs... (initramfs) cryptsetup luksOpen /dev/mmcblk0p2 rootfs
Continue booting... (initramfs) exit
Login (ubuntu/ubuntu) and update initramfs... sudo update-initramfs -u
Reboot... sudo reboot
It should reboot, prompt for the passphrase, then start the OS.
Best Answer
I just tried Lubuntu using the RPi4 64 Bit image from https://ubuntu.com/download/raspberry-pi on a Raspberry Pi 4 Model B.
:)
I didn't experience the black screen, the USB bug, or any WiFi problems (managed to connect to a WPA2 network easily).
:(
However, I was unable to get the sound to work, even after fiddling with the usercfg.txt file.
After consulting the documentation (https://www.raspberrypi.org/documentation/configuration/config-txt/) I tried various combinations with these config parameters:
Unfortunately I could't get either the 3.5 mm jack or the HDMI audio output to work.
I'm about to try it again from scratch this time with Xubuntu as you'd reported success.
Hopefully I'll be able to report back a confirmation of your results soon.
...
Just finished trying Xubuntu with the same Pi. Initially I had the same problem as lubuntu.
:D
Fortunately after reviewing this link: https://forum.manjaro.org/t/rpi-4-audio-issue/103399 I managed to solve the audio problem.
The key command necessary to fix it was:
At the moment I have to call it manually after booting, so it is not a perfect fix but I'll probably add it to a boot script if there is no better solution.
My usercfg.txt file contents are:
I tested it by calling the following command to produce static noise: