Discussion:
KARL, config -e, syspatch difficulties
(too old to reply)
g***@t-t-l.co.uk
2018-04-10 12:48:24 UTC
Permalink
I have a Kettop box with J1900 cpu which is proving a bit of a pain. I
have very limited time (and knowledge) to spend on this but ...

It worked fine with 6.1 i386 (amd64 has been flaky at best with 6.1 and
6.2, I haven't tried 6.3). With 6.2 although bsd.rd was fine to do a
fresh install, booting with the installed kernel failed.

Eventually after much reading of mailing lists I realised it was the
inteldrm driver and discovered "config -ef /bsd". This fix didn't
survive a reboot though and after more time and reading, I worked out
what bsd.booted was and the effect KARL was having.

Next step was to disable KARL. This doesn't seem to weaken my security
to me as the only time the box is rebooted is after an upgrade to a new
version or with syspatch and it's easy enough to relink once and then
disable it again. Then I spotted that syspatch doesn't actually update
the installed kernel if KARL is disabled. That was easy enough to work
round with a trivial script.

Finally my question - have I understood what's going on and is this all
intended? I couldn't find anything documented (reading the source is
beyond me I'm afraid) about these interactions.

I suspect the "right" way to deal with my problem would be to compile my
own kernel but I am trying to avoid having to do this. I couldn't find
any other way to disable a driver on boot.

By the time I had enough idea what was going on to think about filing a
bug 6.3 was getting close and I had read messages (can't remember if on
misc or bugs) that said that inteldrm had been fixed. If it would help
I can open or add to a bug.

Regards,
George.

Loading...