[04:20] <wr> ubuntu server minimal iso size?
[04:49] <cpaelzer> good morning (or whatever applies to you)
[06:01] <lordievader> Good morning
[13:15] <smoser> hallyn: it wasnt "restrictions". but we had a ec2 specific kernel just because it was vastly different
[13:15] <smoser> since then we moved to just using the -virtual subset of the -generic kernel and all was happy.  to my knowledge -virtual should still work and is supported.
[13:16] <smoser> but... we since moved on to again having a -ec2 "optimized" version.  i'm not sure or convinced of the value of the optimization.
[13:16] <smoser> net summary: there isn't really anything "special" needed for ec2
[13:21] <rdkr> hi, i am trying to install server 18 alongside an existing windows install. the installer is not showing me the partition i created for the install. is there some way of doing this in particular? i created the partition with fdisk as a 'linux partition'. cheers!
[13:48] <mustmodify> Ubuntu Server 16.04 + pantheon(gui?) worked fine. Upgrade to 18.04 and my machine is putting itself to sleep on some small interval, like ... 30 min? I'm also experiencing some odd networking issues on boot. Power settings changed to "never sleep." syslog: https://gist.github.com/mustmodify/11a6afdc20b25a31928e3d7abe1d08b1
[13:49] <mustmodify> Syslog blames NetworkManager! I found a StackOverflow post saying I may need to update my kernel. Typically that just happens on its own. How can I force a kernel update and/or recompile if latest?
[14:23] <mustmodify> Well, I tried some things. We'll see if this issue is resolved.
[14:23] <mustmodify> But seriously, there's still something wrong with my networking. Check out these entries from syslog. Seems bad. https://gist.github.com/mustmodify/cc49021d0d4ed79295223a86e741b878
[14:50] <hallyn> smoser: well the specific question i had,
[14:50] <hallyn> was whether i can use any release name i want (uname -r)
[14:51] <hallyn> there are older docs claiming you can't,
[14:51] <hallyn> i've found no newer docs saying "we fixed that", but it seems hard to believe that something like 4.4.109-centos1 would not work
[14:51] <smoser> you should be able to, yes. for hvm. and i think pvm also
[14:52] <hallyn> smoser: the other error i've seeon someone mention is about multiple /etc dirs
[14:52] <hallyn> i've got multiple LVs which each have a rootfs, but of course they are not bootable
[14:53] <smoser> right. so... the import failure that you're seeing i can't speak to. it sounded from tych0 that you weren'te even getting to boot the thing
[14:53] <smoser> but rather some improt processs was just complaining about that.
[14:53] <tych0> right, we're not
[14:53] <tych0> yep.
[14:53] <tych0> you mentioned htere's a way to push raw bytes and boot them without using the import process?
[14:54] <smoser> there might be some more fancy ways at this point.
[14:54] <smoser> but what we initially did (and I believe still do) is basically
[14:54] <smoser>  a.) launch an instance
[14:54] <smoser>  b.) attach a volume
[14:54] <smoser>  c.) dd bytes to volume
[14:54] <smoser>  d. detach volume
[14:55] <smoser>  e.) register ami with that volume as root
[14:55] <hallyn> d'oh.  that sounds deceptively simple
[14:55] <hallyn> thanks smoser !
[14:55] <tych0> heh, ok :)
[14:56] <smoser> i think there might be some sugar around that now
[14:56] <smoser> (possibly which you're already using)
[14:56] <tych0> well, the sugar is causing us problems, so this trick is much appreciated
[14:57] <smoser> i thought there migh tbe some less-sugar alterntiave.. somethinb asically like "create volume from blob"
[14:57] <smoser> all the above wrapped up without you required to have a instance to do it.
[14:57] <tych0> smoser: i guess one complicating factor is that we have two disks
[14:57] <hallyn> i prefer raw paths
[14:58] <smoser> conceptually i think it would be the same, but i've never registered such a ami myself.
[14:58] <hallyn> tych0: why would that complicate things?
[14:58] <tych0> hallyn: because multi-disk support seems relatively recent
[14:59] <tych0> i've found various docs referring to multiple disks not being supported
[14:59] <tych0> but the official docs say it is now
[15:00] <hallyn> 14:53 < smoser> right. so... the import failure that you're seeing i can't speak to. it sounded from tych0 that you weren'te even getting to boot the thing
[15:00] <hallyn> I had no idea what order steps were done in :)
[15:00] <hallyn> (s/had/have/)
[15:00] <hallyn> which is why i prefer the raw route - i hate magic hidden behind cloud services
[15:01] <elfranne> I am seing packet drops on ethtool ... it is packet drop counter ? or per second ? can t find any info on that ....
[15:01] <tych0> man hthey really do not like ubuntu on this launch dialog
[15:04] <teward> rbasak: when did we add nginx to the nginx-server seeds?
[15:04] <teward> s/nginx-server/ubuntu-server/
[15:04] <teward> *is tired*
[15:06] <rbasak> teward: years ago? I don't have a date. Look in bzr blame perhaps?
[15:12] <teward> rbasak: i must have forgotten heh
[15:12] <teward> rbasak: probably was once we got it included in Main, which was 2014 iirc
[15:12] <teward> just waiting on beta freeze to end so the latest round of upstream bugfixes gets included (1.15.4)
[15:14] <rbasak> teward: right - that's _how_ it ended up in main. Something has to pull it in - in our case it was one of the server seeds.
[15:17] <teward> indeed.  all's good, i just forgot :|
[15:17] <teward> (i'm a bit overworked recently, guess I forgot WHOOPS)
[15:31] <mustmodify> Just a ping -- would love some help with my networking issue.
[15:38] <teward> mustmodify: i'd look at the network infrastructure rather than your computer
[15:38] <teward> since it looks like it's just not getting a DHCP reply
[15:39] <mustmodify> Hunh, ok thanks.
[15:39] <teward> mustmodify: or, connect to another network and see if it still works
[15:39] <mustmodify> I wonder how it gets an IP address then
[15:39] <teward> static?
[15:40] <teward> in any case your logs show a DHCP request went unack'd by any DHCP servers
[15:40] <mustmodify> sure. I'll dig into that, thanks. Would that explain a 5 minute wait during startup
[15:40] <teward> so lines 3-4, then 16-20.
[15:40] <mustmodify> with the description "waiting for service to start"
[15:40] <teward> yep
[15:40] <mustmodify> ok
[15:41] <teward> the fact it keeps retransmitting (lines 16-20) indicates that it's not getting a return ACK
[15:41] <teward> which it needs to complete DHCP
[15:41] <mustmodify> Final Q: Any clue why this started when I upgraded from 16 to 18?
[16:01] <mustmodify_> teward: What about this one? It just happened again, hours later. Server apparently put to sleep by NetworkManager ?
[16:02] <mustmodify_> https://gist.github.com/mustmodify/11a6afdc20b25a31928e3d7abe1d08b1
[16:02] <teward> that I don't know about, but i can't tell whether NM is actually calling the suspend or not
[16:02] <mustmodify_> It's a huge mystery.
[16:03] <teward> (it might be receiving a notice that the system is going to sleep, in which case that explains that, but to my knowledge NM doesn't have direct access to call a suspend)
[16:03] <mustmodify_> Is there some log other than syslog that might give details about what caused the suspend?
[16:03] <nacc> https://askubuntu.com/questions/1005507/network-manager-requested-to-sleep-every-30-minutes-wifi-drops
[16:03] <nacc> mustmodify_: --^ check your regular power settings
[16:03] <nacc> also, why are you running NM on a server? :)
[16:04] <mustmodify_> I did check my power settings.
[16:04] <teward> nacc raises a good point
[16:04] <teward> why're you using Network Manager on a server
[16:04] <mustmodify_> nacc: I have no idea. I had server (plus a light-weight GUI) running on this machine with 16.04 for years.
[16:04] <nacc> mustmodify_: my understanding is that it's not NM itself that's suspending your system, it's NM reacting to a sleep trigger, meaning your system is suspending
[16:04] <mustmodify_> Then I just installed 18 and things are all messed up.
[16:04] <nacc> e.g., https://unix.stackexchange.com/questions/64151/networkmanager-disabled-network-when-sending-system-to-sleep
[16:04] <mustmodify_> networking, going to sleep, ...
[16:05] <nacc> mustmodify_: installed or upgraded?
[16:05] <teward> nacc: that's what I thought it was, NM reporting it saw a sleep trigger.
[16:05] <nacc> teward: yeah, the message is vaguely misleading, but i think so too
[16:06] <nacc> i would look just before it in the syslog, but that's not in the gist
[16:06] <teward> indeed
[16:06] <nacc> mustmodify_: more logs, please? :)
[16:06] <teward> And some coffee while you're at it :)
[16:07] <mustmodify_> updated gist, not much helpful in syslog
[16:07] <nacc> cpaelzer: rbasak: sorry for not helping at all with php this cycle... I see 7.3 is in universe. Do you want me to try and help get 7.3 into main next cycle? I know the general steps, or at least we can tagteam it, if we can do a sync/HO beforehand
[16:07] <mustmodify_> Should I remove network manager? Anything I don't need can go, IMO. Just trying to get my system to something that will be stable after this upgrade to v18.04
[16:08] <rbasak> nacc: that sounds good. Thank you for helping out!
[16:08] <nacc> mustmodify_: i don't see why you need a GUI :)
[16:08] <nacc> rbasak: ack, if you want to throw something on my calendar for the future, feel free, or we can sync here when there's more free time
[16:09] <teward> nacc: wrt not helping with PHP, we're all busy, NGINX help last cycle from the rest of the server team was EXTREMELY helpful for me, with heavy work load, so I'm sure we're all good for helping each other out as needed :)
[16:09] <teward> (just glad you're checking in on it all :P)
[16:09] <nacc> teward: yeah, there's just a maze of dependencies from debian that are in universe that have delta because of phpunit at the time (18.04)
[16:09] <nacc> and then php itself with phpunit, etc.
[16:09] <teward> nacc: welcome to Debian Hell.  *shot*
[16:09] <nacc> lol
[16:10] <mustmodify_> nacc: thanks, let me explain. I wanted a heads-up place to show my clients' sites statuses and stuff. And I had this monitor connected to the machine, so...
[16:10] <nacc> mustmodify_: couldn't that be done via a site?
[16:10] <mustmodify_> I figured showing a webpage on that monitor wouldn't use up too much in the way of resources.
[16:10] <nacc> mustmodify_: and if it's a site, why does it need to be local?
[16:10] <mustmodify_> It's not local.
[16:10] <nacc> mustmodify_: i mean, local on a monitor
[16:11] <mustmodify_> Well I'm not sure what you mean by that
[16:11] <nacc> mustmodify_: it doesn't make sense to me to go from -- display site status on a website to run a desktop on the server so i can have a monitor hooked up to it
[16:11] <teward> ^ this
[16:11] <teward> unless you were looking for an always-on screen showing you the status
[16:11] <mustmodify_> right
[16:11] <mustmodify_> that's what I was trying to say.
[16:11] <teward> in which case you can just have something running a website and have *another computer* or an RPi connect
[16:11] <teward> and then just show the data that way
[16:12] <mustmodify_> fine. So if I uninstall this GUI, will any issues be resolved?
[16:12] <mustmodify_> because being productive is more important to me right now than visibility.
[16:13] <mustmodify_> This is a dev machine. I remote into it to use vim to program, so I certainly don't need a GUI.
[16:14] <nacc> mustmodify_: well, the thing is, why is it suspending? that's what you need to debug
[16:14] <nacc> yes, i think it 'might' fix itself when you remove desktop services
[16:14] <nacc> e.g., i think gnome's default is to suspend after some X minutes in 18.04
[16:14] <mustmodify_> I checked the power settings, they're set not to suspend.
[16:14] <mustmodify_> So I don't know.
[16:14] <nacc> mustmodify_: in gnome?
[16:15] <nacc> iirc, there's a kernel level switch to disable suspend as well but i might be wrong
[16:15] <nacc> mustmodify_: i'm only going on what your logs say, which is you are still suspending :)
[16:15] <mustmodify_> I'm still suspending. That's true.
[16:16] <nacc> so the first step is basically just figure out how to flat out disable suspend
[16:16] <mustmodify_> I went into settings > Power > suspend in the GUI and disabled it. I'm checking for gnome command-line stuff now.
[16:16] <mustmodify_> I hadn't thought of that, let me google.
[16:17] <nacc> mustmodify_: https://unix.stackexchange.com/questions/188774/disable-suspending-at-kernel-level-independent-of-distribution-de-and-logged-u ?
[16:18] <mustmodify_> yeah, that's interesting. I don't have an org.freedesktop.upower.policy file.
[16:18] <nacc> that is an old response, so it may or may not be correct
[16:18] <nacc> https://wiki.debian.org/Suspend#Disable_suspend_and_hibernation
[16:19] <nacc> that acutally might be best
[16:19] <mustmodify_> I had found another post with a similar instruction.
[16:19] <nacc> disable suspend in systemd, as that's what is logging a suspend event in your syslog
[16:20] <mustmodify_> nice... "created symlink (various files) -> /dev/null
[16:20] <mustmodify_> well, we'll see what happens.
[16:20] <mustmodify_> nacc: thanks
[16:21] <nacc> mustmodify_: gl!
[16:22] <mustmodify_> thanks.
[16:42] <tych0> smoser: hallyn: so https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html says we can create it from a "snapshot of the root device volume", but our volume's root device is in lvm. at least when i tried via the UI, it didn't seem to want to let me do that
[16:42] <tych0> smoser: hallyn: gonna try some fiddling with the cli, but if you have any pointers about using lvm vs. just a rootfs on an image, that would be helpful :)
[16:43] <dlloyd> aws has no visibility into anything you do with LVM, so if you want disk level operations to make sense you should use straight volumes
[16:44] <tych0> dlloyd: meaning we can't create an AMI where the root partition is on lvm?
[16:44] <dlloyd> you can, it will just contain the full volume
[16:45] <dlloyd> i am assuming you are using lvm to sub partition that volume?
[16:46] <tych0> dlloyd: not sure what you mean by "it will contain the full volume". we have a disk0p1 which is the boot partition, and disk0p2 which is an lvm pv with various lvs, one of which is /
[16:46] <dlloyd> right, so if you generate an AMI from that volume, it will contain everything on disk0, so both of those partitions
[16:47] <tych0> oh, yeah, that's fine
[16:47] <dlloyd> think of aws volumes as a physical disk
[16:47] <tych0> yep
[16:47] <tych0> but it's not clear to me that we actually can generate an AMI from this volume
[16:47] <tych0> or at least, i don't understand how right now :)
[16:48] <dlloyd> root device volume to AWS is just the disk it should attempt to boot from, so if your partition configuration is correct you should be set
[16:49] <tych0> but it wants to name it /dev/sda1
[16:50] <tych0> i think maybe i need to figure out the cli
[17:07] <smoser> tych0: https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html?highlight=register%20image
[17:07] <tych0> smoser: yeah, that's what i've been reading, thanks
[17:07] <smoser> is what you're after. from the cli. i'm not sure of an example commadn line for block device mapping for hvm
[17:09] <tych0> smoser: yeah, so i have,
[17:10] <tych0> http://paste.ubuntu.com/p/smb5v4fZNB/
[17:10] <tych0> but it says, No root snapshot specified in device mapping.
[17:10] <tych0> we don't have a root snapshot, since it's in lvm :\
[19:09] <mustmodify_> OMG more 18.04 issues. Git tag now uses less (or something) by default. Can I turn that off?
[19:13] <nacc> mustmodify_: --no-pager?
[19:13] <nacc> mustmodify_: see `man git-tag` and saerch for 'pager'
[19:13] <nacc> mustmodify_: that's not an 18.04 issue, that's an upstream change, maybe.
[19:22] <mustmodify_> nacc: Maybe, but it wasn't happening before the change. All bad things happen on update! :P
[19:22] <nacc> mustmodify_: right, there's no 'no behavioral changes' on update assertion
[19:22] <nacc> and git, in particular, has no ABI about it's cli
[19:22] <nacc> ABI equivalent, i mean
[19:23] <Skuggen> Git is at least consistent in its inconsistency
[19:23] <nacc> heh
[19:23] <mustmodify_> nacc: ABI?
[19:23] <mustmodify_> should probably google it first, one moment.
[19:24] <nacc> mustmodify_: Application Binary Interface, the 'handshake' applications depend on to know how to talk to interfaces
[19:24] <nacc> mustmodify_: i was using it as a vague way of saying you can't rely on cli behavior of git
[19:24] <nacc> mustmodify_: unless you have it configured to only produce specific behavior
[19:24] <nacc> the 'defaults' can and do change
[19:25] <mustmodify_> So close, google. And yet so far to go.
[19:25] <mustmodify_> https://media.trillian.im/media/?m=aW1hZ2UvcG5nLDEwMTQsMTczLL91O2MF2ITRLg%2B69IY%2BF3G5dgSXW2qt9f6FTaG4C4dy
[19:25] <mustmodify_> anyway, ok, kind of like an API but for CLI stuff.
[19:25] <mustmodify_> and more passive, probably.
[19:25] <nacc> mustmodify_: ABI is stricter than API
[19:26] <mustmodify_> well, depending on how you look at it.
[19:26] <nacc> mustmodify_: ABI means you don't need to recompile your program to use a library
[19:26] <mustmodify_> right, nm about that. Still thinking it through.
[19:26] <nacc> mustmodify_: in any case, the gist was about ABI or API :)
[19:26] <nacc> mustmodify_: there isn't one to a cli program, unless they assert there is one. And git, in particular, does not
[19:27] <mustmodify_> ok. More interesting question. If I have WantedBy=xxx.service at the bottom of my systemd service, does that mean that when xxx starts, I'll also start?
[19:27] <mustmodify_> Or is it more an "abort if not present" thing?
[19:29] <nacc> mustmodify_: `man systemd.service` :)
[19:29] <nacc> err, systemd.unit, maybe
[19:29] <nacc> yeah, that one, sorry
[19:53] <mustmodify_> Wants and WantedBy seem backwards to me.
[19:54] <mustmodify_> If I understand correctly, if you have (just as an example) a Power service and an Air Conditioner service, Air Conditioner would say WantedBy=Power
[19:54] <mustmodify_> but in fact the Air Conditioner wants power, it isn't wanted by the power.
[19:54] <mustmodify_> Maybe I'm misunderstanding, but that's how I read it.
[19:56] <nacc> AC has wantedby=power mens that power.wants will have a symlink to ac. so if you start power, it will start ac.
[19:56] <nacc> wantedby i a means of expressing dependency: "if possible, when i start power, i want to start ac"
[19:58] <mustmodify_> I get that. But the words seem backwards. Because, as I said, AC _is not_ wanted by Power. Rather, AC wants power, and Power is wanted by AC.
[19:58] <nacc> mustmodify_: it is improtant to not confuse english with systemd
[19:58] <nacc> mustmodify_: they are both grammars
[19:58] <mustmodify_> LOL
[19:58] <nacc> don't apply english semantics to systemd terms
[19:58] <nacc> i'm not actually joking
[19:59] <mustmodify_> Well it can be both true and unfortunate, right?
[19:59] <mustmodify_> I mean, they are both grammars. But if the grammars happened to line up, then that would have been more intuitive for potential users.
[19:59] <nacc> mustmodify_: i meant in your sentence: "Because, as I said...". That's english phrasing
[19:59] <mustmodify_> right
[19:59] <mustmodify_> totally.
[20:00] <nacc> mustmodify_: you can express a desire in english. the syntax to achieve the same in systemd will be whatever systemd wants :)
[20:00] <mustmodify_> well it's more definition than grammar but
[20:00] <nacc> it's confusing, for sure
[20:00] <mustmodify_> right
[20:00] <nacc> but once you get it, it makes sense (some small amount)
[20:00] <mustmodify_> I gotcha
[20:00] <mustmodify_> It's systematic. I'll give it that. And a word having that meaning is fine. The choice of that word... I don't think it makes sense. :)
[20:01] <mustmodify_> c'est la vie
[20:01] <nacc> mustmodify_: yeah, exactly
[20:55] <sdeziel> nacc: would you mind setting https://bugs.launchpad.net/ubuntu/zesty/+source/php7.0/+bug/1724896 as "won't fix"?
[20:55] <nacc> ack
[20:55] <sdeziel> Zesty being EOL
[20:55] <sdeziel> thanks
[20:56] <nacc> done and comment added
[21:09] <sdeziel> "git ubuntu clone php-mcrypt" fails for me and says the repo is not imported yet. Wasn't 100% of archive imported for git-ubuntu consumption?
[21:09] <nacc> only main
[21:09] <sdeziel> ah, that explains it
[21:13] <tych0> smoser: got my thing to boot. thanks for all your help today.
[21:13] <tych0> smoser: i owe you one unit of beer in EDI :)
[21:21] <cpaelzer> nacc: I'd think we would love a helping hand to not learn all again the hard way
[21:22] <cpaelzer> we all have odd times these weeks, but then we are quite a bit away from 19.04 atm
[21:23] <cpaelzer> nacc: we should sync via mail to get all involved and find sort of a kick-off session together
[21:24] <cpaelzer> nacc: I'll start a mail thread - thanks!
[21:56] <nacc> cpaelzer_: ack, ty
[23:13] <dar123> hey guyz, i am doing bind config for the first time. I  added two domains, first one works fine. Second one still showing public name server. I even removed the forwarder