just highlight the text you wish to reply to -- a "quote" button will appear above it 
2 Likes
I've been locked out before when my known password wouldn't work. A large image was my culprit, too.
1 Like
That's a good point... although I wouldn't expect quite the same behavior here, it is possible that something is going wrong due to space (even on the Pi if the partition size has not been increased).
Following from @bluewavenet 's idea...
what is the output of
df -h
for each of the devices?
1 Like
Thanks. I tried the default password and an intermediate password I had used and neither worked. Also, this is happening on two different setups with separate build images (R7800 and Pi 4).
R7800:
Filesystem Size Used Available Use% Mounted on
/dev/root 4.3M 4.3M 0 100% /rom
tmpfs 232.0M 1.2M 230.9M 1% /tmp
/dev/ubi0_1 78.1M 4.3M 69.8M 6% /overlay
overlayfs:/overlay 78.1M 4.3M 69.8M 6% /
tmpfs 512.0K 0 512.0K 0% /dev
Pi 4:
Filesystem Size Used Available Use% Mounted on
/dev/root 5.3M 5.3M 0 100% /rom
tmpfs 1.9G 252.0K 1.9G 0% /tmp
/dev/loop0 87.2M 8.8M 71.5M 11% /overlay
overlayfs:/overlay 87.2M 8.8M 71.5M 11% /
tmpfs 512.0K 0 512.0K 0% /dev
@packetmania -- do you want to answer those really good questions?
1 Like
Sorry, I answered them but didn't quote the post. I'm using official images, no malware likely since isolated from 'net after install/app downloads, no scripts in /etc/uci-defaults/, cron empty, don't think I've angered anyone 
So not a space issue... plenty to space in your devices.
How did the hash change exactly?
As in,
- just a single (or two) characters flipped - or a completely different hash
- is it still a hash, or are there some other strings, different length, etc. now in place
Does find /overlay/upper | sort show anything 'unusual', talking about weird file names, signs of filesystem corruption or just something you didn't expect.
bash is usually not a great package to install, as it may cause issues with future sysupgrades if you change your login shell to it (as it's not a default package, it won't be in the next vanilla OpenWrt image --> bang, no valid shell present after a sysupgrade), but it shouldn't cause this issue...
Well, as @psherman says, it does not look like a space problem.
Looking at the list of packages, I see etherwake, but do not see sudo.
The default config for etherwake is option 'sudo' 'off'.
This means etherwake will use root user rather than its own user "etherwake" if I remember correctly (again it is years since I used it).
I possibly incorrectly recall that etherwake sets a default password for whatever user account it is using if not specified as a hash in a .conf file in /etc ........
Maybe try removing etherwake?
I have installed etherwake on many routers over the years and have never seen the ops issue. I doubt etherwake is the culprit. But I do agreee that removing all non-essential package installs would be good.
2 Likes
The problem is even stranger than I thought.
To recall, the issue originally manifested as LuCI not accepting my root password. I was still able to access the router via my password-less ssh login, during which I used passwd to set my root password back to what it was and LuCI would resume accepting it. The initial assumption was my root password in /etc/shadow was being changed by someone. After the issue occurred a few times I added a script to automate the resetting of the password since it was becoming a chore. To help debug the issue that script was supposed to copy /etc/shadow to a backup file prior to running paswd, so that I could examine how the hash changed when the system would no longer accept the password. But my script had a bug that copied /etc/shadow after running passwd, meaning I was comparing the newly-set hash against the original, and of course it's different even though the password is the same (due to the random salt). I found my script bug because a second script I wrote to monitor and log whenever /etc/shadow changes wasn't detecting a change even after the router stopped accepting my root password sometime during the session.
So the issue I'm having is not hat the password in /etc/shadow is changing but that the system randomly stops accepting that password, which is even stranger than the original beleived issue. I verified this isn't a LuCI-specific authentication issue by re-enabling password-based ssh logins and verifying it also doesn't accept my root password when the router enters this state. For a third test I used login in my password-less ssh session and verified it too doesn't accept my root password when the router is in this state. All three will resume accepting the password if I set it again via passwd.
Even stranger is once the router enters this state it wont leave it until I change the password. If I reboot the router without changing the password it still wont accept it on the new session, so that excludes a caching issue. It also wont accept it if I simply touch /etc/shadow or change a value inside and then change it back, also excluding a caching issue. It's acting as if the salt value or MD5 check of the salt+password is yielding the wrong result and thus mismatching against the known-good value in /etc/shadow.
I have some more experiments planned next time this state occurs, including copying a previous /etc/shadow (different salt) over the current file and see if that works. I'm open to other experiment ideas as well.