Bug#1071216: asahi-btsync: calling of asahi-btsync panics
So the bug is not specifically with asahi-btsync, but rather generically with reading that variable from NVRAM. We could even reassign it to librust-apple-nvram-dev since that's where the reading happens, but let's not rush things (also, the variable specifically is a bluetooth variable). Does `sudo asahi-nvram read | grep -i bluetooth` return anything? Do you have any paired bluetooth device on macOS (wondering if the variable is empty simply because there are no paired devices)? For the record, I could not reproduce on a 14" M1 Pro MacBookPro (with a caveat, namely I booted Debian from USB there, using Fedora's m1n1+u-boot initial boot chain since my MacBookPro runs Fedora). Both on the Mini and on the MacBookPro I had previously paired bluetooth devices. Still, there's not much we can do other than report the bug upstream. Do you mind sharing the "Firmware versions" section of the output of `asahi-diagnose` so we know what to say? P.S.: I remembered your machine from previous conversations :-) And sorry for the many questions, I'm trying to get a better picture of the issue before bothering upstream.
Bug#1071216: asahi-btsync: calling of asahi-btsync panics
Hi all, ok this is the actual state for me (as NoisyCoil already found out: macbook pro m1pro 14'') asahi btsync: thread 'main' panicked at src/main.rs:53:17: called `Result::unwrap()` on an `Err` value: VariableNotFound note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace asahi-nvram read system:BluetoothUHEDevices VariableNotFound but asahi-nvram has a bunch of variables I am still running my own u-boot-asahi - actual 2024.07-1+cy8aer1 https://git.g3la.de/repos/-/packages/debian/u-boot-asahi/2024.07-1+cy8aer1 actual builder: https://git.g3la.de/repos/m1-debian/src/branch/baer/m1n1_uboot_kernel.sh @NoisyCoil u-boot-asahi is more or less the original just with the bootmenu patch. Am 01.09.24 um 20:21 schrieb NoisyCoil: Package: asahi-btsync Followup-For: Bug #1071216 X-Debbugs-Cc: noisyc...@tutanota.com, cybae...@web.de Hi all, The reported bug seems to point to a missing variable in NVRAM, which is a bit weird. I cannot reproduce it on my machine (M1 Mac Mini). cy8aer, do you confirm the bug is still there and, if yes, what machine (was it a 14" M1 Pro MacBook Pro?) and version of u-boot-asahi (origin, i.e. debian or self-built, if self-built from what sources, and what version) you are using? Also, using asahi-nvram from the asahi-nvram package, what does `sudo asahi-nvram read system:BluetoothUHEDevices` return on stdout? Does `sudo asahi-nvram read` return anything at all? I feel the answers to these questions might be relevant to better understand the issue before involving upstream.
Bug#1071216: asahi-btsync: calling of asahi-btsync panics
Hi all, ok this is the actual state for me (as NoisyCoil already found out: macbook pro m1pro 14'') asahi btsync: thread 'main' panicked at src/main.rs:53:17: called `Result::unwrap()` on an `Err` value: VariableNotFound note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace asahi-nvram read system:BluetoothUHEDevices VariableNotFound but asahi-nvram has a bunch of variables I am still running my own u-boot-asahi - actual 2024.07-1+cy8aer1 https://git.g3la.de/repos/-/packages/debian/u-boot-asahi/2024.07-1+cy8aer1 actual builder: https://git.g3la.de/repos/m1-debian/src/branch/baer/m1n1_uboot_kernel.sh Am 01.09.24 um 20:21 schrieb NoisyCoil: Package: asahi-btsync Followup-For: Bug #1071216 X-Debbugs-Cc: noisyc...@tutanota.com, cybae...@web.de Hi all, The reported bug seems to point to a missing variable in NVRAM, which is a bit weird. I cannot reproduce it on my machine (M1 Mac Mini). cy8aer, do you confirm the bug is still there and, if yes, what machine (was it a 14" M1 Pro MacBook Pro?) and version of u-boot-asahi (origin, i.e. debian or self-built, if self-built from what sources, and what version) you are using? Also, using asahi-nvram from the asahi-nvram package, what does `sudo asahi-nvram read system:BluetoothUHEDevices` return on stdout? Does `sudo asahi-nvram read` return anything at all? I feel the answers to these questions might be relevant to better understand the issue before involving upstream.
Bug#1071216: asahi-btsync: calling of asahi-btsync panics
Package: asahi-btsync Followup-For: Bug #1071216 X-Debbugs-Cc: noisyc...@tutanota.com, cybae...@web.de Hi all, The reported bug seems to point to a missing variable in NVRAM, which is a bit weird. I cannot reproduce it on my machine (M1 Mac Mini). cy8aer, do you confirm the bug is still there and, if yes, what machine (was it a 14" M1 Pro MacBook Pro?) and version of u-boot-asahi (origin, i.e. debian or self-built, if self-built from what sources, and what version) you are using? Also, using asahi-nvram from the asahi-nvram package, what does `sudo asahi-nvram read system:BluetoothUHEDevices` return on stdout? Does `sudo asahi-nvram read` return anything at all? I feel the answers to these questions might be relevant to better understand the issue before involving upstream.
Bug#1071216: asahi-btsync: calling of asahi-btsync panics
On Thu, 16 May 2024 12:10:04 +0200 Thomas Renard wrote:>
Package: asahi-btsync
> Version: 0.2.0-1+b1
> Severity: normal
>
> Dear Maintainer,
>
> calling of asahi-btsync panics.
>
> - call asahi-btsync
Let's read some Rust:
fn real_main() -> Result<()> {
let matches = clap::command!()
.arg(clap::arg!(-d --device [DEVICE] "Path to the nvram device."))
.subcommand(clap::Command::new("list").about("Parse shared Bluetooth
keys from nvram")) .subcommand(
clap::Command::new("sync")
.about("Sync Bluetooth device information from nvram")
.arg(clap::arg!(-c --config [CONFIG] "Bluez config path."))
.arg(clap::Arg::new("variable").multiple_values(true)),
)
.subcommand(
clap::Command::new("dump").about("Dump binary Bluetooth device info
from nvram"), )
.get_matches();
let default_name = "/dev/mtd0ro".to_owned();
let default_config = "/var/lib/bluetooth".to_owned();
let bt_var = "BluetoothUHEDevices";
let mut file = OpenOptions::new()
.read(true)
.open(matches.get_one::("device").unwrap_or(&default_name))
.unwrap();
let mut data = Vec::new();
file.read_to_end(&mut data).unwrap();
let mut nv = nvram_parse(&data)?;
let active = nv.active_part_mut();
let bt_devs = active
.get_variable(bt_var.as_bytes(), VarType::System)
--->.ok_or(Error::VariableNotFound)?; // <--- your error occurred here!
> expect:
>
> this should show the help page (because it needs parameters)
As you can see it uses the clap crate to provide the command line interface,
and clap, by default, provides help message through the -h,--help options.
> actual:
>
> thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
> VariableNotFound', src/main.rs:52:17 note: run with `RUST_BACKTRACE=1`
> environment variable to display a backtrace
As evidented by the code, your run threw the VariableNotFound error, which is
when it tried to get the "BluetoothUHEDevices" variable but failed.
As this is an Apple only thing, please report to upstream:
https://github.com/WhatAmISupposedToPutHere/asahi-nvram/issues.
--
Sdrager,
Blair Noctis
pgpq5wCHRwPYW.pgp
Description: OpenPGP digital signature
Bug#1071216: asahi-btsync: calling of asahi-btsync panics
Package: asahi-btsync Version: 0.2.0-1+b1 Severity: normal Dear Maintainer, calling of asahi-btsync panics. - call asahi-btsync expect: this should show the help page (because it needs parameters) actual: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: VariableNotFound', src/main.rs:52:17 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.8.9-asahi-5-cy8aer0 (SMP w/10 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages asahi-btsync depends on: ii libc6 2.38-10 ii libgcc-s1 14-20240330-1 asahi-btsync recommends no packages. asahi-btsync suggests no packages. -- no debconf information
