The output of the /var/Xorg.log is:
xf86EnableIO: failed to open /dev/io for Extended I/O
And then
Falling 🍁 back to old probe for modesetting.
Results in:
No devices to configureNo screens to configure
System repaired in zfs from rescue CD.
Another one?
__
Mr. Clay, Daniels, Jr.,!
Sorry for the typo in the mail. Arch linux is a wonderful System as a long as
you KISS, therefore an unreachable target and wait for April, 1st, Judd's
making a joke 😜 then, where it is likely to be known what to do the upcoming
year.
My Cheetah correction syst
I noticed a new : drm-current-kmod
Version: 4.16.g20190918
Worked fine with my AMD R7 and "amdgpu"
I needed the line in /boot/loader.conf
hw.syscons.disable=1
Note: I tried first without adding the loader.conf line.
Same story, cannot boot in framebuffer mode, but now I know the trick I
d
I have written a short test program that runs unlinkat(2) in
capability mode and fails due to not having the write capabilities:
https://people.freebsd.org/~rstone/src/unlink.c
If I run the binary under ktrace and look at the kdump output, it
gives the following incorrect output:
43775 unlink
On 2019-09-18 16:29, Yuri Pankov wrote:
> Yes, exactly, sorry for not mentioning it.
>
> ESXi version: 6.7.0
> ESXi build number: 13006603
Sorry, I've realized it's _not_ crashing when we call ExitBootServices
after all: it's just that we can't call printf after that point. I've
found it gets to
Apply the patch and playing with increasing the value does allow
direct exec of ld via rtld to work. so thank you. The patch probably
shouldn't be applied as-is, though, as executables will just segfault
right away if the sysctl is tuned to a non-page aligned value.
___
- Forwarded message - From: "mms.vanbreukelin...@gmail.com"
To: "freebsd-curr...@gmail.com"
Cc: Sent: Sat, 21 Sep 2019 at 15:18 Subject: The
X11 error correction went to a non-booting kernel @daniel-clay: None of the
three kerns. Boot anymore. Gotta install zfs-utils and zfs
On Sat, Sep 21, 2019 at 12:19:19PM -0400, Ryan Stone wrote:
> If I try direct exec ld via rtld, I get the following failure:
>
> # /libexec/ld-elf.so.1 /usr/bin/ld
> ld-elf.so.1: /usr/bin/ld: mmap of entire address space failed: Cannot
> allocate memory
>
> Is there some sysctl limit I need to bu
If I try direct exec ld via rtld, I get the following failure:
# /libexec/ld-elf.so.1 /usr/bin/ld
ld-elf.so.1: /usr/bin/ld: mmap of entire address space failed: Cannot
allocate memory
Is there some sysctl limit I need to bump up to get around this? I
presume that the binary is just too large giv
