Search results

Inspired by this I've created a VM with 14.0 FreeBSD, default install (by hand in shell, not by bsdinstall): [15:35:17] fbsdforums(/usr)# zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT rpool 16.0T 1.07T 14.9T - - 0% 6%...

I was in the impression that loader.efi is calling ExitBootServices() and hence it's on its own. I agree that with BIOS libsa still relies on BIOS services to get the ball rolling.

The script that comes with it is a shell script /also/ doing this: ## Syslogk LKM rootkit if [ "${QUIET}" != "t" ]; then printn "Searching for Syslogk LKM rootkit... "; fi (${echo} 1> "${ROOTDIR}proc/syslogk") >/dev/null 2>&1 if ${ls} "${ROOTDIR}proc/syslogk" > /dev/null...

Please share your rc.conf and/or any other non-standard configuration you're using so we can replicate that. Also test this on proper GENERIC kernel. if_gre.ko, if_wg.ko and pf.ko can be loaded (/boot/loader.conf), you don't need to recompile kernel for that. yes, altq/libalias won't be in...

Error you see is from FreeBSD zfs loader itself. This means you're beyond the FW (bios or uefi). The loader is using libsa to find and load the kernel. That's where the issue occurs. Quick search doesn't show the limits anywhere; source code doesn't mention this either.

I was able to minimize this to a simple test case: #include <stdio.h> void __attribute__((constructor)) myinit() { printf("%s: hello\n", __func__); } int main() { return 42; } FreeBSD's dtrace probe is not matching this function even though it's listing it. I've opened 278489 for it.

gpart picture confirms you are using legacy boot on GPT disk. (that's ok). You were already in boot prompt, you were passed the "cannot boot from BIOS" stage. From the bootloader prompt try to locate kernel, either current (/boot/kernel/kernel) or an old one ( /boot/kernel.old/kernel). OK...

I'd probably opt for gdb then but I'm not sure what specifically are you trying to achieve/profile/debug. I tried the same program under Solaris and there it works as expected: # dtrace -s ./trace -c ./test dtrace: script './trace' matched 3 probes *** mysetup exec hello: my hello program...

Interesting problem, I was not able to find a solution for it. I'm assuming it's possible as it's possible to do this (debug constructors in libs loaded in future) with gdb. I attempted to use dtrace -x evaltime=preinit -s trace -c ./test but it didn't match any probes this way (opposed to not...

When somebody asks you if you're running GENERIC they are asking if you're using kernel (and/or modules) that are shipped with the given release. Even if you take GENERIC kernel config and recompile it you're using custom kernel. First you should test your config running on GENERIC. If you...

Not that long ago I did debug similar issue (segfault in the rawtherapee program) here in this post. You should check both PR and github conversation there. It was a "locale thing".

To get familiar with the layout of the filesystem have a look at hier.

Similarly in a joking fashion: but who's auditing the auditors! :)

One thing that cloud (or whatever remote hosting) has to offer is (D)DOS attack protections. One can expect less fuzz on those services as you mentioned it's for your own use. But still some script kiddies may catch it and play around. Most likely your ISP doesn't provide such services and you...

I meant dump from userspace. Perhaps I should have included this in your quote: On x86 user that can execute binary can dump it and read it. At least by default. You could make it harder ( security.bsd.unprivileged_proc_debug) but with dynamic ELF you could still inject with LD_PRELOAD. Static...

At least on x86 architecture execute implies read. You can always dump pages marked as executable only and hence read them.

While it may not qualify as an absolute scientific accomplishment JWST is definitely shaking up theories about cosmos. I do think it does matter enough to consider it as huge accomplishment. If only all the money spent on useless wars went to such experiments.

Well this is before system boots. It was classic 'grub related' issue. scottro yeah, it was done in that exact spirit. It shouldn't be possible to step outside of the LAB network at all; I had my little fun. ;)

It supposed to be an isolated env so you don't have access to anything outside of lab. Official fix was to fix it so it boots back to rhel (broken setup). But I improved it ;) This is truly just a trolling though (while still an interesting approach to deploy) it's a bug in a LAB (I reported...

Not sure if you're familiar with the RedHat trainings. Actually, they are not that bad. I do like the fact exams are not some stupid MCMA or MCSA questions without having access to terminal but rather you need to actually deploy something. And on higher level exams it can get interesting. This...