You are not logged in.
You also have to trust the manufactures firmware to respect your setting when you turn it off.
In respect of UEFI, it is not possible to "turn it off" — all you can do is enable CSM ("Legacy" mode), which still runs the boot process through the UEFI firmware but subjects it to an extra added abstraction layer which is probably full of even more bugs.
Secure Boot should help with some of the problems introduced by UEFI so you should use that rather than CSM.
I just install a standard system, back it up then create the subvolume layout as desired and rsync the backup to the new layout.
The fstab and bootloader need correcting afterwards but it works:
empty@E485:~ $ grep '/ ' /proc/self/mounts
/dev/nvme0n1p3 / btrfs rw,relatime,ssd,space_cache,subvolid=257,subvol=/debian 0 0
empty@E485:~ $is Virtualbox not in the repo?
No, it's so shit that the Debian developers removed it from the stable release and won't be backporting it in future.
See https://bugs.debian.org/cgi-bin/bugrepo … bug=794466 for all the gory details.
I prefer qemu-kvm
+1
I think you misread that
Yes, I did. Oops. Sorry OP.
on installing I had to connect through eth0 as wlan is a broadcom card. now that wifi is working I'm not using eth0.
What setting do I need to change?
Have you installed the Broadcom drivers? I would just throw that POS away and buy an Intel card instead but you should be able to get it working, after a fashion.
I've successfully trashed my install 2 more times so far today.
Ha! Serves you right for giving money to those NVIDIA bastards.
haven't found a way to back-out of failed installs in such a way that I get a workable system.
Just FYI:
There is no .xsessionrc in my home directory, only .xsession-errors and .xsession-errors.old.
You are allowed to create new files in $HOME ![]()
Perhaps if you post the converted script here somebody will be able to debug it.
But I have zero experience with sysvinit scripts so I probably won't be much help (sorry).
when i installed openbsd iwm firmware was already in the install
No, the install process does not include the firmware, that's why fw_update(1) is run at the first boot (or after an upgrade to a fresh snapshot).
From the FAQ:
Some manufacturers refuse to allow free distribution of their firmware, so it can't be included with OpenBSD.
Write your own wrapper script for the command, perhaps?
Something like this at /usr/local/bin/systemctl:
#!/bin/sh
case "$1" in
start) service "$2" start ;;
stop) service "$2" stop ;;
esacI don't know if I installed the kernel headers, or if the module built successfully during the installation.
Doesn't look like it, the X.Org log shows that nouveau is being attempted.
And if you could edit your post containing that and enclose it in code tags (rather than the quote tags you have used) that would make this thread *much* more readable, thanks.
To install the headers and the rest of the build tools use
# apt install module-assistant
# m-a prepareThen try installing the nvidia-driver package again, you should see the custom kernel module being built afterwards.
So you are saying openbsd arbitrary downloads non-free firmware upon booting a newly installed system?
Not arbitrarily, only firmware that is required by the hardware is downloaded. The reasoning is that any hardware that doesn't load firmware blobs from the operating system has them implanted in ROM at the factory instead so the battle is already lost, so to speak.
as far as i am aware fw_update is/was a manual process?
No, it's run automatically on first boot and also after updating to a fresh snapshot in -current.
are these the only firmware files openbsd supplies?
Yes, I think so.
Did you install the kernel headers as well as the nvidia-driver package? Did the module build successfully during the installation?
Is nouveau blacklisted?
grep -R nouveau /etc/modprobe.dI think the proprietary drivers still need an X.Org configuration file for ASCII but you don't need nvidia-xconfig, the file is pretty simple:
Another alternative is to autostart this command:
xset b offAdding it to ~/.xsessionrc should do the trick (or use Cinnamon's autostart GUI).
The Debian version only supplies /lib/systemd/system/tomcat9.service, which won't work with sysvinit (obviously).
You could try the sysd2v-0.3.sh conversion script, that might work: http://www.trek.eu.org/devel/sysd2v/
EDIT: they're up to v-0.3 now.
Have you installed the non-free firmware that is required by the nouveau driver?
OpenBSD seems like a viable starting point for a new opensource OS fork. It's clean, simple, and resists binary blobs
No it doesn't, fw_update(1) is run automatically on first boot of a new system and that downloads any firmware blobs required by the hardware and loads it.
Do you find your trolling very entertaining?
Don't feed the trolls d00d. And please try to stay on topic ![]()
The group of developers has to have an idea of where things are going
I can't speak for the developers but fsmithred has just released the first beowulf beta for Refracta so the release is approaching.
there must be a good explanation of why /etc/mtab is symlinked to /proc/mounts ?
Probably so but that isn't the case for Debian buster and symlinking to another symlink just sounds wrong.
The content would be the same either way.
^ Thanks, it works in my buster GNOME desktop :-)
ls /etc/mtab -l lrwxrwxrwx 1 root root 12 Dec 29 16:58 /etc/mtab -> /proc/mounts
That's strange, the Refracta beowulf beta also does that.
From my Debian buster system:
empty@E485:~ $ ls -l /etc/mtab
lrwxrwxrwx 1 root root 19 Sep 23 17:11 /etc/mtab -> ../proc/self/mounts
empty@E485:~ $/proc/mounts is a symlink to /proc/self/mounts so for your system /etc/mtab is symlinked to a symlink, which doesn't sound right.
Does linking it correctly fix things?
cd /etc
# ln -sf ../proc/self/mounts mtabEDIT: use the force, Luke.
Works well in QEMU/KVM, great work!
How do you make the images so small? I use live-build for my images and they're twice the size, even for just an openbox desktop.
And can I steal your firemenu? That's a brilliant idea ![]()
Might be better to use a case statement for the find_editor function though, it will be parsed quicker than the elifs.
I dont believe removing lvm2 is a solution head on a stick.
Yeah, you're probably right. It was just a stab in the dark tbh.