Probably this but seems like a pain to use:

https://www.kernel.org/doc/html/latest/dev-tools/kmemleak.html

deleted by creator

Yes, sorry, you are correct. I’ve edited by other comments.

Edit: You are right. I looked it up:

There seems to be an actual technical difference, in the kernel, between an initrd and an initramfs. An initrd is apparently mounted like a normal file system, it’s just in RAM instead of a backed by a block device. An initramfs is a tmpfs into which a (usually cpio) archive is extracted into. The initramfs apparently would be preferable generally, because the kernel understands that it’s a ramdisk, whereas with an initrd it would go through the block device layer, which would mean it would use more ram: If you read a file from an initrd, the kernel would copy the file to ram (unnecessarily, since it’s already in ram) like it would for a filesystem on disk, but for a tmpfs/initramfs, it understands it doesn’t need to do that.

From a user’s perspective there is no significant functional difference I don’t think, and I don’t think this relevant to OP’s question, that probably has more to do with the userspace tools.

Since it doesn’t happen on Windows, it’s probably a driver issue. You can try a newer (or older) kernel, and you can try to report this to your distro or upstream (probably the Linux kernel mailing list, in this case). Both have a low probability of helping you. You could try and debug this, but that likely requires some advanced skills.

So, firstly, about the nomenclature: initrd (initial ram disk) and initramfs (initial ram file system) are usually used interchangeably as far as I know. For example, even though my Debian uses initramfs-tools, the generated images are called /boot/initrd.img-*. (Edit: There is a technical difference but an initramfs may be referred to as an initrd (like in this case) due to how similar they are.)

For example, when installing a kernel, apt shows this output on my Debian machine:

linux-image-6.12.6-amd64 (6.12.6-1) wird eingerichtet ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.12.6-amd64

What you’re talking about is probably the software used to generate this initial ramdisk, which on Debian is done using initramfs-tools (which contains the mkinitramfs command), while on other distros dracut (command: mkinitrd) might be used.

I will say it strikes me as weird that Devuan doesn’t use initramfs-tools since it’s a Debian derivative. Maybe you are mistaken about this? Possibly no initrd/initramfs is used at all on this specific Pi version of Devuan? IDK.

Edit: See my other comment. I’m wrong. There is an actual technical difference between initrd and initramfs, but I don’t think that’s actually relevant in this situation. Or rather, both are functionally the same, so it doesn’t really matter from the perspective of the user or distro that there’s a difference. I will keep the rest of the comment as is, since I do reckon OP’s problem is unrelated to this difference, and that probably something else is tripping up OP.

whole lot of annoyance over so-called anti-establishmentarianists who rather talk Linux for months on end with no actual plan of moving even though they talk as if they have one, that fucking ticks me off, and I feel as if it’s everywhere because people wanna fit in

Yeah you’re keeping it real, fucking posers amiright? You’re sooo mad at all these phonies just trying to fit in.

I seriously hope you’re just a teenager because that means you’re going to grow out of this phase, otherwise this is just sad.

This reminds me when I was a teenager, it’s sort of a tradition to call anyone who got into $THING after you did a poser, while the older kids make fun of you for the same reason. This establishes the hacking order. Since I reckon I’m the elder in this situation, I’ll do this to you now: Stop being a poser, you don’t want to scare away any cool grown-ups do you?

This is an terrible take. You must have switched the moment you became aware of Linux, had no qualms or before the switch, didn’t mull it over even a little bit.

Please go back in time to when you weren’t using Linux yet, and direct this rant at yourself and see how you like it.

ls inherits stdout/stderr from bash, and then writes directly to that, which in this scenario is the pty (pseudo teletype) device created by xterm. Bash isn’t involved in forwarding that. The ls output goes via the pty device driver in the kernel straight to xterm, bash doesn’t see it.

