site  contact  history  index

Considering heim joints for wheel knuckles

March 28, 2024 — BarryK

Yesterday I considered ball joints on the wheel knuckles:

https://bkhome.org/news/202403/considering-ball-joints-for-wheel-knuckles.html

At the workshop today, I constructed another design, using two heim joints top and bottom:

img1

The orientation of the heim joints has the advantage of allowing any amount of vertical displacement of the wheel relative to trike frame.

The downside is weight. It has the original m12 bolt, inserted through a steel tube with brass sleeve insert. I cut off the head of the bolt and welded it to the cube, as can be seen on the left of the photo. I didn't weigh yesterday's design when assembled, but estimating by weighing the parts, today's design is about 330g heavier. For both sides, that is 660g (0.73 Imperial pounds).

With the original trike suspension, that I had almost completed, I found that the weight had got much higher than desired. A bit of extra weight here and there; it adds up. In particular, the sprung part, the wheel knuckle, should be as light as possible. So, I am not going to take today's design any further.

I'll be back at the workshop after Easter, want to try one more design variant. Oh yeah, Easter has rolled around again. Happy Easter guys!    

Tags: light

Considering ball joints for wheel knuckles

March 27, 2024 — BarryK

I posted about three different types of ball joints that I purchased for comparison:

https://bkhome.org/news/202403/heim-versus-ball-joint.html

Today I was at the workshop where retired guys get together and work on little projects. Lots of good equipment there. Thinking about what ball joints to use with the wheel knuckles.

Back in early January I was working on the wheel knuckles, intending to fit them to the cheap swing-arms that I purchased from China:

https://bkhome.org/news/202401/construction-of-wheel-knuckle-hinges-and-learning-to-weld.html

Various problems with those swing-arms. Sloppy pivots is the main problem, but also the design became very big and heavy; not really what I want for a trike. While my thumb has been healing, have rethinked the design; hence purchase of the ball joints for consideration.

The workshop has some old 40x40mm steel square tube, and I cut out some cubes. Actually that square tube is fencing post, available from Bunnings, but I found an old length to cut up. Here is the first consideration:

img1

...the cubes are just balanced in place, to see how it will look. I won't rush into doing it this way, as it will be a one-way process; the cubes will have to be welded onto the wheel knuckle.

Any downsides? The main one will be limited vertical displacement, restricting how big a bump can be handled.

The spacing between the ball joints is ok. I looked at it with SolveSpace:

img2

...notice that 390mm distance; that is the height of the trike frame above ground. That is intended to be the rest position, with someone sitting in the trike. The distance between the wheels on the ground is 650.99mm.

If the trike frame is pushed down, which would be the same as riding along and both wheels hitting a bump, this table shows how the wheel spacing (on the ground) varies:

Height
Spacing
390
650.99
380
651.93
370
652.28
360
652.05
350
651.23
340
649.85

...wheel scrubbing is at most 1.3mm (0.65mm per tyre); negligible. Snapshot from SolveSpace, at height of 340mm:

img3

...looks good. The ball joints could handle a bit more vertical displacement; just looking at it in SolveSpace, it seems the height could go down to about 320mm, at which point the shock absorbers would also be reaching their limit -- 70mm vertical displacement, a little bit under 3 inches. That's a pretty big bump.

Next-up will consider the wheel knuckle with heim joints.   

Tags: light

Quirky has returned!

March 21, 2024 — BarryK

I created Quirky Linux in 2010 and the last release was in 2018. I then notified Distrowatch that the project was discontinued.

Quirky was a full installation, occupying an entire partition, the same as most Linux distributions. It did not support squashfs (SFS) files, nor did it use aufs or overlay fs layered filesystem. So it did not have "run in RAM with a save file";  what it did have was strategies to minimize flushes to the storage media, to help prolong the life of flash media.

There are some guys active on the Puppy Forum who would have fond memories of Quirky. Well, Quirky is back, though this is "Quirky on steroids". And very highly experimental.

Yes, the features are as described above; however, major new features are added. Quirky can be installed frugally, that is, be in one folder in a partition used for other purposes -- but it has to be a btrfs partition. There is a snapshot and potentially rollback/roll-forward capability, like we have in EasyOS and the pups. The filesystem has read-write compression. There is per-folder encryption.

Regarding the requirement for a btrfs partition, if you want to install to an internal drive, you would probably have one if have installed Fedora or OpenSuse. It is theoretically possible to create a file in a ext4 partition and create a btrfs filesystem in that file (maybe a sparse file) and mount it as subvolume; then can boot into it.

