Public bug reported:
Nothing more to add than summary.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ubiquity 2.18.8.9
ProcVersionSignature: Ubuntu 3.19.0-25.26~14.04.1-generic 3.19.8-ckt2
Uname: Linux 3.19.0-25-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.11
Architecture: amd64
Have you tried adding the id's dynamically for the snd-usb-audio module
like explained on this page ?:
http://www.ha19.no/usb/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317244
Title:
Yamaha
No, sorry forget what I mentioned about udev, that is probably not going
to work.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317244
Title:
Yamaha Steinberg UR22 not supported (Yamaha USB
I see this bug is expired, not sure if that means it can be reopened ?
Anyway, I can see that in Debian 6.0 Squeeze CONFIG_IPV6_ROUTER_PREF
is enabled by default in the kernels.
But in Ubuntu 10.10 it is not.
Is there a reason why it is not enabled in Ubuntu ? I would expect
Ubuntu to use
It also effects Debian 6.0/Squeeze stable (or atleast the version from a
few weeks ago when it was not released stable yet, but I think they
changed anything since then related to this). Here is the bugreport in
Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514464
Also:
I'm not familair with the installer at all, but I had a look at
/var/log/installer/syslog, maybe this has something to do with it:
Oct 2 20:22:49 ubuntu in-target: A error occurred during the signature
verification. The repository is not updated and the previous index files
will be used. GPG
Thanks Colin.
I had some time and access to the laptop again.
So I created a small patch on top of your patch to prove it what
happends.
I did 10 boots and 4 times the code was triggered, 6 times it did not trigger,
but it seems those were the times it did not need to be triggered.
So I think
Ohh, hi Colin, sorry I missed your first 2 messages.
I have a few remarks:
1. won't the timing be different on Maverick ? You still need to be able
to reproduce the problem first.
2. Would it not be a good idea to build a ppa for Lucid so people can
test that ?
3. I've been really busy with
It was quiet a long bug report, but it made sense to me.
I wasn't able to test, the laptop I use for testing was in use this
evening.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because you are a member of Ubuntu
Bugs,
Damien, all good questions, but I got a better response from upstream:
Atleast /dev/tty0 should work, find out why it isn't.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Concerning your last question, I think a default kernel might have
something like 65536 possible values for that and you don't want to
check them all. Probably it can even be raised with a kernel-compile.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You
Your 3rd question:
No1 likes that part of the code, I've got the feeling that part will go
away.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Good very good, so now I can get back to talking to upstream about this.
How they want to put in a real fix.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Damien I think the text was actually tried but failed, but I doubt
moojix has that text as it will not be reached if moojix didn't see:
trying again
Anyhow, I made some more changes and a new ppa.
The ppa is building at this moment.
--
Active VT tracking can fail at startup
I downloaded the ppa on my laptop and it didn't break it.
But I wasn't able to reproduce the problem which we are trying to fix.
So I wasn't able to test the fix/workaround.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification
Damien,
Let me know what you'll find, because then we'll get a good idea of how
bad it really is.
The new ppa has a loop which has 30 times 0.2 seconds (I changed the
usleep also this time).
So that's 6 seconds, that ought to be enough ?
If you have any other code/suggestions let me know.
--
moojix do you have one that does not say the following ?: did not fail
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Then I don't think I actually solved it, just slowed it down enough so
it didn't fail.
I'm already looking at a diff between 0.4.1-3ubuntu1 and
0.4.1-3ubuntu1-lbesselink7
This morning the strace I tried also looked good. I don't think it's the
debug/warning logging to syslog.
Maybe it is the
After a whole evening running tests and no failures (and thus no way to
test the fix), the new ppa gave this result after less then 10 reboots:
Sep 2 00:21:06 laptop console-kit-daemon[]: WARNING: tried but failed
Sep 2 00:21:06 laptop console-kit-daemon[]: WARNING: eventually choose to
That sounds very promissing.
But I've been pondering, maybe it needs more work to be sure.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
Hi,
moojix and cmat could you post the debug from your logs ?
You possible don't want to post all of it, just the stuff that seems to
be different between boots.
I'm especially interrested to know if it says trying again. You can see it
with:
grep trying again /var/log/syslog
In that case
The most logical explanation is, you had the same 'problem' I had when I
turned on --debug for the console-kit-daemon.
It would start logging messages to rsyslogd (which saves it in syslog,
daemon, etc.) early and the timing would be off and you would not be
able to reproduce it.
--
Active VT
The debug that I added which says:
Aug 26 17:44:51 tacto-ppp-01 console-kit-daemon[927]: WARNING:
ck_get_a_console_fd, choose: /dev/tty0
Is earlier in the startup of console-kit-daemon then the previous
versions.
The previous version had the first debug at:
Aug 26 17:44:51 tacto-ppp-01
Yes seems like it, I hope to have time for it this evening otherwise
it's probably something for tomorrow.
If you know how to build it, you could try it out yourself. :-)
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because
So that could mean that when we keep trying to grab the console_fd it
seems to work.
But I'm missing some debug-information, that is a bit strange.
It was a bit late last night so that might be why it is missing. :-)
I hope that is the reason, because otherwise I can't quiet explain it.
--
Damien, I do have a question.
Just to make sure, you did use the same hardware/machine to test ?
I think I read you had several of these machines ? Did you maybe do a
restore from an image or something like that ? Did you use the same
method to do so ?
There was no extra USB-device plugged in
no, I don't think that matters.
I'll have a look at what else I did, maybe I did something wrong and the
debug isn't displayed.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I'll see if I can create some code that does that.
But I hope to get an answer from upstream how they would like it to be
solved.
That way I don't have to create any code which we'll gonna throw away
later. :-)
But more importantly they can incorporate it in the upstream version, so
others
I did what you asked and added a loop, 0.2 seconds 40 times.
I uploaded a new ppa, it will need some time to compile. It says 26
minutes to wait till it will compile amd64 and 8 hours before i386 will
build.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You
Damein,
That's annoying. But atleast now we know, we can ask the kernel for
something, which it will give us, but what it gives us is useless.
Interresting.
No, it does not include that patch.
I was trying to find out what is going on and fixed my problem with a
workaround along the way.
OK, I created a ppa with my quick hack so people can test it.
deb http://ppa.launchpad.net/lbesselink/consolekit/ubuntu lucid main
But it will take a couple of hours before it has been compiled by
launchpad.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You
Well, the ppa is doing compiling. I hope someone, anyone.
Maybe Damien has time to test this ?
It solves this specific problem of the VT_WAITACTIVE.
__
Looking at some of the logging, the most likely candidate for which is changing
the console_fd from under consolekit is this:
kernel: [
Just a small lesson, don't change text at the last moment :-)
Instead of:
Well, the ppa is doing compiling. I hope someone, anyone.
I meant to say:
Well, the ppa is done compiling. I hope someone, anyone can test it.
--
Active VT tracking can fail at startup
I changed the original package (not ppa) to have g_warning instead of
g_debug for VT_WAIT..
let's see what happends.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Aug 22 13:31:14 laptop console-kit-daemon[1108]: WARNING: Could not determine
active console
Aug 22 13:31:14 laptop console-kit-daemon[1108]: WARNING: VT_WAITACTIVE for vt 2
Aug 22 13:31:14 laptop console-kit-daemon[1108]: WARNING: VT_WAITACTIVE for vt
2 returned -1
Aug 22 13:31:14 laptop
Yes, it's this one that failed:
res = ioctl (console_fd, VT_GETSTATE, stat);
Interresting, it would have done:
kb_ok = (ioctl (fd, VT_GETSTATE, vts) == 0);
just moments before that in ck_fd_is_a_console
I wonder...
--
Active VT tracking can fail at startup
So I checked, when it fails:
Aug 22 14:32:46 laptop console-kit-daemon[1119]: WARNING: input of
ck_get_active_console_num: 3
Aug 22 14:32:46 laptop console-kit-daemon[1119]: WARNING: Could not determine
active console
That doesn't make a lot of sense to me, it seems to have called
Aug 22 15:19:19 laptop console-kit-daemon[1110]: WARNING: input of
ck_get_active_console_num: 3
Aug 22 15:19:19 laptop console-kit-daemon[1110]: WARNING: got an error: ioctl
VT_GETSTATE
Aug 22 15:19:19 laptop console-kit-daemon[1110]: WARNING: Could not determine
active console
When I have and
Here is the whole part of the log when it fails:
Aug 22 15:19:19 laptop console-kit-daemon[1110]: WARNING: input of
ck_get_active_console_num: 3
Aug 22 15:19:19 laptop console-kit-daemon[1110]: WARNING: got an error: ioctl
VT_GETSTATE
Aug 22 15:19:19 laptop console-kit-daemon[1110]: WARNING:
A small test-program to query dbus would be enough. That way I could run
it without gdm (and thus X) and see if it can cope with that.
And seems to work just fine if I run it on the console without gdm, etc.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You
Is that first part really threaded though ? Isn't it just failing
because X starts up at the same time or something like that ?
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because you are a member of Ubuntu
Bugs, which is
What I mean is, it starts up tried to find the active vt, when that
succeeds it continues to the next step, it tried to get it again but
fails. Then starts the threads, but not for the active console:
/* don't wait on the active vc */
if (i == current_num) {
I hacked in some code in ck_vt_monitor_init to try again and I think I
got it.
The console_fd was just a bad one so the threads couldn't use it to
VT_WAITACTIVE.
Aug 23 02:32:07 laptop console-kit-daemon[1131]: WARNING: console_fd: 3
Aug 23 02:32:07 laptop console-kit-daemon[1131]: WARNING:
Hi Colin and all the others,
I recently upgraded a laptop and I also sometimes had the 'can not
shutdown/reboot' probleem.
If what Colin mentions is true, then would it not help to just disable
the getting the recently-logged-in-user-list from consolekit as a
test/workaround ?
Which can be
Forget what I mentioned, it doesn't work. I was doing reboot-cycles to try and
produce the error and I got the same problem again:
WARNING: Could not determine active console
WARNING: Error waiting for native console 10 activation: Invalid argument
...
--
Active VT tracking can fail at startup
I wonder what would happen if we enabled the last part again in
/etc/X11/Xsession.d again, instead of the what it says now:
# gdm already creates a CK session for us, so do not run the expensive D-Bus
# calls if we have $GDMSESSION
if [ -z $GDMSESSION ] [ -x $CK_LAUNCH_SESSION ] \
( [ -z
That did not help, maybe if I enable --debug in /usr/share/dbus-1
/system-services/org.freedesktop.ConsoleKit.service it might give us
more information.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug notification because you are a member of
At the moment I'm doing reboots so I could get a some debug from
consolekit, but so far it hasn't happend.
As I don't know consolekit or gdm very well but I can program, I hope it
would give me some idea of where to start to look.
I think maybe the debug I enabled made startup of consolekit slow
Yeah, just noticed that, because your change did not help. :-(
With the debug on, I've not been able to reproduce the problem yet, so I
don't yet have a debug with the error-situation.
--
Active VT tracking can fail at startup
https://bugs.launchpad.net/bugs/544139
You received this bug
I wanted to confirm that it works sooner, but I didn't immediately
understand what you meant. But it does work.
Thank you for pointing out the workaround.
--
Directly use the server/folder given in 'Connect to Server...' dialog
https://bugs.launchpad.net/bugs/460656
You received this bug
Public bug reported:
Binary package hint: flashplugin-nonfree
When you use Firefox a freshly started Karmic RC Live-CD, it might
notice in a webpage 'flash-type-plugin' is not installed. It will ask if
you want to install a such a plugin on the top of the page with a yellow
bar. When you click
** Attachment added: This is the first screenshot
http://launchpadlibrarian.net/34367815/Screenshot-Untitled%20Window.png
--
Firefox automatic plugin-installer does not work on a fresh Karmic RC live-cd
https://bugs.launchpad.net/bugs/460622
You received this bug notification because you are
** Attachment added: Screenshot-Untitled Window-1.png
http://launchpadlibrarian.net/34367793/Screenshot-Untitled%20Window-1.png
--
Firefox automatic plugin-installer does not work on a fresh Karmic RC live-cd
https://bugs.launchpad.net/bugs/460622
You received this bug notification because
** Attachment added: This is the third screenshot
http://launchpadlibrarian.net/34367835/Screenshot-Plugin%20Finder%20Service.png
--
Firefox automatic plugin-installer does not work on a fresh Karmic RC live-cd
https://bugs.launchpad.net/bugs/460622
You received this bug notification
The attachment at comment #1 is the second screen with the error-
message. Comment #2 is the screenshot where it asks if you want to
enable the repositories. Comment #3 is the screen where it says it
succeeded, but actually failed.
--
Firefox automatic plugin-installer does not work on a fresh
Public bug reported:
Binary package hint: gnome-disk-utility
I noticed some similair problems to bug #414107 with Karmic RC Live-CD.
I'll attach 2 screenshots to show you what's wrong.
** Affects: gnome-disk-utility (Ubuntu)
Importance: Undecided
Status: New
--
This is the File - New - Software RAID Array window with a resolution
of 2048x1152. As you can see the text doesn't fit into the screen. In
the next screenshot at a smaller resolution it seems to do this just
fine.
** Attachment added: Screenshot-Create RAID Array.png
This is the same window but with a resolution of 800x600.
** Attachment added: Screenshot-Create RAID Array-1.png
http://launchpadlibrarian.net/34368121/Screenshot-Create%20RAID%20Array-1.png
--
gnome-disk-utility / palimpsest: Software RAID Array option window not wide
enough
This may or may not be related to bug #460643 (kind of similair thing in
a Thunderbird properties window).
--
gnome-disk-utility / palimpsest: Software RAID Array option window not wide
enough
https://bugs.launchpad.net/bugs/460627
You received this bug notification because you are a member of
The version from About is: Palimpsest Disk Utility 2.28.0
The version of the amd64-package is: Version:
2.28.0+git20091012-0ubuntu1
--
gnome-disk-utility / palimpsest: Software RAID Array option window not wide
enough
https://bugs.launchpad.net/bugs/460627
You received this bug notification
** Attachment added: The properties window at 1280x800 screenresolution
http://launchpadlibrarian.net/34368862/Screenshot-Account%20Settings-1280x800.png
--
Thunderbird Server-setting-properties-window in Karmic not wide enough
https://bugs.launchpad.net/bugs/460643
You received this bug
Public bug reported:
Binary package hint: thunderbird
It seems the default window-size or choosen text layout is wrong for the
server-settings-properties-window in Thunderbird when using a Karmic
Release Candidate Live-CD. Changing the screenresolution and choosing
Apply doesn't seem to help.
** Attachment added: The properties window at 800x600 screenresolution
http://launchpadlibrarian.net/34368839/Screenshot-Account%20Settings-800x600.png
--
Thunderbird Server-setting-properties-window in Karmic not wide enough
https://bugs.launchpad.net/bugs/460643
You received this bug
** Attachment added: The properties window at 2048x1152 screenresolution
http://launchpadlibrarian.net/34368870/Screenshot-Account%20Settings-2048x1152.png
--
Thunderbird Server-setting-properties-window in Karmic not wide enough
https://bugs.launchpad.net/bugs/460643
You received this bug
Public bug reported:
Binary package hint: deja-dup
Deja-dup preferences for sftp-account/server does not have the option to
specify a directory. And does not honour the folder setting in the
bookmark-window. This is the same in Karmic Beta, Release Candidate
(9.10) and Jaunty Jackalope (9.04). I
** Attachment added: These are the possible settings for a backup to Amazon
http://launchpadlibrarian.net/34369402/Screenshot-D%C3%A9j%C3%A0%20Dup%20Preferences-Amazon.png
--
Deja-dup sftp preferences doesn't allow specifying a directory
https://bugs.launchpad.net/bugs/460656
You received
As you can see here you can specify a directory but it will not honour
it, because gvfs (which seems to be the backend) doesn't honour it
either when you open the bookmark from the Places-menu it will go strait
to the root or chroot directory on the sftp-server. Now that I think
about it, maybe
This is the preferences window for sftp, as you can see it doesn't have
a directory option.
** Attachment added: Screenshot-Déjà Dup Preferences.png
http://launchpadlibrarian.net/34369969/Screenshot-D%C3%A9j%C3%A0%20Dup%20Preferences.png
--
Deja-dup sftp preferences doesn't allow specifying
Public bug reported:
Binary package hint: mtr
While using Jaunty/mtr-tiny and mtr version 0.75-2 I noticed a problem.
If the only recursive nameservers (the nameserver setting in
/etc/resolv.conf) that are available are IPv6, the dns resolution in the
ncurses ui fails.
In the --report mode it
Public bug reported:
Binary package hint: network-manager
(I tried subscribing to the ubuntu-devel mailinglist but I didn't get a
confirmation message, so I'm filing this as a 'feature-request-bug')
It seems there is a new version drivers that have a lot of things
fixed.
I would like to ask
70 matches
Mail list logo
