OpenBSD sorta' Puppy style

[user1111]

Installed qemu from gslapt (Fatdogs package manager).
Created a qemu (virtual) disk.
Downloaded OpenBSD 7.1 installation iso and booted that using kvm/qemu
Ran through the installation process and rebooted into the newly installed system.
pkg_add'd jwm, rox, geany, galculator, libreoffice, firefox-esr ...etc. and started X (xenodm), and logged in as 'user' into that desktop ... somewhat Puppy look-n-feel.

With qemu you can boot in snapshot mode, copy on write a.k.a layered filesystem style, where the main system is read only and all changes are stored separately. You can later reboot with those change preserved, or simply throw them away after each session, which is what I tend to do once the base system is setup as I like. With qemu the base system and changes have to be on the same filesystem - so I cheated and created a sfs of the base (ro) system, using lz4 compression, and then mounted that sfs, and then sym linked that mounted version into /root ... which is in ram. So the base system is a sfs, and the system is layered. I then started OpenBSD using that and where the snapshot/changes are also written to /root (ram). Much more closer to puppy style. Only thing not in ram is the base sfs, but with lz4 and its fast decompression speeds that's not too much of a issue.

So Fatdog host, OpenBSD guest via kvm/qemu, and where mostly running in ram, with no changes being preserved between reboots and the main system stored in a sfs. The main factor there is that as changes accumulate so that eats ram, but for general browsing/office type activities that worked well on my 4GB system (that is reduced down to 3.3GB after graphics takes its chunky slice). To add in a bit more ram I booted Fatdog with basesfs=direct rather than =ram, so its main sfs isn't copied into ram and frees up around 400MB of additional ram.

A nice feature of that combination is that you have all of the Linux type drivers/modules - for sound, wifi ...etc. (host system) that otherwise might not be included within OpenBSD. For example with Openbsd fowarding sound via sndiod to Fatdog, and using the wifi net connection established within Fatdog before starting OpenBSD.

Main OpenBSD system ... stored in a SFS
|
qemu copy on write snapshot (save/changes area) using ram
|
Following shutdown changes can be preserved (left) or thrown away

There are qemu tools to merge in the snapshot into the main system; And/or you can simply boot in full read/write mode to make changes, perhaps add or remove packages (pkg_delete geany for instance), and then reform a new version of the main sfs (mksquashfs) to reflect those changes.

[user1111]

After a few hours of use - its running very well. I opted to install firefox-esr as the browser and given that its running in a 'clean boot' manner I disabled pledge and unveil ... along with various other performance enhancement (security degradation) tweaks and operationally it runs well, not as snappy as Puppy/Fatdog but most usable and some lag is only to be expected given its running in a qemu session. On par, general speed wise, as a fully installed mechanical disk based system - good enough.

I do like the full OS system ... consistency and excellent manuals (very specific) to guide you.

Only negative is that the laptop does run warm/hot, idles at around 15% cpu usage compared to near 0% - I guess mostly down to qemu. So on my system 58 degrees temperature rather than 54, but not much hotter when active, 60 to 62 instead of 58. Which would also mean quicker battery drainage.

i.jpg (87.7 KiB) Viewed 1468 times

[user1111]

Re-ran another qcow2 virtual disk creation and booted qemu running the OpenBSD install CD within that to install OpenBSD into that virtual disk - but opted to just install the base set, bsd, bsd.rd, base ... etc i.e. omitted manual, games, X, compile installation sets (which are all just tar files anyway, so easily installed later). I then made a sfs of that disk using xz high compression and that resulted in a 299MB sfs filesize.

Enough to copy that to /root (ram), mkdir m and mount the sfs to that m mountpoint, and boot using qemu snapshot mode, so layered with all changes being written to that snapshot file. Booting, having patches applied etc. resulted in around a 250MB 'save file' size, around 180MB if squashed. That would grow rapidly however as the other sets (X, comp, ...etc.) where added in, but was very quick (as its all running in ram).