The containers feature of EasyOS is gone. Instead, there will be more attention given to isolation of apps from each other by the method introduced in Easy; to run each app as its own user. This mechanism can be tightened further.

This new Quirky is built with Void Linux packages, and uses XBPS package management, with PKGget (PPM) as a GUI frontend. As introduced in easyVoid. I was struggling with easyVoid, as it uses SFSs and aufs layered filesystem, which is very incompatible with XBPS. It is this incompatibility that was causing me to implement hacks that I did not like, and turned my attention to bringing back Quirky.

A name for this new Quirky can be "QuirkyVoid", or just "QV". Here is the old logo:

img1

...I never created an SVG for it; will put that on the to-do list.

The new build system is derived from woofV that builds easyVoid; the new name is "woofQV". I will be uploading it to github very soon.

woofQV is very simple. A series of scripts to run, and it creates a drive image file 'qv-<date>-amd64.img'. Just like with EasyOS, write it to a USB-stick and boot it. OK, I did that, and got a normal-looking desktop:

img2

Works as you would expect. What is important though, is what is underneath. The filesystem is completely different. If I am running another distro and plugin the USB-stick and mount the working-partition, this is what is seen:

img3

...the working-partition has a btrfs filesystem, and those folders named "@*" are what is called "subvolumes". This is a frugal-install, as all of this is inside folder 'quirkyvoid'. Folder '@qv' is the root-filesystem -- before clarifying that, explaining more about the drive-image file...

Just like EasyOS, the drive-image file has two partitions; an esp boot vfat partition, and a working-partition. Except the working-partition is no longer ext4. Here is the boot-partition:

img5

...for various reasons, this has 'vmlinuz' and 'initrd'; not in the working-partition.

Here is code in the 'init' script in the initrd, before the switch_root operation:

img6

...that SUBVOL variable is "quirkyvoid/@qv", which mounts the @qv folder onto /newroot folder.  SUBDIR is "quirkyvoid/". Then /dev, /proc, etc are moved to /newroot, and a switch_root performed.

There are three "--bind" mounts, that mount the external folders 'data', '@home' and '@files' inside /newroot. So, after bootup, this is what "/" looks like:

img7

...which looks similar to EasyOS. Except for that new 'data' folder.

It is intended that 'files' and 'home' will be encrypted. This will require a password to be entered at bootup. Currently don't have that, as the 6.8.1 kernel with fscrypt patches doesn't work; booted to the shell prompt, then a second later the kernel crashed. I have reported this to the 'linux-btrfs' mail-list, with a screenshot of the crash.

QV has huge potential, but a lot of work to get it to a reasonable working condition that can be released. A pre-alpha maybe not to far away.

I will post more explanations in future blog posts. I'm a beginner with btrfs, so refinement will happen. Those 'data', '@home' and '@files' located outside of '@qv' is unusual, I gather from reading so far; it seems that it is more usual to create '@home' for example, nested inside '@qv' -- but intuitively it seemed better to have '@home' outside and bind-mount it inside -- anyway, my way seems to be working.    

Tags: quirky

btrfs-progs with fscrypt take-2

March 20, 2024 — BarryK

I posted yesterday about compiling Josef Bacik's fscrypt branch of 'btrfs-progs':

https://bkhome.org/news/202403/btrfs-progs-with-fscrypt-patches.html

There were some things that I didn't understand, and sent an inquiry email to Josef. Here is part of my email:

With ext4, "mkfs.ext4 -O encrypt,..." will enable fscrypt; however
"mkfs.btrfs -O list-all" does not show "encrypt" as an available
feature.

So that is my question, is it just the documentation that is lagging,
and "-O encrypt" will work?

And if so, how do I check? With ext4, can use "tune4fs -l ..." to list
features. I'm new to btrfs, not familiar with the tools.

And here is part of Josef's reply:

You need to make sure when you're configuring btrfs-progs you use

./configure --enable-experimental

so you get the encryption support. However you don't need that to
enable encryption. If you just use the normal fscrypt tools to enable
encryption it'll work properly, we don't do anything specific at mkfs
time like ext4 does, we do it all live.

Good. I have recompiled 'btrfs-progs' and updated the PET. Also recompiled it statically in OE for use of the utilities in the initrd.  

Tags: quirky

btrfs-progs with fscrypt patches

March 19, 2024 — BarryK

Recent posts about btrfs:

https://bkhome.org/news/202403/kernel-681-with-btrfs-fscrypt.html

https://bkhome.org/news/202403/improved-support-for-btrfs.html

