Puppy Linux Discussion Forum

Sofiya wrote: Sun Mar 19, 2023 1:06 am

When I type 'root' for the password, it prints 'r' and returns to the Void login prompt. I have to press the power button, turn off and restart the computer.

also if you just click on reboot, the reboot starts, but it doesn’t reach the window with the choice to save or not, it just reboots

Reinstalled twice, same result

Well that was exactly what I experienced. It seems to be working on all my machines now, and what seems to be the difference is when I transfer a set of numbered upper changes to a new system, it's necessary to shutdown and reboot, maybe twice for good measure and then the logins seem to work. However I'm not using "save2flash" setup. I'm writing directly to the drive.

@Sofiya I saw the same thing on a QEMU VM and it seemed it was a stray upper_changes that caused it but now I am not sure. @geo_c I think experienced the same incident.

We'll have to look at what is going on.

rockedge wrote: Sun Mar 19, 2023 1:18 am

@Sofiya I saw the same thing on a QEMU VM and it seemed it was a stray upper_changes that caused it but now I am not sure. @geo_c I think experienced the same incident.

We'll have to look at what is going on.

I spoke too soon about all my systems logging back in correctly now, not true, I accidentally logged out and got the same result of an "r" in the password field again upon loggin back in. Had to shutdown with the powerbutton.

I am testing but have not replicated the "r" login problem again to try to track down the cause. This or a similar problem was in an earlier version which was a problem in the tty autologin but this was fixed. I don't remember the exact details but will keep on looking for the reason.

rockedge wrote: Sun Mar 19, 2023 6:34 pm

I am testing but have not replicated the "r" login problem again to try to track down the cause. This or a similar problem was in an earlier version which was a problem in the tty autologin but this was fixed. I don't remember the exact details but will keep on looking for the reason.

Strange, I cannot replicate this login problem too (on rc13), I know also that it was an issue a while back but can't remember what exactly caused it. (or what did fix it)

@fredx181 I finally found a way to replicate a login/logout problem by booting into RAM2 mode.

This seems to be related to being booted in RAM2 mode. On QEMU the logout goes smooth but login is wonky. I finally got it to go then I ran save2flash manually and logged out. The login worked but the very next logout the problem had returned.

When booted normally with direct save on a QEMU VM login/logout work normally.

rockedge wrote: Sun Mar 19, 2023 9:31 pm

@fredx181 I finally found a way to replicate a login/logout problem by booting into RAM2 mode.

This seems to be related to being booted in RAM2 mode. On QEMU the logout goes smooth but login is wonky. I finally got it to go then I ran save2flash manually and logged out. The login worked but the very next logout the problem had returned.

When booted normally with direct save on a QEMU VM login/logout work normally.

I'm not booting in RAM2 mode, but I am transferring my numbered upper_changes from usb to hard drive, which normally works fine. Now it works for a few times, but then suddenly gives me the r error.

Also, I had an install booting normally on my studio laptop, and when I booted it today I got an Xfce polkit error, however on reboot, no such error, and appears to be working OKAY.

So I think something is funny, just no clue about it though.

geo_c wrote: Mon Mar 20, 2023 12:38 am

I'm not booting in RAM2 mode, but I am transferring my numbered upper_changes from usb to hard drive, which normally works fine. Now it works for a few times, but then suddenly gives me the r error.

Also, I had an install booting normally on my studio laptop, and when I booted it today I got an Xfce polkit error, however on reboot, no such error, and appears to be working OKAY.

So I think something is funny, just no clue about it though.

To be frank, it will be far too complicated to debug anything when also involving moving of whole load of upper_changes rollbacks. If there is any issue with save2flash then that issue could have effected any rollback changes file earlier.

You need to find a way of causing the error for a simple repeatable case.

First try to see if error (login error) is possible when only using direct saves to upper_changes. If not, then try RAM2 mode to see if something to do with that in which case save2flash becomes likely issue since w_changes=RAM2 simply causes the external upper_changes to be mounted to RAM; it is the writing back via save2flash that needs to be carefully looked into I'd think.

