KLV-Airedale-beta+ Released, Ready for Download

[wiak]

I changed my mind. Better to upload the newest version (v504-rc2) that allows w_changes=/mnt/sdXX/YYYY to boot despite a timing issue with it on my machine (no boot timing issue at all for UUID or other w_bootfrom methods, just that one and even then it does boot).
I'm curious to know if works okay on other computers. If it 'sticks' for a particularly long while during boot then UUID or LABEL method is recommended for now anyway. I'll look into the matter further later, but since UUID and LABEL work fine it is no show-stopper anyway.
Find latest get/fetch script for initrd_v504-rc2 at usual place, here: https://weedoglinux.rockedge.org/viewto ... p=355#p355

The difference (I think) with UUID and LABEL is that WeeDog initrd/init has always used a loop and busybox findfs to wait for the device identified by the UUID or LABEL being ready; basically findfs uses blkid search block devices type code (previously I used a mount attempt in similar loop as suggested by forum member 'seaside'), so I may need to use similar wait loop for /mnt/sdXX w_changes arrangement if I don't want any such wait issues for w_changes=/mnt/sdXX/YYYY format.

[fredx181]

Everything seems fine with Beta6 here. Admittedly, I'm not running many of the tests you guys are....which makes my responses of not much use. I seem to have lost some of my enthusiasm for trying stuff like this out in recent years. A sign of getting older, perhaps?

Disappointing. (cried the whole day... well.. no... ) But I'd understand that you have priorities (like everybody), is it because this is so different from a "real" Puppy ?
I see that @bigpup isn't posting here anymore lately, possibly for same reason ? (don't mean getting older, age doesn't say anything really IMO)

[fredx181]

@wiak Can't help much, I'm afraid.Tested with new initrd several times with w_bootfrom=/mnt/sdXX/YYYY from USB and HDD and got one time (after "lower_accumulated is ...") a delay of around 10-15 seconds, so seems to work most times booting with RAM2 and successful saving changes with save2flash.

[mikewalsh]

@fredx181 :-

But I'd understand that you have priorities (like everybody), is it because this is so different from a "real" Puppy ?

Nah, not really, Fred. Truth to tell, I was never "into" the nitty-gritty, "base" nuts'n'bolts that make Puppy function, either. I was always more interested in what you could run on top of all that, i.e., the user-land software itself. Although I DO have a wee bit more interest in some of what makes Puppy "tick" than I used to, it's true....

