The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

i vomit kittens: Apr 25, 2019

This is an issue I'm experiencing with my Raspberry Pi but I believe it's more of a Linux problem, someone correct me if I'm wrong:

I recently installed Ubuntu 19.10 onto my Pi 4 as it's the only "official" 64 bit operating system currently available for it. Since doing so, I've been having an issue with not being able to SSH into and being unable to access the database/local network service running from it. About once a day, always around 7 PM, when I try to SSH in using myname@ubuntu I get an error that the Pi's ECDSA key has changed and because I have strict checking enabled will not be able to connect. Removing the Pi from my known_hosts file stops this error, but then I begin getting a Permission Denied (publickey) error. If I instead try to use myname@the.pi's.ip.address I get an error that the resource is temporarily unavailable. Hard rebooting the Pi fixes this (I have not tried plugging it in to a monitor in this state to see whether it is actually on before I switch the power off and back on).

I don't believe the power is flickering and causing it to shut down, as all the digital clocks in my apartment would also be reset. Can anyone think of an explanation for this other than the Pi powering off?

# ¿ Jan 8, 2020 03:59

Adbot: ADBOT LOVES YOU

# ¿ Apr 25, 2024 11:48

i vomit kittens: Apr 25, 2019

Methanar posted:

code:
uptime 
Does uptime say that it's been online as long as you think?

That does, but I did notice something odd when looking at the shutdown log in order to see when exactly I hard reset it to compare the uptime. The shutdown/reboot is recorded as:

code:

runlevel (to lvl 5)   5.3.0-1014-raspi Wed Jan  8 00:18   still running

However, my SSH session that I started just a few minutes later shows like it was until a few hours after:

code:

ubuntu   pts/0        192.168.86.237   Wed Jan  8 02:54   still logged in

Uptime says it's been up for about half an hour, which is consistent when I flipped the power.

i vomit kittens fucked around with this message at 04:42 on Jan 8, 2020

# ¿ Jan 8, 2020 04:18

i vomit kittens: Apr 25, 2019

xtal posted:

Also take a look at the actual private keys which I think are in /etc/sshd. Those keys should be completely static and there's no reason they should change even if you have an unexpected reboot. I think there's more to the picture here and that some software is loving with you. The observation that it happens at a certain time is useful. Do you see anything in dmesg during that time?

You mean the private keys on the computer I'm using to remote into the Pi? Those work fine after I reset the Pi so I know it's not those changing.

I looked through the kernel logs but don't see anything timestamped outside of when it was booting up, and that's checking every day since I installed Ubuntu and this started happening.

# ¿ Jan 8, 2020 04:38

i vomit kittens: Apr 25, 2019

xtal posted:

I mean the private keys on the Pi. If you're getting errors about an unknown key, then the key must have changed, which wouldn't happen in ordinary circumstances. You can look at the mtime or checksum of the keys in /etc/sshd/ to confirm if they actually are changing. If they were last modified around the time you installed Ubuntu, then the key isn't changing, and it's more likely the IP is, like other people suggest.

I think that all SSH connections are going to show up in dmesg, so you can also use that to confirm which host you're connecting to. The fact that it happens in the evening is still a correlation I'd like to explore. But it's hard to say if there's some scheduled task that takes place at that time, or if that just coincides with how long a memory leak takes to OOM-kill sshd. I highly doubt that, though, because it would be obvious to you if you were running Crysis.service or something.

Ah, I see. Is dmesg supposed to show me logs beyond the last shutdown, or how can I set that up for next time it happens? The earliest message I can see in it is from right when I last booted.

The conflicting IP thing was what I saw on Stack Overflow. This never happened when I was on Raspbian so I'm not sure if that would be the problem but I went ahead and set the Pi's IP to be reserved for it just in case. I'm in class right now so I'll find out when I get home if it's better today.

# ¿ Jan 8, 2020 15:33

i vomit kittens: Apr 25, 2019

Well it's about that time of day and my server hasn't gone down yet. I'll continue to keep an eye on it until I go to sleep but hopefully this means it was just an IP address issue.

# ¿ Jan 9, 2020 02:25

i vomit kittens: Apr 25, 2019

