f-log

I hadn't played Ancient Dungeon for a while on the Oculus Quest 2(*), so I was a bit surprised when I tried to play it that I could not move forward!

I could consistently move backwards and sideways without issue.

Moving forward, bounced me around. Not a pleasant feeling.

Sometimes a lot and some random sliding while I was motionless and other times just tiny tweaks to the amount I moved.

First attempt at fixing was to reboot.

No change

Then to redraw the quest active boundary.

No change

Then play with all the movement settings in the app. Turning things off and on again is a surprisingly effective strategy.

No change

Check the room for mirrors, reflective surfaces or moving items. Basically anything that might throw off the tracking.

No change

Then to try the old Beta version I still had installed.

That one worked fine.

But after playing with the beta movement settings and going back to the main app IT WORKED!

So I have no idea what is happening. Jut happy to playing in the dungeon again!

(*)It was bought before Meta changed the name.

I have been 3D printing character name holders for my D&D friends.

Everyone loves them and they are so cheap that I can give them away.

and ages ago I created a Raspberry Pi attachment for my 3D printer.

But it has a fatal flaw, the stiffness of the cables coming from the Pi cause it work its way out of the arm and drop off.

As the Pi has the LEDs illuminating the print, this makes it difficult to monitor the printing process.

Luckily I developed the attachment in two parts.

The clip for the printer

The Pi holder

So I have just tweaked the design of the arm and swapped it over.

Note how the forks of the arms come together and there are nodules to stop the Pi falling out!

It is not quite perfect, but I don't need to print a revision, the Pi stays put.

Part of my OPSEC is to run a browser in a VM.

I use VirtualBox and at the end of each session I restore the VM to its previous state, removing any trace it was ever used.

This used to work perfectly. At the end of the session I would close the VirtualBox window and it would ask me what I wanted to do with the running VM. It would revert all the changes and leave the VM ready for the next session.

All good!

Except, some people(*) managed to set the restore option as their default, forget that they had done that and then lose all their work.

After a number of people(*) shouting at VirtualBox engineers about data loss, VirtualBox removed the checkbox.

Which scuppered me. I now had to go to the snapshots and restore the correct one each time.

More users(**) like me complained that this was how VMs are supposed to work and eventually a workaround was found.

There is a hidden option for the state of the original checkbox and this can be set with the command.

VBoxManage  setextradata "MYVMNAME" GUI/DiscardStateOnPowerOff 1

All good, everyone happy!

...

Until the next update.

...

When that value gets reset. Not a huge problem just run the command again.

VBoxManage  setextradata "MYVMNAME" GUI/DiscardStateOnPowerOff 1

Most people happy.

Until the update that broke it and reintroduced the checkbox, but crucially didn't honour the GUI/DiscardStateOnPowerOff value !!!

Agh!

So I have to make sure I tick the box during shutdown at the end of every session :(

(*) It is difficult to stress how much I want to put insults here. They set the damn value and then they ignored the GUI!!

(**) Who want computers to do what they are told, consistently.

A quick and slightly odd Gentoo updating story.

Gentoo builds everything that is installed from source code. This differs in the way most (if not all) Linux distros work. The other distros will update your house by removing the existing one and replacing it with an out-of-the-box ready-to-go building. What if you lived on a steep hill and those styles of house just didn't work? This is where Gentoo comes in, the upgrade would build the new building brick by brick and ask nicely if you have any specific requirements.

I like to manage my Gentoo upgrades manually. I check if there are any upgrades and check I want them with

emerge --sync & emerge --pretend --update --deep world

Then I actually download and start the install process

tail -f /var/log/emerge-fetch.log&
emerge -avDNuUt world

At the end there is a list of post install notes. Most commonly benign, but sometimes I have to make a change based on one of more of the packages notes.

This time it was Grub , the boot manager.

 * Messages for package sys-boot/grub-2.06-r7:

 * For information on how to configure GRUB2 please refer to the guide:
 *     https://wiki.gentoo.org/wiki/GRUB2_Quick_Start
 * 
 * Re-run grub-install to update installed boot code!
 * Re-run grub-mkconfig to update grub.cfg!
 *

Well that sounds straight forward...

grub-install

Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.

Oh! Maybe I don't have /boot mounted?

mount | grep -i boot

/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

Nope.

Or maybe I don't have an EFI partition

fdisk -l /dev/sda1

Device       Start       End   Sectors   Size Type
/dev/sda1     2048    526335    524288   256M EFI System

Nope.

Maybe there is no EFI directory?

ls /boot/

EFI
(other files/folders excluded)

Nope.

So what was going on?

I would seem the default for Grub is /boot/efi

and as Linux is case sensitive ... that's a problem ... that is easily fixed :D

grub-install --efi-directory=/boot/EFI

Maybe if Grub's error message had listed the target as /boot/efi I would have caught on earlier \_%_/

Bit of a gap in service there \_%_/

Not sure when I last had TWO months missing.

Anyway, hopefully it was a blip and things will get back to normal-ish.

Still trying to move house and other fun life changes/issues.

But, I have done bits and pieces :)