I opted to comment out kernel and libs reordering within /etc/rc ... and cut the wait until default boot occurs from 4 seconds to 1 second ... so it boots quicker.

Retain the snapshot file and you can reboot back into the prior session. Delete it and it reboots back to the clean initial session. You can however layer snapshots, incremental changes, so conceptually at least you could make a sfs of each prior snapshot and merge those at bootup. More details here
https://wiki.qemu.org/Features/Snapshot ... shot_Merge

Snapshot-chain-example-1.png (19.34 KiB) Viewed 1446 times

Somewhat similar to Fatdog's multi-session saves where each save creates a additional sfs of the changes, and where those all get layered into the system at bootup, and where you can optionally opt to save, or not, at the end of each session.

[Subito Piano]

Rufwoof -- just happened upon this -- kudos, man -- this looks like a good thing! I've played with BSD a few times but only found one or two versions that seemed to work well for me, I hope to try your "Puppy-ized" version out once school is out and my workload lightens up (a couple weeks away). Keep it up.

[user1111]

Create a virtual disk, qemu boot the install iso to install to that using a single processor (no bsd.mp), but only install the bare system, bsd + base ... and a trick is to ctrl-z just after the sets have been installed and avoid it running the libs relinking by first dd'ing zeros to kernel.tgz (buried somewhere under /etc/) and then rm that file so that the relink fails. Otherwise the cow2 disk actually still has those blocks where kernel.tgz was filled with non-zero data. When zero'd out the final version xz high compresses down to just 100MB - for a basic cli boot with wifi/net support etc.

I did quickly try booting that in snapshot mode and un-tar'd all of the other sets, so that they recorded in the 'save' area (snapshot), which grew that to around 3GB.

Basically I was just testing out 7.1 as I'm in the process of upgrading my server to that, from 6.8. Got most of that done now, where I'm vnc'd into that and have sound forwarded to Fatdog using sndiod - basically where you compile sndiod in Fatdog and create a userid for that, and then run that sndiod on Fatdog and instruct firefox-esr/whatever in openbsd to forward to that

AUDIODEVICE=snd@<fatdog IP> firefox-esr

Quality/response are great, crystal clear sound and very little if any jerkiness in videos, even at full screen (when tigervnc is installed/used within OpenBSD). And that's without me having yet approached performance enhancements such as removing firefox-esr from pledge/unveil and/or other such tweaks (I'm not really a fan of relinking libs and building a new kernel at each boot either when using it just as a desktop system).

The simplicity and structure of OBSD is a beauty in itself, such as that simple sound forwarding method. Under Linux alsa, jack, pulseaudio etc.... yuk. And at the end of the day even though simpler the sound quality seems so much better.

[user1111]

Reformed another base system sfs, using xz high compression =172MB, which includes all of the sets excepting comp (like devx), games and man.

Booted that, installed jwm, rox, mtpaint, galculator, geany, libre office and firefox-esr and the xz compressed size of that snapshot file is 477MB. Extracting that and booting using the mounted main system sfs has changes preserved in that extracted tree; Or if want to reboot to pristine/clean again then rm the extracted folder and re-extract the snapshot sfs content again.

A benefit of layering in a Puppy like manner is that you can mess around, screw things up and have the option to 'reset' the system back to clean again relatively quickly/easily, rather than having to mess around with restoring backups. SFS layering (using sfs) can also run more tightly than full installs.

Booting using Linux provides a broader range of drivers, and has the benefit that the Linux internal firewall (iptables) can be set to drop access to your router - where the qemu/guest system can't modify that rule.

[wiak]

Retain the snapshot file and you can reboot back into the prior session. Delete it and it reboots back to the clean initial session. You can however layer snapshots, incremental changes, so conceptually at least you could make a sfs of each prior snapshot and merge those at bootup. More details here
https://wiki.qemu.org/Features/Snapshot ... shot_Merge