I spoke too soon. The server stopped responding at around 11:30 again last night. I was too tired and pissed to check the logs so I'll see what's there when I get home. I'm probably just going to end up switching back to Raspbian though as the problem started the day I switched to Ubuntu 19.10

# ¿ Jan 9, 2020 15:49

i vomit kittens: Apr 25, 2019

I don't know if you have experience with it or whether it's unnecessarily overcomplicating what you're trying to do but the only way I can think of doing it is using Docker.

# ¿ Feb 2, 2020 16:47

i vomit kittens: Apr 25, 2019

Is there anything special I need to be doing to free up memory after a process is killed?

I have a $5 DigitalOcean droplet hosting a small web app. When I kill the app and rebuild it, the npm process runs out of memory and it fails. However, if I stop the app's startup service, reboot the droplet, and then build it everything works fine. While it's not a ton of extra work to do that, I'd like to be able to do it without restarting everything if possible.

# ¿ Feb 2, 2020 19:27

i vomit kittens: Apr 25, 2019

SoftNum posted:

Are you saying that if you reboot your droplet with the app startup enabled it doesn't work? If so you must be pretty tight under the memory limit anyway. If you're using a database backend I would start there, as far as memory hog suspects.

It seems to also work if I kill the app immediately after rebooting, and usually sits around 30-40% of RAM usage out of 1 GB while the app is running (I haven't checked to see what the usage is immediately after I kill the app and before I try building). It's made using React/Spring and pulls data from a Postgres instance. I did move the Postgres DB over to the Droplet from a Raspberry Pi that I have at home today, however I was also running into the problem before doing that and the impact on memory since doing so has been pretty small.

# ¿ Feb 3, 2020 00:37

i vomit kittens: Apr 25, 2019

So I'm trying to install Debian onto a spare hard drive as my first attempt at using Linux outside of Raspberry Pis/remote servers. When I'm going through the install process I get a notice that I'm missing some non-free firmware, and there's a list of 5 files that look to all be related to my Atheros wireless (they all start with ath10k). I've tried two solutions to this but neither of them worked.

1) I found this Atheros firmware package and copied it into the USB installer I made. This managed to get rid of 3 out of the 5 files on the list, however there are still two that remain. They are ath10k/pre-cal-pci-0000:03:00.0.bin and ath10k/cal-pci-0000:03:00.0.bin

2) I downloaded an unofficial ISO image that claimed to include all of the non-free firmware that Debian lacks by default. This actually changed nothing and I still got the full list of 5 missing items.

In searching for a solution to this, everything I've found suggests to do one of the above. Since neither of them have fixed anything, though, I'm having a hard time figuring out what I should try next. The wireless adapter is a Qualcomm Atheros QCA61x4A.

# ¿ Feb 17, 2020 04:35

i vomit kittens: Apr 25, 2019

Antigravitas posted:

First off, ew.

Second, does the card work? The firmware prober sometimes complains about hardware that works fine without.

Third, the package is firmware-linux, which pulls in all the garbage blobs from the linux kernel tree. Install via ethernet, pull in the package later. You'll probably have to enable the non-free repo for it, Debian doesn't ship garbage by default.

It's the card that's built in to my motherboard

I haven't actually checked to see if the card works; I'm using the NetInstall ISO image so when I would get to that point in the installation I would assume it wouldn't actually be able to finish and abort it. I'll try just clicking through it when I get a chance.

# ¿ Feb 19, 2020 14:58

i vomit kittens: Apr 25, 2019

I guess this might be more of a question about disk management in general, but I have two spare 256 GB SSDs and I'm looking to install Fedora on them. I know in Windows I can make a "striped" volume that will make one logical drive out of both SSDs, so I'm assuming I can do the same in Fedora. What if I wanted to install Fedora on a striped volume, though? Would I need to boot from the live USB, create the volume, and then install Fedora afterwards? The install options also seem to only list actual hard drives and not the volumes, so I'm not sure if the striped partition would show up there once I do figure out how to create it.

# ¿ Oct 25, 2020 23:53

i vomit kittens: Apr 25, 2019

It was actually a lot easier than I thought because it turns out if you just select both hard drives in the Fedora installer it will automatically use LVM to stripe them.

