Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bluetooth not working after update, "systemctl start hciuart" fails #3018

Closed
Nurgak opened this issue Jul 28, 2019 · 19 comments
Closed

Bluetooth not working after update, "systemctl start hciuart" fails #3018

Nurgak opened this issue Jul 28, 2019 · 19 comments

Comments

@Nurgak
Copy link

Nurgak commented Jul 28, 2019

Details:

  • Date | Sun 28 Jul 22:13:46 CEST 2019
  • Bug report | N/A
  • DietPi version | v6.25.3 (MichaIng/master)
  • Img creator | DietPi Core Team
  • Pre-image | Raspbian Lite
  • SBC device | RPi 3 Model B+ (armv7l) (index=3)
  • Kernel version | Letsencrypt supports Free Noip.com Dynamic DNS #1159 SMP Sun Nov 4 17:50:20 GMT 2018
  • Distro | stretch (index=4)
  • Command | systemctl start hciuart
  • Exit code | 1
  • Software title | DietPi-Set_hardware

Steps to reproduce:

  1. Run dietpi-update

Expected behaviour:

  • Bluetooth should be working as before

Actual behaviour:

  • Bluetooth does not work

Extra details:

  • Running the command systemctl start hciuart fails
  • Tried to disable/enable Bluetooth from the dietpi-software menu, no change

Additional logs:

When calling from a script requesting data from a Bluetooth device this is reported:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 175, in activate_name_owner
    return self.get_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 361, in get_name_owner
    's', (bus_name,), **keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'org.bluez': no such name

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/gatt/gatt_linux.py", line 35, in __init__
    adapter_object = self._bus.get_object('org.bluez', '/org/bluez/' + adapter_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 241, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 248, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 180, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/usr/lib/python3/dist-packages/dbus/bus.py", line 278, in start_service_by_name
    'su', (bus_name, flags)))
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/nodered/SmartGadget-gatt/sht31.py", line 5, in <module>
    sm = smartgadget.SmartGadget(adapter_name='hci0', device_mac='FB:52:05:5E:F9:92')
  File "/home/nodered/SmartGadget-gatt/smartgadget.py", line 9, in __init__
    self.manager = gatt.DeviceManager(adapter_name)
  File "/usr/local/lib/python3.5/dist-packages/gatt/gatt_linux.py", line 37, in __init__
    raise _error_from_dbus_error(e)
gatt.errors.Failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

This script has been working more than a year and now fails.

@MichaIng
Copy link
Owner

@Nurgak
Many thanks for your report.

Which DietPi version was it before doing the update?

You could try/check the following:

  • Assure related kernel modules are loaded: lsmod | grep -E '(bnep|btbcm)'
  • Assure the serial device is available: ls -Al /dev/ttyAMA0
  • Assure any serial console + boot messages on this serial device is disabled:
    /DietPi/dietpi/func/dietpi-set_hardware serialconsole disable ttyAMA0
  • Reinstall related packages: apt install --reinstall bluez bluez-firmware pi-bluetooth

@Nurgak
Copy link
Author

Nurgak commented Jul 29, 2019

I forgot the exact previous version, but it was 6.24.x. I remember also installed proftp if that counts for anything.

I followed the checklist and got this message in the end:

Job for hciuart.service failed because the control process exited with error code.
See "systemctl status hciuart.service" and "journalctl -xe" for details.
hciuart.service couldn't start.

Then systemctl status hciuart.service gives:

