KLV-Airedale-beta+ Released, Ready for Download

[geo_c]

. RC4 is performing as expected and the oz kernel is proven to work as is 5.4.70-rt40.

Interesting, that's the kernel @puddlemoon used for jackalpup0.0. Which I'm posting from at the moment.

I'll eventually be trying out some audio applications and see how those work.

[fredx181]

@rockedge
Re: Autologin issue: Did some experimenting and finally followed the advice from the reddit post about this:

Make sure you

ln -s /run/runit/supervise.agetty-autologin-tty1 supervise

(should have followed that in the first place)

So instead of (from inside /etc/sv/agetty-autologin-tty1):
supervise -> /run/runit/supervise.agetty-tty1
it should be:
supervise -> /run/runit/supervise.agetty-autologin-tty1
Which makes this runit service sort of "self-containing", I think that's the solution and from my tests it works well.
Here's the agetty-autologin-tty1 folder with fix as tar.gz, extract and replace in /etc/sv (most important is to replace with the supervise symlink to /run/runit/supervise.agetty-autologin-tty1).

agetty-autologin-tty1.tar.gz

(591 Bytes) Downloaded 138 times

Why it worked for me earlier may be because I tested back then on a fast SSD harddisk.
So it could be a timing issue, the previous autologin logic didn't work mostly (but sometimes it did) when booting from a slow USB stick (but now tested on that and should be ok with new setup).

[rockedge]

that's the kernel @puddlemoon used for jackalpup0.0. Which I'm posting from at the moment.

I know, I compiled the 5.4.70-rt40 full real time kernel. I made it for working with software synths, sequencers, audio recording and CNC machinery and 3d printing on Puppy Linux OS's

https://rockedge.org/kernels/

or direct links ->
huge-5.4.70-rt40-fossapup64.tar.bz2
fdrv-5.4.70-rt40-fossapup64.sfs

[rockedge]

@fredx181
Thanks so much for the help finding that fix! You are a genius of the quick diagnosis.

New UPDATE of beta10 can be downloaded!

So far it working well on the physical and virtual machines I am testing beta10 on.

Download links in first post and in the usual place.

[wiak]

So it could be a timing issue, the previous autologin logic didn't work mostly (but sometimes it did) when booting from a slow USB stick (but now tested on that and should be ok with new setup).

Yes, I'm been trying in qemu now, and that new 'fix' seems to work (I was careful to first clear the /mnt/sda1/WDL-live/upper_changes in my img1.raw file I used with qemu to make sure was pristine). In fact, I can see the timing issue occurring - the autologin service fails on the first attempt, but after that new fix is applied I see it trying again until it succeeds and then the boot completes successfully.

[rockedge]

