[Bug 1391919] Comment bridged from LTC Bugzilla
bugproxy
bugproxy at us.ibm.com
Tue May 19 04:49:36 UTC 2015
------- Comment From hellerda at us.ibm.com 2015-05-19 04:44 EDT-------
(In reply to comment #48)
> > I'd like to understand how hvc0.conf is created, why it's not
> > being created in some cases,
>
> The installer uses various means to detect if a serial console is in use and
> creates the upstart job on the fly.
>
As I suggested above, maybe checking /proc/consoles, if it's not already doing that?
> > and if ensuring it is created might just be the simple fix.
>
> Yes that is the correct fix.
>
Yeah, if we think there's no harm in always adding the file, let's just do that and be done with it, :-)
> The slightly more long-winded analysis I tossed in an email a few minutes
> ago:
>
> So, there are two (maybe three) issues in play with this specific bug.
>
FYI, I just worked on a bug that was a dup of this and...
> 1) The console wasn't in use as "The Console" when we installed, which
> we (probably incorrectly, in this case) key off of to decide what
> console to set up.
>
In my case it was the console used for install: a text-based install using "virsh console", and it was recognized as hvc0.
> 2) The console he set up was using an old kimchi default that used a
> non-standard address we don't look for. Newer versions of kimchi
> are meant to use a more standard address to work around that, but
> it's still an Ubuntu bug that we blatantly ignore random consoles.
>
In my case no kimchi, just generic PowerKVM and virsh.
> 3) He may not have had that console configured at install time at all,
> and we only probe for and setup up console jobs in the installer,
> we make no attempt to do so at boot time. So, if new consoles were
> to show up on second or fifth boot, tough look, no console for you.
>
In my case console was present (and used) at install.
> The first two bugs are ones we can and should fix in trusty. The third
> is probably a wart we need to live with, but can probably fix a bit
> better with systemd in 15.04/15.10/16.04.
Actually it works in 15.04. We only need a fix for 14.04 LTS, and then
only on PowerKVM. It works on PowerVM.
Not sure about 14.10, but I'm guessing it's broken there too if that is
pre-systemd.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to debian-installer in Ubuntu.
https://bugs.launchpad.net/bugs/1391919
Title:
ISST-KVM:Ubuntu14.04: guest console not accessible but ssh and ping
works fine
Status in debian-installer package in Ubuntu:
Confirmed
Bug description:
-- Problem Description --
I installed a guest with ubuntu14.04 using vga over vnc using kimchi. All setup was done, i could ping, ssh to guest, access guest using kimchi. But to access guest using "virsh console":
1. Removed video and graphics line from xml
2. Destroyed guest
3. Started guest using "virsh start --console <<guestname>>
After this guest hangs and dmesg is as follows:
* Starting SystemD login management service [ OK ]
* Starting load fallback graphics devices [fail]
* Starting configure network device security [ OK ]
* Starting system logging daemon [ OK ]
* Starting save udev log and update rules [ OK ]
* Stopping rpcsec_gss daemon [ OK ]
* Stopping save udev log and update rules [ OK ]
* Starting set console font [ OK ]
* Starting NFSv4 id <-> name mapper [ OK ]
* Stopping set console font [ OK ]
* Starting userspace bootsplash [ OK ]
* Stopping userspace bootsplash [ OK ]
* Starting Send an event to indicate plymouth is up [ OK ]
* Stopping Send an event to indicate plymouth is up [ OK ]
* Starting configure virtual network devices [ OK ]
* Starting NFSv4 id <-> name mapper [ OK ]
* Starting configure network device security [ OK ]
* Starting configure network device [ OK ]
* Starting Mount network filesystems [ OK ]
* Starting Upstart job to start rpcbind on boot only [ OK ]
* Starting Failsafe Boot Delay [ OK ]
* Stopping Upstart job to start rpcbind on boot only [ OK ]
* Stopping Failsafe Boot Delay [ OK ]
* Starting System V initialisation compatibility [ OK ]
* Stopping Mount network filesystems [ OK ]
* Starting configure network device [ OK ]
* Starting Mount network filesystems [ OK ]
* Stopping Mount network filesystems [ OK ]
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
* Starting RPC portmapper replacement [ OK ]
* Starting NSM status monitor [ OK ]
* Starting AppArmor profiles [ OK ]
* Starting Bridge file events into upstart [ OK ]
* Starting Bridge socket events into upstart [ OK ]
* Stopping System V initialisation compatibility [ OK ]
* Starting System V runlevel compatibility [ OK ]
* Starting save kernel messages [ OK ]
* Starting internet superserver inetd [ OK ]
* Stopping save kernel messages [ OK ]
* Restoring resolver state... [ OK ]
* Starting CPU interrupts balancing daemon [ OK ]
* Stopping System V runlevel compatibility [ OK ]
I can ping and ssh to guest when machine is in hung state.
It seems it is not giving console output due to below error
Starting load fallback graphics devices
[fail]
Problem occurs when video and graphics lines are deleted, cannot
access console of guest. But we can ssh to guest.
Logging into your system:
root at ubu14mdbsvr1:~# cd /etc/init
root at ubu14mdbsvr1:/etc/init# cat hvc0.conf
cat: hvc0.conf: No such file or directory
On my Ubuntu guest, I have the following in hvc0.conf:
# hvc0 - getty
#
# This service maintains a getty on hvc0 from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL=[2345] and (
not-container or
container CONTAINER=lxc or
container CONTAINER=lxc-libvirt)
stop on runlevel [!2345]
respawn
exec /sbin/getty -L hvc0 9600 vt100
I expect if you create that file and issue a `start hvc0`, you will be able to login. I believe the Ubuntu installer when using graphics mode assumes you will maintain graphics mode and you are responsible as the user to setup the hvc0 login.
I created "hvc0.conf" file in /etc/init, issued `start hvc0` and i
could access the console of guest. It worked.
Problem persists in 14.10. General sense is that we should require
that regardless of the installation method (graphical or not), hvc0 is
always enabled on powerkvm guests, from a customer perspective.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1391919/+subscriptions
More information about the foundations-bugs
mailing list