● hciuart.service - Configure Bluetooth Modems connected by UART
   Loaded: loaded (/lib/systemd/system/hciuart.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2019-07-29 21:36:43 CEST; 56s ago
  Process: 13131 ExecStart=/usr/bin/btuart (code=exited, status=1/FAILURE)

Jul 29 21:36:13 zurich systemd[1]: Starting Configure Bluetooth Modems connected by UART...
Jul 29 21:36:43 zurich btuart[13131]: Initialization timed out.
Jul 29 21:36:43 zurich btuart[13131]: bcm43xx_init
Jul 29 21:36:43 zurich systemd[1]: hciuart.service: Control process exited, code=exited status=1
Jul 29 21:36:43 zurich systemd[1]: Failed to start Configure Bluetooth Modems connected by UART.
Jul 29 21:36:43 zurich systemd[1]: hciuart.service: Unit entered failed state.
Jul 29 21:36:43 zurich systemd[1]: hciuart.service: Failed with result 'exit-code'.

The journalctl -xe gives the same messages as I wrote in "additional logs".

@MichaIng
Copy link
Owner

@Nurgak
And the output of the other commands, both kernel modules are loaded and /dev/ttyAMA0 exists?
Also lets see if anything else blocks the TTY: ps a

@Nurgak
Copy link
Author

Nurgak commented Jul 29, 2019

  • lsmod | grep -E '(bnep|btbcm)': nothing is outputted
  • ls -Al /dev/ttyAMA0 gives crw-rw---- 1 root dialout 204, 64 Jul 29 21:36 /dev/ttyAMA0
  • /DietPi/dietpi/func/dietpi-set_hardware serialconsole disable ttyAMA0:
[  OK  ] DietPi-Set_hardware | Root access verified.
[  OK  ] DietPi-Set_hardware | RootFS R/W access verified.

 DietPi-Set_hardware
─────────────────────────────────────────────────────
 Mode: serialconsole (disable)

[ INFO ] DietPi-Set_hardware | Disabling serial-getty on: /dev/ttyAMA0
[  OK  ] serialconsole disable | Completed

  • apt install --reinstall bluez bluez-firmware pi-bluetooth:
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 3 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/851 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 27915 files and directories currently installed.)
Preparing to unpack .../bluez_5.43-2+rpt2+deb9u2_armhf.deb ...
Unpacking bluez (5.43-2+rpt2+deb9u2) over (5.43-2+rpt2+deb9u2) ...
Preparing to unpack .../bluez-firmware_1.2-3+rpt7_all.deb ...
Unpacking bluez-firmware (1.2-3+rpt7) over (1.2-3+rpt7) ...
Preparing to unpack .../pi-bluetooth_0.1.10_all.deb ...
Unpacking pi-bluetooth (0.1.10) over (0.1.10) ...
Setting up bluez-firmware (1.2-3+rpt7) ...
Processing triggers for systemd (232-25+deb9u11) ...
Processing triggers for dbus (1.10.28-0+deb9u1) ...
Setting up bluez (5.43-2+rpt2+deb9u2) ...
Setting up pi-bluetooth (0.1.10) ...
Job for hciuart.service failed because the control process exited with error code.
See "systemctl status hciuart.service" and "journalctl -xe" for details.
hciuart.service couldn't start.

/dev/ttyAMA0 exists.

ps a gives this:

  714 tty1     Ss+    0:00 /sbin/agetty --noclear tty1 linux
13265 pts/0    Ss     0:00 -bash
13561 pts/0    R+     0:00 ps a

@MichaIng
Copy link
Owner

@Nurgak

lsmod | grep -E '(bnep|btbcm): nothing is outputted

Okay that is a reason since those are the kernel modules required for Bluetooth.
Please run and paste output of (if any):

modprobe bluetooth
modprobe bnep
modprobe btbcm
modprobe hci_uart

If no error occurs (or not output at all), lsmod | grep -E '(bnep|btbcm)' should show some entries then.

Also on RPi you can disable Bluetooth functionality via device tree overlay. Please check for boot and runtime loaded dtoverlays:

grep 'dtoverlay' /boot/dietpi.txt
dtoverlay -l

@Nurgak
Copy link
Author

Nurgak commented Jul 29, 2019

  • modprobe bluetooth:
    modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.14.79-v7+/modules.dep.bin' modprobe: FATAL: Module bluetooth not found in directory /lib/modules/4.14.79-v7+
  • modprobe bnep
    modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.14.79-v7+/modules.dep.bin' modprobe: FATAL: Module bnep not found in directory /lib/modules/4.14.79-v7+
  • modprobe btbcm
    modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.14.79-v7+/modules.dep.bin' modprobe: FATAL: Module btbcm not found in directory /lib/modules/4.14.79-v7+
  • modprobe hci_uart
    modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.14.79-v7+/modules.dep.bin' modprobe: FATAL: Module hci_uart not found in directory /lib/modules/4.14.79-v7+

