You are not logged in.
There are numerous of ways to run programs, including to run programs that keeps other programs running. If a person wants their machine to do that then they would set it up to do so. Or are we working on a premise that end users are stupid, or that end users should be controlled (by owner-administrator-vendor)?
Isn't pipwire something to be run by the (local desktop) user?
Looks to me like your system is all good and that you have run into a flaw in debian's package provisioning; namely that they happen to include a host that is currently unresponsive.
Debian packages are accessed (by your host) via the domain deb.debian.org which afaik is resolved by "fastly" into one (or possibly a few) actual host IP, and it happens that it transiently offers "bad" IP.
If you want your resolution of deb.debian.org go to a specific host of your choice, then you may set up that resolution in your /etc/hosts file.
Sometimes this kind of thing happens if your local meta files are outdated, in which case you will have to run apt-get update to freshen them.
That's good. Just fill the forum with generated crap... much better than the mind-authored.
not.
Something funny is going on if the millisecond timestamp stays the same for the Xorg logs... are you sure that that is the current log file?
It sometimes helps to run
apt-get update
to update your local meta files.
TL;DR; apt asks for particular versions of packages and it does not ask for "whatever is current right now" (as one might think it would do). The meta files tell "slices" of versions across packages that have been tested and shown to work together. Sometimes one would want apt to run "update" automatically upon install of packages, but I guess that would add code "unnecessarily"; anyone who wants update to be part of installing would simply do that themselves.
Sometimes though it's a neworking problem, or that the target server has a transient problem.
I believe it would merely be a boot action aimed at restoring the brightness at boot up to a level that got captured at power down. So, a comfort utility. But I'm sure one can expand the concept to any level of complication and introduce all sorts of knick-knack with elaborate justifications and then you can add steak knives to that...
Some people may want to be able to move a disk to another slot and still have the system to boot.
"before latest upgrade", "after latest upgrade" as well as "updates that came maybe a week ago" are all pretty lousy version identifiers.
Thanks. esp the note about email; (your email got filtered as spam... it reminded me I need to set up my real email address here since google filters rather than forwards some emails that it judges to be spam)
Anyhow, it shows that the second partition on the /dev/sde drive holds an iso9660 filesystem. Presumably the Ventoy iso. (It seems the UEFI bios reorders the drive partitions so that the EFI partition counts as the first one, not mounted)
It's the "load modules" step that requires the media to be mounted for the Chimaera ISO. Though if the network works with the initial modules you can complete an installation without access to the media provided you don't need to set up the target partition as, say, ext4 as part of that installation. The Daedalus ISO boot up requires access to the media at an earlier point and it fails when that media is missing.
One could imagine that the second /dev/sde partition indeed would be the target iso file in some virtual loop-back mounting done by Ventoy software "behind" the kernel, but then this would be the same for Daedalus.
You gave me the Ventoy version (96) on email so I can experiment with it myself.
As I looked into Devuan 5.0.1 ISOs I saw that I had it wrong: that ISO does not consider any Ventoy labelled partition. I then realized I have been referring to an unpublished Daedalus 5.1.0 that was handed out specifically to someone some while ago.
But what does "mount" say (when chimaera installer at partitioning)? And does that partitioner offer a large number of partition types? Maybe I'm wrong there too?
That is interesting. Would you be able to make that ventoy stick image available to me?
If I remember right, the partitioning step needs modules from the media to set up ext4 partitions.
Could you when the partitioning step starts make a detour by using Ctrl-Alt-F2 to enter shell, and there type "mount" to see what is mounted... what is the output of that?
EDIT: also, what does blkid print for /dev/sdg1 ... Have you tried labelling that "Ventoy" ?
there may be an exfatlabel utility for that or tune.exfat.
Right; can you install chimaera with it?
I know it runs and so does daedalus, but they differ in when they need the media. Both of them have the problem that when they need to mount the media, they fail.
EDIT: Though, the Daedalus boot preamble includes logic to look for the ISO as a file in a partition of type exfat and labelled "Ventoy".
So if the Ventoy partition would be labelled "Ventoy" and is of type exfat, then the Daedalus preamble may find the file and loop-back mount that for the installer (as well as for finding the actual installer initrd in the first place). And in that case installation is made possible. This logic is not present in the chimaera iso.
Daedalus is the only release that fails on Ventoy. ASCII, Beowulf and Chimaera work fine.
I am surprised to hear that! Afaik they all need to mount the media, and ventoy doesn't offer it as mountable. Perhaps you could provide me with a such loaded USB with, say, chimaera, to investigate?
EDIT: the installer may well start and bring up a dialog, but it fails after a couple of dialogs when it comes to the step that needs to mount the media. That step essentially uses blkid to find the mountable devices. When using a ventoy boot, the ISO is merely a file somewhere in the first partition.
There's bluealsa (package bluez-alsa-utils) for using bluetooth without pulseaudio.
Though it'll also need asoundrc configuration both so as to make the choice of output dynamic (so you can select output for an already started program) and to have bluealsa as one of the sinks. I'm happy to drop my setup here if you are interested.
EDIT: actually you might get that dynamic choice via pipewire, so the only ALSA pcm setup you need would be for the "output" itself. Something like the following (which I named bt_qudo (for my Qudo speaker):
pcm.bt_qudo {
type softvol
slave {
pcm {
type bluealsa
device 30:21:DC:50:9E:89
profile a2dp
}
}
control { name "PCM" ; card 0; }
max_dB 15.0
}
You will need to set your mac address; i.e. the "device" value, and then of course adjust "max" to your liking.
With that you would need to confiure pipewire playback to use "bt_qudo".
(Then I also have a vague memory of some dbus configuration fiddling; I will need to browse my setup a bit to remind me about that)
Well, there are a couple of graphical tools to mismanage network configurations with, and there is the traditional ifupdown that uses /etc/network/interfaces as its control file.
Guess which I'm using
If your router is set up to provide network settings via DHCP, then you would configure it such for ifupdown. See man interfaces. Otheriwse you need to configure manually, either directly as you did, or by editing the configuration ... for ifupdown it's /etc/network/interfaces, and for gui tools they typically offer their own editing dialogs for manual editing of their configuration files.
You could disable that removal by
sed '469s|rm|##|' -i AMD-Catalyst-15.9-Linux-installer-15.201.1151-x86.x86_64.run
but then I'm not sure how you'd proceed. Doing this the "run" script will leave that temporary directory rather than removing it although it still complains and claims to remove it.
Friends, there are thoughts at many levels and many perspectives.
Let's close this thread.
Yes, the Devuan ISO is built differently from the Debian ISO; the build processes are completely different although many of the building pieces used are common at least in name but also in full.
Any ISO that "works with Ventoy" either includes software explicitly for working with Ventoy, or have their installer fully contained in the initrd that Ventoy unpacks.
The Devuan ISO effectively lacks software for working with Ventoy, since the software it has for that installation usecase is too restricted; it requires your Ventoy partition to be an exfat filesystem labelled "Ventoy".
Apart from that the Devuan installer simply requires the iso media to be directly mountable; i.e. the disk in whole or a disk partition.
Not sure what you are saying there? Does Ventoy do things in some other way than what I described? Is it different now from before?
And what does "supposedly the same ISO except for branding/sources with the equivalent Debian on it" mean?
Probably it gets sorted with an initial
dpkg -i --force-overwrite /var/cache/apt/archives/libc6_2.41-2_i386.deb
or if you use --force-all rather than --force-overwrite.
Thereafter follow up with a new
apt-get -f install
But you should have a live disk at hand, just in case things go badly.
The point is that Ventoy does not provide the respetive ISOs as mountable partitions which is what many installers expect and require; they require that the initrd software of the installer is able mount the media.
They are not set up for "browsing" available partitions for directory trees and search for their media as an image file.
Those installers that are complete in their initrd work with Ventoy, because the Ventoy boot loader knows how to browse the Ventoy partition for the selected image file, then it loads the kernel and initrd from the that image file, and boots that kernel. At that point it drops all access details for the image file.
Also those installers work that have initrd software that can mount the Ventoy partition and search for their own media as image file.
In fact the daedalus installer preamble attempts to do that. But requires (if I remember right) firstly that the Ventoy partition is labelled "Ventoy" and secondly that the partition with the image file is an exfat partition. If the preamble then finds the image file it will set up a loop device fo the image file to make it appropriately mountable for the installer proper.
When you copy the image file directly to a drive it is a due mounatble partition for the installer initrd.
hacksenwerk, if your web browser has styling plugin cability or similar, you could probably use that to adjust the style to you liking.
And if you do, don't heistate to share the fruits of your labour. There might be other people wanting personlized presentation without logging in.
Note that the scripts don't do anything at start, so your "# Default-Start: 2 3 4 5" are without effects.
Also, umountroot doesn't actually unmount the root filesystem, but it remounts the filesytem root as read-only, and that should be enough to usually avoid fsck on boot-up.
And, I'm sure you wouldn't want unmounting to be done upon "S s 1", and you should restore the normal "# Default-Stop: 0 6".
It appears you are using runit rather than sysvinit? If that's the case I wonder if you have set up it's start/stop configuration to execute those scripts? I believe it's done differently from the sysvinit setup although many sysvinit scripts may be used with runit.
The reason for holding back an upgrade would be becuse it wants to bring in another, new package, which is something an upgrade doesn't do. You can find out which new package is concerned and install that, or you maybe do a dist-upgrade instead.