You are not logged in.
Yeah; sorry about that... was meant as a pun really, and not to offend. Apologies.
The key point anyhow is that you can use the preview button to refresh the session.
regards,
This forum has a half-hour timeout for the idle time between interactions which separates them into sessions. If you are editing a post, you may hit preview within that half-hour so as to maintain the session without making the post. That will extend the session timer with another half-hour. It will also refresh your thread view with any posts that have been made while you ahve been sitting there prefectering spelling.
Thanks, yes, and it also needs an early short command line detour for device mapping.
But that detour is not available for booting the installed system, and I'm not sure how to set up grub for that... it seems to need a boot device outside of the encrypted disk?
How do/did you set up "full disk encryption"?
For me the chimaera installer only lets me reduce the disk to a single partition and encrypt that; is that what you mean?
But then, for me, the installer objects and goes into loop trying to force me to have a separate unencrypted /boot partition while not allowing me to erase the setup.
So, would you mind describing your "full disk encryption" (so I can trial it).
Is 1.46.6-1~bpo11+1 from chimaera-backports sufficient?
When installing the package usrmerge it will try to change the file system so that some root directories get changed into symbolic links for the same-named directories in /usr; those are what I call the "silly-links".
Unfortunately the usrmerge developers seemingly opted for going about this in the worst way possible, so the installation of usrmerge is likely to fail successively, requiring some amount of operator hands-on and reinstallation. Once installed, it gets replaced with the usr-is-merged package as indicator or flag for apt/dpkg to not install usrmerge again, ever.
All in all, it's better and almost necessary (esp for avoiding that operator hands-on) when shifting to excalibur, to install usrmerge on daedalus, i.e. before actually shifting. There is no technical difference difference between having or not having silly-links, except for the cases where a package installs binaries with a /bin path and then uses them on a /usr/bin path or vice versa (looking at you, busybox), in which case silly-links are required.
If you want to set up silly-links yourself you only have to make sure that the pathnames /lib* get copied and replaced with their links in "atomic steps"; i.e. you cannot use a shell script that separates "rm /lib" from "ln -sTf usr/lib /lib" specifically because the script intepreter's running of "ln" will require that the ELF-loader is found on its "/lib/.." path. (It's pretty obvious how to work around that though, for example by using busybox-static or , say, newlisp).
fwiw, I've now confirmed that the pulished 20240424... iso for me completes base system installation with hands-on as outlined above.
Argh! With the downloaded netinstall the failure is that "usr-is-merged" is unavailable.
I thought I had worked around that issue but obviously failed ... yes, failed to add that workaround to the commit.
Thanks for testing. There is a new collection (including that commit) coming up shortly.
Ok. Strange. Though I'm using a separate netinstall build so I will download the published one and try that.
"VM" is "virtual Machine", i.e. a machine emulator. I use "qemu-system-x86_64" in its default hardware emulation... with an (emulated) ethernet card, so I'll try without that as well. And the ISO is presented as a cdrom but that also shouldn't make a difference.
Are you using "netinstall", "server" or "desktop" ? I'm using netinstall in a VM and have success with the hands-on I outlined. It you're using "server" or "desktop" I can check with those, though the installer software for the base system is meant to be the same.
Yes, excalibur is testing, and there's some inconsistency with its packages so you'll have to not install packages. I.e., after selecting kernel and generic modules collection, then you
skip both the "configure package manager" and "select and install software" steps, and instead
continue with
"select an init system" followed by
"install the grub boot loader" and finally
"finish the installation"
Doing all that leads to a very basic intallation with "nano" as editor, and you need to manually set up /etc/apt/sources.list in order to start installaing packages with "apt-get".
Run the installation until that red screen, then push contine until the expert install menu comes up showing that you are on "Install the base system".
Now, step down to the "Change debconf priority"; select that and select the suggested "low" priority, which returns you to the expert menu and the "Install the base system" step.
Select that will now give you the option of choosing "yes" for silly-links, and that will then allow the base system installation to complete. Pick kernel and modules, and then use "go back" until the expert install menu again...
.... then it's just to pick your init, install grub, finish installation, and reboot.
.. and I wish there where an https://files.devuan.org/devuan_excalib … README.txt
Yes, no further testing is needed; there appears to be a mismatch between kernel and modules for excalibur so it won't work. Thanks for trying.
Hey @zapper, a positive action on this forum would have been to propose the hands-on and/or package list to use from the Devuan repositories in order to have that "minimalistic system".
As you know, there is no single "Devuan System" as Devuan is a repository of packages that includes all Debian packages except those that are or relies on systemd; it is your choice.
Possibly because it depends on $syslog which isn't started in the rcS collection.
Maybe try also with
# Required-Start: $local_fsas otherwise the root filesystem might still be mounted read-only when the output is attempted.
Could be. But I think the OP issue is at the "audio server" end rather than the device end. At least that's how I remember it although I don't remember the details.
From that display it appears the headset is paired (and I assume you've marked it trusted). If it's paired, you shuld be able to tickle the "Info" option of the right-click menu, which should bring up a window of this-and-that about that headset including some few "UUIDs" for the audio profiles that it implements (eg "Headset", "Audio Sink" etc).
A connection requires that the computer runs one or more "audio servers" that registers to "bluez" as a handler for some profiles. As you already know pulseaudio has a bluetooth "module" to install to make the pulsaudio process such a server.
I haven't used pulseaudio for many years but if I remember it right, in addition to installing packages I also needed to fiddle with some of its configuration files for the module loading to happen. Afair, there are different fiddlings depending on whether pulseaudio is run as root or as non-root user. It's comprised of both the "registering" of the module to pulseaudio's module register file(s) and then some "authorization" hands-on to its runtime configuration files.
By one web search and a little bit of reading I found
https://forums.linuxmint.com/viewtopic. … 4#p2333570
Though I suppose you've also done such trivial a search, found that posting, tried that already and failed?
As far as I understand that description, the error is that the device gets setup with wrong audio profile. And then that the "Bluetooth connection fiddling GUI" only offers a change to that while connection is happening (before it fails).
Which audio proile is it set up with?
Is that a profile that the dongle has?
Have you tried using other profile(s)?
"the job" ?
There was a bug in logind0 where it, upon exiting the seat, changed the ttyN owner to be root and that resulted in the user not being able to run startx a second time (that bug was inherited from the s*d code where it had been logged and resolved as a "won't fix" issue).
Though I don't remember the versions involved off-hand, and I believe the fix got into daedalus so your "freezing problem" is likely something else. If you have any "side entry" (ssh or something) to the host you could check. That bug was only with elogind and not with seatd.
Any user who is allowed to become root may well be in the input group.
Try by adding a single "#" at the beginning of the line that says use-ssh-agent in /etc/X11/Xsession.options; then log out and in to restart the X session.
Some tidbits:
1) the user that runs Xorg in vtN must have rw access to both /dev/ttyN and /dev/tty, and (I think) have w access to /dev/tty0 as well. This access is required for Xorg's VT ioctls.
2) further, that user must have rw access to /dev/dri/card0, i.e. the graphics card in use which typically is card0 but could possibly by card1 etc. This access is required for Xorg's graphics ioctls.
3) further, that user probably must have access to /dev/fb0 as well.
4) further, that user must have access to input devices, ether directly or as mediated by either logind0 or seatd. This access is required for Xorg's use of input devices.
4a) the logind0 method for mediating input deices requires access to a system dbus with whatever plethora of environment variables that requires. This typically gets done by using elogind for "session management".
4b) the seatd method for mediating input devices requires acces to the seatd communications socket.
Normally, (1) is typically achieved by the text terminal getty program which makes the logged in use the owner of the associated /dev/ttyN. The other (2-4) are typically achieved by the devices and the user being in the video group.