[06:27] <nacc> rbasak: with the importer-rework branch as of right nonw, the ipsec-tools reimport is down to 35 minutes pretty consistently
[07:49] <lordievader> Good morning
[10:34] <cpaelzer> rbasak: could it be that if something is only pushed in -security the importer misses it?
[10:34] <cpaelzer> rbasak: take a look at iscsitarget in trusty
[10:35] <cpaelzer> nacc: ^^
[10:39] <rbasak> cpaelzer: could be. But we're in the middle of quite a bit change in logic around how the importer picks up on changes, and the importer is still running the old code currently. So let's see if the problem remains after we've landed our changes :)
[10:39] <rbasak> We don't currently have tests for this area of code (not yet faking Launchpad publications for testing)
[10:40] <cpaelzer> rbasak: is there abug on the rewrite that I could register a "please test this after the rewrite" on?
[10:45] <cpaelzer> rbasak: I know we have a set of known to import with issues - I assume you'll look at those
[10:45] <cpaelzer> just would want to add that there
[10:45] <cpaelzer> so that we remember
[10:49] <rbasak> cpaelzer: we don't have a bug for the rewrite. It's part of our "LP beta" milestone. We could create a bug, but would it be better to have a bug for this distinct issue?
[10:49] <cpaelzer> I'm fine to open one
[10:49] <cpaelzer> it is mostly a reminder to check
[10:49] <rbasak> It's a good idea
[12:25] <ali1234> right, who can tell me exactly why unattended-upgrades is not doing anything on my 16.04 server?
[12:26] <ali1234> it runs twice every day but never installs anything
[12:27] <ali1234> if i run it manually with --dry-run it outputs a list of packages to upgrade, in all other cases it outputs nothing
[12:28] <ali1234> that is, when run automatically
[12:28] <ali1234> actually, last thing it outputs is "allowed origins:..."
[14:32] <jamespage> coreycb: btw I'm tending the addtional backports needed for Queens UCA...
[14:37] <coreycb> jamespage: ok
[15:42] <nacc> rbasak: it depends on timing
[15:42] <nacc> cpaelzer: --^
[15:49] <nacc> cpaelzer: rbasak: so ... i'm not 100% on this, but this is my theory: iscsitarget was published on 7/17. It's possible we missed that evet. We don't catch it up again, because it's no longer published. The linear script walker would catch this, but the version we ran didn't look in older releases (the new one does for all active series).
[15:49] <nacc> so i thinnk it's fix released a la the new scripts
[15:52] <nacc> cpaelzer: were you asking re: LP: #1732918 ?
[17:42] <faekjarz> Hi! I'm anoyed, is it normal to take over 3 minutes to draw all the lines, at about 0.3 - 0.5 lines per second, of a "dmesg" on an ASPEED AST2400? Can i accellerate this? …modprobe …somethingsomething
[17:58] <faekjarz> …i'm not even doing IPMI (iKVM) over a slow connection …i'm directly connected to the box (VGA & USB) …this is my 1st time using a mobo with an Aspeed AST2400 BMC / GPU …is this normal?
[18:00] <nacc> faekjarz: not sure why that'd be an ubuntu issue?
[18:01] <nacc> faekjarz: do you know the BMC can dispaly faster? BMCs are not often about speed (ime)
[18:03] <faekjarz> nacc: because i'm not sure what distros include what drivers, and because i'm using Ubuntu …tadaah, here i am, asking whether i might have missed modprobing something
[18:04] <nacc> faekjarz: i meant, do you know it's not a hardware limitation?
[18:06] <faekjarz> i'm not sure, it's my 1st time using an A-"SPEED" thing (it's an Asus P10S-M) …seems like a misnomer, haha …i'm just double-checking
[18:13] <faekjarz> maybe i sould specialise in Aspeed based boards and enjoy all the free waiting time while getting paid for tech support
[18:15] <BlessJah> is AWS image naming convention ducumented anywhere?
[18:15] <nacc> Odd_Bloke: rcj: --^ maybe you know?
[18:16] <BlessJah> related: https://bugs.launchpad.net/cloud-images/+bug/1458825
[18:18] <nacc> BlessJah: is that bug actually accurate. I do't see the term "root store" on that URL.
[18:32] <BlessJah> nacc: there is "Instance type" field in image locator, it takes values listed in the bug
[18:32] <BlessJah> And the AMI name has cryptic "ebs-ssd": ubuntu/images/ebs-ssd/ubuntu-xenial-16.04-amd64-server-20171026.1
[18:33] <BlessJah> It's more or less obvious what it means, but there is lot of other images that do not follow the convention.
[18:34] <nacc> BlessJah: i'd say the bug needs to mention that, imo. Right now it says the "cloud images" download pages ... and then gives a URL that is not about AMIs.
[18:34] <nacc> BlessJah: if the issue is with the AMIs, that should be specified in the bug, right now it reads like the cloud-images page is wrong.
[19:51] <BlessJah> I'll talk to Faux to get that clarified.
[19:51] <nacc> BlessJah: not super urgent, i suppose :)
[19:51] <BlessJah> And what about thr documentation regarding image name conventions?
[19:51] <nacc> BlessJah: i mean your request might be orthogonal to that bug report
[19:52] <nacc> BlessJah: i pinged who i thought might help, i'd just wait
[19:52] <nacc> BlessJah: i'm not personally involved
[19:53] <nacc> rbasak: fyi, running the gnome-shell import locally from beta/edge snap, it does what it should (braches are being updated) so i assume cpaelzer did a skip-applied import
[19:53] <BlessJah> nice try, you're already knee-deep in this
[19:53] <nacc> BlessJah: :)
[19:53] <BlessJah> ;>
[19:54] <nacc> smoser: --^ do you possibly know?
[19:54] <nacc> smoser: how the AMIs get named and why they are named as they are
[19:58] <smoser> BlessJah: well, if you want to convert the values we have on cloud-images.ubuntu.com to whatever amazon's official values are just use DescribeImages on the image
[20:00] <BlessJah> I want to know how what different names (image/milestone/image-dev) mean and what filter to write to get image I want
[20:02] <smoser> BlessJah: well, milestone ?
[20:02] <smoser> i think you mean label
[20:02] <smoser> what is image-dev ?
[20:07] <BlessJah> prefixes for trusty: ubuntu/images/ubuntu-trusty-..., ubuntu/images/ebs/ubuntu-trusty-..., ubuntu/images/ebs-ssd/ubuntu-trusty-..., same for ebs-io1, ubuntu/images-testing/ubuntu-trusty-...,
[20:07] <BlessJah> but yes, there is no -dev
[20:07] <smoser> ah
[20:07] <smoser> ignore taht
[20:08] <nacc> lol
[20:08] <nacc> smoser: did you see the bug referred to above?
[20:08] <smoser> yeah.
[20:08] <nacc> smoser: ok, just wanted to check
[20:09] <BlessJah> ubuntu/images/ubuntu-xenial- ubuntu/images/hvm-ssd/ubuntu-xenial- ubuntu/images/hvm-instance/ubuntu-xenial- ubuntu/images/ebs-ssd/ubuntu-xenial- ubuntu/images-testing/ubuntu-xenial- ubuntu/images-testing-dev/ebs-ssd/ubuntu-xenial-
[20:09] <BlessJah> xenial, that's where I've seen dev
[20:11] <BlessJah> some documentation somewhere explaining why images have names that they have and a promise that convention won't suddenly change, would be nice to have that
[20:12] <smoser> http://paste.ubuntu.com/25983212/
[20:12] <smoser> dont use names.
[20:12] <smoser> use the stream data.
[20:13] <smoser> sstream-query  --keyring=/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg  --max=1  "--output-format=%(release)s  %(label)s  %(root_store)s  %(virt)s  %(id)s"  http://cloud-images.ubuntu.com/daily/streams/v1/com.ubuntu.cloud:daily:aws.sjson  region=us-east-1  release~(trusty|xenial|zesty|bionic)
[20:13] <smoser> or i guess easier if you use https
[20:13] <BlessJah> How do I glue that to terraform?
[20:15] <smoser> i'm sorry i dont know.
[20:15] <smoser> but that is how you "find the right ami".
[20:16] <smoser> the only variables currently supported (xenial+) are
[20:17] <BlessJah> What is that data stream thing?
[20:17] <smoser> root_store=(instance|ssd) virt=(pv|hvm)
[20:17] <smoser> it is "simplestreams" format. which is horribly documented.
[20:18] <smoser> i'm the author, so its ok for both you and i to say that.
[20:18] <nacc> https://help.ubuntu.com/lts/serverguide/cloud-images-and-uvtool.html ahs some mention
[20:18] <smoser> but that is how we publish data bout clouds
[20:18] <nacc> and there is a launchpad project
[20:18] <smoser> and that is how juju finds image ids
[20:18] <BlessJah> what was wrong with tags and naming conventions?
[20:19] <smoser> a.) naming conventions and you parsing strings sucks (and as you can see over 10 years that kind of fell apart).
[20:19] <smoser> b.) we publish data on all public clouds on ubuntu.com
[20:20] <BlessJah> I get that it's very convenient for juju devs, but it breaks other tools like terraform
[20:20] <smoser> we definitely could tag on amazon, an there might have developed conventions there over time
[20:20] <smoser> so there is some convetion on tags ?
[20:20] <smoser> and that only works on amazon
[20:20] <smoser> not on azure
[20:21] <smoser> or gce or bobs-cloud
[20:21] <nacc> oooh bobs-cloud
[20:21] <nacc> like bobs-burgers
[20:21] <nacc> i'd cloud there
[20:21] <smoser> there are definitely improvements (very much so for doc) that we could make and should  make.
[20:22] <smoser> but we set out to provide information about getting ubuntu wherever you need it.
[20:22] <smoser> the data is available over https or http with gpg signatures inline.
[20:23] <nacc> the poitn being it's not contingent on the cloud provider to be consistent with ubuntu
[20:23] <nacc> ubuntu is consistent with itself :)
[20:23] <smoser> BlessJah: is there some convention for tagging images now ?
[20:23] <smoser> that terraform can read ?
[20:24] <BlessJah> smoser: terraform uses same API as other tools
[20:25] <BlessJah> BTW, it's hilarious how AWS is inconsistent with itself, like when API filter for name accepts globs anchored at both beggining and end, while search in browser uses regexes instead
[20:26] <smoser> You can parse our names on amazon, but really, doesn't it make more sense to *not* ?
[20:26] <smoser> and have sane well formed data ?
[20:35] <BlessJah> It's not about parsing to extract information, but knowing what string will give me latest, production grade image.
[20:46] <smoser> BlessJah: well how is that done for other images?
[20:47] <smoser> i updated that bug
[20:47] <smoser>  ami-0309a879
[20:47] <smoser> oops
[20:47] <smoser> paste fail
[20:47] <smoser> https://bugs.launchpad.net/cloud-images/+bug/1458825
[20:48] <smoser> BlessJah: we *did* originally start out with a well formed naming convention on EC2.
[20:49] <smoser> but bucket limitations , ebs, many different things ultimately made changes necessary and inconsistent. but we have tried to provide that data in a consistent format over http on cloud-images.ubuntu.com
[21:04] <sveinse> I'm running 16.04 on a server, and I'm constantly bothered with that smbd requires a manual restart for samba to work
[21:05] <sveinse> systemctl status smbd reports active (exited) with status=0, and the logs simply sais "* Starting SMB/CIFS daemon smbd", "...done" and then its out.
[21:05] <sveinse> Restarting smbd fixes everything
[21:05] <sveinse> Familiar to anyone?
[21:06] <sarnold> does journalctl or /var/log/*samba* something have more details?
[21:09] <sveinse> sarnold: ah, yes it does. "no network interfaces found", then "No sockets available to bind to." and a subsequent stacktrace and coredump
[21:09] <sarnold> sveinse: eww :)
[21:09] <sveinse> that kinda explains it thou
[21:09] <sarnold> sveinse: but at least you've got something to work with.
[21:10] <sarnold> jeeze, what an impenetrable page.. https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
[21:11] <sarnold> sveinse: I think, try the systemctl to change the samba service, "to include After=network-online.target and Wants=network-online.target."
[21:12] <sveinse> My turn to eww: samba is still started through /etc/init.d, so it does not help to change the systemd start prereqs :(
[21:12] <sveinse> Anyone knows if the upcoming 18.04 LTS will have changes this?
[21:12] <sveinse> I'm willing to live with this until the next LTS arrives
[21:13] <sveinse> sarnold: thanks
[21:16] <sarnold> sveinse: well, at least -a- debian samba package has some smb.service, nmbd.service, etc files, http://sources.debian.net/src/samba/2:4.6.7%2Bdfsg-1/debian/rules/#L176
[21:16] <nacc> sveinse: i'm 99% sure the init.d script source lsb-functions, which then switches to systemd
[21:17] <sarnold> sveinse: .. and if kind of looks like that version should be in the next LTS
[21:19] <sveinse> Yeah, I'm looking at the package manifest for my samba. I'm having 2:4.3.11+dfsg-0ububut0.16.04.11, and it does not have any native systemd units it seems
[21:20] <nacc> samba: /lib/systemd/system/samba.service
[21:20] <nacc> sveinse: --^
[21:21] <sveinse> nacc: yup, that is in the newer packages, right?
[21:21] <nacc> that's in xenial.
[21:21] <sveinse> wierd. what version is that?
[21:21] <nacc> sveinse: i don't know what 'manifest' you were referring to?
[21:22] <sveinse> nacc: heh, mine. That is list of the files installed the package, dpkg -L samba
[21:22] <nacc> sveinse: i'm going off the apt-file output
[21:23]  * nacc spins up a container
[21:23] <nacc> can't trust anyone
[21:23] <nacc> sveinse: samba.service is admittedly not the same as smbd.service
[21:24] <sveinse> nacc: my /lib/systemd/system/samba.service is a symlink to /dev/null :O
[21:24] <nacc> sveinse: which means it's been masked
[21:25] <nacc> (iirc)
[21:26] <nacc> hrm, and can't enable it because the inits cript has no runlevels
[21:28] <nacc> sveinse: ok, nmbd.service and smbd.service are generated
[21:28] <nacc> sveinse: which means they can be ordered
[21:28] <nacc> *i thikn
[21:28] <sveinse> /lib/systemd/system/samba.service is owned by the samba package. Reading samba.preinst and .postinst, shows that it is apparently is doing init.d manipulation and not any .service stuff
[21:29] <sveinse> which is wierd, if you're getting other results
[21:29] <nacc> sveinse: what other results?
[21:29] <nacc> sveinse: i agree samba.service is masked
[21:29] <nacc> sveinse: smbd.service and nmbd.service exist
[21:29] <nacc> they are generated
[21:30] <sveinse> nacc, you mentioned nmbd.service and smbd.service. On my system they don't exist, neither in /lib/systemd nor /etc/systemd
[21:30] <nacc> sveinse: i just said, agai, they are generated
[21:30] <sveinse> nacc: so, what version are you getting in your container?
[21:30] <nacc> not on the filesystem
[21:30] <nacc> they still exist and are systemd services
[21:31] <sarnold> oh my
[21:31] <nacc> see `man systemd-sysv-generator`
[21:32] <sveinse> nacc: oh, yes, ah, yes yes. systemd makes services out of init.d items, true. That is the service I need to restart to get smbd working
[21:32] <nacc> sveinse: right, and i think above you were just saying you need to order it? or sorry, missig context
[21:33] <sarnold> I was suggesting it needed to be ordered
[21:33] <nacc> sarnold: ah ok
[21:33] <nacc> so the problem is smbd starting before network?
[21:33] <sveinse> nacc: for some reason, systemd starts smbd too soon when network isn't available yet (so it coredumps), so I wonder how I can order it when it does not have a service file
[21:34] <sarnold> after seeing https://anonscm.debian.org/cgit/pkg-samba/samba.git/commit/?id=61eaeba2a7a2df61b681b4ea545811569de421d0 earlier I assumed we had systemd unit files for samba...
[21:34] <nacc> i think we do now
[21:34] <nacc> but not in xenial
[21:34] <nacc> so it might need a bug
[21:34] <sarnold> sveinse: it -coredumps- on interface-not-available?
[21:34] <sarnold> that sounds like another bug report too, heh
[21:36] <sveinse> sarnold: I get this in /var/log/samba/log.smbd, https://bpaste.net/show/7e92863d2661
[21:37] <sveinse> but no core in the mentioned directory (perhaps ulimit is too low)
[21:37] <sarnold> sveinse: hrm. I'm _guessing_ that they chose to dump core on a huge number of issues, just so they could have something to debug with :)
[21:37] <sarnold> sveinse: apport might have eaten the core
[21:39] <nacc> sveinse: pulling up the git repo so i can try help a bit better
[21:40] <nacc> 2:4.4.4+dfsg-1 is when it was fixed in debian
[21:41] <nacc> https://git.launchpad.net/~usd-import-team/ubuntu/+source/samba/commit/?id=28a135855171ad2b00821c23e5b4e6b589cd7e1b
[21:42] <nacc> presumably exactly for this problem
[21:42] <nacc> as those are all After=network.target
[21:42] <sarnold> .. which might be before the network is online
[21:42] <sarnold> did samba switch to IP_FREEBIND or whatever the option is?
[21:43] <nacc> sarnold: above my pay grade
[21:43] <nacc> ahasenack: --^
[21:43] <nacc> (i thinkn he's out right now, though)
[21:43] <sarnold> nacc: and with the weather as nice as it is right now, this might be the last we see the sun until july 5th
[21:43] <nacc> sarnold: yeah
[21:44] <nacc> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
[21:45] <nacc> so it seems like *maybe* that hsould be network-online.target
[21:45] <sveinse> nacc: yes, seems it would
[21:45] <nacc> sveinse: the "right" fix (least sensitive/invasive) for 16.04 is to put the right headers i the lsb file
[21:45] <nacc> with a $network depedency
[21:45] <nacc> which will translate to a Wants/After network-online.target
[21:46] <sveinse> You guys think its safe to pick a backported samba in a production server?
[21:46] <nacc> no
[21:46] <nacc> :)
[21:46] <sveinse> (horrible question)
[21:46] <nacc> but i also don't think it's safe to run samba ;)
[21:46] <sveinse> tell that to all the win guys who think they rule the world
[21:46] <nacc> sveinse: intneresting
[21:47] <nacc>  /etc/init.d/smb *does* have $network
[21:47] <nacc> err, smbd and nmbd
[21:48] <sveinse> Our router is handing out DHCP IPs, even to servers with "fixed" IP. Could it be that assumption? Because $network in that context is when ip is up, not when dhclient has done it's job, right?
[21:49] <nacc> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ syas $network gets intnerprted by systemd to mean wait on network-onlinne.target
[21:49] <sveinse> horrible failure mode from smbd thou
[21:49] <sarnold> that could sure explain why you see it and yet we're not over-run with this complait on irc every day...
[21:50] <nacc> sveinse: ah but yeah, that could imply you are in network-online already
[21:50] <nacc> before you actually are :)
[21:51] <nacc> sveinse: check `systemd-analyze critical-chain smbd.service`
[21:51] <nacc> see if it is ordered correctly
[21:51] <sveinse> interestingly its after network-online.target
[21:51] <sarnold> nacc: nice :)
[21:52] <nacc> yeah
[21:52] <nacc> so it did it "right"
[21:52] <nacc> the issue is your system thought it was 'online' before it was, for some meaning of 'online' and 'think'
[21:53] <nacc> well, 'thought', but conjugated
[21:53] <sveinse> yes
[21:53] <sveinse> well, then it's time to argue with the router infra guys about why I need to set a fixed ip and not run dhcp :D
[21:54] <nacc> sveinse: i guess you could trawlt he log and see 'when' you got "Reached target Network is Online" and see if it is correct
[21:56] <sveinse> hmm. the journal does not mention "online", but systemd-analyze said it happened at 24.227s. I wonder if I can get journal -b0 to dump with entries in seconds since startup rather than using wall clock
[21:58] <nacc> sveinse: hrm, my journalctl does show the line
[21:58] <nacc> sveinse: in a 16.04 lxd
[21:59] <sveinse> nacc: It does. My bad. grep online does not find "Online"
[21:59] <nacc> sveinse: ah :)
[22:00] <nacc> sveinse: if you don't mind, before you EOD, can you check if there is a bug for the samba systemd units as they currently are (ref the commit i gave above) and that it's a behavior change to depend on network.target when 16.04 depended on network-online.target (implicitly via $network)
[22:00] <sveinse> network online is 1 second after getting dhcp address.
[22:01] <sveinse> now here is an interesting thing: I see that nmbd starts after network online. But smbd starts well before network online and "network"
[22:01] <nacc> sveinse: even in the critical chain output?
[22:02] <sveinse> https://bpaste.net/show/44fad5355fa9
[22:03] <nacc> that's after nmbd.service
[22:03] <sveinse> Do I read that smbd is depending on nmbd?
[22:03] <nacc> so if nmbd.servic is after nnetwork-online, so is smbd :)
[22:03] <nacc> sveinse: top-level is the one you asked for, then each little down is a dependency
[22:03] <nacc> smbd.service depended on nmbd.service depended on network-online.target depended on ...
[22:04] <nacc> and if you depend on something (in this parlance) we mean it started after
[22:05] <sveinse> snipping parts of the journal logs: https://bpaste.net/show/722f3f847e68
[22:08] <nacc> very strange
[22:08] <nacc> i suppose it's possible for systemd to start a unit twice and only emit the second one
[22:08] <nacc> but that would imply you've done some local config to force smbd to start
[22:08] <sveinse> nacc: not deliberately...
[22:09] <nacc> sveinse: hrm, i genuinely don't know
[22:09] <nacc> sveinse: i would file a bug -- it feels like something is wrong, but i don't know what
[22:09] <nacc> i would file against both samba and systemd, tbh
[22:10] <nacc> sveinse: that log does imply a race, for some reason, between dhclient starting and finishing and smbd starting
[22:10] <nacc> sveinse: which does read like ad ependnecy on network rather than network-online
[22:10] <sveinse> I've got /etc/init.d/samba AND smbd and nmbd. Do you have this in your container?
[22:11] <nacc> sveinse: yeah
[22:11] <sveinse> ok, thanks
[22:11] <nacc> samba is like the meta-service
[22:11] <nacc> it makes sure smbd and nmbd are running
[22:11] <nacc> oh and samba-ad-dc
[22:12] <sveinse> yes, you'll see that in the journal paste as well. In proper relationship to "network online"
[22:12] <nacc> yeah
[22:13] <nacc> it's clearly a bit of a thundering herd there
[22:13] <nacc> all that gets logged in the same secod :)
[22:13] <nacc> and given logging, it's also possible we are seeing weird output that is not related to the actual order
[22:13] <nacc> i mean it coudl be racy writing to the journal
[22:19] <sveinse> nacc: isn't the journal race safe? I.e. it writes the entries "mutex"-wise in the order they're received?
[22:19] <sveinse> but granted, the services might be out of orders over the cpu cores
[22:25] <nacc> sveinse: i'm not sure, i meant simply that i'm not sure what guarantees the order things are written is the order in which they are received
[22:26] <nacc> e.g., it might have receive 4 parallel service starts
[22:26] <nacc> those all get shown as starting, in some order, because ... well, we can't read parallel
[22:26] <nacc> but they really all started simultaneously
[22:26] <nacc> i don't trust the timestamps of the journal to tell me that :)
[22:27] <sveinse> nacc: no, agreed
[22:28] <sveinse> the timebox for fixing this thing is up soon, but what exactly do you want me to do with this? I suppose report it, but with what data?
[22:29] <nacc> sveinse: yeah, `ubuntu-bug samba`, with whatever you can summarize out of the above
[22:29] <nacc> ahasenack: should see this in his backlog whenn he's back too
[22:29] <nacc> sveinse: i'm out for a while, so he's likely to be the one to help
[22:31] <sveinse> heh, ubuntu-bug samba asks "How would you best describe your setup?" 1) I am running a Windows File Server, 2) I am connecting to a Windows File Server, C) Cancel... Eeehh. None of the above. :P
[22:32] <nacc> sveinse: it *might* just be easier to do a https://bugs.launchpad.net/ubuntu/+source/samba/+filebug
[22:32] <nacc> sveinse: and maybe mentio that the above options are a bit limited :)
[22:47] <sveinse> nacc: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1733011
[23:00] <nacc> sveinse: thakns
[23:00] <sveinse> nacc: thanks yourself
[23:01] <sveinse> Now I need to fix something else
[23:01] <nacc> sveinse: yeah that's *really* weird, but you did a good job summarizing it ...
[23:19] <drab> is there some kind of very small ubuntu based distro to be used for rescue?
[23:19] <drab> (I know I asked about this already, bust still looking)
[23:19] <drab> damn small linux seems discontinued, ubuntu is huge (1.5GB)
[23:19] <drab> ideally I'd use mini.iso, but it doesn't provide a bootable system, only install (same for server)
[23:40] <gun1x> is docker foss ?
[23:45] <nacc> gun1x: a question for docker, presumably.
[23:46] <gun1x> nacc: nevermind, found my answer