Overlayfs cannot handle zram

I have moved from aufs to overlay filesystem (it used to be named overlayfs, but they changed the name to just overlay, which is a very strange decision).

The documentation for overlay states that direct writes to the lower layers is forbidden, so that rules it out for Puppy Linux.

However, usage in Quirky does not require writes to lower layers, so overlay looks good.

Except that I have just run into a brick wall. I have discovered that overlay cannot handle the upper rw layer being a zram.

A zram is used for the live-CD. I thought that I had done everything correctly, however the 'init' script in the initramfs was failing, the kernel crashing.

I setup an experiment. Created folders just like in the initramfs: q_ro/q_sfs, q_rw, tempwork, q_new.

Using the same busybox from the initramfs, this works:
# ./busybox mount -t overlay -o lowerdir=./q_ro/q_sfs,upperdir=./q_rw,workdir=./tempwork overlay ./q_new

Then, mounting a squashfs file on the ro layer:
# ./busybox umount ./q_new
# ./busybox mount -t squashfs ./q_ro/q.sfs ./q_ro/q_sfs
# ./busybox mount -t overlay -o lowerdir=./q_ro/q_sfs,upperdir=./q_rw,workdir=./tempwork overlay ./q_new

Success again. Now create a zram:
# ./busybox umount ./q_new
# ALLOCK=1000
# USEK=500
# echo "${ALLOCK}K" > /sys/block/zram0/disksize
# echo "${USEK}K" > /sys/block/zram0/mem_limit
# mkfs.ext2 -m 0 -L qrw /dev/zram0
# mount -t ext2 /dev/zram0 ./q_rw

And try again:
# busybox mount -t overlay -o lowerdir=./q_ro/q_sfs,upperdir=./q_rw,workdir=./tempwork overlay ./q_new
mount: mounting overlay on ./q_new failed: Invalid argument

Have I misunderstood something here? Do I have to go back to aufs?

Quirky 8.1.6 x86_64 released

No comments
This new Quirky is codenamed "SlaQ" and is built from Slackware 14.2 binary packages.

The background, announcement and release notes are here:

A very brief announcement blurb:

Quirky Linux 8.1.6 x86_64 is codenamed "SlaQ" and is built using the woofQ Quirky Linux build system, using Slackware 14.2 binary packages. Thus, SlaQ has compatibility with all of the Slackware repositories, including "slacky" and "salix".
Quirky is a fork of Puppy Linux, and is mainly differentiated by being a "full installation" only, with special snapshot and recovery features, and Service Pack upgrades.

Instructions to install are here:

Quoting from the above link:

SlaQ is provided as a 8GB USB Flash stick image, or for an SD-card. This file may be written to an 8GB or greater Flash stick. In the latter case, at first bootup there will be an offer to increase the filesystem to fill the drive.

Very easy install instructions for Windows users. The above link explains how to install from the commandline in Linux, though I intend to develop a simple GUI.

For those who still want one, there is also a live-CD ISO file.

The primary download host is Ibiblio:

There are faster mirrors, such as NLUUG:

You will notice that the Flash-stick image file is 398MB. The reason it is so large (by Puppy standards) is because it is gzip compressed. The same file xz-compressed is only 238MB.
Gzip compression is used as that is understood by many Windows image-writer applications. The *.img.gz file is very easy to install for Windows users.

The live-CD ISO is 304MB. It is smaller because internally it uses xz compression.

There are some known issues.

1. There is Bluetooth support, but it needs work.
2. SeaMonkey has a few problems. It is stuck on DuckDuckGo for starters.
3. Paste into a terminal, does not wrap.

Also, the build does not have Samba. Nor python, but v2.7 is in the "devx" PET.

Regarding SeaMonkey, it is version 2.46. The SM developers released 2.40 in March 2016, then nothing until 2.46 was released at the end of December 2016. Perhaps they were under pressure to get something out. Whatever, 2.46 has multiple issues, mostly annoyances.

Partition resize was broken

No comments
At first bootup of Quirky on the Raspberry Pi, QuickSetup runs. This is a GUI to quickly make basic configuration choices.

One thing it does is check if there is unused space at the end of the drive. This will occur if the drive is bigger than the image-file written to it. Quirky is supplied as a compressed image file, that expands to a nominal 8GB -- but it is actually a bit smaller, so as to fit on any "8GB" SD-card.

So even on an 8GB card there is going to be a bit of unused space at the end. Much more so if you use a 16GB or 32GB SD-card.

QuickSetup checks if there is more than a few hundred MB empty space at the end of the drive, and if so, offers to resize the Quirky partition to fill the entire drive.

OK, this works on the Pi. However, I discovered yesterday that it does not work on a PC. The reason is, I supplied Quirky Xerus 8.1.5 x86_64 as a 8GB USB Flash stick image, with a GPT (Guid Partition Table).

The partition resizing fails with a GPT, due to the use of Busybox 'fdisk'. My "easyinit" ramdisk has Busybox in it, compiled statically. I have written about Easyinit in earlier posts.

However, the full 'fdisk' utility, in the 'util-linux' package, can handle the partition resizing in a drive with GPT.

I have compiled fdisk statically in Buildroot, so have added that to Easyinit.

This fix applies to Quirky Xerus and the soon-to-be-released SlaQ X86_64 Linux distributions.

Win10 locked me out

No comments
Windows 10 continues to be a less than optimal experience for me.

I haven't been able to upgrade since June 2016. I used to be able to upgrade, but no longer. When I click the button to check for upgrades, it just reports there was an error, and provides a code that I am to give to Customer Support.

My Asus E200HA came with Win10, I only purchased it this year. Haven't messed around with it much, just installed a few apps, and shrank the partition (using Microsoft's own partition management tool).

Annoying, yes. I do not want to phone Customer Support and wait in a queue.

Then, last night, Win10 wouldn't let me in, with this message:

This device has been locked for security reasons. Connect your device to a power source for at least two hours, and then restart it to try again

What, locked out of my own computer! What nerve MS has!!!

This problem is discussed here:

ROX-Filer frozen on E200HA

1 Comment
Ha ha, the saga continues with my Asus E200HA! Yesterday I posted about fixing the keyboard, again:

I then created what I thought was going to be the release version of SlaQ, booted up on the E200HA, all seemed OK, but after a few minutes, ROX-Filer locked up. Everything else kept working. I noticed CPU usage climbing precariously, so shutdown.

Have used SlaQ on the E200HA a few times since then, Rox has been OK. Hmmm...

I am using an old version of ROX-Filer that was compiled in T2. I notice that Fatdog is using more recent source:

...this is a fork of the original project, which is mostly dead.

OK, I will compile it in SlaQ, and hope it performs better.

Pages: ... [3] [4] [5] [6] [7] [8] ...