You are not logged in.
Yes chimaera-backports came back. I think it got removed when bullseye-backports got removed; then bullseye-backports came back; and then after a while chimaera-backports came back. And during all that bullseye and chimaera also got archived. All done very much on purpose by Debian and Devuan "repository dev's"; I'm sure there is a story.
Perhaps it stays like it is for a while.
Yes.
Print it out, frame it and hang up on the wall.
Then you can show your kids and grand kids how adults do things.
@steve_v: you still here? And you still contribute to the discourse?
You are too kind.
It looks like there you have a task to volunteer for.
Well, at least half the population is above average IQ...
I wouldn't worry about that until it fills up; then removing old kernels is the first step. Though generally it may also be a good idea to keep a "live installer" USB stick on the shelf.
Hmm, yes I only have two kernels with their initrd, each pair being 12+32 Mb, so again, I don't understand what they refer to. That's standard Debian kernel+initrd adding up to 44 Mb each. So if you need more than 10 of them you might be in trouble.
EDIT: perhaps if you want lots of pre-pivot software it will enlarge initrd, and perhaps that'll then grow above 100Mb.
I'm not sure what that issue is about; my excalibur boot directory is 100 Mb, though also not a separate partition. I think 487 Mb is plenty and it's certainly fine as a raw partition.
EDIT: I also have an EFI partition with <5 Mb bootloader (grub), which gets mounted as /boot/efi.
@marma-lade: did you by chance opt for "expert" install, and then skipped the "load additional components" step?
Yes, it should be fine like that. Of course any dkms modules might play up.
I've also seen that some people have issues with their windowing programs with excalibur, but that's more of a post-upgrade concern.
And some, like me, might prefer
Binary::apt::APT::Color "false";
Seems your DNS is playing up. First try ping -n deb.devuan.org and second try traceroute -n deb.devuan.org. Does that give anything?
Btw. use code blocks for code (and console output); not quote blocks.
Change your sources to use http://deb.devuan.org/merged, i.e. /merged and not /devuan ... see https://www.devuan.org for details.
It appears your system in the chroot has a directory "/run/systemd/system"; perhaps that chroot filesystem has a bind-mounted "/run" from an outer "grml live iso" system with that badness in it?
.. and chimaera-backports has (finally?) been removed.
Point your browser at http://deb.devuan.org/merged/dists and http://archive.devuan.org/merged/dists/ to see all available repositories.
Yes, @tux_99, I read your post too hastily, and I thank you for your suggestion. My note about childish noise obviously doesn't apply to your offer.
The Devuan git store has had address block blocks a long time, and it does work to some extent. But as you would know, it's a method that requires constant monitoring and tuning, and that one can accept longish periods of seriously degraded service.
Yea we tried blocking IP addresses, but we stopped at some 50000 addresses blocked (60% ipv4 and 40% ipv6. A lot of effort and not effective.
Anyone with a viable solution may contribute. All else is just childish noise.
DDoS is an abbreviation for "Distributed Denial of Service". It is a label given to what happens when a "rouge actor" sets up a system where a large number of computers "hammers" a service with incessant networking, and the service gets bogged down so that it fails to provide service.
That is what git.devuan.org is suffering of; a constant such hammering is happening that is a magnitude or more larger than how it was just a year ago.
The Anubis front-end feature makes it possible for git.devuan.org to provide service.
Your input is without value unless you can provide an alternative solution.
Perhaps, rather than a string of negativity, you have a good solution for how to avoid the server being DDoSed by all today's crawlers?
"Brought no result" is perhaps not too expressive.
Does this mean that you copied the ISO file onto the device as suggested? Could you please show the exact command you used when doing that?
Did you try booting in legacy mode as well as UEFI, and in both cases the console display stayed off?
It is quite peculiar (and unusual) that your system has such a hard time booting. You never told which CPU it is. And the machine assembly as a whole, is that a certain "brand" or is it your own assembly? What's the brand of the USB stick?
Interesting. That method should indeed allow the EFI boot loader to start so you should have come to that initial bootloader menu. One reason for not getting there could be that the UEFI bios is particular about the EFI partition.
I think the easiest way for you would be that you go back and simply use 'cp' to copy the ISO onto the stick device, like so
cp iso /dev/sdc
if /dev/sdc is the stick device.
Then try with that.
The point is that your method will lead to failure later on anyhow, even if the bootloader gets started.
Thanks. Peculiar. Which brand of computer is it? I mean, which hardware, especially which CPU.
How did you copy the Devuan installer image to the USB stick?
I'm confused; what do you do leading to a black screen? Can you please try to describe all that happens after power on... what happens on the computer and what do you do (if anything). Is it just that you power it on but it stays with a black screen? (Though that wouldn't seem to indicate that something "loads").
What does "and loads" mean?
Is "secure boot" is turned off?
Yeah; my reference is to your thread title: "I seem to crash when I go to a certain website..."