Trying to install FreeBSD. Both 15.0-amd64-current-bootonly and 14.1-stable-amd64-bootonly panic in ioapic_create() at boot. Disabling ACPI doesn't help. Should I try older ISOs?

HER, Is this a VNET jail? Or a non-VNET jail? I think it must be a non-VNET jail. In which case the jail guest shares the network stack with the host. In which case whatever happens to the network stack anywhere happens everywhere. (Pretty sure, I think, not absolutely positive.)

ukky, If it were me I would try older images but I would also be checking the system. I would boot a live boot image. I would run memtest. The panic may indicate a hardware problem.

rwp: thanks, will try live ISO.

i updated from 13.2 to 14.1. it seems to have gone well, but i have a couple of applications running remotely that are no longer able to ssh to the server. I can still ssh manually using their keyfile / user & passsphrase. what do I look for?

jnewt, You got past the out of disk space problem? Excellent! :-)

rwp: right, not vnet

rwp: finally. what a mess that was

rwp: i'm going to upgrade those root disks from 120 to 256 in the future

jnewt, Is this for root? In sshd_config look at the setting of PermitRootLogin which might be no or might be prohibit-password or even something different.

rwp: yes.. i am using more jails now .. and learning my way... i had a vision jails were 100% secure.. but maybe not for 'non vnet jail' .. i mean.. if the guest is able to disable the host firewall...

rwp: no, i have a specific & restricted user login for this remote application.

I don't want to have to merge those sshd_config files. In the upstream they configure with "Include /etc/ssh/sshd_config.d/*.conf" but that's not in FreeBSD 14.

