[00:08] <drab> it only took two afternoons...
[00:08] <drab> rebuilding a trimmed down version, I think I got rid of everything I could safely got rid of
[00:08] <drab> hopefully I didn't break it
[00:09] <drab> I'm now at 111MB with all the modules
[00:16] <drab> \o/
[00:16] <drab> memtotal seems to have no bearing, I think the problem I had was that I messed up the tar...
[00:17] <drab> this desktop I'm testing on has 6Gb and I see tmps / 5.8Gb 531MB used
[00:17] <drab> so it seems to just use whatever there's available
[00:18] <TJ-> Yes, I think so too
[00:18] <TJ-> yes, that's how tmpfs works
[00:37] <drab> this is pretty damn cool, could even apt install xorg and get fluxbox going, in case people want to test something GUI
[00:44] <drab> now if I could figure out how to change the motd to give some instructions...
[00:45] <drab> can't find where all the ubuntu blah blah blah comes from... wiki says update-motd and mentions landscape, but none of those are debootstrapped
[00:45] <drab> anything I put in /etc/motd gets appended to that, not replacing it
[00:47] <TJ-> isnt't there an /etc/motd.d/ ?
[00:47] <drab> nope, not in the debootstrap chroot
[00:47] <TJ-> I'm pretty sure it uses runparts to call scripts to fill it
[00:48] <drab>  /var/run/motd.dynamic has some bits of it, not sure how that's genarated tho and it's not the full motd
[00:48] <drab> I have no /etc/update-motd.d of sort
[00:48] <drab> and no /etc/init.d/motd either
[00:49] <drab> don't see a systemd motd unit either
[00:50] <TJ-> "dpkg -S motd "
[00:50] <drab> I'm blind
[00:50] <drab> sometimes I wonder how my brain works...
[00:50] <drab> there is /etc/update-motd.d/ ...
[00:50] <drab> it's from base-files
[00:52] <TJ-> ahh sorry, I forgot the proper path name
[00:53] <drab> I think I did check that, somehow failed to see it, good call on dpkg -S
[00:53] <drab> bit burned out...
[00:53] <TJ-> :D
[00:53] <TJ-> it's my goto, followed by apt-file search
[01:18] <drab> very opinionated, contriverd and overall messy, but in case anybody ends up needing it for now I've dumped the whole process in a gist
[01:18] <drab> https://gist.github.com/spikedrba/057acad8b3bfb0266544347ced8b53d4
[01:18] <drab> it's actually fairly convoluted, especially to save space
[01:19] <drab> will turn it into a script or something tomorrow, but that's enough for a saturday, considering it a win
[01:19] <drab> thanks TJ- for all the support
[01:19] <TJ-> be great to be able to mount the rootfs using webdav :)
[01:19] <TJ-> you're welcome
[01:19] <drab> lol, you know what, I actually looked at it :P
[01:19] <TJ-> it's the obvious alternative to NFS if we want to use HTTP
[01:19] <drab> the main problem seems to be filesting not really being supported
[01:19] <TJ-> shouldn't be too hard to do
[01:20] <drab> but maybe I misunderstood and stuff
[01:20] <drab> generally speaking this imho would be a pretty darn good thing to have in a usable/stock fashion
[01:20] <TJ-> so the target only needs to fetch the files it needs from the untouched ISO/squashfs on the server, rather than transfer the entire thing over
[01:20] <drab> especially in the world of containers
[01:20] <drab> where running something like nfs-kernel-server is not quite an option
[01:21] <TJ-> I think the MAAS stuff with image-streaming for clouds might be the best thing - use what's already available
[01:22] <drab> I guess I should look at that again
[01:22] <drab> I didn't see a clear path to get a rescue system out of that
[01:23] <TJ-> no, I was more thinking about incorporating that image streaming into PXE  boot methods. currently it only supports TFTP and there is a PR to add HTTP support, so WEBDAV wouldn't be a long stretch
[04:45] <drab> ok, I'm down to 90MB compressed, fully functional with all the drivers etc, custom motd with autologin and blazing fast to a ramdisk installing additional sw
[04:46] <drab> polished into a script that does all the building and spit up 3 files, roofs.tar.xz, vmlinuz and initrd.img ready to go to the pxe server
[04:46] <drab> \o/
[15:39] <faekjarz> hi, is "dmesg | grep -i edac" the only method of verifying that ECC RAM is actually running in error correcting mode? greping for edac returned nothing, and greping for "error", "ecc" or "memory" returned nothing indicative of ECC mode.
[15:41] <TJ-> faekjarz: see "man 1 edac-util"
[15:45] <faekjarz> TJ-: No manual entry for edac-util …oops *install edac-utils* (it's edac-utilS, btw, with an s ;)
[15:46] <TJ-> :D
[15:46] <TJ-> indeed
[15:46] <TJ-> the man-page is edac-util though
[15:47] <faekjarz> k :)
[15:51]  * faekjarz goes off and reboots the machine that runs the router
[16:30] <faekjarz> edac-ctl --status returns "drivers not loaded." In /lib/modules/4.10.0-38-generic/kernel/drivers/edac are quite a lot of candidates, certainly edac_core, should i modprobe others on my Core i3-6100T? amd64_edac_mod, maybe? (I'm running 16.04 w/ the HW enablement kernel)
[16:40] <TJ-> faekjarz: amd edac driver on an Intel CPU?
[16:43] <faekjarz> well, i thought it refers to AMD64 64 bit instruction set. i already discarded edac_mce_amd.
[16:47] <faekjarz> oh, right it depends on edac_mce_amd, i'll give skx_edac a shot
[16:47] <TJ-> faekjarz: no; it'll be one of the i*.ko drivers, it depends on the chipset of course
[16:48] <drab> .o/
[16:48] <faekjarz> aye, the i3-6100T is a skylake
[17:33] <drab> urm, something really strange is going on with busybox and initramfs
[17:33] <drab> the fs where I generated the initramfs had /etc/resolv.conf configured
[17:34] <drab> however when booted I get dropped into an initramfs shell because an address can't be resolved and indeed /etc/resolv.conf is missing
[17:34] <drab> but pinging ips work as it works if I add /etc/resolv.conf and then ping hostnames
[17:35] <drab> the dns was correctly passed with dhcp because the network script shows it
[17:36] <drab> even stranger, and probably unrelated, after I started a ping to check I can't quit that anymore
[17:36] <drab> Ctrl-c has no effect
[17:36] <drab> so now I have to reboot and can't get back to the initramfs prompt
[17:36] <drab> really strange
[17:51] <faekjarz> Are those EDAC modules even required for ECC RAM to correct errors, or do they only provide an API for reporting and logging tools?
[18:39] <trippeh> faekjarz: pretty sure bios/uefi handles that, but you may need the drivers to control policy on multi-bit errors?
[18:39] <trippeh> ie kill process or panic/reboot
[18:39] <trippeh> with multi-bit I mean uncorrectable
[18:41] <trippeh> have to run.
[18:51] <faekjarz> trippeh: ok. Do you hav an idea why i can't load skx_edac? I mean, ok, modinfo says "MC Driver for Intel Skylake server processors" and some might consider an i3-6100T not a server CPU. …but it sure is Skylake. i7core_edac loads without errors, but doesn't seem to expose a memory controller to edac-util / edac-ctl
[18:54] <arunpyasi> Hi everyone, what respository setup does Ubuntu use in http://us.archive.ubuntu.com/ ?
[19:24] <drab> arunpyasi: how do you mean?
[19:25] <drab> arunpyasi: https://askubuntu.com/questions/28355/what-is-the-structure-of-an-ubuntu-repository
[19:46] <arunpyasi> drab, I mean does Ubuntu use Dak or something else to maintain the repo.
[21:05] <rbasak> arunpyasi: it uses Launchpad.
[21:06] <rbasak> The "soyuz" component I think.
[21:06] <rbasak> It's a fairly independent implementation.