KLV-Airedale-beta+ Released, Ready for Download

[fredx181]

@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!

Mmm.. one thing I can think of, edit-sfs has /root/.config/rox.sourceforge.net/... inside, perhaps try deleting that and see if that fixes it.

[wiak]

Okay, I wasn't going to yet, but thought I'd better fix the SG2D auto use RAM0 if trying to use RAM2 when not on Linux format. Very simple change that only effects anyone using SG2D and even then it is very minor difference.

So, new version WDL intird_v504-rc3 upload. Fetch it (as initrd-latest.gz) using the usual get_WDLskelinitrd_latest.sh script from https://weedoglinux.rockedge.org/viewto ... p=355#p355

[rockedge]

@wiak I'm testing them out right now in beta8.

These are the boot stanza's I'm using ->

Code: Select all

title KLV-Airedale-beta8  (LABEL)
  uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
  kernel /KLV-Airedale-beta8/vmlinuz  w_bootfrom=LABEL=psystem=/KLV-Airedale-beta8 net.ifnames=0
  initrd /KLV-Airedale-beta8/initrd.gz
  
title KLV-Airedale-beta8 (UUID)
   uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
   kernel /KLV-Airedale-beta8/vmlinuz  w_bootfrom=UUID=8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa=/KLV-Airedale-beta8 net.ifnames=0
   initrd /KLV-Airedale-beta8/initrd.gz
  
title KLV-Airedale-beta8 (/mnt/sdb1/)
  uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
  kernel /KLV-Airedale-beta8/vmlinuz w_bootfrom=/mnt/sdb1/KLV-Airedale-beta8 net.ifnames=0
  initrd /KLV-Airedale-beta8/initrd.gz

I got all 3 to boot. Method #3 took longer than #1, #2

[wiak]

title KLV-Airedale-beta8 (/mnt/sdb1/)
uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
kernel /KLV-Airedale-beta8/vmlinuz w_bootfrom=/mnt/sdb1/KLV-Airedale-beta8 net.ifnames=0
initrd /KLV-Airedale-beta8/initrd.gz[/code]

I got all 3 to boot. Method #3 took longer than #1, #2

Yes, it is interesting that last one takes longer (on some hardware, but not on normal hard disk I think). As I said I know 'why' (basically), but would likely take quite a bit extra code (basically to make it become a UUID type of boot) and not worth it I think to complicate the initrd/init for a non-recommended boot method. UUID or LABEL is preferred and recommended. However, it is good the above method does at least get there...

[wiak]

I got all 3 to boot. Method #3 took longer than #1, #2

Something seems to be wrong with that rc3 initrd. I think I had a dodgy upload, but not sure so please don't use in iso yet. I am reassembling and re-uploaded - will be v504-rc4 now. Not ready yet. Will announce once I have it and tested.

[rockedge]

@wiak All right let us know when ready. I believe I am using the "latest" from the get latest script yesterday and today I will swap in the new version right away for a beta9

[fredx181]

@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..

It's the package "mime-add", after install rox crashes, but only when trying to open a partition (and /mnt/home).
I suggest not to include mime-add until we found out what's exatly causing the crash, I have no idea atm.

[wiak]

@wiak All right let us know when ready. I believe I am using the "latest" from the get latest script yesterday and today I will swap in the new version right away for a beta9