(Don't get me wrong; it's brilliant that the community has as many who ARE interested in this stuff; yourself, wiak, rockedge, PhilB., peebee, mistfire, josejp7474, etc, etc..... (I could go on ad infinitum, couldn't I?? ))

--------------------------------

This is what I mean when I've said in the past about how the community works together "as a team". We all have our strong suits, weak ones, and particular areas of interest. We "complement" each other in that respect, everyone working together for (hopefully) the benefit of all.

My fascination with 'portable' software goes back several years before the start of my Linux journey, so it's a bit of a long-standing "bee in my bonnet". It took a few years with Puppy - and Linux in general - before I really understood enough stuff to be able to start doing summat practical with it all.

I guess it's probably much the same story for most of us, TBH.

Mike.

[rockedge]

@mikewalsh The KLV's that I am running and testing depend hugely on the portables. Really makes the OS more powerful and I do not need to constantly reconfigure stuff in every new version. I have like 20 or more KLV's and Puppy's going and believe me it's not a trivial thing getting a quick set up for even simple testing. With the portables I just put a copy ofr the needed *.desktop file in /root/Desktop or /home/spot/Desktop and off to the races......

[rockedge]

@fredx181 , @wiak Where do we stand with the initrd.gz? What testing needs to be done and successful to move on?

I'm going to add the rc2 version of the skeleton

[mikewalsh]

@rockedge :-

@mikewalsh The KLV's that I am running and testing depend hugely on the portables. Really makes the OS more powerful and I do not need to constantly reconfigure stuff in every new version. I have like 20 or more KLV's and Puppy's going and believe me it's not a trivial thing getting a quick set up for even simple testing. With the portables I just put a copy of the needed *.desktop file in /root/Desktop or /home/spot/Desktop and off to the races......

Well; glad to be of service, young man..!

I will NOT take credit for the efforts of others, Erik. So many of my packages that I make available have had input from many other members, anyway; this is why I often say that what I produce is more of a "community effort" in the long run.

The only thing I'll take credit for is the packaging, and putting it all together so it works. And if I'm satisfied, and it does what I want it to do, then - and ONLY then - will I "share".

But that doesn't mean to say that things are 'set in stone'. Things can often benefit from tweaks to make them even more usable....

Mike.

[fredx181]

@fredx181 , @wiak Where do we stand with the initrd.gz? What testing needs to be done and successful to move on?

I'm going to add the rc2 version of the skeleton

Mainly if booting with w_bootfrom=/mnt/sdXX/YYYY (instead of with UUID or LABEL) combined with w_changes=RAM2 (or perhaps any other w_changes= , not sure)
gives a delay or not at boot (as wiak mentioned to have delay on his setup).

[rockedge]

@fredx181 Ahhhh, I see....excellent! Still okay.

Beta7 is ready in the usual place
same as beta6 except beta7 is equipped with initrd_v504-rc2.gz and w_init_504-rc2

[Clarity]

@gyrog employs a SAVESPEC file which is deposited on the boot-folder for PC discovery at subsequent boot time. This works for my UEFI PCs where upon subsequent boots, the ISO booting (file/frugal) finds the location of the SAVE-SESSSIONs without the need for user edits of the boot stanzas when changes are needed.

Is this technology that is used in WoofCE PUPs OR the SAVESPEC idea useful in our case, here?

In other words: Is the same SAVESPEC a bonus we could derive benefit and also be consistent with its benefit to WoofCE PUPs?

Just a thought.

[wiak]

This works for my UEFI PCs where upon subsequent boots, the ISO booting (file/frugal) finds the location of the SAVE-SESSSIONs without the need for user edits of the boot stanzas when changes are needed.

Debian live distributions used to, as far as I recall, put a marker file in the bootfrom directory, which is searched for on boot. WeeDog initrd doesn't work that way and doesn't need it since for normal frugal boot the grub.cfg is used to say exactly where the bootfrom directory to use is.

WDL initrd actually puts far more than a SAVESPEC file on its bootfrom directory, it puts most of the actual init code (in the form of w_init) - any information at all can be stored in there, as is actual code for doing most of the overlay functionality tricks. However, all such files (e.g. SAVESPEC or w_init) can only be loaded once the initial boot initrd/init (which is inside compressed initrd.gz) can mount to bootfrom partition (you can't read any external placed file until you can mount its partition). So it is a chicken before the egg sort of situation - by the time w_init is able to be read we already know where the bootfrom partition is and have mounted it by which time the rest of the boot process is fine (so any SPEC file irrelevant at that stage for that purpose).

Of course that external w_init file (which is optional by the way) can contain extra information for passing on to the main root filesystem for once the switch_root occurs, and it already does that to some extent. However, happily, neither WDL init nor its external w_init file need any information stored that applies only to one distro (Puppy SAVESPEC file and similar with its other SPEC file, DISTROSPEC and so on, is info for Puppy alone). WDL initrd is very generic and doesn't need or use such distro-specific SPEC files so can be used to boot most distros (which is why, for example, weedogit is possible), even Puppy so overlayfs has been available for booting Pups via WDL initrd for several years now via that.

So no, what you suggest would not solve any boot issues we are addressing. If someone wanted to store some extra info readable on the next boot they can do so via w_init code if they individually wish, but that would be for their own specific purposes and not needed (or advantageous) per se in the WDL initrd design when it comes to booting.

[wiak]

@fredx181 , @wiak Where do we stand with the initrd.gz? What testing needs to be done and successful to move on?

I'm going to add the rc2 version of the skeleton

Yes, there is not problem at the moment that particularly needs anything changed in latest initrd_v504-rc2. So that is the correct one to now use (not been tested much, so time will tell of course).

The 'possible' boot delay is for one special case (that doesn't need to be used anyway - personally I never use it and fact is the method could be removed from the initrd without loss of function - but I leave it in since it does work fine for non-slow boot media and probably fine most others too). If anyone finds they get a boot 'delay' if ever using the likes of w_bootfrom=/mnt/sdXX/YYYY method of specifying w_bootfrom (with a slow external usb stick) there is already a simple solution: don't use that method, use what is the recommended w_bootfrom=UUID=xxxxxxxxxxxxxxxxx=/YYYY method instead (which is not known to have any boot delays when using slow boot devices like usb sticks).

In practice I doubt that w_bootfrom=/mnt/sdXXX/YYYY related delay probably doesn't occur with most machine ever anyway. I doubt if it occurs on modern usb sticks in modern computers at all; my dev machine is from 2008, but even then the delay isn't 'huge' and machine goes on to boot fine. With UUID method, however, no delay at all, which sames me a few seconds of waiting...

[rockedge]

@wiak I have the updated initrd.gz rc2 in place in beta7, and so far operating well. I have also decent boot up speeds overall.

[wiak]

To be frank, from the initrd developer's point of view, the w_bootfrom=/mnt/sdXX/YYYY was minor to address and not worth bothering about further anyway since alternative and often better anyway UUID and LABEL methods already exist and work fine.

What did cause a lot of headaches (and needed extra complicated code) was accommodating the operation of the likes of SG2D. Unlike what some have said that was not simply a matter of including a suitable loopback.cfg file in the boot folder of the iso. No, no, no. I needed to embed probably 50 lines of code, mixed in various places inside the initrd/init code to allow SG2D to work. It is NOT the case at all that once SG2D has done its part the rest of the boot becomes just like a normal frugal install - not at all - the WDL initrd/init needs to then specially search for the iso SG2D says is to be used and since all the sfs addons and so on that iso contains are embedded inside the iso all sorts of 'tricks' need to be coded into the initrd/init to make it appear to work as 'normal' (especially to allow save persistence to work).

Let's just say, an initrd/init is a very critical piece of code and quite tricky to work with (one mistake and all you are likely to get is kernel FAIL message at boot - not easy to debug at all...). So changing even one line of code in initrd/init is something that can't be taken lightly, changing dozens of lines is just asking for trouble!!!
Hopefully, latest initrd.gz 504-rc2 is fine or close to it, but wow that SG2D extra code took probably hundreds of extra hours work and testing overall. NOT correct to say SG2D does not involve extra dev time - really it was the opposite. Nothing against SG2D - it is a useful facility for quick iso testing - more than that, personally I feel normal in own subdir type frugal installs are better and likely to be able to do more with them in terms of boot configuration options/save persistence mechanisms available.

[wiak]

@wiak I have the updated initrd.gz rc2 in place in beta7, and so far operating well. I have also decent boot up speeds overall.

Yes, nothing I have added will affect boot times at all (aside from that special case that didn't work at all prior).

[rockedge]

@wiak I have not run into boot problems with any of the initrd.gz versions. Really happy with the overall performance.

Right now just going along trying some customization and running some the features through the paces.

[wiak]

For those who yearn for the days of Puppy Linux or similar small distros being used most or all of the time as main desktop by general users, I believe that is more and more unlikely despite some of these smallish distros being fantastic (especially because of the frugal install facilities offered). The fact is, I myself have continued to use a now pretty old laptop as my main computer - my 2008 HP Elitebook 2530p 14" screen, sometimes 2 and sometimes 4GB RAM machine that has old but useful core2duo Intel processor inside. I do suffer with limited hard drive space as a result though - often only a couple of GB left for dev work!!! (though the hard drive could be easily upgraded of course - at 'relatively' small cost, but my whole computer only cost me around thirty dollars...).

However, soon my partner is upgrading to a modernish PC for her business needs (the 32GB RAM type of computer...). That means I will inherit something newer (haven't checked, but has at least 8GB RAM, I think 16GB, and a large SSD drive). Actually it already runs WDL_Arch64 as its main distro - all nicely tuned for the business needs, so I will likely continue with that as my main distro, but I also jump back and forth between that and KLV-Airedale (every day) and, occasionally, VoidPup64. KLV-Airedale has all the 'new' tricks and it works great to the extent that I never miss not being on WDL_Arch64 (I already use the new WDL initrd on WDL_Arch64 but haven't yet copied across the mainly fredx181-provided save2flash and so on user-scripts). Fact is though, that I will not be limited in space on the coming new machine, so no problem for me any longer to try out the various WeeDogged distros provided via weedogit.sh (in fact that is one raison d'etre for me creating weedogit.sh really). Fast fibre is also changing the landscape and download size becoming irrelevant - dialup days are gone and ADSL vanishing over time. Since the result continues to use WDL initrd then I continue to get all the frugal install advantages, so it is perfectly possible I will end up adopting (modifying) an upstream read-made-and-supported distro (though most don't interest me for other reasons). WDL and more general KL-related developments remain vitally important to me even then.

In general, I suspect, therefore, that the increased resource power of 'modern' machines (basically anything less than ten years old...) makes it unimportant how big the initial installation media is so the hole in the market that the likes of Puppy used to fill becomes non-existent really. Even usb sticks are huge nowadays (days of CD and DVD also all but gone). That doesn't make Pups or Pup-sized frugal install distros of no importance any more - there remains that advantage of being able to easily customise our distro if we choose to run with one of the distros discussed on this forum, but the weedogit.sh installed distros do muddy that water somewhat. For some of us it is 'nice' though to be able to run sometimes very slim distros and add ONLY what we really want - and more so if we like to run several distros at the same time in a network of virtual machines (though at the end of the day the per-distro result is sometimes surprisingly HUGE anyway...), so the build mechanism is really what is most important here (and of course the all-important very-flexible overlay functionality provided by the initrd.gz). That is why WeeDogLinux development continues to be something I do - I can build very specialized distros (as small or large as desired) via its build system in conjunction with its WDL skeleton initrd.gz. I certainly do not see the point of developing a less-flexible boot init mechanism and consider that a dead-end longterm (what would be its attraction?) - but (maybe with some luck) the existing WDL initrd.gz does provide some really flexible options that make the likes of KLV-Airedale very nice to work with. But still, I do think even some Puppy stalwards are, perhaps secretly, often running bigger distros as their main desktop nowadays, and I imagine that is why some old familiar faces no longer take part very often, not only in some threads here but also on the forum at all.

Point is, I feel that the reason for developing distros of Puppy-like frugal facilities has changed to a large extent. The market for Puppy is smaller in a general sense - old machines are indeed now going to landfill and no use to keep them anyway (they are often power-hungry anyway). So this forum needs a different market, which to me is those in the Linux community that actually want great flexibility in the Linux they can build and great functionality in the frugal install facilities these distro provide. It is indeed also an interesting hobby from a technical/developer point of view.

Nevertheless, these needs/interests provide only a limited market for of potential users nowadays, for sure, and yes the word 'tinkerers' come to mind - it is like a computer 'club' of sorts, but those who remain in it certainly get lots of advantages (and fun, tinkering, be that with system level components or the likes of portable app creations), and even those who run weedogit.sh WeeDogged bigger distros also have their place here since the flexibility and utility apps developed to benefit from that will then work for these user's chosen distros too. In fact, that could be the biggest market at the end of the day since none of these bigger distros provide much flexibility themselves (as yet anyway) in their use of live systems (most just provide minimum live system support that is just enough, and no more, to boot the distro for later full installation - WeeDog them and it becomes a different ballgame).

I hear some people deriding any non-Puppy as if somehow the result is just another boring distro, as if Puppy itself is some special case that is less-boring. Really that kind of negative propaganda is just nonsense. There is nothing particularly 'exciting' at sticking with Puppy just because it reminds the older cronies of the early 2000's when Puppy was in its heyday in the world of the lesser Damn Small Linux and Slitaz. Puppy has to keep being developed to meet the needs of the types of computer we all gradually come to own nowadays, and if its package manager isn't as good as those of other distros then users simply wouldn't bother with installing it. Cute to provide a distro with many functional apps in a tiny size (like a demo of what can be done with so little resources), but the days of anyone wanting Inkscape lite are probably over - we want Inkscape full or forget it. But, yes, the portable apps addon concept is one solution to that, which some may prefer (others may simply want reliable package management), so both methods are valid and attractive overall.

[fredx181]

@rockedge All is fine on beta7 !
(edit: well except the bad font appearance still in firefox, to find good solution would be nice)

About the autologin fix:

- Copy 'conf' (and overwrite existing) to /etc/sv/agetty-autologin-tty1/
- Copy 'run' (and overwrite existing) to /etc/sv/agetty-generic/
- Reboot (probably required, not sure though)

Although it works well, there's a small mistake because /etc/sv/agetty-generic/run is part of existing package "runit-void".
If runit-void will be updated (but won't happen soon, I think), then the fix probably won't work anymore as /etc/sv/agetty-generic/run will be overwritten.
So, in time, no hurry, better copy the "run" script to /etc/sv/agetty-autologin-tty1/ overwriting the symlink, so then looks;

Screenshot.png (16.44 KiB) Viewed 1098 times

[mikewalsh]

@wiak :-

Will:-

In general, I suspect, therefore, that the increased resource power of 'modern' machines (basically anything less than ten years old...) makes it unimportant how big the initial installation media is so the hole in the market that the likes of Puppy used to fill becomes non-existent really. Even usb sticks are huge nowadays (days of CD and DVD also all but gone).

That I can definitely confirm. Running with 32 GB of DDR4 here.....5+TB of storage.....with the 'kennels' all running nicely from a 1 TB Crucial MX500 SSD.

But Puppy / related distros still have an important part to play. Why waste that additional space? I'd rather it was available for MY use, as opposed to being swallowed up by bloated OSs that don't do anything that Puppy is capable of.

As for USB sticks, yeah. 512 GB are becoming more common these days. I have at least half-a-dozen 128 GB sticks kicking around the place myself.....and am even considering one of the afore-mentioned 512 GB sticks, since they're now cheaper than what I paid for the first 128 GB SanDisk..!

Mike.

[wiak]

Note I've changed the get_WDLskelinitrd fetch script filename (to generic 'latest') since makes it easier for me to update that and weedogit.sh (which also uses skeleton WDL initrd).

So you'll see a new fetch script named get_WDLskelinitrd_latest.sh.tar (dummy tar) at https://weedoglinux.rockedge.org/viewto ... 8cc15#p355

But NOTHING you need to do since you already have the latest (which is initrd_v504-rc2) and it's already in your KLV-Airedale beta7 release.

In future, that same get_WDLskelinitrd_latest.sh script will always download whatever becomes the 'latest' version. I'll only ever need to re-upload that script if for some reason the download links it refers to need to be changed, which usually shouldn't be the case (I hope...).

I hope the time will come soon that nothing needs changed anyway (or rarely)...!!! I feel that situation is coming soon, both for the initrd and also for KLV-Airedale overall - though main distro 'polishing' can of course go on for a long time, and addons/portable apps and so on tend to need constant updating to keep up with upstream upgrades (that's 4 ups in seven words...). Hopefully, the overall KLV-Airedale build 'recipe' will become stable soon though.

[rockedge]

@fredx181 , @wiak

I've been looking at the FIrefox - font rendering problem and found that others using Void Linux and EndeavourOS are experiencing the same font rendering issues with Firefox. Other Arch Linux variations are also effected, though not in every case.

Found in Reddit thread a possible workaround:

Either set custom default for the common font families or link /usr/share/fontconfig/conf.avail/70-no-bitmaps.conf to /etc/fonts/conf.d/. This is probably Helvetica defaulting to the bad one from xorg-fonts.

or link /usr/share/fontconfig/conf.avail/70-no-bitmaps.conf to /etc/fonts/conf.d

Code: Select all

ln -s /usr/share/fontconfig/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d/
xbps-reconfigure -f fontconfig

Screenshot_2022-03-14_10-21-08.png (29.85 KiB) Viewed 1299 times

So far I am not personally experiencing this on the test machines, but the problem seems to be with xorg default fonts

[fredx181]

Code: Select all

ln -s /usr/share/fontconfig/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d/
xbps-reconfigure -f fontconfig

Great ! that fixes the firefox font rendering, thanks.

[rockedge]

@fredx181 I'll remember adding this to the PLUG file. I've decided once KLV-Airedale is at RC1 to then finish the PLUG file that will create and build a brand new KLV-Airedale with all the features in place. So some reverse engineering to match the PLUG file functions to get the end result that is the model for the PLUG file.

I am right now compiling a custom KLV kernel 5.16.14 without AUFS. I have already run this morning a compile of 5.16.14-RE2 with AUFS patches included but I am thinking KLV doesn't need AUFS and while the CPU is warmed up go ahead and build a KLV kernel with the overlayfs built in, SMP PREEMPT, virtulization support enabled, Parallel and serial port support enabled. Improved TIMER settings.

better copy the "run" script to /etc/sv/agetty-autologin-tty1/ overwriting the symlink,

Also thanks Fred, for this tip. There might be other sections that this scenario will also occur. That a system upgrade will overwrite some specfic KLV modification. So far this has only happened once but a while ago that I forgot what it was. Maybe filemnt

So if this kernel works well there will be a beta8 running it and including the small change fredx181 recommends.

UPDATE: Running the new KLV specific kernel and so far I am really pleased with it's performance. Really smooth boot. After lunch I will put it together as the kernel and in a beta8.

[rockedge]

Beta8 is ready!

It is beta7 with the kernel 5.16.14-KLV compiled with no AUFS patches specifically made for KLV-Airedale-beta8

So far in testing the best running version yet. Shows short boot times on the limited tests I've made before it's bed time.

[mikewalsh]

@rockedge :-

Beta 8 running very smoothly here, Erik. I've switched from the Fossapup k5.4.53 kernel, just to give this new kernel a try. Even on my hardware, it seems that bit faster....

Nice one! It just keeps getting better.....

Mike.

[wiak]

I found one small limitation/error, with the current WDL initrd but only to do with SG2D booting and I'm not doing any further dev work on it at the moment since it seems otherwise stable and fine. It's actually just a tiny single-line omission for that special SG2D case, I forgot to set variable bootdev, the effect of which is that if a user tries to use RAM2 mode with SG2D but have the iso installed on a FAT32 partition, the auto-switch to RAM0 will not occur (i.e. the kernel will crash). However, the grub menu does SAY that the partition has to be Linux format for that RAM2 case to work for which case all is fine with SG2D RAM2 use anyway. Nevertheless that minor SG2D bootdev variable omission will be fixed for non-beta releases.

There is an other issue with SG2D I'm mentioned before - it is a limitation, not an error. Since if using RAM2 mode the upper_changes save persistence folder gets written to the bootfrom dir by default, which is to dir BOOTISOS in the case of SG2D, only one WDL-related distro can use that mechanism since upper_changes does not have a unique per-distro filename. However, there would be arguments for and against using a unique filename for that in practice, because if unique it becomes much more difficult to write rollback type utilities and there is no problem with upper_changes being a stable name in normal per own subdir frugal installs since the subdir is unique anyway. I have to think about that SG2D matter further - I am at the moment at least very much against complicating the initrd/init code simply for the sake of SG2D (though it could be done), which may or may not become important as a mechanism longer term. Simple (KISS) approach is generally best and more efficient overall unless there is a lot to gain or lose otherwise. Rather than expend further energy on that I'll wait and see what the future brings.

It's worth noting/understanding that an upgrade to the initrd doesn't require upgrading the rest of the distro if you have already made a frugal install you can always just fetch the new initrd. At this stage, in practice though, rockedge is building new beta isos thick and fast so includes any new initrd in that process.

[fredx181]

@rockedge Perhaps in new beta you can add the firefox font fix and (however not so important, but just nice to see correct icons for e.g. .sfs files) mime-add :
viewtopic.php?p=50387#p50387

[rockedge]

@fredx181 I thought I had the MIME modifications included, I see now that it's not working so I will re-install it in Beta8

Also the font fix will be added.

How is the boot up speeds with beta8 on your machine(s)?

[fredx181]

@fredx181 I thought I had the MIME modifications included, I see now that it's not working so I will re-install it in Beta8

Also the font fix will be added.

How is the boot up speeds with beta8 on your machine(s)?

Can't really notice a difference on beta 8 TBH, but anyway it's fast enough ! (only when booting with e.g. w_bootfrom=/mnt/sdXX/.... , I got a long delay sometimes, seems random and occurs at/after "lower_accumulated is ..." booting with UUID is fine though, so no complaint).

[rockedge]

@fredx181 I ran into the problem of the crashing Rox again when I modified beta8.
The only change was adding the packages -> mime-add-1.0_0.noarch.xbps and edit-sfs-1.0_0.noarch.xbps.

I can't be certain, but I add the packages and squashed the rootfs and tested. This showed that Rox was crashing as it did with beta2, which I think I added the same 2 packages..

I will have to go ahead and try them one by one. I have to test again by installing them on a running system and check ROx's operation. Otherwise I will have to repeat the steps adding the packages and squashing. Either way, we need to find out if one of these or both are the cause.

I returned to the previous beta8 and Rox works fine. I'll report as I know more!