hjo1620's picture

I downloaded


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): 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: or


Where can I find the correct root password for webmin and shellinabox ?

Alon Swartz's picture

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.

hjo1620's picture


The terminal where the password is given, on a Swedish keyboard, as z123***
passes on the password as z123""" to webmin and shellinabox, as if I was using a US keyboard layout.
I can login in the terminal with z123*** and
I login to webmin and shellinabox with z123""".
Issue solved.
But rather strange that the given password characters were interpreted differently on the "instance" vs. in the services.

Jeremy Davis's picture

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.

Jeremy Davis's picture

which includes a question about keyboard. Have a look and vote here.

Add new comment