Okay, newest v504-rc4 is now ready to fetch using the get script (will store it as initrd-latest.gz as usual now.

The exact same get_WDLskelinitrd_latest.sh will download it (NOT the kmod version - that's just for the likes of Arch Linux). If you don't have a copy of get_WDLskelinitrd_latest.sh it is here:
https://weedoglinux.rockedge.org/viewto ... 4143f#p355

Check first few lines of w_init-latest once you have fetched it to make sure you have v504-rc4

I've tested this new initrd in normal frugal install type configuration and working fine for me thus far.

I have modified the SG2D/boot_from_iso related code a bit so won't know for sure if that bit is still okay till you give me the new iso!!! (but doesn't effect the normal frugal install use); I'll test the SG2D/iso part out more thoroughly once beta9 is releases, thanks.

By the way, the reason I had a problem with previous initrd upload was that I was developing it on a usb flash stick and think I shutdown before everything was synced correctly - not sure though, but this new one should be fine (aside maybe for SG2D/iso-boot, though I'm hopeful that still working fine too...).

Also, I have a nice new trick in this one especially useful (if it works) for SG2D use; I'll explain after I've checked if it works - I won't if it doesn't...

[rockedge]

@wiak I have a beta9-TEST which is a beta8 with the rc4 initrd.gz, and it will not boot cleanly using LABEL boot stanza. It appears /upper_changes can't be created if that makes any sense. This is the very first tests on QEMU virtual machines. The ISO will not boot unless RAM2 is selected. I have not tried booting yet from the QEMU hard drive.

[wiak]

@wiak I have a beta9-TEST which is a beta8 with the rc4 initrd.gz, and it will not boot cleanly using LABEL boot stanza. It appears /upper_changes can't be created if that makes any sense. This is the very first tests on QEMU virtual machines. The ISO will not boot unless RAM2 is selected. I have not tried booting yet from the QEMU hard drive.

Did it boot cleanly with beta8 using LABEL with QEMU virtual machine? I'm surprised what I've added would make difference, but maybe it does then - in which case its best to go back to previous initrd for now. Is the beta9-TEST available for download? I haven't used QEMU for a long time, so I'll have to install that and see what I can find. Would be useful if you could give me the exact grub stanza you used so that I can try it out (and if you make the TEST beta9 downloadable somewhere that would be best). My partner's new business computer has arrived so I'll now inherit bigger machine for my own use - thank goodness - working with only a few GB hard disk spare makes juggling what's installed and what's not installed very tricky (currently not easy for me to build any iso to test...).

[wiak]

@wiak I have a beta9-TEST which is a beta8 with the rc4 initrd.gz, and it will not boot cleanly using LABEL boot stanza. It appears /upper_changes can't be created if that makes any sense. This is the very first tests on QEMU virtual machines. The ISO will not boot unless RAM2 is selected. I have not tried booting yet from the QEMU hard drive.

Okay, I've been thinking about what you say again. I doubt beta8 will be any different when it comes to booting from LABEL (but not in a RAM0 or RAM2 mode). You are talking about booting from the iso as a cdrom I presume??? Save changes to media cannot of course happen to a read-only iso file so impossible for that grub line to successfully create upper_changes. I don't think there is any error in the initrd that causes that - it is just a fact of what that grub line is asking the system to boot into. The only way it could work would be if you had also set up an img drive that could be mounted as say sda1 on boot and you had a grub line that said w_changes=/mnt/sda1, if you see what I mean (if you also wanted RAM2, you also need w_changes1=RAM2). However, the raw iso cdrom image does not try to mount sda1 on booting (why would it?); to make it do so, the initrd/init itself would need to specifically mount /dev/sda1 on any boot, and again that would be an unusual default thing to do (I don't think Pups do that).

I don't have your TEST iso, but I don't see anything wrong with the LABEL code in the WDL initrd/init, so I expect same result - you should be able to boot with LABEL as long as you are in RAM0 mode - probably even RAM2 mode, but won't work as RAM2 save2flash since upper_changes can't be loaded once again from /mnt/sda1 since that has not been mounted or arranged. In summary, booting from iso like that basically seems limited to me, unless I am missing some trick I don't know about (I haven't really used QEMU for years. To use QEMU for full weedog init facilities the best is to make a proper frugal install into an image disk - that's a different matter - all should work from there.

SG2D booting (nothing to do with QEMU per say) is a different matter - the WDL initrd/init does of course mount the partition that iso is in so can use it for save persistence.

Anyway, let me know if my understanding of what you are doing is correct, and please post both the commandline you are using to start your qemu and also the grub stanza you are talking about, and also a copy of your TEST iso would be very helpful. Thus far, I think your results are what I'd expect and not an error in other words unless you mean something different to what I'm thinking you do.

[rockedge]

@wiak the odd thing is it makes it to the auto login and on that line instead of "root" appearing it hangs a moment then the next text is the time being set then it hangs. The key is the auto login. Something is not working perhaps with the the auto login logic?
Only RAM2 mode worked. Up to this point all the of the boot options worked on QEMU including mounting sda1 if I had formatted the virtual drive before hand.

I would start the CD with RAM0 then with GParted set up the v-drive with ext3, then a regular boot with auto persistance would work perfectly. I reverted back to the RC2 initrd and all of it worked again.

Something is slightly off with the autologin and or the initrd? Hard to say since the boot makes it to the auto login and no user is selected and it jumps right to setting the timezone.

[rockedge]

@wiak , @fredx181 this time I let it hang at the autologin and I pressed enter on the keyboard and it gave me the login prompt! I logged in as root and everything works!

So something in the login logic maybe?

[fredx181]

@wiak , @fredx181 this time I let it hang at the autologin and I pressed enter on the keyboard and it gave me the login prompt! I logged in as root and everything works!

So something in the login logic maybe?

This autologin issue is only when using qemu ? So I can assume that without using qemu it's no use to try reproducing?
Could have to do with autologin depending on being on tty1, perhaps booting with qemu works different (I know very little about qemu, so just shot in the dark)
Btw, can't see why the changed autologin logic could give problems, it's such a very simple change.

EDIT: could it be that you included /etc/sv/agetty-autologin-tty1/supervise/did-autologin in your test setup ? That may explain it, as it shouldn't be there in the first place.

[fredx181]

@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..

It's the package "mime-add", after install rox crashes, but only when trying to open a partition (and /mnt/home).
I suggest not to include mime-add until we found out what's exatly causing the crash, I have no idea atm..

Found out what caused the rox crash, it occured not specially when opening a partition e.g. sda2, but any directory containing .iso or .xbps files.
New mime-add package:

mime-add-1.1_0.noarch.xbps

Fixed mime-add

(35.88 KiB) Downloaded 153 times

Made some changes for the mime setup. I tested rox with all added mime types (e.g. opening folder containing e.g. xbps), should not crash anymore after mime-add install.

[rockedge]

@fredx181 I can reproduce it on the DELL Poweredge R210 as well. If I press enter on the keyboard when it hangs by auto login it goes right to the login prompt. Once logged in all works!
Some minor thing I think, is probably behind this.

Can it be something with ./supervise/did-autologin ??

Very cool that you found what was happening with the Rox crash after the MIME package addition!
Now I can add it to the rootfs SFS.

[fredx181]

@fredx181 I can reproduce it on the DELL Poweredge R210 as well. If I press enter on the keyboard when it hangs by auto login it goes right to the login prompt. Once logged in all works!
Some minor thing I think, is probably behind this.

Can it be something with ./supervise/did-autologin ??

How you suggest I can try to reproduce this ? (without qemu) I tested with w_bootfrom=LABEL=.. already on beta8 with newest initrd from wiak, but for me no such problem...

[rockedge]

@fredx181 , @wiak

I found a copy of /etc/sv/agetty-autologin-tty1 saved in /upper_changes so to try it out I deleted it from /upper_changes and it booted right into root again automatically.

I will test this out some more to pinpoint it.

The MIME package made Rox look much nicer as does Thunar!

UPDATE: I can not make much rhyme or reason out of why this is happening. It seems that the root user is not being placed at the prompt during the auto login

UPDATE-2: Narrowed down to /upper_changes/etc/sv/agetty-autologin-tty1/conf is being somehow written which is different than the rootfs version and overrides the autologin from the rootfs SFS.

It should look like this:

Code: Select all

if [ -x /sbin/agetty -o -x /bin/agetty ]; then
	# util-linux specific settings
	if [ "${tty}" = "tty1" ]; then
		GETTY_ARGS="--autologin root --noclear"
	fi
fi

BAUD_RATE=38400
TERM_NAME=linux

but is overwritten by a copy in /upper_changes that looks like this a:

Code: Select all

if [ -x /sbin/agetty -o -x /bin/agetty ]; then
	# util-linux specific settings
	if [ "${tty}" = "tty1" ]; then
		GETTY_ARGS="--noclear"
	fi
fi

BAUD_RATE=38400
TERM_NAME=linux

Removing /upper_changes/etc/sv/agetty-autologin-tty1 the boot sequence returns to normal.

_

[rockedge]

Another update, I have tried several things now but none seem to be really the fix.

Is anyone else experiencing this missing auto login strangeness?

I've been messing with this all day long since it started happening. Suddenly this popped up on another machine as well but with another version. Really strange.

Could it be because the beta9 in question is on a USB hard drive /mnt/sdb1 ?

I moved an exact copy to a frugal install on the internal HDD /mnt/sda1 and it is working normally.

[wiak]

Another update, I have tried several things now but none seem to be really the fix.

Is anyone else experiencing this missing auto login strangeness?

@rockedgeLike I said I don't have space on my computer to build an iso at present so I was hoping you'd put your beta9 up for download so I can test. Also, need to know if you are experiencing problems only with QEMU boot and if so exact details of how your QEMU is configured and setup and booted.

Like Fred, I have only a little experience with using QEMU in recent years, but main thing is I have no beta9 iso to test sorry.

Seems so unlikely it could be anything to do with the initrd anyway since you are already past that point when login is involved; i.e. switch_root to main filesystem is last thing initrd does and clearly it has done that.

Also it remains unclear to me if you have same problems with beta8 or just your new beta9?

[rockedge]

@wiak I'm not testing on QEMU at the moment. I am working on a physical machine.
It has an internal HDD and an external USB HDD.

I am not seeing it as much on internal drive as the USB HDD.

Beta8 is doing the same thing intermittently . That's what makes it weird. Maybe the USB HDD is having a problem?

All set to download and test. Has the latest initrd.gz and the MIME package as well.

[wiak]

All set to download and test. Has the latest initrd.gz and the MIME package as well.

Em... I used modify_initrd.sh and checked the init in that beta9 after downloading it, but seems to be the old -rc2 whereas the latest initrd contains init -rc4
Anyway, I tried booting it (installed on my /dev/sdb2 usb stick) but it didn't boot... stuck at:

void-live login: No network connection yet...

Going to try the previous iso (beta8), which I still have, in same configuration. If it works, I'll then try latest initrd with it.
EDIT: booted into root desktop OK. This also has WDL initrd 504-rc2 (there is no rc3 for various reasons, went straight to rc4 when made latest upload). I'll try rebooting a few times to see if it sticks at all on my old HP Elitebook 2530p laptop (again, as installed on /dev/sdb2 usb stick). Then, all going well, I'll substitute in the latest rc4 initrd and report back to this post; this all being done using beta8 though.

[fredx181]

@rockedge Tested beta9 iso, before trying to boot I replaced initrd.gz and w_init with rc4 version.
It booted fine to the Desktop, so autologin works for me, but not logging in as spot, same issue as before.
So looked at /etc/sv/agetty-autologin-tty1/conf and noticed that GETTY_ARGS= is wrong, should be without --autologin root : so GETTY_ARGS="--noclear" (--autologin root is already in the 'run' script, makes autologin run only once, which the fix is all about)
After changing that, I could login as spot, then all seems to be fine for me.
My grub2 stanza (on sdb2 ext4 label 'aire'):

Code: Select all

menuentry "KLV-Airedale-beta4 label w_bootfrom AIREDALE" {
insmod part_msdos
insmod ext2
set root=(hd0,2)
	linux /AIREDALE/vmlinuz w_bootfrom=LABEL=aire=/AIREDALE net.ifnames=0
	initrd /AIREDALE/initrd.gz
}

Tell me if I can do more testing, I'm not sure if I understand what's the problem for you exactly.
EDIT: Ah... now I see, can reproduce now, after rebooting with the change made above, autologin doesn't work.
Noticed that ./supervise/did-autologin is not created.
Weird.. it worked before, no idea yet how to fix.

[wiak]

My real problem remains that I want to test beta9 iso with initrd rc4 (not rc2 as it is just now), but I don't have space to make the iso... Tomorrow I'll try and get time on my partners larger laptop (which has space on it) - I tend not to do dev work on that since the business machine... but I'll try and be careful.
By the way, is it a hybrid iso, and what dd line to write it - I hardly do that and don't want to get the command wrong...

I was trying (using beta8):

Code: Select all

dd KLV-Airedale-beta8.iso of=/dev/sdb bs=1M

but didn't think about booting from the usb stick thereafter (grub didn't start up).
For some reason, my old HP elitebook 2530p just kept reading from the usb stick (usb light flashing) - I couldn't even ESC into BIOS (so that wasn't a test of anything relevant, but an issue with the dd command or something wrong what was written to the usb stick I suppose). I suppose I 'could' write an actual DVD (this old machine has a DVD R/W drive, but first I have to find a writable DVD disc...).

[fredx181]

@wiak I don't think the issue has to do with ISO, it's about the autologin fix that's recently added, which has a problem, see btw also my EDIT in previous post.

[wiak]

@wiak I don't think the issue has to do with ISO, it's about the autologin fix that's recently added, which has a problem, see btw also my EDIT in previous post.

I'll leave you two to it for that. Playing with qemu now, thanks for the tip about formatting the raw img /dev/sda1 to ext Linux format rockedge (I forgot about doing that - daft of me), so yes beta9 booted for me to root desktop in that, but I'll leave any other issues about autologin to yourselves since I've not been working on that bit at all.

I do wish I had a beta9 iso with initrd rc4 in it though because I'm wanting to test with SG2D to see if my new idea worked or not (never been tested). But, tomorrow, I'll make myself a beta9 iso with rc4 init in it if new beta with rc4 and whatever autologin fix not uploaded before then.

Personally, I think it is risky using a new kernel during main distro development. Best to keep using a kernel established as not producing any issue: timing issues/ race-conditions - when things that used to work go weird I'd always worry about that. Once distro proved stable with stable kernel then its ok to try alternative kernels.

If I was you, I'd stick with the kernel used in the alphas for now (ozsouth kernel?)

[rockedge]

@wiak I did take out rc4 but that wasn't the problem! I'll spin out a beta9 with oz kernel and rc4 again.

ALL SET! I just uploaded beta9 with the oz kernel and the RC4 initrd.gz

UPDATE: First runs are showing KLV is booting smoothly again!
Tested on physical and virtual machines

[wiak]

If that doesn't fix it, and you are sure the autologin code is correct, then I'd resort to going back to a plugin build. I presume you've been gradually adding to existing builds to produce the new isos, but I feel that becomes risky over time. I base that comment on experience I have with WDL_Arch64 - for a long time it is fine, but if I leave it too long to upgrade then some packages can end up upgraded and some not and I've ended up having strange side-effects where some key parts of the system (or packages) stop working, probably glibc-related or other incompatibilities with newer libs and older packages still there. In these cases, making a brand new plugin build always fixed the issues (without me ever determining what caused the issues). I'm just worried you will run into that problem if not building new iso from scratch with latest of everything all part of the new build by default. It may be nothing to do with that, but I do wonder. My qemu test of that newest beta9 seems to work (with LABEL and RAM2) most of the time, but sometimes freezes just as login message appears... Too late to test it further here.

Today my fast fiber broadband cable was installed and then connected, so at least it no longer is a huge bore waiting to download new iso - I still have no hard disc space left on this machine though, but one step at a time... Actually beta9 seems to be booting (in qemu) if I leave it long enough - I'm not sure yet.

[rockedge]

@wiak I am also aware of the overall upgrades that could cause some mismatch problems.

The PLUG file is not ready enough to fill in yet! But I can go back to a beta that is okay and unsquash the rootfs and start from there again.

This is the first time this boot hangup problem has appeared where the autologin lags. So far testing the beta9 looks like it's back to normal on my end. RC4 is performing as expected and the oz kernel is proven to work as is 5.4.70-rt40. Usually it's the firmware SFS that's the cause of problems.

The "full install" method is working well to generate SFS and ISO's quickly and accurately and is easy to do full upgrades.

Right now beta9 is working well.

[rockedge]

Beta10 is ready to download and test.

Latest system upgrades included as well as the beta9 features. Will continue to catch up with the PLUG file.

Update: seems to be working well with the limited testing so far......