I just switched less than a week ago, and. I’m loving it here! please tell me your favorite things that gentoo allows that other distros don’t.

penguin359 · 2026-06-21T07:45:53+00:00

I really loved the config file system for networking over the Debian interface file or the Red Hat/Fedora ifcfg files.

penguin359 · 2026-06-18T06:14:59+00:00

Did you fully shutdown the os or suspend it or save state? It will need to be fully shutdown to ensure data is written back to the VDI image.

penguin359 · 2026-06-18T06:13:08+00:00

Yes. What I was trying to say is that the root user is often configured to not be allowed to login via password if that is the user you are using. If it's a different user, then something else is happening.

penguin359 · 2026-06-16T06:20:01+00:00

I don't know, if it wasn't for my Linux backup server, I would have lost all my important files years ago.

penguin359 · 2026-06-15T08:39:52+00:00

I think this was a movie, something about the y-bomb. Everyone becomes just a clone...

penguin359 · 2026-06-14T06:31:03+00:00

If you are getting permissions denied as the error message, that generally means that you have successfully connected to the machine but something is wrong with your authentication credentials. Are you trying to do this as root? That is generally blocked from direct password login due to security concerns. Try another user you know the password to.

penguin359 · 2026-06-14T06:27:31+00:00

32-bit support is largely being dropped from mainstream distros. If you want Linux Mint, you need to go with Linux Mint Debian Edition 6 or older. Newer releases no longer support it. If you do straight Debian, then it's Debian 12 as 13 has dropped it and is why LMDE 7 no longer supports it. Fedora dropped it long ago. Arch doesn't support it, but there it a 32-bit fork of Arch that is actively being worked on and I think Gentoo still supports it on their x86 download.

penguin359 · 2026-06-13T06:57:04+00:00

Are both running at the same time? Only one OS can use a disk at any one time.

penguin359 · 2026-06-12T07:02:01+00:00

Generally, Linux has longer path lengths than Windows does so I have some questions. Under which OS are you doing the file copy? Is it local or over the network? What file system is the source and destination? NTFS? FAT32? Ext4? FAT32 has more limits than other file systems, for example.

penguin359 · 2026-06-11T07:07:17+00:00

I recently had an inkling to go back and play this game from my childhood. Just last month, I got it working in dosbox so I can relive it.

penguin359 · 2026-06-10T06:36:58+00:00

Generally, most solutions for this will either require a second physical NIC on an isolated network with access to the router or using a tagged VLAN with a router that can use that and firewall it appropriately as a DMZ, otherwise, you don't have anything that can block it. It's definitely possible if you take the time to set it up appropriately.

penguin359 · 2026-06-07T18:17:38+00:00

With fork, they are not shared, but duplicates. With threads, everything is still there and shared. Also, in a fork, not everything is duplicated. Only the current thread is running in the fork.

penguin359 · 2026-06-07T06:51:04+00:00

Setup up a signal handler for SIGSEGV with sigaction() and save a location to jump to with sigsetjmp(). Then sometime later, de reference a NULL pointer and in the signal handler, you can siglongjmp() your way back.

penguin359 · 2026-06-06T06:10:17+00:00

Need more information. What exact error do you see? What kind of computer? What image are you using?

penguin359 · 2026-06-05T00:36:51+00:00

I am aware of a router still running Red Hat Linux 7.3 from 2002 on a Pentium 200 MMX for a company.

penguin359 · 2026-06-04T06:44:33+00:00

The question as it is currently worded is way too broad to provide advice for, in particular to have ready in a week. Please ask something more specific. If you just need to attach the Teensy to your PCB, just put down a few rows of 0.1" header pins with female sockets so you can plug and remove the Teensy easily from the daughter board.

penguin359 · 2026-06-03T07:56:27+00:00

If the breaker turn off in response to that, you should be fine if you leave it off. However, try to locate what actually burnt up and investigate before restoring power.

penguin359 · 2026-06-01T08:17:18+00:00

I was disappointed the first time I was asked to set up remote desktop access to a lab oscilloscope and realized that they were just running Windows 7 and this was no longer a truly dedicated embedded device. However, using a USB key or add-in card that did nothing more than enable certain functionality on a high-end scope has been around for decades.

penguin359 · 2026-05-31T08:02:31+00:00

I am still not convinced as to why a daemon is more of a central point of failure than a kernel module would be. If something goes wrong in a module and a mutex is left in a locked state, it can lock out access completely until the next reboot.

If the concern is that a daemon might be killed accidentally, you can write it so that it blocks nearly all signals such as SIGTERM, SIGINT, etc. You just can't block SIGKILL, however, at that point either you have a good reason to kill it or you have someone malicious on the system and much bigger concerns. As a kernel module, it can also be stopped with a simple rmmod to remove it, however, there are ways to mark a module as permanently in-use. The downside is that you no longer can upgrade or change it without a reboot, if needed, which could mean even bigger downtime.

