You are here
hjo1620 - Mon, 2011/06/06 - 14:33
I downloaded
http://www.turnkeylinux.org/download?file=turnkey-ec2sdk-11.1-lucid-x86-...
and created a VBox VM using the .vmdk file as disk.
I chose my own root password during install.
After install I can access (but not login to):
https://192.168.56.103:12320 and
I can login using root, in the native terminal.
I can ping google.com
I did cat /var/log/boot.log, and found no generated password.
However, I cannot login as root on:
https://192.168.56.103:12320 or
Where can I find the correct root password for webmin and shellinabox ?
Forum:
Tags:
The root password you set...
The root password you set during the first boot configuration is the same for console access, shellinabox and webmin.
Regarding a randomly generated password in /var/log/boot.log, that's only relevant on the Amazon EC2 builds when launching from the AWS console.
Issue solved
It's a limitation of defaulting to a US keyboard...
And having WebUI access and installing to hardware (or desktop VM that interprets hardware directly).
If you don't use a US keyboard then the keystrokes are interpretted incorrectly when sitting at the hardware, but as your web browser (or any other remote access tool) is running on your local computer (which one would assume is set up to work correctly with your non-US keyboard) then the keystrokes are interpreted correctly and passed (via the internet/network) to your TKL appliance. But obviously they don't correspond to what is stored on your server as it has the wrong information to start with.
So this situation only occurs when you run the machines locally on hardware. If you use AWS/other VPS provider/or virtualisation which uses a Web browser UI then this situation will not occur.
So I guess the workaround for use of TKL on hardware (and desktop VM) is to use a US keyboard for install if possible, or failing that, use standard characters on install that (hopefully) won't be mis-interpreted and then change the password (via SSH terminal, WebShell, Webmin or some other remote means) after install...
The only way to completely fix this would be to detect & confirm the use of US/non-US keyboard on install. That's not a huge deal I guess but seeing as users with non-US keyboards would be a minority, and users installing to hardware & desktop VM; a subset of them, at this point I don't know whether it will be a priority for the core devs. Regardless I think that it is good that this is documented so at least users such as yourself can work out what is going on!
[edit] I edited my original post to include desktop VM as a problematic target. Initially I thought this was limited to hardware install, but on re-reading the thread it seems the OP had this issue with desktop VM software.
Also: Bug reported here.
PS I just added a poll
which includes a question about keyboard. Have a look and vote here.
Add new comment