Having said that, it would seem odd if save2flash was effecting login but not effecting anything else. Autologin a systemd-related 'trick'.

My feeling is that something has changed since a system update that is affecting our autologin/login/logout mechanism. The dangling "r" is similar to what was happening before the routines were modified to allow an automatic login BUT also then allow logging out and logging in as another user and back again.

I think within that mechanism something is amiss.......

@fredx181 might be able to help to sort it out. @geo_c I also noticed this "r" first time when using a previous upper_changes which until this point caused no problems being transferred from one version to the next.

Big question is....does this occur in the stock rc13 or an even further updated/upgraded version?

UPDATE: There might have been a system update that changed out one of the modified scripts that handle the logout/login

rockedge wrote: Mon Mar 20, 2023 1:16 pm

Big question is....does this occur in the stock rc13 or an even further updated/upgraded version?

I ran void Xbps system update on all my installs, and I was beginning to feel that perhaps it has something to do with it. I can't tell you what all was updated, as it was quite a bit since the origingal RC13 update.

From quick investigating:
Indeed the login problem appears after system upgrade, package runit-void installs /etc/sv/agetty-tty1 which conflicts in some way with the custom autologin setup (/etc/sv/agetty-autologin-tty1)
Not much tested yet, but I think workaround is deleting /etc/sv/agetty-tty1 after system upgrade and then after reboot with save it should be OK (then /etc/sv/agetty-autologin-tty1 is the default runit on tty1 again).

Thinking about it how to prevent this from happening when doing a system upgrade, not sure if possible

@fredx181 I just found it also!

Yes the fix is to delete or rename /etc/sv/agetty-tty1. There already is the original /etc/sv/no-agetty-tty1 still there from the original construction which can be deleted as well.

I remembered that we went through this already with one other update a while ago where we discovered a runit-void upgrade will write the file again. Also at that time we found that it conflicted with the autologin-tty and removing it was a solid fix.

rockedge wrote: Mon Mar 20, 2023 9:17 pm

@fredx181 I just found it also!

Yes the fix is to delete or rename /etc/sv/agetty-tty1. There already is the original /etc/sv/no-agetty-tty1 still there from the original construction which can be deleted as well.

I remembered that we went through this already with one other update a while ago where we discovered a runit-void upgrade will write the file again.

Temporary fix, yes, but not "upgrade proof".

No it's not that stable at all!! maybe a script at shutdown after a full system update to check for agetty-tty1

@geo_c definitely go into the directory /etc/sv and DELETE both /etc/sv/agetty-tty1 and /etc/sv/no-agetty-tty1
Then Reboot immediately

That will fix the logout login problem!!!!

I am repackaging KLV-Airedale-rc13 with the system upgrade of runit-void completed and the agetty-tty1 is removed.

IMPORTANT : Make sure there is no agetty-tty1 in any upper_changes

I've just up and in a hurry so not following discussion clearly. However, maybe following mechanism helpful?

https://docs.voidlinux.org/config/services/index.html

To prevent a service from starting at boot while allowing runit to manage it, create a file named down in its service directory:

# touch /etc/sv/<service>/down
The down file mechanism also makes it possible to disable services that are enabled by default, such as the agetty(8) services for ttys 1 to 6. This way, package updates which affect these services (in this case, the runit-void package) won't re-enable them.

@wiak that makes total sense. Good catch on this one. It would seem just having a standing down order for agetty-tty1 would be the long term fix and update/upgrade proof.

UPDATE : touch /etc/sv/agetty-tty1/down looks like it works nicely. Shouldn't forget to actually utilize runit capabilities.

I have already added the fix to a new rc13 ISO and it's uploaded with a new hash file.

rockedge wrote: Mon Mar 20, 2023 9:30 pm

@geo_c definitely go into the directory /etc/sv and DELETE both /etc/sv/agetty-tty1 and /etc/sv/no-agetty-tty1
Then Reboot immediately

That will fix the logout login problem!!!!