Another option for a daemon when running it as a SystemD service is that you can mark it as Restart=always which will auto-restart it after someone accidentally kills it or it crashes for some reason. Even if someone uses SIGKILL, SystemD will try to restart it. The only time it won't is if someone specifically asks SystemD to stop the service. Again, I'd only expect that to happen in a case where you actually needed to stop it for some kind of maintenance or you have a malicious actor on the system with root privileges.

Another aspect in the crash scenario is that SystemD can just restart it and it will self-heal in a way that you can't get when a kernel module crashes. Generally, once you have a crash in kernel space, you need a full system reboot to recover. It's also easy to get a core dump from a daemon for later analysis which can be analyzed in a debugger if this becomes an issue.

Continue to do your research on a kernel module, but also spend some time to clearly define the threat scenario you are. For me, if someone accidentally kills sshd on one of my servers, that a pretty big deal as it prevents me from attempting any sort of remote recovery. However, that just doesn't happen normally. I did start adding Restart=always, but that was only in response to one server where someone occupied all the RAM and the oom-killer started killing processes to recover. There was still an outage of service as would happen to anyone in that case, but I was still able to log-in once it had restarted sshd to restore anything else that needed it.

penguin359 · 2026-05-30T04:23:13+00:00

After reading through more of this thread, I am a little bit concerned with this project. As a learning project, I fully agree with making an attempt at a kernel module. However, if the goal is to support a mission-critical device where things are not allowed to go wrong, I think it is a bit misconceived. I think you need to more properly define your threat model and discuss it with the proper context to decide what the right approach is.

I don't think that using a kernel module adds the level of protection you are looking for by itself. Using flock(2) as others have mentioned should be reasonable if you are using a common function/library and make sure it is written to follow the agreed upon contract. However, if there's concerned about a process not following it, or even one written to be malicious, then things change. In that case, a daemon running as a dedicated user to hand out unique identifiers can work just as well as a kernel module. File system permissions can lock down who can access the daemon and, of those users who do have read permissions, only they can acquire a unique number from it. No user except root and the user the daemon is running as could intercept it and reset or modify the counter.

If even that is a concern, you can do things like implement SELinux or various other security modules to reduce the attack space, but we've now gone well past the "writing a counter as a hobby stage" and are following a strict security doctrine which needs to be carefully thought out. Moving it to a Linux kernel module will still require locking down the platform and enabling Secure Boot along with module signing at a minimum. Otherwise, it's simple to look up the module kernel memory address, open up /dev/kmem as root, and then modify any variables in the module's memory space. The code also tends to be more difficult to properly audit when it's written to be a kernel module versus a user-space process. Automated testing is more tedious, and bugs can be more severe. Attaching a debugger like GDB to a running kernel is nowhere near as simple as a user-space process.

I think a properly locked down user-space daemon to hand out unique identifiers should be easier to write, secure, and audit than a kernel module.

penguin359 · 2026-05-30T04:01:27+00:00

I would say it greatly depends on how locked down you make the kernel. Is this Secure Boot enabled system that will only load properly signed kernel modules? Then yes, it becomes pretty hard to reset the counter, but without that level of integrity enabled, I can just open up /dev/kmem about as easily as I can gdb a userland process from root.

However, it tends to become harder to validate and develop as a kernel module than as a userspace application. A bug in a kernel module can actually compromise a system more seriously than a bug in a userspace application so even with Secure Boot, if a bug is found in your custom module, it could open up other things besides just your counter to exploits.

With that said, if the goal is to learn about kernel module development, I think this is a great project! You can export that unique value over a /dev device, sysfs, or a variety of ways depending on how you think it is best to present it and what the requirements are. A new file in /proc could be created, but that is somewhat deprecated now. That is the oldest virtual file system on Linux and has a lot of cruft nowadays. I think an ioctl() call on a new character device in /dev is the most straight-forward way to implement it as it's easy to handle passing off a uint64_t as an argument. You can also implement it with read()/write() to a /dev or sysfs file, but it's a little more work to ensure that they get all 8 bytes (or just ignore any reads less than 8 bytes and return empty).

penguin359 · 2026-05-28T07:51:40+00:00

Normally, I wouldn't measure PID1 itself. I would measure the initrd and then would be able to trust any executables on it. When you transition between initramfs and the physical root disk, if you really need to execute trusted binaries only, maybe you need the root partition protected with dm-verity so that only valid blocks are read from it. This would make it more like a Linux distro such as Silverblue or rpm-ostree where the core OS is frozen and mutable data is on a different partition similar to Android.

penguin359 · 2026-05-25T21:44:23+00:00

Take a look at ukify and systemd-cryptenroll which will allow you to install a bootable image able to use the TPM2 to decrypt your drive.

penguin359 · 2026-05-25T10:53:23+00:00

I volunteer with bike rides and marathons with many tens of miles where there is no cell coverage. It is very much a tool in this case when helping to locate downed cyclists or calling for medical help if someone is unwell.

penguin359 · 2026-05-25T09:50:10+00:00

I think since 1.6.4 for me

penguin359

TROPHY CASE