https://bkhome.org/news/202403/btrfs-progs-compiled-statically-in-oe.html

However, to support fscrypt, patches need to ba applied to 'btrfs-progs'. One of the main developers of btrfs is Josef Bacik, and he is the primary implementer of fscrypt support in btrfs. He has fscrypt patches for btrfs-progs:

https://github.com/josefbacik/btrfs-progs/tree/fscrypt

I have compiled his btrfs-progs in EasyOS Kirkstone and created a PET:

https://distro.ibiblio.org/easyos/amd64/packages/pet/pet_packages-kirkstone/

For the record, this is how I configured the source:

# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-crypto=builtin \
--with-convert='' --disable-python --disable-libudev --disable-zoned --disable-convert \
--disable-documentation --disable-backtrace

I uploaded the source tarball to ibiblio:

https://distro.ibiblio.org/easyos/source/alphabetical/b/

Need static binaries for the initrd. Here is the build recipe:

https://github.com/bkauler/oe-qky-kirkstone/commit/e80f8a9bc3eb8241b03127d61379e55738b3092f     

Tags: quirky

Kernel 6.8.1 with btrfs fscrypt

March 16, 2024 — BarryK

I posted about 52 patches available to implement fscrypt in btrfs:

https://bkhome.org/news/202403/linux-kernel-btrfs-supports-fscrypt.html

I have compiled the 6.8.1 kernel with btrfs builtin (not as a module) and those 52 patches applied. The kernel also has both overlay and aufs builtin.

For anyone who wants them, those patches are in a tarball, available here (inside build-kernel.tar.gz):

https://distro.ibiblio.org/easyos/source/kernel/6.8.x/6.8.1-20240316/

Here is how I applied the patches:

if [ -f 3rd-party/filesystem/btrfs-fscrypt.tar.gz ];then
echo "btrfs fscrypt patch..."
cp -a -f 3rd-party/filesystem/btrfs-fscrypt.tar.gz temp1/
cd temp1
tar -xf btrfs-fscrypt.tar.gz
cd ..
cd linux-${KERNVER}
Psorted="$(find ../temp1/btrfs-fscrypt -type f -name '*.patch' | sort -n | tr '\n' ' ')"
for aP in ${Psorted}
do
patch -p1 < ${aP}
done
cd ..
rm -f temp1/btrfs-fscrypt.tar.gz
rm -rf temp1/btrfs-fscrypt
fi

...excessive "cd" operations, but it works.

The kernel was compiled in EasyOS Kirkstone-series version 5.7 and the PET is here:

https://distro.ibiblio.org/easyos/amd64/packages/pet/pet_packages-kirkstone/

...there is no broadcom-sta module for it, as it failed to compile.

Note, it you are running EasyOS, there is a bit more involved than just installing the PET. The PET is used in WoofQ when building EasyOS. Developers can, however, open up the PET and extract 'vmlinuz' and the modules, then manually change to use that kernel (it is at /boot/vmlinuz).    

Tags: quirky

Improved support for btrfs

March 15, 2024 — BarryK

I posted earlier today about compiling 'btrfs-progs' linked-statically, as I want to include the 'btrfs' utility in the initrd:

https://bkhome.org/news/202403/btrfs-progs-compiled-statically-in-oe.html

I will also have the 'btrfs-progs' package in the main filesystem.

using Gparted, I created a btrfs filesystem in a partition in a USB-stick, but the icon for the partition did not display on the desktop.

Hmmm... I have never worked with btrfs before, despite it being around for so many years, and the choice for root filesystem of some distros such as Fedora. I looked through the scripts and found out what was wrong. Fixes committed:

https://github.com/bkauler/woofq/commit/00505fe6ccfdd950d3d89d011afa2bbf9d868724

For anyone interested in reading more about btrfs:

https://btrfs.readthedocs.io/en/latest/   

Tags: easy

btrfs-progs compiled statically in OE

March 14, 2024 — BarryK

OpenEmbedded calls the package "btrfs-tools". I have compiled it linked statically with musl. Recipe:

https://github.com/bkauler/oe-qky-kirkstone/commit/ab75d7c484a76ab237354d53dcc5831d0999f984

It required that 'util-linux' had to be recompiled, to build libblkid.a and libuuid.a:

https://github.com/bkauler/oe-qky-kirkstone/commit/d1d43ecf7ee4eae89177d754bbc82e1f0f14156f

I know that the btrfs-progs git site has it available as a static binary; however, mine is smaller, and I want to use it in the initrd which is not compressed.   

Tags: oe