I am repackaging KLV-Airedale-rc13 with the system upgrade of runit-void completed and the agetty-tty1 is removed.

IMPORTANT : Make sure there is no agetty-tty1 in any upper_changes

Checked all the upper_changes folders.

Indeed when I updated Void before copying RC13 into the system directory then booted into fossapup and renamed upper_changes to 33upper_changes-DPi7-RC12to13, a bunch of tty stuff appeared in /etc/sv. There are none in my current upper_changes, 33 being the last numbered folder.

I take it I just delete the /etc/sv/agetty-tty1 and /etc/sv/no-agetty-tty1, and then reboot. Can I do that from fossapup which I'm running in now? Seems like that should be just as good.

@geo_c deleting the agetty-tty1 and no-agetty-tty1 is an okay fix. And make sure there are none in any of the upper_changes Or use the official fix which is to create an empty file called /down in the agetty-tty1 directory called /etc/sv/agetty-tty1/down.

This is the official Void Linux method using the runit service manager to insure that agetty-tty1 remains disabled from boot to boot., which prevents the conflict with service agetty-autologin-tty1 during the logout/login cycle.

Thanks @wiak and @rockedge .

@geo_c Creating a file "down" in /etc/sv/agetty-tty1 is the fix for the long term, deleting /etc/sv/agetty-tty1 is not because then at the next upgrade of runit-void you'll get the same login problem.
If you already deleted the /etc/sv/agetty-tty1 folder, better re-create it again and create the file "down" inside.
mkdir -p /etc/sv/agetty-tty1; touch /etc/sv/agetty-tty1/down
At next runit-void upgrade the down file is there, so the agetty-tty1 service stays disabled (as it should be in this setup), and agetty-autologin-tty1 has priority.

fredx181 wrote: Tue Mar 21, 2023 9:09 am

Thanks @wiak
and @rockedge (but small correction, the file should be called down, not download) .

@geo_c Creating a file "down" in /etc/sv/agetty-tty1 is the fix for the long term, deleting /etc/sv/agetty-tty1 is not because then at the next upgrade of runit-void you'll get the same login problem.
If you already deleted the /etc/sv/agetty-tty1 folder, better re-create it again and create the file "down" inside.
mkdir -p /etc/sv/agetty-tty1; touch /etc/sv/agetty-tty1/down
At next runit-void upgrade the down file is there, so the agetty-tty1 service stays disabled (as it should be in this setup), and agetty-autologin-tty1 has priority.

I'll do that.

I didn't do anything last night because I suddenly became exhausted and buggy. Also there was no 'no-agetty-tty1' and I noticed the difference between 'down' and 'download' that @rockedge and @wiak mentioned, so I just went to bed.

That's an easy permanent fix it seems.

@fredx181 @geo_c putting "download' instead of "down" is my mistake. Was tired and watching a basketball game late and it was a bug and typo about to happen.

I fixed it in the post! and is now correct with touch /etc/sv/agetty-tty1/down creating the "down" file in /etc/sv/agetty-tty1

In the repackaged rc13 ISO which has been uploaded, the upgrade produced /etc/sv/agetty-tty1 is present and has the down file in place.

How was that song from the Beatles, "How can you laugh when you know I'm download'"

Or that Janis Joplin favorite......."Download On Me"

'down' worked wonders, all 6 installs of KLV-airedale re-logging in successfully.

@rockedge @fredx181
Of course we can't over look this scorching live footage of Freddie King's "Goin' Download'

@rockedge @fredx181 Thanks for the fix, it's working great.

@Sofiya It was @wiak that helped put us on the right track reminding us to look at using runnit commands.

@wiak Thank you for your help in troubleshooting this issue.
for the fix, it's working great.

The luxury of void updates!

I got an Xfe filemanager upgrade to 1.45. Wasn't expecting that.

Interersting,

I just booted and apparently Rox jumped in and took over the pinboard. I rebooted and it went back to normal.

@rockedge I think you mentioned this somewhere else.

Actually I'm not sure how all that works. I have Rox pinboard enabled, and it seems like that would conflict with Xfce.