=== i486 is now known as amd64
[04:18] <daddy0> had mce errors daily for a week while using bionic... went back to xenial 7 days now and nothing
[04:18] <daddy0> hmmm
[04:19] <daddy0> any ideas?
[04:19] <daddy0> e6700 8gb ram gts450
[04:22] <lotuspsychje> daddy0: we talked about this before
[04:23] <lotuspsychje> daddy0: nvidia is a no go yet on wayland
[04:27] <daddy0> i was playing steam dota2, and some wine 3d games
[04:28] <daddy0> so it was all thru wayland?
[04:28] <daddy0> thought xorg was default for bionic
[04:28] <daddy0> forgive me im still learing a
[04:29] <lotuspsychje> daddy0: the final plan is xorg by default on 18.04 yes
[04:29] <daddy0> but wayland is the default for the alpha that im using?
[04:29] <lotuspsychje> daddy0: not sure if it changed already in this stage
[04:29] <daddy0> isee
[04:30] <daddy0> the mce errors said cpu fwiw
[09:21] <Ian_Corne> I'm not finding snap installed apps via gnome-shell, anyone else? Feature or bug?
[11:03] <tomreyn> daddy0: maybe be the bionic installation you had came with buggy intel microcode updates, this cuold explain mce's. i'm not sure whetehr those are on the installation media (then it's totally possible) or downloaded live (then i don't think this is what happened since those updates got pulled)
[14:07] <Ian_Corne> any other users of chrome and gmail notifications? It seems they lag hard when hovering over them
=== Night is now known as Guest71574
[17:29] <jackpot51>  Has anyone noticed delays in the Bionic daily image when running in QEMU?
[17:29] <hggdh> jackpot51: what type of delays?
[17:30] <Odd_Bloke> jackpot51: And by "Bionic daily image" you mean the daily ISO?
[17:30] <jackpot51> Before showing the ubiquity selection, there is a blank screen for about 30 seconds. Yes, I mean the dialy ISO
[17:30] <hggdh> sorry, did not ee that type of delay
[17:31] <jackpot51> bionic-desktop-amd64.iso from yesterday
[17:31] <flocculant> jackpot51: yup - though with xubuntu's daily - been seeing that for weeks though
[17:31] <jackpot51> I run it as follows: kvm -m 2G -vga qxl -hda hda.img -boot d -cdrom bionic-desktop-amd64.iso
[17:32] <jackpot51> -vga std does the same thing, by the way
[17:32] <TJ-> jackpot51: what is the host it's running on?
[17:32] <TJ-> jackpot51: Xenial?
[17:32] <jackpot51> Ubuntu 18.04
[17:32] <TJ-> jackpot51: so 18.04  on 18.04 ?
[17:32] <jackpot51> Yep :)
[17:34] <TJ-> could be related to qemu/kvm patches for PTI - you've got host-kernel+qemu/kvm --> guest-kernel interactions. Did the previous daily behave? Can we narrow down the point at which this began?
[17:39] <jackpot51> I believe this has been an issue for a while. A colleague of mine has the issue with the same ISO but using 17.10 as the host. I have seen it with dailies for at least the past week
[17:40] <powersj> the 30 second comment is interesting as we added a 30 second timeout during language selection
[17:40] <powersj> see: https://lists.ubuntu.com/archives/ubuntu-server/2017-November/007627.html for background
[17:43]  * powersj tries the desktop iso
[17:43] <flocculant> powersj: that sounds about as long as I've been having long boot times 
[17:44] <jackpot51> powersj: jderose will try Ubuntu server 18.04 on 17.10, I will try it on 18.04
[17:44] <flocculant> if in fact it's the issue on desktop
[17:44] <powersj> thanks - that would be good as I am not seeing the issue with server
[17:44] <jackpot51> It may be on desktop, but seeing it in xubuntu is odd. After server, we will try xubuntu and see if it feels like the same issue
[17:45] <flocculant> jackpot51: okey doke
[17:45] <flocculant> could be local to me - but who knows
[17:51]  * powersj sees "A start job is running for Ubuntu live CD installer"
[17:53] <jderose> powersj: in today's bionic server iso, i'm getting stuck at "Select and install software... Installation step failed". but no delay launching DI anyway
[17:54] <powersj> jderose: can you run md5sum on your server ISO so I can check it out
[17:54] <powersj> wanna make sure I'm using the same one as you
[17:56] <jderose> powersj: c302305611be0e0321f3b4fcbc9e53db  bionic-server-amd64.iso
[17:57] <jackpot51> I had success launching the server iso, b5c0b9a1221ac222ccd7cf0681a5984a *bionic-server-amd64.iso
[17:57] <jackpot51> Have not installed yet
[17:57] <powersj> jderose: ah the pending ISO suggest avoiding those as they do break and my CI will prevent bad ones from coming out
[17:57] <powersj> it is good though that all of us seem to be booting the server ISO correctly
[17:58] <jderose> ah right, forgot i'm using pending rather than current, will check current now...
[17:59] <TJ-> It looks like the delay is in syslinux, which implies a BIOS mode boot. Does it also happen for an EFI mode boot (which uses GRUB) ?
[18:02] <jderose> TJ-: yes, the delay is happing for jackpot51 and i in UEFI mode under QEMU also (using ovmf)
[18:02] <jackpot51> I have a delay with the 18.04 ISO on both BIOS and UEFI
[18:02] <TJ-> Just tested that, it doesn't delay for an EFI boot
[18:03] <jackpot51> Let me update my desktop image, I pulled mine yesterday
[18:03] <TJ-> For me it hits the GRUB menu, pauses about 4 seconds then auto-starts the "Try Ubuntu" entry
[18:04] <jackpot51> Does it change with -vga qxl ?
[18:04] <jackpot51> What arguments are you using?
[18:04] <TJ-> qemu-system-x86_64 -name Bionic-Test -m 2G -bios /usr/share/ovmf/OVMF.fd -machine accel=kvm -vga qxl -monitor stdio -serial tcp:127.0.0.1:9999 -k en-gb -drive file=/dev/sda,if=scsi,format=raw,readonly -cdrom /home/tj/Downloads/bionic-desktop-amd64.iso -boot d
[18:06] <jackpot51> On what host are you running?
[18:07] <jackpot51> For me, the delay occurs after the plymouth splash screen with that same command
[18:09] <jackpot51> I will let you know when I can rerun it with the latest ISO. The one I currently have has this md5sum: 064ab6173bc942d3327098f57748182e *bionic-desktop-amd64.iso
[18:09] <TJ-> jackpot51: I hit Esc to watch what's going on rather than leave splash up
[18:10] <TJ-> startup jobs seem to be trundling along,
[18:10] <jackpot51> I ran without quiet and splash, the screen goes blank before the halt. GNOME shell starting?
[18:13] <powersj> once it boots running `systemd-analyze blame` might be interesting, for me with that slightly modified command line from above I get 20s for plymouth-quit-wait.service
[18:14] <jackpot51> Here is the journal log: https://paste.ubuntu.com/26506933/
[18:15] <jackpot51> systemd-analyze returns 6.489s (kernel) + 1.637s (userspace) = 8.127s
[18:15] <jackpot51> Which is inaccurate
[18:15] <jackpot51> systemd-analyze blame has the hisghest time as dev-sr0.device, 2.224s
[18:16] <jackpot51> In the logs, there is a jump from Feb 02 18:10:29 ubuntu NetworkManager[974]: <info>  [1517595029.9565] manager: rfkill: WWAN hardware radio set enabled
[18:16] <jackpot51> To the next line Feb 02 18:10:40 ubuntu nm-dispatcher[1052]: req:3 'connectivity-change': start running ordered scripts...
[18:17] <jackpot51> That is at line 1384 in the paste. From line 1384 to line 1411, there is a time difference of 30 seconds. At this point, GNOME Shell reports starting
[18:25] <TJ-> From the serial console here it looks like there's the usual network-online.wait delay... graphical.target wants don't kick off until that comepletes
[18:26] <jackpot51> The same thing happens with the latest ISO: 50e3297bebfeea58ff5bd48f1e2d94fe *ubuntu-bionic-desktop-amd64.iso
[18:27] <TJ-> I also edit the kernel command-line before starting, so it has "debug console=tty0 console=ttyS0,115200n8 earlyprintk=serial,ttyS0,115200n8" (and quiet splash removed)
[18:27] <jackpot51> Ah, that would be good
[18:28] <TJ-> The qemu command above redirects the serial console to TCP port 9999, and I have "nc -l -p 9999 | tee /tmp/bionic-daily.log" running too to capture that /and/ be able to interact with the system by logging in at the "login:" 
[18:29] <jackpot51> Is there a reason why this wait time wouldn't be in systemd-analyze ?
[18:29] <TJ-> If it occurs /after/ graphical.target is achieved, yes
[18:31] <TJ-> try booting with "systemd.unit=multi-user.target" so the GUI isn't started. Then log-in, and do "systemctl start graphical.target" - see if there's any difference. THat should also separate out the real service bring-up delays from the GUI start-up
[18:32] <jackpot51> Ok, will do
[18:34] <jackpot51> Is there a password?
[18:34] <jackpot51> Ah, it is blank
[18:35] <jackpot51> The delay is after starting graphical.target
[18:35] <TJ-> jackpot51: line 1386 "dbus-daemon[969]: [system] Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)" -- 25 seconds --- could be implicated
[18:36] <TJ-> jackpot51: so check the gdm logs, /var/log/gdm/ I think
[18:37] <jackpot51> I think you are right. That happens after systemctl start graphical.target, and right at the delay
[18:37] <jackpot51> The bluez issue
[18:38] <TJ-> jackpot51: good that you've proved that is related to the graphical.target too
[18:39] <jackpot51> Maybe I should disable the bluez dbus service before running graphical.target?
[18:41] <TJ-> bug #1533206 looks to be related, I wonder if the patch got dropped during MIR
[18:41] <ubottu> bug 1533206 in Blueman "Blueman-applet crash on login: DBusException in call_blocking(): org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out" [Undecided,New] https://launchpad.net/bugs/1533206
[18:41] <TJ-> basically, if there's no BT device the bluez daemon can't be reached on DBus so things calling it end up timing out
[18:42] <TJ-> which might explain why VMs see it but bare-metal often doesnt (for laptops etc.)
[18:43] <jackpot51> After disable dbus-org.bluez.service, I do not get that message any more
[18:43] <jackpot51> But the delay is still there
[18:44] <jackpot51> Instead, I get Feb 02 18:10:53 ubuntu gsd-media-keys[1540]: Failed to grab accelerators: Timeout was reached (24)
[18:44] <jackpot51> Something similar to that
[18:46] <TJ-> jackpot51: right, and I checked - blueman still has the patch (and shouldn't affect a Gnome desktop anyhow)
[18:46] <TJ-> I suspect it's gnome-shell related
[18:47] <TJ-> although ... hmmm... that wouldn't affect xubuntu
[18:51] <TJ-> I'm testing today's amd64 image now
[18:55] <jackpot51> I can test Xubuntu as well
[19:19] <jackpot51> Yes, there is a delay in Xubuntu on my system as well
[19:22] <jackpot51> Logs here: https://paste.ubuntu.com/26509009/
[19:22] <jackpot51> Jump is at line 960
[21:04] <taohansen> when doing an apt update tracking "devel" in my /etc/apt/sources.list i receive this funky warning: https://gist.github.com/7931576c4babb39489b9adc82e226ff0
[21:04] <taohansen> everything appears to be functional but this warning implies to me that Ubuntu intends to remove support for tracking "devel" in the future? is that a corrent supposition?
[21:05] <taohansen> correct*
[21:06] <Odd_Bloke> taohansen: I'm not sure I follow your line of reasoning; devel points at bionic at the moment, and apt is making sure you understand that what you're asking for isn't what you're getting (at least, not verbatim).
[21:06] <nacc> taohansen: it might be apt being more verbose
[21:06] <Odd_Bloke> I don't see why you would infer that support is going away. :)
[21:06] <nacc> i'm not sure it's an archive change, reallly, as i thought devel was just a symllink
[21:07] <taohansen> Odd_Bloke: irrational paranoia perhaps. 🙂 thanks for clearing up my confusion
[21:50] <TJ-> How /on earth/ is one supposed to interact with the Gnome network manager applet to configure a connection? There's a mutli-application drop-down, but it just says "Wired Connecting" and no way to influence it. Desktop has "Network Manager 1 new notification" but no way to interact with it, either
[21:51] <nacc> TJ-: on my system if i click up there, each network device has a twisty section (smalll right-facing triangle)
[21:51] <nacc> TJ-: and under each of those i can change settings, disablle, etc
[21:52] <TJ-> nacc: the desktop shows a clock too; is this some form of screen-lock? I don't seem able to get rid of it
[21:52] <nacc> TJ-: i've never had a clock on my desktop :)
[21:52] <nacc> i have a clock in the panel at the top
[21:54] <TJ-> nacc: this is in a qemu VM: http://iam.tj/projects/ubuntu/bionic-daily-desktop.png
[21:54] <nacc> Tah yes, that llooks like th elock screen
[21:54] <nacc> i *think* this is the thing people have talked about, you have to 'swipe up' or something?
[21:55] <nacc> i'm really not sure
[21:55] <TJ-> hmmm, so how does one get rid of it I wonder?
[21:55] <nacc> i have not fresh istnalled in a while, so i don't know :)
[21:55] <nacc> but i would ugess that's why it's grayed out
[21:55] <TJ-> nacc: You're correct! Well I'll go to the foot of our stairs, what a silly non-intuitive behaviour for a desktop and mouse!
[21:56] <nacc> yeah, i think it's somethig inherited from convergence-like bheavior
[21:56] <TJ-> there should at least be a graphic hint there :D
[21:56] <nacc> but i really dont' know, someone else complained about that (possibly here) a while ago
[21:56] <nacc> there used to be like a arrow path at the bottom (and a grabber)
[21:56] <nacc> but y'know, gnome being all modern, maybe they removed that :)
[21:56] <nacc> </sarcasm>
[21:56] <TJ-> :p
[21:57] <TJ-> You know my views ... I'm just trying diagnose this long delay at start-up for the installer
[22:00] <TJ-> I get more utility out of the 115200 baud serial link I've got connected to it's console
[22:03] <nacc> TJ-: :)
[22:04] <TJ-> * except when I forget and press Ctrl+C and kill the entire VM :D doh