[01:28] hi 16.04 solved my blank monitor problem. i have a gtx 960 ssc and a 4k and hd monitor [01:28] i first tried 14.04.3 [01:29] only non fatal error i got was fecs install had failed? [01:29] i'm using the tested nvidia prop drivers and it's a lot smoother than xorg [01:30] anyhoo it's the daily build for 16.04 i'll [01:30] do i need to enable anything for system stats/feedback in xenial? [01:32] thanks folks :) [07:53] howdy [07:54] Will we be able to move the panel to the bottom when 16.04 is out? === lordieva1er is now known as lordievader === lordievader is now known as Guest98681 === Guest98681 is now known as lordievader [08:56] Good morning. === uaa is now known as Guest14860 === Guest14860 is now known as damascene === IdleOne is now known as Guest13578 === damascene is now known as Guest58378 === Guest58378 is now known as damascene [11:49] Hi folks === jrib is now known as Guest26166 [13:55] first upgrade attempt 1404 -> 16.04 was a great success [13:56] kernel paniced during the upgrade [13:56] very weird [13:56] not sure how that can even happen [13:57] jtaylor: its not recommended to upgrade yet from trusty [13:58] jtaylor: clean install instead to test [13:58] lotuspsychje: someone has to test the upgrade [13:59] jtaylor: sure, but still not recommended in this stage [13:59] I'm aware of that [14:00] lets say you want to report a bug to 16.04 and you have some weird leftover from 14.04 [14:00] not very effective [14:01] I'm able to figure that out, but not what could cause a panic during an upgrade [14:01] it shouldn't touch the running kernel at all [14:19] jtaylor are you trying recover that installation? [14:19] joumetal: I'm currently doing so [14:20] joumetal: interesting the kernel also panics on boot [14:20] but by setting init to bash I can rerun the installation [14:20] lets see what comes out when its done [14:22] my guess is its somehow related to my lvm setup [14:22] maybe the upgraded migrated something on disk and the current kernel (4.2) could not deal with it [14:22] (or corrupted) [14:25] jtaylor, the latest kernel for 16.04 is 4.4 [14:26] but 14.04 is 4.2 [14:26] nop [14:26] well not yet latest but soon ;) [14:26] !info linux-image-generic trusty [14:26] lts-wily whih will be default on the next point release [14:26] linux-image-generic (source: linux-meta): Generic Linux kernel image. In component main, is optional. Version 3.13.0.77.83 (trusty), package size 2 kB, installed size 29 kB [14:26] lotuspsychje: hats 14.04.0 [14:26] I'm on 14.04.4 [14:27] (not yet released) [14:27] then what are you doing in #ubuntu+1? [14:27] I'm testing the upgrade to +1 [14:27] Is there a set time in the release schedule at which point it would be safe to rely on apt-get upgrade getting you to the same state as a fresh install of the release? In particular, at what point will that apply for alphas/betas/etc. of 16.04? [14:27] I thought that there were still points during the early alphas where changes to the install infrastructure could result in the final install being different? [14:28] nneul: there is no set time, its always the case [14:28] jtaylor, do you have / and /home partitions? [14:28] nneul: its not recommended to upgrade until final, fresh install 16.04 for testing [14:28] jtaylor: so it's reasonable to rely on: (install of release on april >21) == (install of alphas + apt-get upgrade on april >21) ? [14:29] you might accumulate some stuff thats not present in a clean fresh install [14:29] but generally upgrading gets you to a very similar state [14:29] nneul: local config files might differ though as they are creted at runtime [14:29] BluesKaj: no /home, but lots of lvm partitions [14:29] ok, that works. those sorts of things are just normal expectations of any time you do updates... [14:29] Thank you! [14:29] jtaylor: Is upgrading from Trusty already possible? [14:29] With the -d flag or something? [14:29] lordievader: no [14:30] lordievader: possible yes, should you do it no [14:30] jtaylor: Wasn't planning that ;) Having one test box is enough. [14:32] jtaylor, if you had a /home partiton then you could install to / and simply set the mountpoint for /home during the installion partitioning phase, and you'd have an up to date clean install if you chose a daily image iso . [14:33] BluesKaj: if I did not want to test the upgrade that would be option [14:33] but I do ;) [14:33] (I expected it to fail, but not like that) [14:34] i don't see the point of testing theupgrade proces, but that's your call [14:36] BluesKaj: That path should also be tested. Quite a lot of people don't want to reinstall when going to Xenial. [14:38] * BluesKaj shrugs, ok lordievader be my guest, have fun :-) [14:38] upgrade proces will be tested by the devs too right [14:38] i dont see the point either [14:38] I'm not saying I'm going to test is. But I am saying testing the upgrade is valuable. [14:39] lotuspsychje: Most testers on iso.qa.u.c are volunteers. Probably only a handfull are developers. [14:39] lotuspsychje: upgrades depend on what is installed [14:39] there are so any changes made everyday, i's like chasing bubbles IMO [14:39] against wich file would a bug be filed for an upgrade? [14:39] lotuspsychje: it is impossible to test all permutations [14:39] lotuspsychje: (also I am a dev) [14:39] upgrades are always tricky [14:40] It is strange that iso.qa doesn't list any upgrade tests though. [15:32] hurray the borked upgrade has recovered and I have a working system :) [15:33] nice [15:34] quite amazing that a 3000k package upgrade of a system actually works with only some minimal nodding [15:36] did you use update-manager? [15:36] do-release-upgrade [15:36] but that paniced at an unknown state, quite early [15:37] the rest just dist-upgrade -f and install -f and some manual removals where that failed [17:31] hi [17:32] is it normal, on xenial, that a normal user can do "init 6" in terminal? [17:35] init 6 rebooted [17:36] sure, but for normal users??? [17:36] on 14.04 it needs root rights [17:37] sudo init 6 [17:40] i am using ubuntu-studio 16.04, and i do not understand, that "init 6" is working for a normal user ... [17:48] any idea? [17:50] Ain't that polkits doing? Since desktop users can reboot a machine, I suppose the same counts for running init 6. (Which will probably be translated to systemctl reboot) [17:53] what means desktop user? in the moment a normal user can reboot or shutdown (init 0) the server ... is that normal? [17:54] For a server it might be different. But for the desktop flavours of ubuntu the normal users are able to reboot the machine. [17:54] Anyhow, like I'd said I'd investigate polkit for this. [17:55] since when is it normal, that a user. without su, can do init 6 or init 0? [17:56] I don't know about init, but like I said a desktop user should be able to reboot a machine. And since init is replaced with systemd... [17:58] ok, since when a user can do "systemctl isolate rescue.target", for exp., without root permission? [17:59] If polkit is setup to allow that, a user can. Have you investigated the polkit settings? [18:00] sorry, but what is polkit? [18:00] Guest60557: https://www.freedesktop.org/wiki/Software/polkit/ [18:01] ok === michael__ is now known as Guest65238 [18:10] lordievader, systemctl isolate ... .target needs root password, but init is working without password [18:13] any idea? === Guest86349 is now known as IdleOne [19:03] Hmm, that is odd. Especially seeing that run levels do not really exist anymore.. [21:00] Unity launcher on the botton -> is it possible using current build ? [21:00] dbarros: no [21:01] not even by a workaround? [21:01] there was a patch proposed but not accepted. you could compile that patch in yourself [21:04] https://code.launchpad.net/~feng-kylin/unity/unityshell-rotated-kylin/+merge/281182 [21:04] this is the patch all the news sites say its already included into 16.04, but its not [21:05] I see