I don't know much about qemu, so didn't know about qcow2 and merge/snapshot abilities. It is interesting. Are whiteouts involved in this system? Just wondering how delete mechanisms in terms of the layers work. I remember, decades ago now, cow copy on write type filesystems when using User Mode Linux, which was incredibly resource efficient in terms of sharing base system between networks of uml virtual machines.

[user1111]

Are whiteouts involved in this system? Just wondering how delete mechanisms in terms of the layers work.

qcow2's copy on write is more a case of redirect on write - disk blocks layering rather than file layering. The main layer is read only, any new writes have the relevant data blocks 'layered' (written to the 'save' area that are then subsequently referenced first). So no whiteouts are involved, for instance a prior file that was removed would have its respective inode updated to flag the file as having been removed, and the data block that inode existed in would be recorded in the 'save' area - that subsequently got referenced first, found, and where the files deletion would be reflected in the 'seen' view.

That said, I know relatively little about qemu myself so take the above with a pinch of salt.

[user1111]

Used Fatdog, with qemu installed, to create a 13GB vHDD, and then qemu booted OpenBSD 7.1 iso to install OpenBSD to that vHDD.

Once the installation had finished, I dd'd the image to a 14GB usb stick and then booted that usb. Ran surprisingly well/quickly. pkg_add tigervnc and vnc'd into another OpenBSD box to run Libre/Firefox ...etc. Playing youtubes with sound forwarded to the laptop (that booted the usb) and good quality.

gzip'd the 13GB image file and 274MB gzip filesize. I did exclude the comp (like devX) and games sets from the installation process. I also removed kernel.tgz during the installation process (ctrl-z after sets installation finished) and resumed again (fg) after removing kernel.tgz (grep /install for the location) .. which disables the kernel reordering security measure, but saves on space).

dd'd the image using blocksize of 8192, so was quite a slow write process.

Basically ran ...
qemu-img create LiveUSB.img 13000m
qemu-system-x86_64 -hda LiveUSB.img -cdrom install71.iso
dd if=LiveUSB.img of=/dev/sdb bs=8192

Does take quite a while to both do the install and then the dd. Assume perhaps a couple of hours.

[user1111]

A few general tweaks for OpenBSD after you've installed, booted and pkg_add firefox-esr libreoffice mtpaint jwm rox-filer tigervnc ....etc.

Remove firefox-esr from being pledge/unveil

Code: Select all

DISABLE="/etc/firefox-esr/{unveil,pledge}.{main,content,gpu}"
for THIS in $DISABLE ; do
   echo $THIS
   echo disable > $THIS
done

Set firefox-esr to use memory based filesystem (mfs) for its cache (that is lost at reboot) by adding a line to /etc/fstab something like

Code: Select all

951762f9609faefd.b /home/user/.cache/mozilla/firefox mfs rw,nodev,nosuid

(the 951....b value should be the same numerics as what is already set for swap in /etc/fstab and just basically sets up a ramfs for firefox cache that's based in swap).

Turn on hyper-threading by adding hw.smt=1 to /etc/sysctl.conf, and whilst you're there also add

kern.maxproc=32768
kern.maxthread=4096

Edit /etc/rc to comment out the lines that invoke libs and kernel reordering.

Add 'user' (or spot or whatever regular userid you use) to staff, operator and _sndiop groups (in /etc/group). Staff get allocation more resources in general.

The above bolsters speed/reduces security. Another change is to edit /etc/rc.conf/local to include sndiod_flags=-L- to activate sndiod, and also add apmd_flags=-A. In /etc/sysctl.conf you might also add hw.perfpolicy=high (alternatively set it to auto). Your laptop will run hot, but quickly. Not for my AMD/Acer but for others you might be able to also set hw.setperform=100 which is turbo mode, default mode is 99 which is a % value).

