rebeccablackos
rebeccablackos copied to clipboard
n3rdopolis
Request for 32 bit iso of latest version, and future versions please?
I tired, it's been a while since I tried the 32 bit ISOs admittedly. Lots of issues recently show up in 32 bit now, that don't show up in the 64 bit builds here and there, even though I build with the same scripts (except for a few packages that require different build flags), and at the exact same commits
Right now it seems everything builds. except for Qt6, which while currently Qt6 is only there in a demo capability, since everything else Qt is Qt 5...
Good to hear it :) Can I give it a try? Will report any bugs if you like?
I just got Qt 6 to build, Although these new ISOs won't be build with Commit 7856 completely, since the fix for it is in Commit 7863, but I should have an ISO for you soon
EDIT: Dang that was the 64 bit one. I opened https://bugreports.qt.io/browse/QTBUG-109476
The issues that I remember that still remain is this one https://bugreports.qt.io/browse/QTBUG-78652 . And still not fixed. The Qt folks closed it, I guess because it's fixed in Qt 6, but nothing KDE builds against Qt6 yet, and KDE still uses 5.15
Although I might try to report it against that KDE branch that maintains Qt 5.15
Interesting! Does the animated adwaita 'watch' cursor also cause the segfault, I wonder?
The smaller ISO will be available in ~35 minutes here, https://sourceforge.net/projects/rebeccablackos/files/2022-12-12/32bit/ with the upload speed
in the future, the next pushed versions the 32 bit and the 64 bit ISOs will be associated with the same tag again
Thanks :) Started downloading the 2.7 gb iso, is there a smaller one coming?
Thanks, had fun playing with it. Install failed at dpkg-configure openssh-server but got it working i.e. installed grub using debian netinst rescue mode. Have had a quick look at each desktop offered. Which of the environments is most stable / least experimental? Found myself preferring the fullscreen terminal desktop version. Gnome and KDE seem to work well but too heavy for the old eee pc.
Noticed 2 people have downloaded the 32 bit iso, and only one of them was me. Was the other one you? If not, then there is another???
There must be another. lol
It's all very bleeding-edge, so I can't say none are not experimental TBH
Was it Calamares that failed at openssh-server?
since you got it installed, can you run sudo dpkg-reconfigure openssh-server to see what you get? It's odd that that command failed.
Suspecting my odd test data was the cause, tried to reproduce with sensible test data. Error not reproduced.
There is another! omg!
Some desktops seem better than others for running the installer. In weston, trying to full-screen the installer crashes it! Couldn't launch it from the icon at all under gnome, kde wasn't much better. Can't remember which one I used the first time, but the second time never managed to install it via icon or menu, only through terminal.
OK, anyway, I reordered the order that it corrects SSH server, so that if that command does fail, it won't cause Calamares to bail until after the bootloader is configured.
I can't replicate it failing under KDE, but Gnome was failing because it handles the Exec line different, so I corrected that. Calamares maximize fails in Weston because of some Wayland protocol error. Odd, not sure if that's a Weston bug or not
Mate desktop seems to offer the most improvement opportunities. Various panel items don't load (notification area, wntk etc), and the cursor is invisible, making it difficult but not impossible to use.
As for that install bug, the more I think about it, it's best that the install fails with such insecure test data. Actually using a live system in that state would leave it wide open. Can't find a way to message you privately to share the specific example.
Can't find anyway to switch desktops without rebooting! It tells me my username or password is incorrect. I selected automatic login at install time, is that the problem?
Mate is kind of as-is because their Wayland support is not quite complete yet.
Although the cursors not appearing is odd, could be hardware cursors. Try to replace the line in /usr/share/wsessions.d/wayfire.desktop
Where it says try to change set=WLR_NO_HARDWARE_CURSORS=1@SOFTWARE to set=WLR_NO_HARDWARE_CURSORS=1 (removing @SOFTWARE that way it disables hardware cursors for Wayfire unconditionally. (instead of only when Software Rendering is being force)
As far as the example that caused the ssh config failure, can you say what field you're suspecting? You don't have to give me what was in it, but let me know if it was say, the hostname or not
Odd that you can't log in, autologin should not be the problem. Does your password work with sudo? any special or odd characters?
yes, the password is a special character used by expert lazy users who do a lot of installing and configging. it actually appears many times on this page and it is .
it works with sudo etc, but is disallowed by some password strength checkers. Suspect it was allowed by calamares but not by openssh.
Odd, yeah I don't think the password should cause issues with the ssh phase, to my knowledge dpkg-reconfigure openssh-server does ssh-keygen under /etc/ for the machine, not the user as far as I know
I tried just now in a VM, I can create a user, and log in with a password of . so it doesn't appear to be an issue in how waylandloginmanager is handling the password
removing @SOFTWARE disables mouse and keyboard input on the login / greeter screen!
Restoring @SOFTWARE fixes it.
Added a new user, attempted to logout then login as the new user, same error.
Do you have an old bare metal 32 bit box you can try it out on? Otherwise, any other info you need about my system?
and sudo dpkg-reconfigure openssh-server returned
rescue-ssh.target is a disabled or a static unit, not starting it
Just tried logging out and logging in as the root user. It works!
Suspect my users don't belong to the right groups?
Odd, I just tried to have qemu emulate a core 1 duo processor, and an install, and ssh didn't fail, not sure the best way to replicate it. That warning message you get about rescue-ssh.target is normal
I always get them mixed up but useradd creates the user as disabled, adduser is better. The group membership doesn't seem to be the cause, a user in only the primary group works, but the waylandloginmanager lists disabled user accounts. oops.
Odd that removing @SOFTWARE from a wsession file does that to the greeter screen. The wsession files are only read for user session starting, and should not impact the loginmanagerdisplay greeter. Although it could be the session you are starting dead-hanging on startup. There are no VTs, so as a session is beginning to start up, so it's a side effect of the flicker-free transition that happens, instead of a blank screen.
I used adduser, and the installer generated user has the same problem. Oh, and the VT option is very cool and minimalist if logging in as root :)
may I suggest an old asus eee pc? The 900, 900a, or 901 are ideal, if you get one with a 16GB ssd or more
I wonder if the keyboard layout is causing the password to be entered weird. The loginmanagerdisplay shouldn't be but lets eliminate it. If you hit Login>Enter User Name, and start typing text in that box, are incorrect characters showing up?
It's not that, password types correctly in username field. The system does swap £ with # and " with @ but that's a common problem.
Dang Trying on a Dell Inspirion E1405 with a Core 1 Solo processor, I could not seem to replicate the SSH config failure, and user logins work.
when you log in, and it fails, anything interesting in journalctl?
I can't get a terminal from the login screen so would journalctl still give useful info after booting?
E1405! interesting. To get an idea of it's processor grunt, what result does it give for sudo dd if=/dev/urandom of=/dev/null bs=8M count=1024 status=progress?
journalctl, having found the relevant portion after reboot, if it's not here then it's not in the journal:
`Dec 23 06:51:25 saturday systemd-logind[372]: System is powering down.
Dec 23 06:51:25 saturday runuser[1333]: pam_unix(runuser:session): session closed for user waylandloginmanager
Dec 23 06:51:20 saturday runuser[1333]: pam_unix(runuser:session): session opened for user waylandloginmanager>
Dec 23 06:51:20 saturday runuser[1314]: pam_unix(runuser:session): session closed for user waylandloginmanager
Dec 23 06:51:11 saturday runuser[1314]: pam_unix(runuser:session): session opened for user waylandloginmanager>
Dec 23 06:51:10 saturday waylandloginmanager: received command Leave for seat seat0
Dec 23 06:51:10 saturday waylandloginmanager[416]: received command Leave for seat seat0
Dec 23 06:51:10 saturday runuser[1264]: pam_unix(runuser:session): session closed for user waylandloginmanager
Dec 23 06:50:53 saturday kernel: perf: interrupt took too long (6716 > 6703), lowering kernel.perf_event_max_s>
Dec 23 06:50:41 saturday runuser[1264]: pam_unix(runuser:session): session opened for user waylandloginmanager>
Dec 23 06:50:41 saturday runuser[1260]: pam_unix(runuser:session): session closed for user waylandloginmanager
Dec 23 06:50:41 saturday runuser[1260]: pam_unix(runuser:session): session opened for user waylandloginmanager>
Dec 23 06:50:41 saturday waylandloginmanager: Invalid password for friday, or username invalid
Dec 23 06:50:41 saturday waylandloginmanager[1178]: Invalid password for friday, or username invalid
Dec 23 06:50:41 saturday runuser[1243]: pam_unix(runuser:session): session closed for user waylandloginmanager
Dec 23 06:50:36 saturday runuser[1243]: pam_unix(runuser:session): session opened for user waylandloginmanager>
Dec 23 06:50:33 saturday perl[1242]: pam_unix(login:auth): authentication failure; logname= uid=0 euid=0 tty= >
Dec 23 06:50:33 saturday runuser[1216]: pam_unix(runuser:session): session closed for user waylandloginmanager
Dec 23 06:50:26 saturday runuser[1216]: pam_unix(runuser:session): session opened for user waylandloginmanager>
Dec 23 06:50:25 saturday runuser[1200]: pam_unix(runuser:session): session closed for user waylandloginmanager
Dec 23 06:50:15 saturday runuser[1200]: pam_unix(runuser:session): session opened for user waylandloginmanager>
Dec 23 06:50:15 saturday waylandloginmanager: received command Login for seat seat0
Dec 23 06:50:15 saturday waylandloginmanager[416]: received command Login for seat seat0
Dec 23 06:50:15 saturday runuser[1154]: pam_unix(runuser:session): session closed for user waylandloginmanager
Dec 23 06:50:07 saturday runuser[1154]: pam_unix(runuser:session): session opened for user waylandloginmanager>
Dec 23 06:50:07 saturday waylandloginmanager: received command Switch for seat seat0
Dec 23 06:50:07 saturday waylandloginmanager[416]: received command Switch for seat seat0
Dec 23 06:50:07 saturday runuser[1118]: pam_unix(runuser:session): session closed for user waylandloginmanager
Dec 23 06:49:54 saturday runuser[1118]: pam_unix(runuser:session): session opened for user waylandloginmanager>
Dec 23 06:49:54 saturday runuser[1114]: pam_unix(runuser:session): session closed for user waylandloginmanager
Dec 23 06:49:54 saturday runuser[1114]: pam_unix(runuser:session): session opened for user waylandloginmanager>
Dec 23 06:49:54 saturday waylandloginmanager: Invalid password for thursday, or username invalid `
Dec 23 06:50:33 saturday perl[1242]: pam_unix(login:auth): authentication failure; logname= uid=0 euid=0 tty= >
dang, that is indeed it evaluating the password and it coming up wrong, can you journalctl |grep pam_unix seems that line is getting cut off by the journal pager, I mostly want to see what the user= is
and for that user, can you sudo passwd -S $THE_USER ?
It's coming up as logname= uid=0 euid=0 tty= ruser= rhost= user=friday
sudo passwd -S $friday gives root P 12/22/2022 0 99999 7 -1
also same output for sudo passwd -S $root and sudo passwd -S $thursday
Try sudo passwd -S friday without the dollar, the dollar meant $THE_USER as in it's a variable, I should have been more clear there.