You are not logged in.
I received an email reply from one of the Linux kernel maintainers stating that users should review configuration options for a new kernel (e.g. 6.12, currently in the rc? cycle) to see that one's hardware is properly supported.
Unless someone writes a tool to interrogate the kernel source and compares it with what hardware is installed (via usb-ids and pci-ids, for many of the cases), it is not easy to identify what changed configuration options may be relevant for their hardware.
My problem was that the CONFIG_USB_XHCI_PCI_RENESAS=m option was disabled by default in the 6.12.0-rc? kernels, so building a new kernel with CONFIG_USB_XHCI_PCI_RENESAS=m is required if one has the hardware (and not all users build their own kernels).
The simplest check for those considering installing a new kernel (whether or not they do build their own kernels) would be to compare the kernel .config file for their currently running kernel and for the new kernel (which they may have built themselves or just installed a binary from an upstream repository) and check what was different that might be applicable to their hardware.
However, a pci-ids / usb-ids check from installed hardware and new kernel source would be more complete.
Hardware detection / identification in this case, ie lspci -v did show the Renesas USB 3.0 controller and that kernel module xhci_pci was used on this hardware, but not that kernel module xhci_pci_renesas was needed, since that hadn't been built as CONFIG_USB_XHCI_PCI_RENESAS=m needed to be explicitly enabled.
A new kernel release changelog that lists applicable pci-ids / usb-ids with changed support (new modules needed, removed, changes in configuration options needed to enable/disable hardware support) would also help.
When a new Debian kernel is released to Experimental, I will file a bug report if the xhci_pci_renesas module is not included in the built kernel.
EDIT, according to the following Debian kernel merge request, CONFIG_USB_XHCI_PCI_RENESAS=m should be enabled for the Debian GNU/Linux 6.12 kernels:
https://salsa.debian.org/kernel-team/li … ote_528686
I wasted several hours bisecting the failure of the 6.12-rc? kernels to recognise USB hard disks connected to a Renesas USB 3.0 host controller.
The hardware affected was identified as:
lspci output:
02:00.0 USB controller: Renesas Electronics Corp. uPD720201 USB 3.0 Host Controller (rev 03)
lspci -n output:
02:00.0 0c03: 1912:0014 (rev 03)
This hardware had been supported in the Linux kernel for some years with the xhci_pci module enabled by CONFIG_USB_XHCI_PCI=m
Now with 6.12.0-rc? kernels it also requires the xhci_pci_renesas module enabled by CONFIG_USB_XHCI_PCI_RENESAS=m.
The problem is that CONFIG_USB_XHCI_PCI_RENESAS=m is not enabled unless manually selected.
Hope that this saves someone some time.
KDE/Plasma seems to keep reading a lot of stuff from disk on inital login, which may be holding up something that pipewire start-up needs.
Once it is all cached in RAM, a logout/login cycle avoids the reading from disk.
It sucks to be a vacuum cleaner.
I have been using in .xsessionrc
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-pulse /usr/bin/pipewire-pulse
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-wireplumber /usr/bin/wireplumber
but sometimes I have to log out and log in again for the sound card to be recognised. The sound card is fine and I don't have to do anything more than logging out and in again, but it would be great if it worked every time.
I run unstable/ceres and had a fair wait to upgrade kstars.
It involved removing indi-bin and aptitude recorded the process thus:
[REMOVE, NOT USED] libev4:amd64 1:4.33-1
[REMOVE, NOT USED] libindi-plugins:amd64 2.0.3+dfsg-1
[REMOVE, NOT USED] libindialignmentdriver2:amd64 2.0.3+dfsg-1
[REMOVE, NOT USED] libindidriver2:amd64 2.0.3+dfsg-1
[INSTALL, DEPENDENCIES] libgsl28:amd64 2.8+dfsg-3
[REMOVE, DEPENDENCIES] indi-bin:amd64 2.0.3+dfsg-1
[REMOVE, DEPENDENCIES] libgsl27:amd64 2.7.1+dfsg-6+b1
[UPGRADE] astrometry.net:amd64 0.95+dfsg-1+b1 -> 0.95+dfsg-1+b2
[UPGRADE] asymptote:amd64 2.90+ds-1 -> 2.90+ds-1+b1
[UPGRADE] inkscape:amd64 1.2.2-3+b1 -> 1.2.2-4
[UPGRADE] kstars:amd64 5:3.7.0-2 -> 5:3.7.0-2+b1
[UPGRADE] lib2geom1.2.0t64:amd64 1.2.2-4 -> 1.2.2-4+b1
[UPGRADE] libastrometry0t64:amd64 0.95+dfsg-1+b1 -> 0.95+dfsg-1+b2
[UPGRADE] libgiac0t64:amd64 1.9.0.93+dfsg2-2 -> 1.9.0.93+dfsg2-2+b1
[UPGRADE] libgnuradio-fec3.10.11:amd64 3.10.11.0-1 -> 3.10.11.0-1+b1
[UPGRADE] libgnuradio-wavelet3.10.11:amd64 3.10.11.0-1 -> 3.10.11.0-1+b1
[UPGRADE] libgslcblas0:amd64 2.7.1+dfsg-6+b1 -> 2.8+dfsg-3
[UPGRADE] libindi-data:amd64 2.0.3+dfsg-1 -> 2.0.9+dfsg-1
[UPGRADE] libindiclient2:amd64 2.0.3+dfsg-1 -> 2.0.9+dfsg-1
[UPGRADE] libipe7.2.30:amd64 7.2.30-1+b1 -> 7.2.30-1+b2
[UPGRADE] libstellarsolver2:amd64 2.6-1 -> 2.6-1+b1
[UPGRADE] python3-astrometry:amd64 0.95+dfsg-1+b1 -> 0.95+dfsg-1+b2
[UPGRADE] xcas:amd64 1.9.0.93+dfsg2-2 -> 1.9.0.93+dfsg2-2+b1
These kinds of transitions where earlier version packages depend on a library (in this case libgsl27 with a different name to the library required by the later versions of the packages (in this case libgsl28) seems to confuse the resolver used by aptitude and some manual experimentation was needed.
Ironically, after removing inidi-bin, I could re-install a later version of indi-bin:
[INSTALL, DEPENDENCIES] libev4t64:amd64 1:4.33-2.1
[INSTALL, DEPENDENCIES] libindi-plugins:amd64 1.9.9+dfsg-3+b4
[INSTALL, DEPENDENCIES] libindialignmentdriver1:amd64 1.9.9+dfsg-3+b4
[INSTALL, DEPENDENCIES] libindiclient1:amd64 1.9.9+dfsg-3+b4
[INSTALL, DEPENDENCIES] libindidriver1:amd64 1.9.9+dfsg-3+b4
[INSTALL] indi-bin:amd64 1.9.9+dfsg-3+b4
I had similar "fun" with the 64-bit time upgrade process.
What I needed to have in / was:
bin -> usr/bin
lib -> usr/lib
lib64 -> usr/lib64
sbin -> usr/sbin
After that, the base-files upgrade worked.
PS, on my i386 installation I had to use /usr/lib/klibc/bin/ln if the default ln program was unavailable while changing symbolic links.
Hmm, upgrade
[UPGRADE] base-files:amd64 13.3devuan1 -> 13.4devuan1
failed because I had symlinks from /bin -> /usr/bin and /sbin -> /usr/sbin still present.
However, a lot of scripts in /etc/init.d still have /bin and /sbin hard-coded, and removing those symbolic links causes a boot failure.
I've put package base-files on hold for now.
Didn't attend this concert but have seen some of the artists live (includes Marty Friedman on guitar):
Linked Horizon - Luxendarc Kikou - based on the soundtrack of the game Bravely Default
https://www.youtube.com/watch?v=ZDrp0k-11lM
Also available on Amazon Prime with English subs.
@GlennW my current solution is:
~/.xsessionrc
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-pulse /usr/bin/pipewire-pulse
/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-wireplumber /usr/bin/wireplumber
Currently working fine, but if the packages related to pipewire get upgraded, one may need to exit the desktop session, and if sound isn't working on logging in again either do:
init 1
then
exit
to get the desktop session login manager up again,
or in extreme cases shutdown the computer and reboot.
Hi, I'm having rendering issues with one web site for mesa versions later than 23.2.1 when using 2 different pc's:
one with an Radeon HD 5450 gpu (aka CEDAR), PCI ID 1002:68f9 (TeraScale 2) and
one wth an AMD A10-6800K APU with Radeon(tm) HD Graphics, whose GPU is reported as: Richland (aka ARUBA) Radeon HD 8670D, PCI ID 1002:990c (TeraScale 3).
What happens is when running chromium on https://abc.net.au/news/justin and selecting news articles in new tabs, those pages with large images only display the top and bottom part of the images.
I've reported the issue at https://gitlab.freedesktop.org/mesa/mesa/-/issues/10228 and attempted git-bisecting the problem, but had to skip around 100 commits as there were other rendering errors that prevented me seeing the specific problem that I was reporting.
If anyone is still running a Radeon r600 GPU (see https://www.x.org/wiki/RadeonFeature/ particularly TeraScale 2 or TeraScale 3, see https://en.wikipedia.org/wiki/TeraScale … hitecture) ) I would appreciate you reporting your exact GPU model and mesa version and whether you experience the same issue.
If you can take the time to create a gitlab account and update my bug report, even better.
Unpacking dpkg (1.22.5) over (1.22.4) ...
Setting up dpkg (1.22.5) ...
dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind dpkg's
dpkg: warning: back, breaking its core assumptions. This can cause silent file
dpkg: warning: overwrites and disappearances, and its general tools misbehavior.
dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
But the self-contradiction continues:
Q: Does dpkg support merged-/usr-via-aliased-dirs?
A: No. This approach is considered broken by design and breaks many common expectations.
In dpkg the expected breakage includes:failing to notice file conflicts with the subsequent silent file overwrites by f.ex. dpkg, dpkg-divert and update-alternatives,
files disappearing during package upgrades or diversion installation,
failing to activate triggers on pathnames,
failing to find pathnames on dpkg-query -S searches,failing to install packages shipping the same filename in real and aliased directories (with rather cryptic errors), f.ex. to be able to install otherwise dependency satisfiable packages needed by old software,
completely messing up the filesystem by simply using dpkg-deb -x or tar -x.If you have a system that has been installed recently (since Debian buster) or switched via the usrmerge hack, you might want to consider using the dpkg-fsys-usrunmess program (but beware that it should not be used in systemd's emergency mode) or reinstalling. For further information see Teams/Dpkg/MergedUsr.
Debian officially only supports merged-/usr-via-aliased-dirs systems. Converting to an unmerged-/usr setup might break the system in unexpected ways in the future, including data loss or failure to boot.
It's helpful to know what is different in your dmesg output compared with booting before usrmerge.
I had enough "fun" with incrementally adding symbolic links from old locations within /bin /lib /sbin to where the new locations in /usr/bin /usr/lib and /usr/sbin as individula packages changed the location of their files and finally installing the usrmerge package after I had manually done all the work.
Unfortunately when there are a lot of changes in one hit, it is difficult to identify the specific changes/errors that broke things.
While I was in the middle of git-bisecting a mesa issue I foolishly upgraded several packages without checking what was changing.
Some packages including the one containing getty and possibly mount had finally moved to their new locations and I was late adding symbolic links from the old locations.
Finally it was time to move the few remaining binaries in /bin to /usr/bin and from /sbin to /usr/sbin then:
cd /
mv bin oldbin; ln -s /usr/bin bin
mv sbin oldsbin; ln -s /usr/sbin sbin
/lib on i386 had one more caveat:
in /usr/lib you must have the symbolic link:
ld-linux.so.2 -> i386-linux-gnu/ld-linux.so.2
otherwise you will get a kernel panic on boot as the kernel tries to load init.
There were no other non-symbolic-link files in /lib that I had to worry about by now.
Then I was able to do:
cd /
/usr/lib/klibc/bin/mv lib oldlib;/usr/lib/klibc/bin/ln -s /usr/lib lib
After that I could successfully update package base-files which depended on package usrmerge
I keep writing letters to myself
Dear Me
update-initramfs broke when it couldn't find blkid
cd /sbin
ln -s /usr/sbin/blkid blkid
fixed things.
I also put package base-files on hold because in unstable it now depends on package usrmerge
I'll finally check /bin /lib /sbin for files other than symbolic links and see if I can finally manually make /bin /lib /sbin symbolic links to /usr/bin /usr/lib /usr/sbin
now package base-files in Devuan unstable (13devuan4) requires package usrmerge.
login 1:4.13+dfsg1-4 moved to /usr/bin
from /usr/share/doc/login/changelog.Debian.gz:
shadow (1:4.13+dfsg1-4) unstable; urgency=medium
[ Helmut Grohne ]
* DEP17: Move login and shadowconfig to /usr. (Closes: #1059915)
After the upgrade, I needed to do:
cd /bin
ln -s /usr/bin/login login
otherwise login via console/virtual terminal/telnet with ssl failed
Thankfully, desktop login still worked after the upgrade and before adding the symbolic link.
Reverted in the latest update:
Format: 1.8
Date: Tue, 13 Feb 2024 17:33:24 +0100
Source: kmod
Architecture: source
Version: 31+20240202-2
Distribution: unstable
Urgency: medium
Maintainer: Marco d'Itri <md@linux.it>
Changed-By: Marco d'Itri <md@linux.it>
Closes: 1063749
Changes:
kmod (31+20240202-2) unstable; urgency=medium
.
* Stop using /usr/lib/modules/ because it requires coordination with other
packages. (Closes: #1063749)
Package kmod 31+20240202-1 broke kernel builds for me, downgrading to kmod / libkmod2 to 31-1 fixed things.
@GlennW If you haven't heard it, Terra Firma by Tommy and Phil Emmanuel: https://www.youtube.com/watch?v=AzHUF3o5ML8
I remember Steven J. Vaughan-Nichols, aka sjvn from the UnixWare days.
Also met a few interesting Unix/BSD people back in the 1990's.
The history of that era is valuable.
Thanks @steve_v, one last thing - you should have mentioned that /usr/bin/daemon is in package daemon.
I'm wondering if this third-party repository has packages that aren't Devuan compatible for whatever reason.
At your own risk you could try removing that symbollic link and installing php8.3 from Debian Experimental.
TDR rant:
changing where packages install files so that they end up in /usr/{bin|sbin|lib} can only be expected to happen one package at a time (or with packages that have dependencies on each other package's versions), so those packages should create symbolic links from /{bin|sbin|lib} if directories /{bin|sbin|lib} themselves aren't symbolic links to /usr/{bin|sbin|lib}
So far, I've only noticed package acl "doing the right thing" by leaving symbolic links in /bin pointing to the new binaries in /usr/bin
I have finally moved anything in /bin that is not a symbolic link to /usr/bin to /usr/bin
Also, moved anything in /sbin that is not a symbolic link to /usr/sbin to /usr/sbin
WARNING ln, ls, mv are in /bin - if you don't already have copies of ls, ln and mv in /usr/bin you should probably copy the versions in /bin to /usr/bin before doing a move / link that involves mv, ls and ln.
Alternatively, just leave files from package coreutils in /bin.
The tactic that I used was to run a command like:
cd /bin
ls -lt|grep -v /usr/bin|more
to see files grouped by date of installation.
It turned out that many newly updated packages had the newer files in /bin but there were still files from the same packages in /usr/bin from older versions of the packages.
So what I needed to do was move the files from /bin to /usr/bin a few packages at a time, then create symbolic links from /bin to /usr/bin
To do this I ran:
cd /bin
ls -lt|grep -v /usr/bin|awk '{print $9}' > tmp.tmp
then manually edited tmp.tmp to just include the file/link names of the oldest few packages.
Then I ran the following to move the files/links to /usr/bin:
cat tmp.tmp|xargs -i mv {} /usr/bin
and the following to create symbolic links in the /bin/directory:
cat tmp.tmp|xargs -i ln -s /usr/bin/{} {}
This was repeated until all file/link names in /bin that weren't symbolic links to /usr/bin had been moved to /usr/bin and sybolic links from /bin to /usr/bin created.
I then did the same for /sbin:
cd /sbin
ls -lt|grep -v /usr/sbin|awk '{print $9}' > tmp.tmp
edit tmp.tmp manually to only include file/link names from a few packages at a time, then ran
cat tmp.tmp|xargs -i mv {} /usr/sbin
to move the files/links to /usr/sbin and
cat tmp.tmp|xargs -i ln -s /usr/sbin/{} {}
to create symbolic links from /sbin to /usr/sbin:
Again, this was repeated until all file/link names in /bin that weren't symbolic links to /usr/sbin had been moved to /usr/sbin and sybolic links from /bin to /usr/bin created.
I then re-ran:
update-initramfs -u -k $(uname -r)
to make sure that update-initramfs was using the latest installed packages.