What I do is I configure sshd_flags="-f /usr/local/etc/ssh/sshd_config" in /etc/rc.conf and then my /usr/local/etc/ssh/sshd_config contains exactly two lines. Include /usr/local/etc/ssh/sshd_config.d/*.conf and Include /etc/ssh/sshd_config and then I do all of my local configuration changes in /usr/local/etc/ssh/sshd_config.d/sshd_local.conf

jnewt, So it was using ssh keys but now the ssh keys are not working? I would check /var/log/auth.log and see if it logs any error messages for these login attempts. Should be a clue there. I suspect then that the clients are using obsoleted ciphers/algorithms which have been disabled. Maybe.

HER, Jails are not a complete VM system. I am not even sure that is what is happening. I will have to try a test and deduce it. But it seemed reasonable.

rwp: the message I'm getting on the client side is: "ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain"

I mostly use VNET jails these days. But also remember that a process would need to be root in the jail in order to take that action.

but then i can open a terminal on the client and run ssh -i keyfile user@server:port and it uses the keyfile, i put in the passphrase and it connects

No supported methods remain. That's the clue. Between the client and the server they don't have a compatible method. Probably the client is old and /should/ be updated.

so to me, it presents as a client issue, but I know the only thing that changed was the server updated. so I'm digging around

You will need to figure out what method is obsolete and either upgrade the client or enable it on the server.

rwp: oh ffs, if i have to upgrade another server my head is gonna light on fire

It's a never ending conveyer belt forward.

But before you get to that point try this on the server side: /usr/sbin/sshd -d -p 2222

Then on the client attempt the login to the port 2222

On the server side that sets up a one-shot server in the foreground with all of the debug messages going to the terminal. It has useful information about which algorithms and ciphers each end is using.

Perhaps on the client side it will be enough to dump more verbosity with ssh -vv too.

When OpenSSH 8.8 released it was a breaking release for many old clients. openssh.com/txt/release-8.8

aand there it is: "userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]"

Read those release notes looking at the ssh-rsa workarounds listed.

And then let me STRONGLY SUGGEST changing the client from ssh-rsa to ed25519 keys. That's the best workaround. "ssh-keygen -t ed25519"

Using ED25519 keys has the side effect of avoiding the SHA-1 problem because ED25519 keys were newer and never used SHA-1 anywhere and it also pushes the client to use that for the host key too.

Which turns it into a win-win situation really. You shouldn't have to upgrade your clients OS, just their access ssh key. Stronger keys, more efficient, faster, avoids SHA-1.

Since ED25519 keys were introduced in OpenSSH 6.5 as long as the client is newer than that then it is supported on older clients.

HER, I have this vague memory that there is a sysctl security level available to prevent jails from having that level of access to the network stack. I don't remember more off the top of my head. But perhaps searching around in that area or asking others if they know might turn up something?

rwp: why does it allow me to use the key from the terminal, but the client application can't? shouldn't an outdated ssh version without the allowance on the server side stop both?

rwp: right, i will search that too, thanks

jnewt, I don't understand which part is which part. You try from the client command line and it is working but some client side application program (what?) is not working?

Sounds like the client side application program is not the same as the command line ssh?

correct. so it sounds like maybe the application itself needs upgraded...which I am very unqualified to do

(not that I'm qualified to do what I do here anyway, but i digress)

it's almost like it's not using the system level ssh installation, otherwise there would be no discrepancy

jnewt, It's an endless conveyer belt. Upgrade one thing. Something else needs to be upgraded. Abandon all hope!

On the other side of things, if your desktop system is upgraded and then the client is too new, it is possible to create an older jail and then jexec into the jail and use the older system to client ssh out to a remote older system. That works pretty straight forward. Just mentioning that in passing.

i think the best course of action is to just never upgrade. isn't the space station running on like windows 95 or something? we'll probably be fine

The opposite direction though I have the same problem. A co-worker and I have this almost but not quite dead contract git. My co-worker friend is using an ancient Windows box to access the subversion based version control. Can't contact the server anymore. But has no real reason to do so either since the project is virtually moribund anyway.

I figure we will work something out if we really need him to be able to ssh connect to the svn server. I will probably set up a vnet jail running an older ssh and lock it down to just him or something.

As far as the ISS still running old systems that is true. And the Mars rover is running a system with a known remote code vulnerability. But you have to be able to poke packets at those systems too and they are rather space-gapped systems. :-)

I was just listening to 2.5 admins and them talking about how rsa-512 was finally deprecated in openssh (or something like that)

perhaps the keys are ancient, and rsa is actually supported, but keys that ancient (insecure) are not unless you specifically allow them

My new email server powered by freebsd + openstmpd + dovecot

:)

Greetings

poudriere users, did you notice this problem : at the end of a bulk poudriere generates a pkg.pkg (new format name iirc) , while pkg bootstrap -f expect the old name pkg.txz ?

rwp: 9.3-release-amd64-memstick boots fine.

ukky, Interesting. I have no idea! I don't use the memstick versions but have only ever used the disc1 iso images.

rwp: bisecting, latest working image is 14.0 on that system. Both 14.1 and 15.0 trigger panic at boot. I don't think memstick vs disc1 matters.

We have devel/py-graphql-core, devel/py-graphene, .. maybe a couple others from github.com/graphql-python but no gql? Any chance it's there by a different name?

gql is graphql python client from the same project.

There isn't a simple way to inspect python ports for something that looks like a plist? maybe freshports?

I'm pretty sure ports doesn't have gql though.

Nothing listed in FreshPorts contains gql in the pkg-plist

But does freshports track auto plist ports?

Most py- don't have a plist file.

Only what it can extract from pkg-plist or from ...

skered: But yeah, py- ports are hard to get pkg-plist infor from, example: freshports.org/databases/py-carbon

ukky, Given what you have found so far I am sure you have found a kernel bug! One that would be good to root cause and get fixed. Good hunting!

hello is this the channel for GNU/FreeBSD

lw: Yes, but only the flavor that runs off of LILO

vkarlsen: oh good, i just installed LILO on my 386, i really hope GNU/FreeBSD didn't recently announce any plans to drop 32-bit x86 support!!

fortunately the Linux Public License makes it illegal for them to do that

lw: isn't that project dead?

Oh, I was thinking of GNU/kFreeBSD, which yes is dead.

Not entirely dead. People work on it still.

Even after the termination of the project by Debian?

debdrup: Yes.

Yeah, there does seem to be a tiny bit of activity on the mailing list even in 2024, more than a half year after.

And there's an IRC channel on OFTC - #debian-kbsd.

Some folks *want* it to be dead, but it is not so.

Seems pretty rude.

Eh, everyone can have opinions.

True.

opinions on a SSD for a SLOG/ZIL for a zfs raidz storage device? seems to be mixed opinions online. my use case is just a home nas, but you know, gotta optimize :)

main question is do you even need one

if you do, do you have any spare pcie lanes?>

because if you do just shove a pcie->nvme conversion card in

and wallah

i have a few extra SATA SSDs and plenty of room on my backplane, so was thinking to mirror them and try it out

Sounds a plan

buy some smaller dram backed SATA SSD's and shove them in mirrow or raidz

an entry in the separate intent log takes up ~80 bytes and you'll need one for each record - so figure out the maximum number of records that can be on your raidz and you'll have the size it needs to be

more importantly, do you understand that the separate intent log is _only_ for synchronous writes?

it won't speed up any asynchronous writes at all, and those are the majority of what you're likely seeing, unless you're working with databases, nfs, or another sync-heavy write load

something that will speed up any zpool is a special vdev used for metadata and allocation classes - but those also need to be sized appropriately, and you also need them in an n-way mirror

debdrup: yeah, i have my doubts if it'll yield any real benefits. i'm mostly just experimenting. i'll read up on the special vdev you mentioned. hadn't heard of that.

it's somewhat new

with zfs and enough non-volatile flash devices to throw at a zpool (for cache, log, and special vdev, and eventually maybe even a dedup device), spinning rust can be made to feel a lot like flash storage, despite having much higher density

Cache and power failures interact badly. High performance enterprise level HBA cards usually have a battery to keep their cache going long enough to write through upon sudden power failure. The ZIL should either have this. Or don't do it at all.

An HBA card without any cache is in some ways better because there is no worry about the battery having failed off with it.

If you haven't got a UPS configured with graceful shutdown then that's the place to start first.

I avoid batteries on HBA's, personally. But, there's always a UPS in it's place.

Unless, of course, the HBA's can be flashed between RAID/HBA (IT-mode most manufacturers call it?) Then I'll leave it so the card can be resold later as whatever the purchaser needs. I always disconnect the better in HBA mode, though.