# ¿ Oct 26, 2020 01:43

i vomit kittens: Apr 25, 2019

Not sure whether this belongs here or the Windows thread, but I'm trying to create a custom WSL distro using RHEL 8 and running into a problem that I'm not experienced enough to know how to solve. The instructions I'm following are here: https://wsl.dev/mobyrhel8/

Everything works fine up until the point where I create a launch script at /etc/profile.d/00-wsl2-systemd.sh and edit the sudoers file to use it.

The script:

code:

if [ "$(ps -c -p 1 -o command=)" != "systemd" ]; then
        if [ -z "$SUDO_USER" ]; then
                export > "$HOME/.profile-systemd"
        fi

        if [ "$USER" != "root" ]; then
                exec sudo /bin/sh "/etc/profile.d/00-wsl2-systemd.sh"
        fi

        if ! grep -q WSL_INTEROP /etc/environment; then
                echo "WSL_INTEROP='/run/WSL/$(ls -r /run/WSL | head -n1)'" >> /etc/environment
        fi

        if ! grep -q DISPLAY /etc/environment; then
                echo "DISPLAY='$(awk '/nameserver/ { print $2":0" }' /etc/resolv.conf)'" >> /etc/environment
        fi

        exec /usr/bin/nsenter --mount --pid --target "$(ps -C systemd -o pid= | head -n1)" -- su - "$SUDO_USER"
fi

if [ -f "$HOME/.profile-systemd" ]; then
        source "$HOME/.profile-systemd"
fi

if [ -d "$HOME/.wslprofile.d" ]; then
        for script in "$HOME/.wslprofile.d/"*; do
                source "$script"
        done
        unset script
fi

What I'm adding to the sudoers file:

code:

Defaults env_keep += "WSL_INTEROP"
%wheel ALL=(root) NOPASSWD: /bin/sh /etc/profile.d/00-wsl2-systemd.sh

When I restart the distro after this, it fails to start and just gives me the error " nsenter: failed to parse pid: '' ". The only thing I can think of is that it might be an issue with the line in the script below, but like I said I'm not experienced enough with Linux to be 100% certain of that or know how to fix it.

code:

exec /usr/bin/nsenter --mount --pid --target "$(ps -C systemd -o pid= | head -n1)" -- su - "$SUDO_USER"

# ¿ May 18, 2021 18:13

i vomit kittens: Apr 25, 2019

RFC2324 posted:

What do you get if you run just the ps snippet?

ps -C systemd -o pid=

This command doesn't return anything, trying 'ps -ef' gives:

code:

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 13:36 ?        00:00:00 /init
root        11     1  0 13:36 ?        00:00:00 /init
root        12    11  0 13:36 ?        00:00:00 /init
danie       13    12  0 13:36 pts/0    00:00:00 ps -ef

# ¿ May 18, 2021 18:41

i vomit kittens: Apr 25, 2019

hifi posted:

'ps -C systemd' is selecting processes named 'systemd', of which you have none. nsenter is reporting you gave it nothing for a pid.

figure out why you have 'init' instead of 'systemd'

searching your link for 'init' it looks like you aren't doing this part: https://wsl.dev/mobyrhel8/#a-distro-needs-a-manager

Are you referring to the 'scripted way to launch SystemD' that he links there? The way it's worded there put me under the impression that the addition the /etc/wsl.conf below that was a replacement for it but after actually clicking that link it seems I'm probably wrong. Lemme restart the process again and give that a shot.

# ¿ May 18, 2021 18:52

Adbot: ADBOT LOVES YOU

# ¿ Apr 25, 2024 11:48

i vomit kittens: Apr 25, 2019

hifi posted:

I mean adding the call to systemd in wsl.conf. init is the default which you have.

I do have that [boot] and command line in my wsl.conf.

I did notice this time around that the script, wsl.conf changes, and sudoer modifications in the git repo are a bit different from what's presented in the instructions. I tried copying those for that part instead and now something else is happening. Trying to start the distro doesn't give an error message, but it just hangs for a second and then does nothing at all, leaving me in the PowerShell terminal. Running ps -ef now shows that systemd is running but it doesn't have a PID of 1.

# ¿ May 18, 2021 19:18

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible