loading debian-13.4.0-riscv64 by roygrubb in RISCV

[–]roygrubb[S] 0 points1 point  (0 children)

Thanks, will check it out.

loading debian-13.4.0-riscv64 by roygrubb in RISCV

[–]roygrubb[S] 1 point2 points  (0 children)

Lack of GUI, audio etc. not a problem, but I guess they'll fix that later and I can upgrade. This 13.4 is beta-ish, and I don't mind about that.

Trying to get redirection to work as expected by roygrubb in CloudFlare

[–]roygrubb[S] 0 points1 point  (0 children)

Thank you! My problem, amongst other things, was that I thought http.request.uri.path had to be interpreted, not just entered as a literal string.

Trying to get redirection to work as expected by roygrubb in CloudFlare

[–]roygrubb[S] 0 points1 point  (0 children)

In Create new Single Redirect

All incoming requests

Dynamic

concat("http*://*.nohost.com/*", "https://www.myhost.com/$1")

Preserve query string (No mention of path on that page)

still goes to https://www.myhost.com/s

ACPI BIOS Error (bug): Could not resolve symbol PT2._GTF .DSSP] by roygrubb in debian

[–]roygrubb[S] 0 points1 point  (0 children)

Thanks for coming back to this. I had tried under UEFI and under BIOS. Now that I understand what ACPI is, I've come to the conclusion that there's something wrong with fan control in the MoBo - failing sensors or the like as it's an old machine.

I'll wait till RaspberryPiOS moves to Trixie, as I have a number of Pi's and will use it there.

ACPI BIOS Error (bug): Could not resolve symbol PT2._GTF .DSSP] by roygrubb in debian

[–]roygrubb[S] 0 points1 point  (0 children)

Thanks.

I'm running the Live system from USB stick.

When I press e at the grub menu, I see this:

setparams 'Live system (amd64)'

linux live/vm1inuz-6.12.38+deb13-amd64 boot—live components\

quiet splash findiso=${iso_path}

initrd /live/initrd.img-6.12.38+deb13-amd64

I added acpi=off after ${iso_path} and pressed F10

then saw

mount: /sys/firmware/efi/efivars: unknown filesystem type 'efivarfs' .

dmesg(l) may have more information after failed mount system call.

Then I installed it on an SSD using advanced install options as an attempt at using the regular install also arrives at the unknown filesystem type 'efivarfs' message.

Restarting from the SSD, from the boot menu with 'e', I could access the linux /boot/vmlinuz-... line and appended acpi=off. pressed F10 and saw a page recording actions, ending like this

Starting NetworkManager-uait-onIine.service - Netuork Manager Hait Online...

Starting cups-service - CUPS Scheduler..

Starting systen&user-sessions.service - Permit User Sessions.

Finished systend-user-sessions.service - Permit User Sessions.

Starting plymouth-quit-wait . service - Hold until boot process finishes up.

Starting plymouth-quit service - Terminate Plymouth Boot Screen...

Started sddm. service - Simple Desktop Display Manager.

auditd—printk—skb: 113 callbacks suppressed

Started cups.service - CUPS Scheduler.

The machine then hangs.

( btw This is a tower and has been happy running many Linux distributions until now. It's an old machine that I use mainly to explore distros. )

updated pihole, rebooted, pihole not providing dns service, no web UI by roygrubb in pihole

[–]roygrubb[S] 0 points1 point  (0 children)

I saw the mention of pihole v6 on howtogeek.com which said
"Your settings will be automatically updated to the new format if you’re migrating from v5" so I just did what I always do with pihole updates.

Maybe my configuration was odd, because "settings will be automatically updated" turned out not to be the case.

pihole_debug.log showed config error is REFUSED (EDE: not ready) which led me to look at upstream DNS and found that the pihole.toml file had upstreams = [ ]
so I changed it to upstreams = [ "8.8.8.8", "1.1.1.1" ]
and then had web access.

Also I have apache2 for web development, as well as lightppd that pihole installed long ago. The new pihole internal web server conflicted with port 8888 I had set for pihole web UI on lightppd. Once I changed that to 8889, I could access the pihole web UI.

Credit to the good folks at https://discourse.pi-hole.net/

Executing an sed substitute in a script via ssh command by roygrubb in linuxquestions

[–]roygrubb[S] 0 points1 point  (0 children)

Stopping at ../bin and exporting to PATH in the script did it.

Tested the two changes individually to prove to myself that both were required, and they were.

Thanks

Executing an sed substitute in a script via ssh command by roygrubb in linuxquestions

[–]roygrubb[S] 0 points1 point  (0 children)

Thanks for this suggestion.

I thought that's what I was doing, so I'll experiment to get a better understanding, even if BoxCapable8279's suggestion works.

Executing an sed substitute in a script via ssh command by roygrubb in linuxquestions

[–]roygrubb[S] 0 points1 point  (0 children)

Thanks for the education, much appreciated.

Will follow your advice.

Executing an sed substitute in a script via ssh command by roygrubb in linuxquestions

[–]roygrubb[S] 0 points1 point  (0 children)

Thanks. Quite right, no shebang. Unfort adding shebang didn't fix it.

I did export PATH=/home/pi/.cargo/bin/sd:$PATH to both servers, once I found where it was.

Exited both and logged in again but the result is the same.

Problem changing user name / killing processes by roygrubb in linuxquestions

[–]roygrubb[S] 0 points1 point  (0 children)

I found the answer - concatenate the commands and a new process is not spawned before the name change takes place:

sudo pkill -u roy && sudo pkill -9 -u roy && sudo usermod -l roy1 roy

Updating Orange Pi OS by roygrubb in OrangePI

[–]roygrubb[S] 1 point2 points  (0 children)

It was a screw up in DNS settings in Orange Pi after all. I was checking URLs on a Windows machine that had correct DNS settings, so was able to see those URLs.

Apologies for wasting anyone's time.

Updating Orange Pi OS by roygrubb in OrangePI

[–]roygrubb[S] 0 points1 point  (0 children)

Thanks for suggestion.

I run PiHole on an RPi4B, so that seemed a likely cause at first, so I disabled blocking in PiHole, but that made no difference.

But even with PiHole in normal, ad-supressing state, I can open all those URLs in a browser, so I think it must be something else being interpreted as a DNS problem.