11 Nov
2015
11 Nov
'15
11:49 a.m.
Author: Andy Smith
Date: 2015-11-11 04:38 -000
Hi Andy.
Thanks for the help, I do appreciate that Bitfolk is a service for
real geeks and that support for installations is not part of the deal.
Your support is one of the reasons why Bitfolk is special :)
I'm sorry to see
you're having problems. Here's an asciicast I just made of me
installing Ubuntu 14.04 i686 on the same host that you're on:
https://asciinema.org/a/ckiwp5sm75kbll77wj3r23myt
I watched the asciicast and what you did is pretty well what I did.
The main difference was the partitioning. When I did the first and
subsequent installs the partitions were already there and I just
labelled and formatted them. You deleted everything and started from
scratch.
The other difference is that for the first and last attempts I took
the LAMP and encryption options. These two installations both booted
but with error messages and I was unable to ssh into them. It is
running like that now. The installations without those options would not boot.
I suspect what has happened to you is that somehow grub-pc (GrUB 2.x)
has become installed. Only grub-legacy is supported at the moment¹,
but the self-installer is not meant to leave you with grub-pc, so it's
still a bug.
I hate GrUB2 :) I always had the feeling that it was designed for and
by enterprise users. On your screencast you were offered a grub boot
menu. I did not see this on mine.
The other thing it might be is that I see you have a
quite interesting
partition layout.
I mentioned this above. I am happy to do another install deleting the
partitions and doing exactly what you did.
broken install still exist, for me to examine?
Yes. It is running. I will not touch it until you have given me the
all clear. I am happy to give you my login details.
Depends what "could not log in" means. :)
>
I tried to ssh to the IP address and received an instant 'connection
refused'. It did not respond to ping.
The strange thing is that I just tried again, received a response to
ping and to ssh:
$ ssh zaphod(a)85.119.83.139
zaphod(a)85.119.83.139's password:
Permission denied, please try again.
I typed in the password very carefully three times and checked that
the caps lock were not on.
You should have seen a block of text printed before
the login prompt
which tells you what the (randomly-generated) credentials are.
I did see the instructions but there was no block of text telling me
the credentials. I suspect that it disappeared because I touched
something but left the login prompt. I am not a screen user and it
took me longer than it should to escape from the login prompt :( Once
I did that I did succeed in logging in to the rescue environment.
Did yours not look like that? If it did, then clearly this is still
too confusing.
It did and it was confusing to someone who is not used to screen. I
did control + a k to kill the session but it returned to the same
login screen when I made a fresh connection. It was later that I found
contol + ] that returned me to the Xen shell. Later I saw that on the
initial screen it tells about control + ] but it was not visible when
I needed it.
Do you have any suggestions on how to make this
clearer?
Maybe a 'how to get out of here if your login fails' hint at the login
screen? I guess the typical Bitfolk customer would not need that sort
of help.
Thanks again.
Steve
11 Nov
11 Nov
12:03 p.m.
Hi Steven,
On Wed, Nov 11, 2015 at 11:49:30AM +0000, Steven Walker wrote:
But if you did what I did then you would not have an xvda1 that is
an extended partition with an xvda5 inside it, so you must have done
something different to me. Probably at the "Partition disks" stage,
01:38 in to the above asciicast?
Author: Andy
Smith
Here's an asciicast I just made of me installing Ubuntu 14.04
i686 on the same host that you're on:
https://asciinema.org/a/ckiwp5sm75kbll77wj3r23myt
I watched the asciicast and what you did is pretty well what I did. I mentioned this above. I am happy to do another
install deleting the
partitions and doing exactly what you did.
I think you should try that, but it would be nice to know which
option you chose so that I can do that myself and see if I can make
it still work for people anyway.
I tried to ssh to the IP address and received an
instant 'connection
refused'. It did not respond to ping.
The strange thing is that I just tried again, received a response to
ping and to ssh:
$ ssh zaphod(a)85.119.83.139
zaphod(a)85.119.83.139's password:
Permission denied, please try again.
I typed in the password very carefully three times and checked that
the caps lock were not on.
You realise that your rescue VM is still running, right? So that is
what is sitting on your IP address, and the only user account on it
is called "user" and has a randomly-generated password. So that
would explain why it pings and does not let you log in.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
12:07 p.m.
New subject: Failed Ubuntu 14.04 Install [off topic]
Steven Walker <sjb.walker(a)gmail.com> said, in message
CAORZ3UB2gD28=O6NYkCuHv4J9xS8kYF9R+bSYEgyD80zrkZx2w(a)mail.gmail.com:
I hate GrUB2 :) I always had the feeling that it was designed for and
by enterprise users.
To be fair, Grub 2 is quite nice if you ignore all the dross piled
on dross that installers put into the grub config file. A hand-written
grub 2 config can be pretty concise and self-explanatory:
Here's an entry off my "Rescue/Install" pen drive:
menuentry "Rescue Image" {
linux /images/rescue.x86_64.krn
initrd /images/rescue.x86_64.igz
}
Here's one to boot a Mint 17.2 live ISO image stored as a file in /isos
on the pen drive:
menuentry "Mint 17.2 Cinnamon 64-bit" {
set isofile='/isos/linuxmint-17.2-cinnamon-64bit.iso'
loopback loop $isofile
linux (loop)/casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper
iso-scan/filename=$isofile quiet splash --
initrd (loop)/casper/initrd.lz
}
Cheers,
Alun.
--
Alun Jones, auj(a)aber.ac.uk, 01970 622637
Mathemateg, Ffiseg a Chyfrifiadureg, Prifysgol Aberystwyth
Mathematics, Physics & Computer Science, Aberystwyth University
12:23 p.m.
I think I can explain the problem with the login at the rescue
terminal. I just logged into the Xen shell and ran the console
command. This did not generate a response. After a while it gave an OK
which I assume means it had some sort of connection. Nothing much
happened so I hit enter which put me into the Rescue Environment but
without any credentials appearing.
Once I had failed to log in a couple of times the advice about Control
+ ] had risen up the screen and was no longer visible.
I paste the session below.
Steve
xen-shell> console
Running console for simpee - exit with Ctrl+]
[34294.348131] nfs: server 85.119.80.243 not responding, still trying
[34301.149539] nfs: server 85.119.80.243 OK
BitFolk Rescue Environment - https://tools.bitfolk.com/wiki/Rescue
This virtual machine is running read-only over NFS with a unionfs ramdisk to
allow changes. This means:
- anything you write to its filesystem will not survive a reboot
- you only have about half your RAM size as writable space
If you need to write more, or you need it to persist past a reboot, you'll need
to use your VPS's storage. Please see:
https://tools.bitfolk.com/wiki/Rescue#Persistence
for more information.
Your user account is called 'user' and its password has been randomly-generated
(see above). Be careful what you do with it as networking is now active and
sshd is running. The 'user' account has full sudo access.
rescue login:
12:41 p.m.
Hi Steven,
On Wed, Nov 11, 2015 at 12:23:46PM +0000, Steven Walker wrote:
xen-shell> console
Running console for simpee - exit with Ctrl+]
[34294.348131] nfs: server 85.119.80.243 not responding, still trying
[34301.149539] nfs: server 85.119.80.243 OK
The NFS server that the rescue VM is running from didn't respond for
a couple of seconds. I don't know why, but it's unrelated.
BitFolk Rescue Environment -
https://tools.bitfolk.com/wiki/Rescue
This virtual machine is running read-only over NFS with a unionfs ramdisk to
allow changes. This means:
- anything you write to its filesystem will not survive a reboot
- you only have about half your RAM size as writable space
If you need to write more, or you need it to persist past a reboot, you'll need
to use your VPS's storage. Please see:
https://tools.bitfolk.com/wiki/Rescue#Persistence
for more information.
Your user account is called 'user' and its password has been randomly-generated
(see above). Be careful what you do with it as networking is now active and
sshd is running. The 'user' account has full sudo access.
rescue login:
All of the above is the login prompt and the motd file that appears
on every login. So all that happened was you pressing return a few
times failed the login and printed a new login prompt.
At boot of the rescue VM, the very last thing to be printed before
that motd and prompt above is the random password:
****************************************
Resetting user password to random value:
New user password: imeiXuoy
****************************************
BitFolk Rescue Environment - https://tools.bitfolk.com/wiki/Rescue
…etc
So perhaps I should just put the bit with the password into the motd
as well, so it reappears every time you fail your login.
In any case, I think we've established that you do not need to use
the rescue VM at this stage? So it is safe to use "shutdown" or
"destroy" from the Xen Shell.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Please consider the environment before reading this e-mail.
— John Levine
12 Nov
12 Nov
1:15 p.m.
Date: Wed, 11 Nov 2015 12:03:07 +0000
From: Andy Smith <andy(a)bitfolk.com>
To: users(a)lists.bitfolk.com
Subject: Re: [bitfolk] Failed Ubuntu 14.04 Install
Hi Steven,
I watched the
asciicast and what you did is pretty well what I did.
But if you did what I did then you would not have an xvda1 that is
an extended partition with an xvda5 inside it, so you must have done
something different to me. Probably at the "Partition disks" stage,
01:38 in to the above asciicast? I mentioned this above. I am happy to do another
install deleting the
partitions and doing exactly what you did.
I think you should try that, but it would be nice to know which
option you chose so that I can do that myself and see if I can make
it still work for people anyway.
You realise that your rescue VM is still running, right? So that is
what is sitting on your IP address, and the only user account on it
is called "user" and has a randomly-generated password. So that
would explain why it pings and does not let you log in.
Whoops, yes, now I understand.
Steve
3089
days inactive
3090
days old
5 comments
3 participants
participants (3)
-
Alun -
Andy Smith -
Steven Walker