I think I'm starting to see a pattern.

@MichaIng
Copy link
Owner

@Nurgak
Ayy, at least the loaded kernel is on an outdated version. Perhaps you did never reboot after the DietPi update? Would totally make sense if the installed kernel does not match the one that is currently active. DietPi-Update should have definitely upgraded to Linux v4.19, while the active session seems to be v4.14: uname -a

Re-assure that kernel+firmware packages are up-to-date, then reboot:

apt -y install raspberrypi-kernel raspberrypi-bootloader libraspberrypi-bin
reboot

Ah wait BEFORE reboot, please check free space on /boot partition. The new kernel+bootloader include a bunch of files for RPi4 which fill the partition nearly completely. That is quite a problem if you ever installed some additional dtoverlays or external systems placed obsolete files there:

df -h /boot
ls -Al /boot

@Nurgak
Copy link
Author

Nurgak commented Jul 29, 2019

I most definitely rebooted, many times.

  • uname -a
    Linux zurich 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
  • df -h /boot:
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        42M   24M   18M  58% /boot
  • ls -Al /boot
total 22382
-rwxr-xr-x 1 root root   23946 Jul 28 21:24 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root   24205 Jul 28 21:23 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root   23723 Jul 28 21:24 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root   23671 Jul 28 21:24 bcm2708-rpi-zero.dtb
-rwxr-xr-x 1 root root   24407 Jul 28 21:24 bcm2708-rpi-zero-w.dtb
-rwxr-xr-x 1 root root   25293 Jul 28 21:24 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root   26463 Jul 28 21:24 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root   27082 Jul 28 21:24 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root   25261 Jul 28 21:24 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root   52296 Jul 28 21:23 bootcode.bin
-rwxr-xr-x 1 root root     119 Jul 29 22:15 cmdline.txt
-rwxr-xr-x 1 root root    2433 Jul 28 22:11 config.txt
-rwxr-xr-x 1 root root   18693 Jul 28 21:24 COPYING.linux
drwxr-xr-x 4 root root    4096 Jul 28 21:40 dietpi
-rwxr-xr-x 1 root root    6098 Apr  2  2018 dietpi-README.md
-rwxr-xr-x 1 root root   11591 Jul 28 22:11 dietpi.txt
-rwxr-xr-x 1 root root    2649 Jul 28 21:23 fixup_cd.dat
-rwxr-xr-x 1 root root    6724 Jul 28 21:23 fixup.dat
-rwxr-xr-x 1 root root    9802 Jul 28 21:23 fixup_db.dat
-rwxr-xr-x 1 root root    9798 Jul 28 21:23 fixup_x.dat
drwxr-xr-x 2 root root     512 Apr 23  2018 .fseventsd
-rwxr-xr-x 1 root root     145 Mar 13  2018 issue.txt
-rwxr-xr-x 1 root root 5299792 Jul 28 21:24 kernel7.img
-rwxr-xr-x 1 root root 5017104 Jul 28 21:24 kernel.img
-rwxr-xr-x 1 root root    1494 Jul 28 21:23 LICENCE.broadcom
-rwxr-xr-x 1 root root   18974 Mar 13  2018 LICENSE.oracle
drwxr-xr-x 2 root root   14848 Jul 28 21:24 overlays
-rwxr-xr-x 1 root root  685412 Jul 28 21:23 start_cd.elf
-rwxr-xr-x 1 root root 4854088 Jul 28 21:23 start_db.elf
-rwxr-xr-x 1 root root 2878052 Jul 28 21:23 start.elf
-rwxr-xr-x 1 root root 3791560 Jul 28 21:23 start_x.elf
drwxr-xr-x 2 root root     512 Mar 20  2018 System Volume Information
  • apt -y install raspberrypi-kernel raspberrypi-bootloader libraspberrypi-bin
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libraspberrypi-bin is already the newest version (1.20190709~stretch-1).
raspberrypi-bootloader is already the newest version (1.20190709~stretch-1).
raspberrypi-kernel is already the newest version (1.20190709~stretch-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

And even after a reboot I still get the same modprobe errors.

@MichaIng
Copy link
Owner

MichaIng commented Jul 29, 2019

@Nurgak
Ah nice, the RPi4 files are not present on the Stretch version (that is anyway not RPi4 compatible) of the firmware packages, that is great, never recognised this, but just checked the packages from archive.

Okay packages are up to date, if you rebooted then the following should both show 4.19.57:

ls -l /lib/modules
uname -a

Boot files are dated Jul 28, so those are definitely updated and packages version 1.20190709 is 4.19.57.

As long as uname -a shows 4.14.79, things cannot work. If you definitely rebooted and it still does not show 4.19.57, then something very mysterious is going on...

... and now I see something mysterious: /dev/sda1 42M 24M 18M 58% /boot

  • Did you move boot partition to some USB drive?
  • Although this should not affect the kernel upgrade.
  • But I am not sure what happens if USB boot is enabled but an SDcard is still attached. Perhaps it loads bootloader + kernel from SDcard then, but then if fstab has been updated, later the USB partition is mounted to /boot 🤔.

@Nurgak
Copy link
Author

Nurgak commented Jul 30, 2019

  • ls -l /lib/modules
total 8
drwxr-xr-x 3 root root 4096 Jul 28 21:23 4.19.57+
drwxr-xr-x 3 root root 4096 Jul 28 21:23 4.19.57-v7+
  • uname -a
    Linux zurich 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux

Rebooting didn't help either, still 4.14...

I didn't make any changes on the boot partition, it's on the SD card just like everything else.

Thank you for the help so far, super quick responses...

@MichaIng
Copy link
Owner

@Nurgak
But you have external drives attached, right?
Please paste:

df
lsblk

@Nurgak
Copy link
Author

Nurgak commented Jul 30, 2019

Yes, I have a large hard drive connected to the RPi3 that I use as a pure network file storage.

  • df
/dev/root       14876288 2436924  12422980  17% /
devtmpfs          495480       0    495480   0% /dev
tmpfs             500088       0    500088   0% /dev/shm
tmpfs             500088   31588    468500   7% /run
tmpfs               5120       0      5120   0% /run/lock
tmpfs             500088       0    500088   0% /sys/fs/cgroup
tmpfs              51200     224     50976   1% /var/log
tmpfs            1047552       4   1047548   1% /tmp
tmpfs              10240    1460      8780  15% /DietPi
/dev/sda1          42131   24152     17979  58% /boot
  • lsblk
sda           8:0    1  7.3G  0 disk 
├─sda1        8:1    1 41.8M  0 part /boot
└─sda2        8:2    1  7.2G  0 part 
mmcblk0     179:0    0 14.5G  0 disk 
├─mmcblk0p1 179:1    0 41.8M  0 part 
└─mmcblk0p2 179:2    0 14.4G  0 part /

Wait... does that mean the boot partition is on the HDD? I never put it there myself.

@MichaIng
Copy link
Owner

@Nurgak
Exactly:

├─sda1        8:1    1 41.8M  0 part /boot
├─mmcblk0p1 179:1    0 41.8M  0 part 

A partition from the external drive is used as boot partition while the actually loaded partition on the SDcard is not mounted.
I have NO idea how such a situation can occur. The partition on external drive is even perfectly formatted with the default 41.8M etc. That is VERY strange 😄.

Okay at least we know the issue now. Lets see how to solve this best:

lsblk -o NAME,PARTUUID # Get the partition UUID of the SDcard boot partition
cat /etc/fstab # Check how the wrong partition is mounted via fstab
cat /boot/cmdline.txt # Failsafe, assure all partitions inside there are correct
cp -a /boot /mnt/dietpi_userdata/boot_bak # Backup of the mounted boot partition (that holds the current kernel)
mkdir /mnt/boot_sd
mount /dev/mmcblk0p1 /mnt/boot_sd # Mount the actual SDcard boot partition
cp -a /mnt/boot_sd /mnt/dietpi_userdata/boot_sd_bak # Backup SDcard boot partition as well
rm -R /mnt/boot_sd/{,.??}* # Clear SDcard boot partition
cp -a /boot/* /mnt/boot_sd/ # Copy current kernel+bootloader+DietPi code to SDcard boot partition
umount /mnt/boot_sd
fsck /dev/mmcblk0p1 # failsafe
umount /boot

And then we need to adjust fstab and in case cmdline.txt according to the output of the first three commands.
Last step is then to reinstall firmware packages, to be failsafe.

@Nurgak
Copy link
Author

Nurgak commented Jul 30, 2019

  • lsblk -o NAME,PARTUUID
NAME        PARTUUID
sda         
├─sda1      27504eef-01
└─sda2      27504eef-02
mmcblk0     
├─mmcblk0p1 27504eef-01
└─mmcblk0p2 27504eef-02
  • cat /etc/fstab
#-----------------------------------------------------------
#NETWORK
#-----------------------------------------------------------
#Please use DietPi-Drive_Manager to setup network mounts




#-----------------------------------------------------------
#TMPFS
#-----------------------------------------------------------

tmpfs /tmp tmpfs defaults,size=1023M,noatime,nodev,nosuid,mode=1777 0 0
tmpfs /DietPi tmpfs defaults,size=10m,noatime,nodev,nosuid,mode=1777 0 0


#-----------------------------------------------------------
#MISC (bind)
#-----------------------------------------------------------


#-----------------------------------------------------------
#SWAPFILE
#-----------------------------------------------------------


#-----------------------------------------------------------
#PHYSICAL DRIVES
#-----------------------------------------------------------
PARTUUID=27504eef-02 / auto defaults,noatime,rw 0 1
PARTUUID=27504eef-01 /boot auto defaults,noatime,rw 0 0
/var/swap    none    swap    sw    0   0
tmpfs /var/log tmpfs defaults,size=50m,noatime,nodev,nosuid,mode=1777 0 0
  • cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=27504eef-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

[...]

  • fsck /dev/mmcblk0p1
fsck from util-linux 2.29.2
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/mmcblk0p1: 271 files, 48296/84261 clusters
  • fsck /dev/mmcblk0p1
fsck from util-linux 2.29.2
fsck.fat 4.1 (2017-01-24)
/dev/mmcblk0p1: 271 files, 48296/84261 clusters

[...]

  • reboot

Everything works are before! Thank you so much :)

@Nurgak Nurgak closed this as completed Jul 30, 2019
@MichaIng
Copy link
Owner

MichaIng commented Jul 30, 2019

@Nurgak
Okay but it is not yet fully solved.
The issue is that somehow the external drive partitions seem to be clones from the SDcard, since the partition UUIDs are identical. Not sure if this came from same backup via dd some time ago, at least nothing that DietPi scripts do.

Please do:

mkdir /mnt/sda2
mount /dev/sda2 /mnt/sda2
ls -Al /mnt/sda2

You see the content of the drives second partition. I am 99% sure that it looks like a OS root partition, so it is an old state backup of the SDcard root partition. Compare with ls -Al / which should look very similar.

Since it's size is only 8 GiB I guess it is not the large storage drive that you mentioned before, however makes sense to assure there is really nothing required on it before going on with below 😉. Else I suggest to move the contained files to another location temporarily, a second drive or on external system, to do the format (below) and copy back required files.

So if reboot went fine, and in case you moved/copied required files away, then please format this drive via dietpi-drive_manager > /dev/sda1 (or sda2, doesn't matter) > Format > Format mode: drive (so the whole drive is formatted) and proceed, defaults should be fine. Then you can use if for other things. It should have become a new PARTUUID that does not conflict with the SDcard anymore: lsblk -o NAME,PARTUUID

After everything is back in order as it should, to cleanup:

umount /mnt/sda2
rm -R /mnt/sda2
umount /mnt/boot_sd
rm -R /mnt/boot_sd
# And the previously made backups
rm -R /mnt/dietpi_userdata/boot{,_sd}_bak

@Nurgak
Copy link
Author

Nurgak commented Jul 30, 2019

This is what I got:

  • ls -Al /mnt/sda2
total 88
drwxr-xr-x  2 root   root    4096 Dec 15  2018 bin
drwxr-xr-x  2 root   root    4096 Mar 13  2018 boot
drwxr-xr-x  4 root   root    4096 Mar 13  2018 dev
drw-rw----  2 dietpi dietpi  4096 Mar 20  2018 DietPi
drwxr-xr-x 90 root   root    4096 Dec 16  2018 etc
drwxr-xr-x  6 root   root    4096 Sep 11  2018 home
drwxr-xr-x 17 root   root    4096 Apr 24  2018 lib
drwx------  2 root   root   16384 Mar 13  2018 lost+found
drwxr-xr-x  7 root   root    4096 May 16  2018 mnt
drwxr-xr-x  4 root   root    4096 Apr 24  2018 opt
drwxr-xr-x  2 root   root    4096 Mar 20  2018 proc
drwx------  8 root   root    4096 Dec 15  2018 root
drwxr-xr-x  5 root   root    4096 Mar 20  2018 run
drwxr-xr-x  2 root   root    4096 Dec 15  2018 sbin
drwxr-xr-x  3 root   root    4096 Sep 11  2018 srv
drwxr-xr-x  2 root   root    4096 Mar 20  2018 sys
drwxrwxrwt  8 root   root    4096 Mar 20  2018 tmp
drwxr-xr-x 10 root   root    4096 Mar 20  2018 usr
drwxr-xr-x 12 root   root    4096 Dec  6  2018 var
  • ls -Al /
total 63
drwxr-xr-x   2 root root  4096 Jul 30 08:05 bin
drwxr-xr-x   6 root root  3072 Jan  1  1970 boot
drwxr-xr-x  15 root root  3500 Jul 30 22:27 dev
drwxrwxrwt   3 root root   120 Jul 30 22:26 DietPi
drwxr-xr-x  88 root root  4096 Jul 28 22:12 etc
drwxr-xr-x   5 root root  4096 Dec 29  2018 home
drwxr-xr-x  17 root root  4096 May  5 16:01 lib
drwx------   2 root root 16384 Mar 13  2018 lost+found
drwxr-xr-x   9 root root  4096 Jul 30 22:55 mnt
drwxr-xr-x   4 root root  4096 Dec 29  2018 opt
dr-xr-xr-x 111 root root     0 Jan  1  1970 proc
drwx------   8 root root  4096 Dec 29  2018 root
drwxr-xr-x  22 root root   720 Jul 30 22:27 run
drwxr-xr-x   2 root root  4096 May  5 16:02 sbin
drwxr-xr-x   3 root root  4096 Jul 28 21:26 srv
dr-xr-xr-x  12 root root     0 Jan  1  1970 sys
drwxrwxrwt   9 root root   200 Jul 30 22:39 tmp
drwxr-xr-x  10 root root  4096 Mar 20  2018 usr
drwxr-xr-x  12 root root  4096 Dec 24  2018 var

I'll format the external drive on another system rather.

Thanks again for the excellent and super quick help ;)

@MichaIng
Copy link
Owner

MichaIng commented Jul 30, 2019

@Nurgak

I'll format the external drive on another system rather.

Jep most importantly the partitioning is gone. I think on Windows you need to use the disk management tool, as formatting via explorer only formats a single partition but not the whole drive.

Thanks again for the excellent and super quick help ;)

You're welcome.

@msongz
Copy link
Contributor

msongz commented Aug 2, 2020

i got this error when enable bluetooth on pi4

 - Command: systemctl enable --now hciuart
  - Exit code: 1
  - DietPi version: v6.31.2 (MichaIng/master) | HW_MODEL: 4 | HW_ARCH: 2 | DISTRO: 5
  - Image creator: DietPi Core Team
  - Pre-image: Raspberry Pi OS (32-bit) Lite
  - Error log:
 Job for hciuart.service failed because the control process exited with error code.
 See "systemctl status hciuart.service" and "journalctl -xe" for details.

                         Retry          : Re-run the last command that failed
                         Open subshell  : Open a subshell to investigate or solve the issue
                         Send report    : Uploads bugreport containing system info to DietPi
                                        ●─ Devs only ──────────────────────────────────────●
                         Change command : Adjust and rerun the command

@MichaIng
Copy link
Owner

MichaIng commented Aug 2, 2020

Please paste:

journalctl -u hciuart

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants