[05:10] <lotuspsychje> good morning to all
[05:36] <lotuspsychje> mornin sirru5h
[05:36] <sirru5h> Howdy everyone lotuspsychje sup
[05:36] <lotuspsychje> aqbout to breakfast mate :p
[05:36] <sirru5h> lol you always beat me
[05:37] <lotuspsychje> heh
[05:37] <sirru5h> Ahh very good night time here
[05:37] <sirru5h> You must live in asia or australia
[05:37] <lotuspsychje> belgium
[05:37] <lotuspsychje> european timezone
[05:38] <sirru5h> ha interesting I guess it would be what 5am there
[05:38] <lotuspsychje> 7h38
[05:38] <lotuspsychje> morning Sveta
[05:38] <Sveta> good morning lotuspsychje :-)
[05:39] <sirru5h> 8 hrs ahead alright good stuff
[05:40] <sirru5h> lotuspsychje, I got a question for ya
[05:41] <lotuspsychje> shoot
[05:41] <sirru5h> In Ubuntu 17.10 in wayland do gui apps work in terminal when you use sudo
[05:42] <lotuspsychje> sirru5h: ive read they would block that by default
[05:44] <lotuspsychje> sirru5h: didnt test gksudo on artful yet
[05:44] <sirru5h> Yeah only issue is that even in GUI using "Activities" I only get the authentication prompt but no Synaptic
[05:44] <sirru5h> Like I get around that but meh : /
[05:50] <sirru5h> It's odd not sure if it is a bug or what extactly
[05:52] <lotuspsychje> sirru5h: not sure what you mean exactly, synaptic is GUI?
[05:52] <Bashing-om> sirru5h: No GKSU un wayland : https://ubuntuforums.org/showthread.php?t=2374812 work-a-round .
[05:57] <sirru5h> Bashing-om, now synaptic package manager works may have to put it into cron
[05:57] <Bashing-om> sirru5h: :)
[05:58] <lordievader> Good morning
[06:39] <Bashing-om> Good nite guys \o
[07:03] <ducasse> morning all
[07:22] <jink> Morning, ducasse.
[07:25] <ducasse> hiya jink
[07:26] <ducasse> rise and shine! :)
[07:26] <jink> Heh.
[07:26] <jink> I was at work an hour and a half ago.
[07:29] <ducasse> :)
[08:13] <lotuspsychje> bbl work
[09:52] <BluesKaj> 'Morning folks
[11:55] <TJ-> nacc: ping?
[13:24] <pauljw> Hi everyone
[13:58] <TJ-> 18.04 = Brilliantly Bionic
[14:00] <BluesKaj> TJ-, what's you reference?
[14:00] <TJ-> Me!
[14:00] <BluesKaj> heh
[14:00] <pauljw> heheh
[14:01] <TJ-> Mark Shuttleworth actually
[14:02] <BluesKaj> tried installing kxstudio, no public key available for 17.10
[14:04] <BluesKaj> TJ-, ^
[14:05] <TJ-> I pulled it in manually with "apt-key adv --keyserver hkp://keyserver.ubuntu.com --recv-key <KEYID>"
[14:05] <BluesKaj> oh , I forgot about that ...thanks
[14:10] <ducasse> TJ-: has that actually been announced now? 18.04, i mean?
[14:15] <nicomachus> I thought it would be in this interview if anywhere, but it's not: http://www.omgubuntu.co.uk/2017/10/why-did-ubuntu-drop-unity-mark-shuttleworth-explains
[14:15] <TJ-> ducasse: yes
[14:15] <TJ-> see http://markshuttleworth.com/archives/1518
[14:17] <ducasse> " I give you 18.04 LTS, the Bionic Beaver."
[14:17] <ducasse> that sounds better...
[14:18] <TJ-> heheh
[14:18] <TJ-> I prefer Brilliantly Bionic
[14:18] <TJ-> brings back memories of Lee Majors in the Bionic Man TV series
[14:19] <ducasse> i dunno, i bionic beaver could be one hell of a mascot :)
[14:19] <TJ-> I think he's going to have some problems with the USA audience for which "beaver" has certain 'other' connatations"
[14:20] <TJ-> I can imagine the memes now
[14:21] <ducasse> lol
[14:21] <pauljw> i'm sure it's not just the USA with those other connotations...
[14:21]  * TJ- whistles
[14:25] <nicomachus> LOL, the bionic beaver...
[14:25]  * nicomachus is USA audience and is burshing off GIMP for meme making
[14:26] <pauljw> :)
[14:57] <nacc> TJ-: pong
[14:57] <nacc> TJ-: saw the discussion with sil in the other channel
[14:57] <nacc> TJ-: do you want me to do the ppa build?
[15:48] <TJ-> nacc: Hiya - just back from running the Huskies! I'm going to create a bug report to capture all the info we gathered and then get maszlo to subscribe to it, and then we can look at doing some builds. I need to confirm just what dbus patches are in 17.10 related to the fd in-flight issue first. I've also seen signs that despite disabling laptop-mode, it was still doing 'stuff' so I'm going to get him
[15:48] <TJ-> to purge that package first before we do anything else.
[15:49] <TJ-> nacc: I suspect the reason it works on USB but not SSD is simply I/O throughput, so nto convinced its a valid data-point
[15:49] <TJ-> nacc: if maszlo does a HDD install as he suggested he might, and that works, that'd also point to the SSD being so fast there's some race-condition combined with some kind of power-saving modes somewhere.
[15:51] <TJ-> nacc: the weird part is, the messages "EXT-fs (sda6) Opts errors=remount" that occur multiple times come from the ext4 driver at the end of its successful remount() function, so there's no real clue what is putting the rootfs back into ro mode!
[15:53] <maszlo> TJ-: nacc: good day
[15:54] <TJ-> maszlo: I'm just creating a master bug report so we can capture all the info properly and offer some options of patched packages if appropriate
[15:54] <TJ-> maszlo: did the M2 install see the same issue on battery?
[15:54] <maszlo> TJ- nacc : these are the logs i pulled this morning. comparing the faulty boot and boot of fresh 17.10, both on battery. This is the fresh install: journalctl http://paste.ubuntu.com/25810306/ and dmesg http://paste.ubuntu.com/25810343/  And then there are the one trying to get working journalctl http://paste.ubuntu.com/25810351/ and dmesg http://paste.ubuntu.com/25810355/
[15:54] <maszlo> TJ-: It did not M2 boots just fine
[15:55] <TJ-> maszlo: did you already report this bug in Launchpad? If you didn't someone else has reported something very similar Bug #1725458
[15:56] <TJ-> maszlo: That's on an HP so not you!
[15:56] <maszlo> I have not posted this.  was hard for me to point where the actual issue was
[15:57] <TJ-> haha it also says the fix is what I thought about last night after you'd gone! the fstab doesn't have a "defaults" so "rw" isn't being applied!
[15:57] <TJ-> maszlo: edit /etc/fstab, for the root / entry options change to "rw,errors=remount-ro"
[15:58] <TJ-> maszlo: according to that user that appeared to work *once*
[15:58] <maszlo> TJ-: 'workaround' though right? its what ever is querying the battery
[15:59] <TJ-> maszlo: yes, try it though. Then - based on what I noticed in the logs - purge the laptop-mode-tools package completely off the system
[16:00] <TJ-> maszlo: those are all to try to confirm there's actually a race condition/bug between systemd and dbus. Your log has lots of "Transport endpoint is not connected" - what that means is systemd lost its connection to the service clients it controls using them via Dbus.
[16:00] <Bashing-om> maszlo: TJ- If any help . My fstab entry for an SSD " UUID=d9c2a8e6-d014-42a6-846f-7e7892f4aef5 /               ext4    noatime,errors=remount-ro 0       1 " .
[16:00] <maszlo> TJ-: what is the kernel parameter vt.handoff=7  i dont have that on the upgraded system but on the fresh
[16:01] <TJ-> maszlo: so I'm thinking this issue could be related to 2 bugs in dbus recently fixed. we should be carrying a patch for one of them, but not for the other
[16:01] <TJ-> Bashing-om: are you using 17.10 ?
[16:02] <TJ-> maszlo: that's for the display manager to try to prevent screen flicker when the console hands over to the GUI
[16:02] <Bashing-om> TJ-: No .. sorry that is a 16.04 install . I read that 17.10's vt_handoff is VT1 vice VT7 now .
[16:03] <TJ-> GDM runs on tty1 yes but I suspect the handoff is more for Xorg's benefit.
[16:04] <maszlo> TJ-: i noticed that my upgrade still starts up laptop-mode.. and the fresh install i see nothing in that log
[16:06] <TJ-> maszlo: I was wondering if the ext4 option "commit=600" added by l.m.t is causing the issue
[16:06] <TJ-> maszlo: which is why I suggest purging since that option was being added even when we disabled all of l.m.t
[16:07] <maszlo> what is the proper way to do that 'sudo apt-get purge laptop-mode-tools' ?
[16:08] <TJ-> maszlo: yes
[16:08] <maszlo> i noticed something.. has apt replaced apt-get?
[16:08] <maszlo> seems like parameters after that are all the same
[16:11] <maszlo> TJ-: after that do i just install it again?
[16:15] <TJ-> maszlo: apt is the user-friendly front-end to apt-get etc.
[16:15] <maszlo> TJ-: so.. after i run purge i rebooted couple times and powered on fine without AC.  booted into the fresh 17.10 and it does not even have laptop-mode-tools installed
[16:16] <TJ-> maszlo: so that points the finger at l.m.t. doesn't it?
[16:16] <TJ-> maszlo: the report is bug #1726930
[16:17] <maszlo> TJ-: yes it does.  only difference i see between the two is that the upgraded 17.10 without laptop-mode-tools does not have working buttons to dim / brighten the lcd.. this does work on fresh
[16:18] <TJ-> maszlo: that could be something to do with the thinkpad_acpi module; I think that is responsible for those platform bits
[16:19] <TJ-> maszlo: it's possible the upgrade is carrying some different config options somewhere that effect that
[16:20] <TJ-> maszlo: I was reading the laptop-mode code earlier trying to deduce if it could cause this. I'll dig deeper now. I suspect it puts the SSD into a very low power state which is adding latency in a way that is causing the isue
[16:20] <maszlo> TJ-: possible that is one of the other things we disabled?
[16:21] <TJ-> maszlo: I don't think there is anything else disabled is there? we left it with laptop-mode.service, laptop-mode.timer and lmt-poll.service disabled, but it seems something was still operating from l.m.t. despite that
[16:21] <TJ-> maszlo: we re-enabled systemd-resolved, systemd-hostnamed, colord
[16:21] <TJ-> maszlo: what happens if you install l.m.t. to the fresh 17.10 install on the M2 device?
[16:22] <maszlo> TJ-: all three of those services are in part of laptop-mode-tools i take it?
[16:22] <maszlo> TJ-:  i can try that now
[16:25] <BluesKaj> TJ-, 18.04 is Bionic Beaver , another dumb handle :-)
[16:28] <maszlo> TJ-: will give this another minute.. looks like after installing the laptop-mode-tools on M2 it does the same thing.  I just cant get to tty2 and have stupid splash and quiet params on there
[16:31] <TJ-> maszlo: try pressing the Esc key, that should clear the plymouth splash
[16:32] <maszlo> TJ-: yeah did that second boot, strange thing is it didnt freeze on second boot
[16:32] <maszlo> laptop_mode does still act fishy.. only works when on battery power, but it did allow system to boot
[16:34] <TJ-> maszlo: I'm wondering if some of the power-saving options it applies to the mass storage device(s) are causing extreme latencies on the device
[16:34] <BluesKaj> I might as well post it here too,  ‎ Development starts in only two days, on October 26, when the toolchain is uploaded to the archives,    http://news.softpedia.com/news/ubuntu-18-04-lts-dubbed-as-the-bionic-beaver-launches-april-26-2018-518186.shtml
[16:34] <TJ-> maszlo: I think we need to collect detailed info  on the storage devices
[16:34] <maszlo> TJ-: this is on the M2 http://paste.ubuntu.com/25810708/
[16:36] <TJ-> maszlo: that's what I'd expect. It doesn't do anything when on AC (unless you configure it to do so) l.m.t.'s purpose is to extend battery life by applying aggresive power-saving options to devices
[16:37] <maszlo> TJ-: what value do you suppose 'state' is pulled from?  status?
[16:38] <TJ-> maszlo: can you "sudo apt install hwinfo" and then "sudo hwinfo |& tee hwinfo.log"
[16:38] <maszlo> TJ-: that is probably it.. just noticed that that BAT1 shows Discharging, and BAT0 shows Unknown
[16:40] <TJ-> maszlo: sounds about right. sounds like that bug in the battery firmware I referred to last night
[16:41] <TJ-> maszlo: if you have a launchpad account add that hwinfo.log as an attachment to the bug report
[16:43] <TJ-> maszlo: I'm wondering if this issue is provoking another bug in systemd/dbus because those Transport endpoint disconnects shouldn't happen
[16:48] <maszlo> TJ-: crap.. i did that hwinfo from the M2.  is that where wanted to run that from?
[16:49] <TJ-> maszlo: it doesn't matter, it's info on the system hardware and will/should include the SSD :)
[16:51] <TJ-> maszlo: is the CT500BX100SSD1 the one with the upgraded system on it?
[16:51] <TJ-> maszlo: the other is SanDisk SSD U110
[16:52] <maszlo> TJ-: correct the CT500 is the upgrade, and SanDisk is the M2
[16:52] <TJ-> I'd guess so; 465GB vs 15GB
[16:53] <maszlo> TJ-: that 16GB one was the 'hybrid' drive option with hdd.  Its cool extra space for hidden os
[16:54] <maszlo> TJ-: used it for RemixOS (android) for a bit, but has held kali or tails until yesterday when became part of testing
[16:55] <TJ-> Woa! on 17.10  "apt-cache rpdends laptop-mode-tools" shows "systemd" depends on it
[16:55] <maszlo> TJ-: but then why was it not installed on my fresh 17.10 install?
[16:55] <TJ-> ... *but* "apt-cache depends systemd" show's it's a "Break"!! Breaks: laptop-mode-tools
[16:56] <TJ-> maszlo: rdepends picks up depends/recommends/breaks/conflicts
[16:56] <TJ-> so, systemd here is actually declaring it breaks l.m.t. but a do-release-upgrade isn't removing l.m.t.
[16:57] <maszlo> TJ-: oh
[16:57] <maszlo> TJ-: so the real fix is to just remove it
[16:58] <TJ-> maszlo: yeah... I guess as it was already installed theres was nothing in systemd post-inst scripts to mark l.m.t. for removal
[17:01] <maszlo> TJ-: I dont know why, but i commented out that line from /etc/default/grub and my brightness buttons work again.  maybe it didnt like windows :P
[17:03] <TJ-> maszlo: you mean the acpi_osi=Windows 2015 ?
[17:04] <maszlo> TJ-: yeah i just commented out that whole line, still have debug on too
[17:04] <TJ-> maszlo: well if the system behaves without out that's progress I guess
[17:04] <maszlo> TJ-: I am betting its something with this.. the status is unknown because BAT0 is not used until BAT1 is dead.  that is probably why its not listed as discharging
[17:05] <TJ-> maszlo: right, it could be that, but the l.m.t. code does a loop over all nodes in /sys/power_supply/ so it should see BAT1's status too
[17:05] <maszlo> TJ-: Yeah just ripping that lmt out seems to have done it
[17:06] <maszlo> TJ-:  maybe i missed it, thought it was only complaining about BAT0
[17:07] <nicomachus> some of the reactions to BB on reddit are exactly as predicted.
[17:07] <TJ-> yes, it only logged the complaint about BAT0. If l.m.t. DEBUG logging were on it'd report all the devices it finds etc.
[17:07] <nicomachus> https://www.reddit.com/r/Ubuntu/comments/78fseb/ubuntu_1804_lts_is_bionic_beaver/
[17:08] <TJ-> fnarr fnarr!
[17:11] <maszlo> TJ-: going to send you a pm
[17:13] <TJ-> maszlo: It's disabled :)
[17:13] <maszlo> TJ-: i see that.  wanted to paypal you some coffee money
[17:17] <TJ-> maszlo: thank-you, but it's not necessary :)
[17:18] <maszlo> TJ-: No thank you.  wanted to provide some fuel for hunting bugs
[17:20] <TJ-> As I said at the start last week, I don't allow software to beat us
[17:21] <maszlo> TJ-: :D
[17:29] <TJ-> maszlo: I dunno about you but I feel extremely relieved we've got to the bottom of it, after the intensity of the debugging
[17:56] <TJ-> maszlo: nacc Bingo! I thought there might be something being triggered by udev based on the logs, and the debian bug report changelog entry confirms that was the original problem: "This avoids that broken software
[17:56] <TJ->      like laptop-mode-tools, which runs mount from within udev rules, causes
[17:56] <TJ->      the root file system to end up read-only"
[17:57] <TJ-> maszlo: that'd explain why this still happened when we disabled l.m.t. services. It also installed a udev rule which udev was firing
[18:09] <TJ-> nacc: looking at the patch for systemd_215-5ubuntu1 that includes that Debian patch, it's debian/patches/udev-re-enable-mount-propagation-for-udevd.patch and it simplt removes "MountFlags=slave" from /lib/systemd/system/systemd-udevd.service
[18:11] <nacc> TJ-: yeah, i thinnk we want to figure out what changed in l-m-t
[18:11] <TJ-> I'm checking now
[18:12] <TJ-> now I know what the crux of the issue is it shouldn't be too hard.
[18:14] <maszlo> TJ-: i am not sure where this would be found.. but I am assuming that this not being a common issue.. maybe this was a default package in Ubuntu-gnome but not ubuntu 17.04?
[18:17] <nacc> TJ-: laptop-mode is *supposed* to remount your fs??
[18:17] <nacc> TJ-: (readig some of the commit messages)
[18:19] <TJ-> nacc: yes, with "commit=600" we see in maszlo cases, but it shouldn't cause a read-only remount
[18:19] <TJ-> nacc: this looks to be close https://git.launchpad.net/laptop-mode-tools/commit/?id=695afe51215a28a05f2ce0fba2656f32f2a0a421
[18:20] <TJ-> if udev was killing a background process that might explain why l.m.t. seemed to be repeatedly executed
[18:20] <nacc> TJ-: that should be in th eversion in artful
[18:21] <nacc> TJ-: also, to be sure, in maszlo's case, purging lmt didn't always fix it?
[18:22] <nacc> or did it?
[18:22] <TJ-> yes it did, always, and installing it into the fresh install also provoked the bug
[18:23] <nacc> ah ok
[18:23] <nacc> TJ-: sorry, wasn't caught up on that
[18:26] <nacc> TJ-: sure would be nice if the systemd changelog actually referred to what fixed it in l-m-t
[18:26] <TJ-> I'm wondering if the fact we've got l.m.t. trying to run that in the foreground (from etc/rules/lmt-udev) to deal with an earlier systemd issue has been caught out by artful's version of systemd! Sort-of a cat-n-mouse game. It'd be worth trying to revery that not-in-background change *and* try removing the system-udevd.service setting for MountFlags=slave" too
[18:28] <nacc> TJ-: yeah
[18:28] <TJ-> oh you bB&^&^%! - the udev rule: ACTION=="add", SUBSYSTEM=="usb", RUN+="lmt-udev force"   ... I did notice that the l.m.t. invokations seemed to be around USB device discovery
[18:29] <TJ-> the problem is, l.m.t. being shell scripts not a proper daemon
[18:30] <TJ-> 5 new USB devices discovered... 5 extra invocations of l.m.t force
[18:30] <nacc> TJ-: ah
[18:30] <TJ-> we had 5 instances of the messages repeated
[18:30] <nacc> TJ-: yep, i was just reading another commit in l-m-t about the triggers
[18:30] <TJ-> which commit? I'm getting lost :)
[18:31] <nacc> TJ-: ok, so there are two orthogonal changes, it seems like -- 1) systemd enabled mount propogation to workaround buggy l-m-t udev rules that remount fs, which result in private mounts for systemd-udevd's namespace and that trip the root fs outside of that namesapce to become ro
[18:32] <nacc> 2) l-m-t at some point supposedly fixed their udev rules (1.68, but I'm still not seeing an obvious change), but perhaps it is ef0d749abaf4ccfa408c41b4e8d744b423daff23 ?
[18:33] <TJ-> nacc: wasn't the 'fix' just to not background the lmt-udev script call to non_systemd_way ?
[18:35] <nacc> TJ-: i think that fix came later
[18:35] <nacc> based upon the versioning
[18:35] <nacc> that is, 1.68 doesn't have the fix you are referring to, afaict
[18:36] <TJ-> right! ef0d749a points to that USB udev rule I pointed out above
[18:37] <nacc> TJ-: yeah, but that is also not in 1.68 :)
[18:37] <nacc> TJ-: (it's also possible systemd's changelog is wrong)
[18:37] <maszlo> maszlo
[18:38] <daftykins> yeah that's you!
[18:38] <maszlo> lol ops thats not search
[18:38] <TJ-> but systemd maybe weren't aware of this change, there's been changes on both sides over time relating to udev killing foreground, then killing background, processes as well as the mout slaves issue
[18:38] <nacc> TJ-: yeah, that might be it
[18:38] <nacc> it might have been 'fixed' at one point, but both sides moved and broke it
[18:38] <TJ-> nacc: I need a coffee!!
[18:39] <maszlo> daftykins: i was looking for time stamp of when removed a package.. back from lunch and still on BAT1
[18:39] <nacc> TJ-: yeah, and systemd is a bear
[18:39] <TJ-> nacc: indeed, that's what it looks like
[18:39] <nacc> TJ-: I think i can probably get someone from foundations to look, if we have the bug filed
[18:39] <TJ-> nacc: I'll do some more digging before you need to do that. I'd like to try reproducing it here
[18:40] <nacc> TJ-: 5fe7a63738fb758f1d5f8809d8fc0bcdce2f1e4a seems like a likely, related, commit
[18:40] <TJ-> nacc: it would be good to have absolute proof of what is going on with debug logs from both packages
[18:40] <nacc> TJ-: so that's probaby the 'fix' referred to by the systemd changelog
[18:40] <nacc> TJ-: and then the fix was fixed as systemd changed behavior in the commit you found
[18:41] <nacc> TJ-: and then the systemd service was also changed in  ef0d749a
[18:41] <TJ-> timeline looks about correct
[18:41]  * TJ- rolls eyes
[18:42] <daftykins> maszlo: 'BAT1' doesn't mean anything to me :)
[18:42] <TJ-> i think enabling udev debug logging is the next step. if we can show it causing rootfs to be remount-ro that'll clinch it
[18:43] <maszlo> TJ- nacc this might not be needed but guess was correct, the status 'Unknown' that it was complaining about BAT0 being bad was might have been that it was in idle state.  soon as BAT1 emptied out /sys/class/power_supply/BAT0/status now shows discharging
[18:43] <TJ-> daftykins: maszlo's Lenovo has 2 batteries BAT0 and BAT1, there's problems with laptop-mode-tools not being able to read the status of BAT0. We wondered if that was the trigger for the bug we're working on
[18:43] <daftykins> amusingly i have a client with a Lenovo X240 where the internal battery went AWOL entirely under Windows the other day
[18:44] <maszlo> nacc: TJ- would it be worth wild putting lmt back in to see if it boots with that state?
[18:44] <TJ-> maszlo: I think that could be it, I think we have an intersection of 3 bugs here in 3 separate places: 1) battery firmware, 2) l.m.t. and 3) systemd-udevd
[18:44] <TJ-> maszlo: indeed it would
[18:45] <maszlo> TJ-: BAT1 is now status 'unknown' btw
[18:45] <TJ-> daftykins: there is a known (recall) issue with batteries on many lenovo models due to a bad firmware in Panasonic-made batteries. You should check if your client is affected
[18:45] <daftykins> if booted with AC power in, it would stay on with the internal battery connected, but the OS and firmware had no idea where it was receiving power from :)
[18:45] <TJ-> maszlo: that is weird
[18:45] <daftykins> mmm well it's 2014 model so i doubt it
[18:46] <TJ-> daftykins: worth checking. recalls due to faulty manufacture don't expire with warranty
[18:46] <maszlo> TJ-:  i did check, neither of mine were panasonic.  My BAT0 is sony, and BAT1 is LGC
[18:46] <TJ-> maszlo: yeah... you're OK :)
[18:47] <TJ-> maszlo: I think we may j push this to upstream to l.m.t. devs since it's getting quite confusing... maybe its a problem with 2 batteries *and* state unknown
[18:47] <TJ-> maszlo: they maybe 'assume' there's only 1 battery
[18:47] <TJ-> maszlo: although as I said, the code loops over all nodes in /sys/class/power_supply/
[18:48] <daftykins> already pulled it and have tossed it i think :)
[18:48] <TJ-> time to get dressed - still in my running kit :)
[18:48] <daftykins> larger capacity unit has been purchased for the secondary, that internal one was a tiny toy of 2000mAh iirc
[18:50] <maszlo> daftykins: this is only my first notebook that isnt a bunch of 18650 cells.  not sure out it gets 5-6 hr?!
[18:51] <daftykins> what's the model?
[18:52] <maszlo> 2000mah is like one 18650.. I used recycled them to esp8266 projects and flashlights :)
[18:52] <maszlo> daftykins: this is T450s
[18:53] <maszlo> daftykins: maybe is more like 3-4hrs i dunno.. i am came from a terrible linux system that used optimus dual video cards (asus)
[18:53] <daftykins> mmm seen plenty of those in my time, makes life a lot easier for pure portability having intel only
[18:54] <daftykins> i'm still not convinced Linux is ever a wise choice for battery longevity though :)
[19:03] <TJ-> my notebook gets about 11 hours
[19:04] <TJ-> ouch! "[Parent 1858, Compositor] ###!!! ABORT: DRI2SwapBuffers         : BadDrawable"  Firefox crash whilst lock-screen was up
[19:05] <TJ-> Asus Transformer T300chi, kinda tablet hybrid with bluetooth keyboard
[19:10] <lordievader> TJ-: That is quite a lot. Mine does about 5 hours.
[19:11] <lordievader> Coming from 2-ish hours that is quite an improvement :)
[19:12] <TJ-> Yes, I was pleasantly surprised
[19:12] <TJ-> it's got oomph too when I need it. my main issue with is we still don't have support for the touchpad in the BT keyboard, it only operates as a mouse, which is painful
[19:13] <TJ-> proprietary stuff yet again
[19:14] <maszlo> TJ-: these two are journalctl http://paste.ubuntu.com/25811746/ and dmesg http://paste.ubuntu.com/25811752/ with the BAT1 dead and BAT0 discharging.  It does not report the battery is bad, likely because status is discharging
[19:15] <TJ-> maszlo: so l.m.t. is behaving with BAT0 discharging?
[19:15] <maszlo> TJ-: forgot that detail, no still doesnt boot properly. just doest complain that battery is bad
[19:16] <TJ-> maszlo: makes sense; it's the udev rules issue. You can try a couple of manual 'patches' to see if it gets fixed if you want
[19:18] <maszlo> TJ-: the theory is that having lmt would provide longer battery life? battery drain seemed consistent to what i was getting before
[19:19] <TJ-> maszlo: the first is to "sudo cp /lib/systemd/system/systemd-udevd.service /etc/systemd/system/" and then do "sudo sed -i '/MountFlags=slave/d' /etc/systemd/system/systemd-udevd.service" to remove that option, then reboot.
[19:19] <TJ-> maszlo: depends on how much you're using it and what devices I think.
[19:19] <TJ-> maszlo: I'll try 17.10 on my notebook later and see what happens
[19:20] <TJ-> Got to clear some space for an LV where it can be put
[19:21] <TJ-> maszlo: dinner time here so I'll be back later