Siduction Forum

Habe ich einen (Tipp-)Fehler in der Datei 'pyfll' gefunden?
In '_writeFile(self, arch, file)' findet sich in Zeile 1268 ein Eintrag
f.write('127.0.1.1\t' + hostname +'.local\t' + hostname + '/t newdev' + '\n\n')Sollte das '/t' dort nicht eher ein Eintrag '\t' (Tab?) sein. so sehe ich darin keinen Sinn. Eventuell ist das 'newdev' auch ein '_newdev' oder kann ganz weggelassen werden?

PS: Zur Zeit kann übrigens keine ISO gebaut werden (Python-Problem).

Kann mir jemand hier vielleicht einen Rat geben, wie ich nach dem Starten einer selbstgebauten Siduction-ISO ein Kommando (als root) ausführen kann? Den einfachsten Weg, dieses in eine 'rc.local' zu packen, haben systemd und Debian - welches den rc-local.service nicht (mehr) anbietet - leider versperrt. (Unit rc-local.service could not be found.)
Gibt es eine Datei im 'pyfll'-Umfeld, die so etwas bei Modifikation erlaubt? Etwa eine, die selber beim Start Kommandos ausführt? Bei oberflächlichem überschauen des Codes, habe ich keine gefunden, aber vielleicht kennt sich ja jemand besser aus.

Wer sich für den Hintergrund interessiert: Ich starte die Life-ISO per grub-Kommando, wobei das 'Image' per 'toram'  aus einer NTFS-Partition ins RAM übertragen wird. Leider hinterläßt das zwei 'loop'-Devices, von denen das erste (loop0) auf die ISO-Datei des Images in der NTFS-Partition verweist. (Einen dazugehörigen 'mount'-Eintrag gibt es - Gott sei Dank(?) - nicht.) Das blockiert dann das Mounten der gesamten Partition durch das 'udisks2'-System. Da loop0 zu diesem Zeitpunkt längst nicht mehr benötigt wird, reicht ein 'losetup -d loop0' (als root) aus, um das zu beheben. Eben dieses Kommando würde ich gerne automatisch ausführen lassen, um es nicht jedes Mal eintippen zu müssen. Dafür einen eigenen sytemd-Service einführen zu müssen, erscheint mir als reichlicher "Overkill". Warum müssen die KISS Dinge nur einfach alle aus Linux ausgebaut werden?

Thank you very much for the great explanation!  I learned something new! 
I had found already that blacklisting the other module worked, by experimenting, but still I was wondering why the old way was not working anymore.
Thanks again!

The little "hack" editing the virtualbox entry in /var/lib/dpkg/status works for me to allow the dist-upgrade to go through. Verified that VBox still starts properly and that VMs still also launch. Thanks @Teriarch for this trick and it is very useful for situations like this and of course ensure that the package in question still works after upgrades of Python for example.

Here is the reason, why it no longer works:
> blacklist ath12k
You blacklisted ath12k, however:

# lsmod | grep wifi
ath12k_wifi7          143360  0
ath12k                733184  1 ath12k_wifi7
mac80211            1757184  2 ath12k,ath12k_wifi7
cfg80211            1593344  3 ath12k,ath12k_wifi7,mac80211
mhi                  143360  3 ath12k,ath12k_wifi7,qrtr_mhi
ath12k_wifi7          143360  0
ath12k                733184  1 ath12k_wifi7
mac80211            1757184  2 ath12k,ath12k_wifi7
cfg80211            1593344  3 ath12k,ath12k_wifi7,mac80211
mhi                  143360  3 ath12k,ath12k_wifi7,qrtr_mhi
shows that the loading of kernel module ath12k was not triggered
by a direct kernel event.