I am having trouble logging out as root and also when I type fast enough (the login prompt is looping on it's own) to get back in. Basically it looks like logging out as root and trying to login to spot is broken

[fredx181]

I am having trouble logging out as root and also when I type fast enough (the login prompt is looping on it's own) to get back in. Basically it looks like logging out as root and trying to login to spot is broken

Yes, same for me, thought my keyboard was broken, WTF ! Typing e.g. whoami gives: woami: command not found.
Sorry, should have tested better, I think the new addition of the supervise symlink causes that somehow, I'll keep searching for a true fix, but don't have much faith in it TBH.

[wiak]

On another matter (/boot/grub/menu.lst):

Code: Select all

 title KLV-Airedale-beta10 (LABEL, RAM2)
 kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=RAM2 net.ifnames=0
 initrd /initrd.gz

That won't work for RAM2 booting from an iso since would try and mkdir upper_changes on readonly /mnt/sr0. I think the following should work though (I'll test this in a short while):

Code: Select all

 title KLV-Airedale-beta10 (LABEL, RAM2)
 kernel /vmlinuz w_bootfrom=LABEL=KLV-Airedale=/ w_changes=/mnt/sda1/WDL-live w_changes1=RAM2 net.ifnames=0
 initrd /initrd.gz

EDIT: Yes... that second one worked (I rebuilt my test iso with that change) - using qemu and save2flash worked back to /mnt/sda1/WDL-live/upper_changes (which correctly mounted to /mny/layers/uc_ro)
So that is one success at least!

[wiak]

Odd with previous auto-login agetty method though... I found no problem with qemu boot in RAM0 mode, but whenever external (being raw img /dev/sda1) upper_changes was used (be that as mounted to overlay top layer, or as mount --bind to /mnt/layers/uc_ro then the login hung (always saying what my Timezone is as last message in console). I'm busy checking out w_init for the case of w_changes=/mnt/sda1/WDL-live w_changes1=RAM2, but thus far I haven't come up with anything unexpected in debug messages through that part of the boot, but hard to check since keep having to add more debug statements and rebuild iso prior to qemu boot. Question in my brain is: why involving external upper_changes has effect on that autologin failure? Very hard to work out what is going on.

[rockedge]

@wiak That is really good news. And the stanza makes a lot of sense as I looked at it.

I will add this to the ISO and for now revert to the original autologin / logout methods until we can find out a better method.

The autologin problem seems tricky to pinpoint exactly. It just started to happen.

[wiak]

Too late here now for me to double-check or even say exactly what I've done, but I put the autologin etc/sv stuff back to how it was in beta8 and beta9, which resulted in the freeze during boot attempt into RAM2 mode on qemu. But now I've modified part of w_init and something I just did got it to boot in that RAM2 LABEL mode, which never worked all evening prior. Maybe just luck, but I am hopeful. If so then the problem is not autoboot at all, but a timing issue. I will know if I've solved the issue tomorrow after I've slept - I hope so, but definitely a tricky one this... looking hopeful though - boots ok every time I try in qemu now. However, I'm not using usb stick, so have to double-check on that now (so, yes, maybe fails then - we'll see).

You will have a long wait till I report back though. Maybe ten or twelve hours from now.
EDIT: Sorry, CANCEL ABOVE... Just froze again - must have just been momentary luck... My goodness - I have no idea. Really does look like it is indeed autologin issue - weird one though - trying to think how to debug this further??? Don't myself no much about autologin - though I've used similar agetty autolog lines prior in WDL_Arch with systemd (was fine but maybe a bit different) - problem is, if it doesn't work, it doesn't work - what to do...??? How about a login manager? But why do I find it working in RAM0 mode on this qemu set up I'm trying, but not RAM2 with uc_ro involved? Doesn't actually make any sense to me - the uc_ro stuff seems fine in all my debug checks thus far and can't see the relationship to autologin anyway... OH, RAM0 didn't work just now either, unless I hit wrong selection - I'd be happy to know it didn't work sometimes either - working from RAM only would introduce less time lag of course so makes sense in that way that RAM0 has a better chance...

[rockedge]

I feel the path to redemption begins with elogind. So I have begun to dig into this feature as it seems to be the way to manage user login logout.....I think.......

Some experiments with login managers I feel are needed.

[fredx181]

Re: Autologin / Login problem: I have a theory (no..no.. not saying I'm sure ):
From the beginning of using agetty-autologin-tty1 I think that there was (and still is on beta10) interference with the agetty-tty1 service (also controlling tty1), so I tried removing it and the problem seems to be fixed.
To test you can remove it from the running system (I tested on beta10) but NOT while at tty1. So logout to console (on tty1), go to tty2, login and startx, and from terminal:
rm /etc/runit/runsvdir/default/agetty-tty1 (will remove the service completely).
Then best to reboot I guess, with changes saved and see how it goes (for me went well, autologin works, login as spot works and no weird change of what I type at console).
So, just not including the agetty-tty1 service in the rootfs could be the solution (then, in fact agetty-tty1 is replaced by agetty-autologin-tty1).

Downside of this could well be that an update of the "runit-void" package will enable the agetty-tty1 service again (and.. back in trouble ).
So yes, perhaps best to install a simple display-manager, "nodm' maybe ?

[rockedge]

@fredx181 I've been trying things out for hours and hours now with not much success. I started to try to install login manager but I didn't get one running yet.

I installed nodm but couldn't get it going so investigating how when I noticed that the nodm is no longer maintained.

Let me test out what you found out and also see if I can get a login manager working. I have another forum software update that just was released to fix something that they broke in the last upgrade.

I'll do that tonight since it take hours to upload the new replacement code

[fredx181]

Take it easy Erik !! There's time !

[rockedge]

I'll do the update later on.

I am putting together a beta10 with the initrd-rc4.gz and removed /etc/sv/agetty-tty1 and squashing the rootfs for a test

UPDATE: seems to work @fredx181 and so far is logging in and out nicely. Also booted smoothly. I must try the boot more. This is what was strange to begin with.

[mikewalsh]

@rockedge :-

I agree with Fred. Fer chrissakes, kick back for a while, man! Take some time out, and recharge the old batteries for a bit....

There is such a thing as getting too close to the problem; "you can't see the wood for the trees", y'know? I often find with apparently insoluble problems that when taking a break things seem to sort themselves out in the old noggin.....as if by magic.

It's good advice..!

You have nowt to prove.....to anybody.

Mike.

[rockedge]

I am burning off nervous energy...I have the Bayern Munich vs Union Berlin game on one screen and UCONN vs Mercer in tournament basketball on another...both are winning but does help to study this nagging problem.

KLV-Airedale is running really well with the 3 kernels I've tried out recently and really it's the only the autologin and some other xorg errors when changing from tty1 to tty2 and back again, that is a problem.

Minor stuff really...just really perplexing

[rockedge]

Beta10 Repackaged with autologin fix and kernel 5.16.14-KLV READY for Download

@fredx181's autologin fix and @wiak's improved boot stanza for RAM2 mode from the ISO boot in QEMU

EDIT1: KLV is running very well and is quite responsive. Removing the conflicting agetty-tty1 seems to be the fix. I am now experimenting with the beta10 and the 5.15.12-oz kernel together. I see a modprobe error that the overlayfs module can't be found when using 5.16.14-KLV which has overylayfs built in.

I have not seen any negative side effects using the KLV kernel

@wiak I tried out an experiment: first started KLV and used normal persistance and the upper_changes is created. Then I booted the same install with RAM2 using the boot stanza you added the modifications too. But it is not only saving on a save2flash run, but looks like it is running like a normal /upper_changes persistence mode

[wiak]

Beta10 Repackaged with autologin fix and kernel 5.16.14-KLV READY for Download

@fredx181's autologin fix and @wiak's improved boot stanza for RAM2 mode from the ISO boot in QEMU

EDIT1: KLV is running very well and is quite responsive. Removing the conflicting agetty-tty1 seems to be the fix. I am now experimenting with the beta10 and the 5.15.12-oz kernel together. I see a modprobe error that the overlayfs module can't be found when using 5.16.14-KLV which has overylayfs built in.

I have not seen any negative side effects using the KLV kernel

@wiak I tried out an experiment: first started KLV and used normal persistance and the upper_changes is created. Then I booted the same install with RAM2 using the boot stanza you added the modifications too. But it is not only saving on a save2flash run, but looks like it is running like a normal /upper_changes persistence mode

New beta10 booting fine for me also on my old laptop under qemu.

Will have a closer look now at the RAM2 operation in terms of running under qemu today rockedge. Odd that you found it running like a normal upper_changes persistence mode in addition to what it is supposed to do with save2flash - pretty complicated debugging iso boots as you know - getting closer anyway.

[rockedge]

@wiak It's a monster relief that the boot sequence flow is better now and the hiccup at the autologin solved (for now). The initrd-RC4.gz looks good with 5.16.14-KLV

Beta10 is performing nicely as a VirtualBox machine. Thunar detects the SAMBA shares across the network as well as when on a physical machine

[wiak]

But it is not only saving on a save2flash run, but looks like it is running like a normal /upper_changes persistence mode

Confirmed. Isn't the save2flash dialog supposed to pop-up on reboot/shutdown when in RAM2 mode; didn't see it. Maybe nothing to do with initrd (though I'll try and check) but rather save2flash automatically saving without being asked?

EDIT: yes, I think it must be save2flash issue. I'm in RAM2 mode on qemu boot at the moment and, from directory root, did terminal command: touch mynewfile
I then checked /mnt/layers/RAM/upper_changes/root and mynewfile was correctly in there.
I then checked /mnt/sda1/WDL-live/upper_changes/root and the file was not in there, so that is all correct from RAM2 initrd/init working point of view. The initrd/init knows nothing about shutting down of course so is not involved at that stage - only save2flash could write back mynewfile to WDL-live/upper_changes, which is what seems to be happening, so we need save2flash debugged under that boot from iso mode.

[rockedge]

save2flash automatically saving without being asked?

It very well might be. It is a possibility. I did not see a shutdown/reboot prompt either and a small stop in the shutdown flow that could be a write to /upper_changes.

Also have a QEMU machine going

[wiak]

Ah, wait a minute, I did not see the shutdown checkbox about save session. I'll try again to see if works if that box unchecked.

[rockedge]

I just tried that, it did not work for me

[wiak]

Ah, wait a minute, I did not see the shutdown checkbox about save session. I'll try again to see if works if that box unchecked.

No... it is still being save back to upper_changes, so something wrong with save2flash I think. At least it shouldn't be active at that time when you don't want it.

[rockedge]

I wonder what is happening to be able to trigger a save. It is happening I'm pretty sure the pause I am seeing at reboot/shutdown is save2flash writing

[wiak]

I wonder what is happening to be able to trigger a save. It is happening I'm pretty sure the pause I am seeing at reboot/shutdown is save2flash writing

I don't know xfce4 logout procedure or what script is being used to trigger save2flash. I'm currently leaving the machine searching for all files containing word 'save2flash' ...brute force method... Most likely an easy fix (unlike that autologin stuff). snapmergepuppy does the final merge, just don't know where it is being triggered.

[wiak]

Ah... I think it is because save2flash script isn't taking into account w_changes1=RAM2 possibility, only has w_changes=RAM2 as far as I see. I thought @fredx181 said he had adapted the script to also work with w_changes1, which is necessary for when using alternative upper_changes location as we in fact need for iso use.

No, he does account for w_changes1=RAM2 in save2flash (looking at script now). Trying to see what is going on... Why is save2flash yad pop-up not occurring??? or is snapmergepuppy being called and bypassing save2flash (like I say I don't know what calls save2flash). Or is it something else (mysterious) altogether... seems unlikely (I am suspecting something to do with that logout restart/shutdown checkbox about save session or not - maybe staying active?).

[rockedge]

@wiak I played around with the session save checkbox in the early alpha phase and I remember it did something unexpected but I don;t remember the details. I will have to play around with it.

I will also look at the save2flash and see if we can track down the mechanism.