In order for what you’re suggesting to work, bash would have to open up it’s own pty, which it doesn’t. But something like tmux does. Hence why I wrote you’d need to make a shell/tmux hybrid. The bash/tmux hybrid could then intercept the ls output and forward it to the xterm pty, like you are imagining. But tmux (or screen) are complex pieces of software, basically full terminal emulators. Adding an overlay (or whatever) feature to xterm for bash to use would surely be less complicated. Though I guess with how many terminal emulators there are, you’d need to convince at least the most popular ones to implement that (good luck). So both ideas, while theoretically possible, seem like non-starters. Too much thankless work and plenty of pushback I imagine.

Since everyone keeps mentioning yt-dlp I gotta ask: what’s wrong with the original youtube-dl? I keep using it, it works, it’s still being updated.

This doesn’t seem like something a shell can implement properly. Well, except maybe you could make a shell+tmux hybrid, but that’s a terminal emulator running inside of a terminal emulator then (as are tmux and screen).

The problem is that when you run e.g. ls, it prints directly to the terminal. The shell could, once ls finishes, reposition the cursor to the top and then print over the ls output, but that’ll just overwrite part of the ls output and ruin the scrollback buffer, which would be annoying.

I think if you really wanted to implement this properly you’d need some sort of new feature (like an overlay layer maybe), implemented by the terminal, and then the shell would have to be patched to make use of that.

The “slow down and then quickly fully freeze”, while it could be other things, might be a low RAM situation. Could be some buggy program that is leaking memory. Try running EarlyOOM or systemd-oomd.

Listen to yourself. What’s a distrobox? Boxbuddy? I’m already annoyed about someone expecting me to learn about this and I’ve used Linux exclusively for 25 years. I actually did Linux from Scratch and used that for 6 months for actual stuff. Telling a noob who wants to do normal things that work on a normal Linux distros that because of the (recommended by you) immutable distro they have, they need a container which has an actual normal linux distro inside it to run the thing they want to run, they’ll want to run away and probably never speak to you again.

And about flatpak: I had so many bugs that somehow only happen when you get the flatpak. And you can’t install command line tools over flatpak, you can’t install servers or drivers. Regular users (especially windows power user types) are likely to run into these things and curse you for recommending the one distro where you can’t just apt install theclitoolineed.

I’m not sure about recommending immutable distros to noobs, I’ve read enough reports from people that want to (or because of some hardware crap, need to) install or mess with some low-level stuff that just won’t work on the immutable distros, plus a bunch of online advice or help will just not be applicable.

I don’t think so and have never heard that, but I could be wrong.

You can just do for f in * (or other shell glob), unless you need find’s fancy search/filtering features.

The shell glob isn’t just simpler, but also more robust, because it works also when the filename contains a newline; find .. | while read -r will crap out on that. Also apparently you want while IFS= read -r because otherwise read might trim whitespace.

If you want to avoid that problem with the newline and still use find, you can use find -exec or find -print0 .. | xargs -0, or find -print0 .. | while IFS= read -r -d ''. I think -print0 is not standard POSIX though.

My built-in SD card reader shows up in lspci as an “SD Host Controller”. Since lspci and lsusb should list everything that’s connected, it should show up there. If it’s not there, it is not connected, or idk, it’s broken maybe. Or it’s not listed with a name, just a number. I think the names come from some database of known devices. Maybe your SD card reader is a unicorn and nobody has ever seen it before and so it’s not in the database.

Pretty sure the main difference is that one puts stuff in a directory called esp (which I assume is a placeholder for the actual directory?), and the other one is put in /efi. That needs to be the path to your efi partition, because that’s where the UEFI expects to find things it can boot. The target is probably redundant, i.e. it defaults to x84_64-efi on Gentoo (maybe not on Arch?) and the id is just a name, you can put whatever there. See man grub-install.

You’re ignoring the fact that the US knows the weapons are used for war crimes, have been used for war crimes before, and that they’re supplying ever more weapons despite this. If you give your kid a gun and you know he’s going to murder someone, and he’s done it before multiple times, you’re going to jail.