You know how this works, do you? When the kernel detects new hardware
(either by coldplug or hotplug) it either records the event in the sys filesystem
(for later userspace systemd- udev service to catch up and force the kernel event
trigger, coldplug ) or it submits the event to a netlink socket for already running userspace
udevd to handle it (hotplug, causing a HW interrupt). In any case brave udevd reads the kernel
event by continuously polling the socket and needs to identify the module before causing
modprobe to finish off the job.
The netlink socket provides hardware specific details about the device, in your case:

The Qualcomm WCN785x Wi-Fi 7 (FastConnect 7800) uses the PCI vendor ID  17CBIts
specific PCI device ID is 1107

Hence it fires up modprobe:
/sbin/modprobe -abq pci:v000017CBd00001107sv*sd*bc*sc*i*

In order to identify the module modprobe consults  /lib/modules/7.1.3-1-siduction-amd64/modules.alias
and finds:
alias pci:v000017CBd00001107sv*sd*bc*sc*i* ath12k_wifi7
Now that it knows the name of the module to load, it checks against /etc/modprobe.d/*.conf
to see whether it's blacklisted and low and behold: It'not! But before it finally loads it, it must
also satisfy all module dependencies by consulting  /lib/modules/7.1.3-1-siduction-amd64/modules.dep:

kernel/drivers/net/wireless/ath/ath12k/wifi7/ath12k_wifi7.ko.zst: kernel/drivers/net/wireless/ath/ath12k/ath12k.ko

So prior to loading that, it first must load ath12k, and that is exactly what modprobe does, this time without
consulting the blacklist.

To summarize: Your blacklist no longer works, because ath12k no longer has any HW aliases, as you can see from:
$ sudo modinfo ath12k:

filename:      /lib/modules/7.1.3-1-siduction-amd64/kernel/drivers/net/wireless/ath/ath12k/ath12k.ko.zst
license:        Dual BSD/GPL
description:    Driver support for Qualcomm Technologies WLAN devices
firmware:      ath12k/WCN7850/hw2.0/*
firmware:      ath12k/QCN9274/hw2.0/*
depends:        mac80211,cfg80211,qmi_helpers,mhi
intree:        Y
name:          ath12k
retpoline:      Y
vermagic:      7.1.3-1-siduction-amd64 SMP preempt mod_unload
parm:          debug_mask:Debugging mask (uint)
parm:          ftm_mode:Boots up in factory test mode (bool)
But ath12k_wifi7 has:
$ sudo modinfo ath12k_wifi7

filename:      /lib/modules/7.1.3-1-siduction-amd64/kernel/drivers/net/wireless/ath/ath12k/wifi7/ath12k_wifi7.ko.zst
license:        Dual BSD/GPL
description:    Driver support for Qualcomm Technologies 802.11be WLAN devices
alias:          pci:v000017CBd00001112sv*sd*bc*sc*i*
alias:          pci:v000017CBd00001107sv*sd*bc*sc*i*
alias:          pci:v000017CBd00001109sv*sd*bc*sc*i*
depends:        ath12k,mhi,mac80211,cfg80211
intree:        Y
name:          ath12k_wifi7
retpoline:      Y
vermagic:      7.1.3-1-siduction-amd64 SMP preempt mod_unload
Solution: You should blacklist ath12k_wifi7 rather than ath12k (blacklist only works for aliases, not for
module names, when called).

HTH

Why blacklisting, If I want to disable it I use as root 'rfkill block <ID>', with 'rfkill list' you can see which ID wlan/wifi have.

What about to disable WiFi via networkmanager, nmtui, nmcli or iwctl?

Or use 'systemctl <stop/disable/mask ... unmask/enable/start> iwd.service'.

Do you have a hardware switch?

@harley-peter
> I don't know for what the package python3-lib2to3 is necessary.
> If I understand you right I can uninstall the package.

It once was needed for the transition python2 -> python3, IIRC.
So it's outdated by years. Try a:

$ sudo apt-get -s remove python3-lib2to3

and see, what gives. If nothing else accompanies its exit, get rid of
it right now.

> For virtualbox there is no need to hurry, I can wait some days. Thanks!

That's a wise decision. The suggestion was not for the faint of heart.
If you mess with the package manager the wrong way, you break your system;
no questions asked.

And for the rest of the flock: "You have been warned!"

@teriarch:
I don't know for what the package python3-lib2to3 is necessary. If I understand you right I can uninstall the package.

For virtualbox there is no need to hurry, I can wait some days. Thanks!

@harley-peter
> python3-lib2to3  virtualbox  virtualbox-ext-pack  virtualbox-qt
python2-lib2to3:
What do you need it for? Last version is for bookworm python3.11,
no longer part of Debian sid.

virtualbox &Co.:
You can trick the package manager into thinking you have a newer version, like so
(Debian virtualbox version  7.2.8-dfsg-1 is perfectly fine with python3.14, the Debian
maintainers are only overly accurate). Look for the following lines in /var/lib/dpkg/status
(after backup):

Package: virtualbox
Status: install ok installed
Priority: optional
Section: contrib/misc
Installed-Size: 151566
Maintainer: Debian Virtualbox Team <team+debian-virtualbox@tracker.debian.org>
Architecture: amd64
Version: 7.2.8-dfsg-1
--
Package: virtualbox-qt
Status: install ok installed
Priority: optional
Section: contrib/misc
Installed-Size: 54592
Maintainer: Debian Virtualbox Team <team+debian-virtualbox@tracker.debian.org>
Architecture: amd64
Source: virtualbox
Version: 7.2.8-dfsg-1
Replaces: virtualbox (<< 4.1.6-dfsg-2~)
Depends: virtualbox (= 7.2.8-dfsg-1), libc6 (>= 2.34), ,..
Simply replace all those lines (and only those, no other lines in  file
/var/lib/dpkg/status) containing string "7.2.8-dfsg-1" by according
lines containing string "7.2.8-dfsg-1b" instead. Finally search for line

Depends: iproute2, procps, virtualbox-dkms (>= 7.2.8-dfsg-1) | virtualbox-source (>= 7.2.8-dfsg-1) | virtualbox-modules, systemd | systemd-standalone-sysusers | systemd-sysusers, python3 (<< 3.14), ...

and only replace string "python3 (<< 3.14)" by "python3 (<< 3.15)" in that line.
Now you are good to go for the transition. But if that's all too complicated, simply wait
for the official virtualbox update.

These two are OK to install now:

don@cville:~$ sudo apt policy libreoffice
libreoffice:
  Installed: 4:26.2.4.2-2
  Candidate: 4:26.2.4.2-2
  Version table:
 *** 4:26.2.4.2-2 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
don@cville:~$ sudo apt policy python3
python3:
  Installed: 3.14.6-1
  Candidate: 3.14.6-1
  Version table:
 *** 3.14.6-1 500
        500 https://deb.debian.org/debian unstable/main amd64 Packages
But vbox is still a problem:

don@cville:~$ sudo apt -s install virtualbox virtualbox-qt

Solving dependencies... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Unsatisfied dependencies:
 virtualbox : Depends: virtualbox-dkms (>= 7.2.8-dfsg-1) but it is not going to be installed or
                      virtualbox-source (>= 7.2.8-dfsg-1) but it is not going to be installed or
                      virtualbox-modules
              Depends: python3 (< 3.14) but 3.14.6-1 is to be installed
              Depends: libgsoap-2.8.139 (>= 2.8.139) but it is not going to be installed
              Depends: liblzf1 (>= 1.5) but it is not going to be installed
 virtualbox-qt : Depends: libqt6help6 (>= 6.6.0) but it is not going to be installed
                Depends: libqt6statemachine6 (>= 6.6.1) but it is not going to be installed
Error: Unable to satisfy dependencies. Reached two conflicting assignments:
  1. virtualbox:amd64=7.2.8-dfsg-1 is selected for install
  2. virtualbox:amd64 Depends python3 (< 3.14)
      but none of the choices are installable:
      [no choices]