Networking wise and OpenBSD doesn't support my laptop's wifi, so I tether via usb cable to my phone for wifi access (phones wifi turned on, mobile data turned off (unless out and about), attach usb and tap the 'Transfer files' option and then set tethering on. On laptop dhclient urndis0 gets a IP allocated. That is however a NAT based IP, so for instance if the server is hard wired ethernet that you want to vnc into from the (tethered) laptop you have to set up a ssh (reverse) port forward in order to get the servers sound being played on the laptops speakers

Laptop open a terminal and run ... ssh -R 11025:localhost:11025 <ip of server> ... for sndiod forwarding (leave that terminal open to maintain that reverse tunnel link)
Then in another terminal connect to the server ... ssh <ip of server>
and as user run vncserver ... which starts that listening on :1
On laptop vncviewer <ip of server>:1 and in that gui desktop open a terminal and run AUDIODEVICE=snd@localhost/0 firefox-esr ... and the laptop display and sound card should see/hear a youtube played in firefox-esr. I love the simplicity of OpenBSD such as being able to redirect sound to whatever IP you like in such a easy manner. OpenBSD is very much like that, simple elegant solutions, maybe not always the best, but that works, such as when hyperthreading vulnerabilities arose OpenBSD simply opted to turn off hyperthreading.

You might also want to sshfs mount a server folder to the laptop
sshfs serverip:/folder local-folder ... as then you can use rox to drag/drop files/folders more easily.

OpenBSD installs by default with fvwm as the window manager, so with jwm installed you want to add to ~/.xsession a line of 'jwm' so it starts with that instead.

For sound level from the command line its mixerctl

mixerctl outputs.master=128,128 for instance for mid level setting, 255,255 for max. Just running mixterctl command alone shows all of the choices and values for all of the sound devices.

[user1111]

Used Fatdog, with qemu installed, to create a 13GB vHDD, and then qemu booted OpenBSD 7.1 iso to install OpenBSD to that vHDD.

Once the installation had finished, I dd'd the image to a 14GB usb stick and then booted that usb. Ran surprisingly well/quickly. pkg_add tigervnc and vnc'd into another OpenBSD box to run Libre/Firefox ...etc. Playing youtubes with sound forwarded to the laptop (that booted the usb) and good quality.

Tried that usb stick in another PC, booted and ran well.

Nice to have a little 20+ cpu/64GB+ ram portable pocket stick

img.jpg (160.43 KiB) Viewed 843 times

Did try X forwarding with sound (ssh -Y user@192.168.1.4 AUDIODEVICE=snd@192.168.1.10/0 firefox-esr) - but that was jerky. vncserver/viewer (tigervnc) works much better. Forwarded sound (sndio) can blip periodically for a brief instant when starting other programs/tabs - simple solution is to just run those other things on other CPU's

5G is progressing well around my way, so soon will be able to ditch 65 quid/month Virgin Media for a 20 quid/month unlimited 5G (and at least have one thing that is deflating in price (everything/one seems to be jumping on the 'inflation' bandwagon and ramping prices 25%))

[user1111]

Screenshot of Openbsd bare metal install (to laptop /dev/sda4 partition as part of a multi (dual) boot alongside Fatdog/EasyOS ..etc).

Just the base OpenBSD and nothing else other than a couple of bits of firmware installed when I initially ran fw_update after doing the original 7.1 OpenBSD install and pkg_add jpeg ... for the turbo jpeg (single package).

ssh -Y (X forwarding) using my Fatdog PC and running chrome - playing a youtube, where sound is also forwarded back to my laptop headphones using sndiod.

Top right is htop being run on that Fatdog box, bottom right is top on the laptop. Bottom right is bmon running on Fatdog ... for a overall indication of load/bandwidth.

Rather than install more packages on OpenBSD to take the screenshot I just used xwd (which I'd forgotten about and had to search to be reminded) and then scp'd the file over to the Fatdog box and used gimp to convert that to a jpeg.

screenshot.jpg (140.98 KiB) Viewed 805 times