[05:11] <Deihmos> isn't there an expert install for the server?
[05:11] <mason> Deihmos: You can get the alternative installer, and that's the Debian text interface.
[05:11] <Deihmos> i wonder why there is a channel for server and ubuntu when they are both the same
[05:11] <mason> Hang out in both for a while and the differences will emerge.
[05:17] <Deihmos> the standard installer comes packed at over 3GB
[07:51] <ruben23> hi there guys need help, i have a local web server and my local page URL http://<IP_ADDRESS>.0/website  --> is there a way i can access this URL by name like http://website.local like that please help
[07:56] <blackflow> ruben23: you can put  "<IP_ADDRESS>   website.local"   (without parentheses) into your /etc/hosts file (and I'm assuming you typo'd the last 0)
[07:57] <blackflow> ruben23: so that's /etc/hosts on your computer FROM which you want to access that hostname. alternatively you'll need a DNS server in your network configured to serve the "website.local" zone
[07:59] <ruben23> blackflow: so i need local DNS server also
[07:59] <blackflow> ruben23: only if you don't want to set up /etc/hosts on every computer you want to access that IP from.
[08:01] <ruben23> blackflow: this host will be access by all 20 local pc they belong on the same LAN
[08:01] <blackflow> Deihmos: "expert installe for the server" -- yes, use debootstrap for most expert flexibility and control.
[08:02] <blackflow> ruben23: then you'll need a DNS server, and maybe you can teach your LAN resolver already, to serve that zone
[08:02] <ruben23> blackflow: help me how to set this up please
[08:04] <blackflow> ruben23: what exactly? several possibilities are offered
[08:05] <blackflow> I'm assuming the most simplest is that you already have a LAN resolver (the gateway itself, perhaps? the router?)?
[08:05] <ruben23> i have a 45 PC access a web server , with a local site, but to access it they used ipaddress of the webserver, can it be accessible by hostname only, so i need to setup a local DNS server, im not sure how to setup a local DNS server
[08:06] <ruben23> yes i have a router from a Internet Provider
[08:06] <blackflow> ruben23: the consult the manual of the router from your internet provider and see if you can add a zone to its DNS settings. how to do that, depends on your router and is out of the scope of this channel
[08:07] <blackflow> ruben23: if it can't to that, then see if it can specify the DNS settings for the DHCP service it provider. in there you'd have to supply the IP address of the DNS server taht you'll have to set up. this DNS server will have to be both authoritative for "website.local" and a recursive resolver for all the rest.
[08:09] <blackflow> I'm trying to remember if there's a simpler way, perhaps something based on avahi and no need for a central DNS...
[08:10] <ruben23> blackflow: do i need a server for this DNS server.? somehow
[08:10] <ruben23> i cna only see on the router is this function --> Static DNS Configuration , DDNS Configuration
[08:11] <blackflow> ruben23: yes you do. but wait, I think you don't need a central DNS for  .local  and something like the avahi service
[08:13] <blackflow> ruben23: okay, I had to look that up and I found some articles but for Fedora, I suppose it's possible to do this with avahi and mdns, but I've never done it and could'nt help you with that. But you have the keywords now to look up something on google yourself.
[08:15] <blackflow> ruben23: another simple solution is not to use .local at all, but some real domain in your control, and just set something like  "dev.example.com"  (where example.com is the domain you own)  to point at <IP_ADDRESS>  or whatever the LAN ip it really is, at your domain registrar or where the NS is.
[08:16] <blackflow> though with mdns approach, all your PCs will have to support it as well, which shouldn't be a problem to set up, I guess
[08:17] <blackflow> ruben23: ah, https://help.ubuntu.com/community/HowToZeroconf
[08:18] <ruben23> Thanks a lot i will loo into tat now
[08:18] <blackflow> ruben23: yeah .local is special and usable for mDNS like that.
[08:21] <ruben23>  blackflow: but all the pc access that local URl are windows
[08:29] <blackflow> ruben23: windows should support mdns afaik
[08:30] <blackflow> ruben23: you need avahi only on the machine that hosts your website. avahi then broadcasts its mdns hostname website.local, and all the mdsn clients (of which I assume windows too) will pick that up and know where in the LAN website.local is.
[08:31] <blackflow> mDNS as protocol (multicast DNS), should be supported by windows, macs and linuxes
[13:22] <Delvien> runing an ubuntu-server 18.04 in a vm.. new install and getting weird network interfaces which I cant bring up (with netplan) 3 network interfaces named veth######, I only have one network device attached, how cna i get rid of these and get networking up?
[15:17] <tomreyn> Delvien: "ip l" may provide more info on these virtual nics
[15:18] <tomreyn> http://manpages.ubuntu.com/manpages/bionic/en/man4/veth.4.html
[16:10] <Deihmos> i installing the server does not install tyhe video drivers
[16:10] <Deihmos> how do i determine the driver that i need?
[16:28] <blackflow> Deihmos: all the gpu drivers are probably already in the kernel. anything else are optional, out of tree drivers for nvidia and amd
[16:29] <Deihmos> i don't get hw transcoding on plex when there is no desktop
[16:30] <Deihmos> someone told me without the desktop, there was no dependency to install the i965-va-driver
[16:32] <blackflow> Deihmos: that's VAAPI acceleration driver for intel, you can always install it if you need it
[16:36] <Deihmos> how do i determine the version that i need
[16:41] <blackflow> Deihmos: you probably don't need a specific version, or else you'd know already :)  just use the package provided by the distro
[16:41] <Deihmos> ok
[18:06] <Deihmos> blackflow: did not work. still no vaapi acceleration on the server
[18:07] <Deihmos> i did apt install i965-va-driver
[18:44] <kinghat> so i have my server mounted via smb share on my nix desktop. is it ok to delete files from the server through the mounted share?
[18:45] <kinghat> like those deleted server files end up in my desktop trash, is that normal?
[18:45] <tomreyn> how your desktop handles your delete requests depends on your desktop
[18:45] <tomreyn> which i understand does not run ubuntu
[18:46] <kinghat> what do you mean does not run ubuntu?
[18:46] <tomreyn> you said "on my nix desktop"
[18:47] <tomreyn> "nix" does not sound like "Ubuntu"
[18:47] <kinghat> sorry, its ubuntu. both server and desktop.
[18:49] <tomreyn> ubuntu desktop support would be in #ubuntu normally, but let's take a shortcut here: ubuntu's default file browser "naultilus" will move files to trash when deleted unless you hold down shift while doing so.
[18:50] <tomreyn> and it is not generally a misguided approach to delete files off a network share. unless you still need those.
[19:00] <kinghat> just seems add they end up in a different computers trash.
[19:00] <kinghat> does server even have a trash?
[19:02] <tomreyn> unless it runs a graphical desktop, probably not,
[19:02] <tomreyn> and i don't think the file is really moved to your local computer
[19:03] <tomreyn> usually what happens is that your client moves the file to a hidden /.Trash-$UID directory on the share, and adds references to that to its local trash.
[19:04] <tomreyn> which then makes it look as if the file was stored in your local trash.
[19:05] <tomreyn> this gives you the (crazy, IMO) user experience users may be used to from windows, but personally I find this undesirable which is why i disable this feature if i ever have to use a graphical file browser, and use it on network shares. or just hold down shift while deleting.
[19:05] <kinghat> and then emptying local(desktop) trash sends signal to remove it on the share?
[19:06] <tomreyn> yes
[19:06] <tomreyn> that's if the network connection still works then ;-)
[19:06] <kinghat> and that hidden .Trash is in root on share?
[19:06] <tomreyn> i think so
[19:13] <kinghat> easiest way to install new ubuntu server OS over the network?
[19:14] <kinghat> probably easier as the board has IPMI.
[19:15] <tomreyn> if its just a single server, the easiest approach may be to use the ipmi with remote virtual media, yes
[19:18] <kinghat> how does the remote virtual media work?
[19:18] <tomreyn> that's outside the scope of ubuntu support
[19:19] <kinghat> kk
[20:02] <kinghat> if i want static ip on the server during setup do i need to set it to manual?
[20:03] <kinghat> https://irc.kinghat.info/uploads/c401cfdf4ff2f2d6/Screenshot--03-02-2019--14-03-08.png
[20:11] <tomreyn> if by "static" you mean "not assigned by a local dhcp server", then yes, you will need to enter it manually.
[20:12] <tomreyn> (that's unless you do a (partially or) fully automated installation, that is.
[20:15] <tomreyn> i consider this installer to create broken installations, so personally i prefer the "alternative server" installer (based on debian's)
[20:15] <kinghat> broken installations is no good.
[20:18] <kinghat> also this is the 18.10 installer.
[20:23] <tomreyn> i also don't run servers on non LTS releases
[20:29] <kinghat> this is a play server so no harm.
[20:29] <kinghat> thanks for the help tomreyn!
[20:30] <tomreyn> you're welcome.
[20:32] <kinghat> has it always been the case that you cant have uppercase characters in the server name?
[20:35] <tomreyn> according to RFC 952 "No distinction is made between upper and lower case."
[20:35] <tomreyn> if the installer does, it's either the result of an ubuntu / debian policy or a bug.
[20:36] <tomreyn> i don't know whether it has always been this way.
[20:36] <kinghat> that must be the case.
[20:40] <kinghat> so what is going on here? https://irc.kinghat.info/uploads/248bc3804d712991/Screenshot--03-02-2019--14-40-00.png
[20:41] <kinghat> like some cloud-init process that is just constantly running? it just started up on login.
[20:52] <tomreyn> cloud-init is installed by default on ubuntu-server
[20:53] <tomreyn> i also don't like how it spills all over the login screen, but can imagine that there are scenarios where this can be useful.
[20:54] <tomreyn> s/login screen/login (text) prompt/
[20:54] <tomreyn> it could also be a bug, not sure.
[20:59] <kinghat> do i just `ctrl+c` it?
[20:59] <tomreyn> dont's you have a login prompt then?
[21:00] <tomreyn> you may have one but it may have scrolled off the screen. maybe try pressing enter first of all
[21:00] <kinghat> if i ctrl+c it?
[21:00] <tomreyn> see if that gives you a password rompt
[21:00] <tomreyn> *prompt
[21:00] <kinghat> i logged in and it started all that
[21:01] <kinghat> ya enter gave me the user input
[21:01] <tomreyn> then pressing enter probably gives you a shell prompt
[21:01] <kinghat> ya it did
[21:03] <tomreyn> IMO services shouldnt mess with your shell or login prompt like this, but ... oh well, you got what you paid for. you can always uninstall cloud-init, though.
[21:04] <kinghat> i think i may have on the previous install. i logged out and back in and it didnt do it the second time so 🤷♂
[21:05] <tomreyn> this massive output is only on the first run either way, i think.
[21:05] <kinghat> probably the case
[21:05] <tomreyn> the idea there is to enable you to securely login to a server via ssh
[21:06] <tomreyn> not having to trust on first use
[21:06] <kinghat> ya i didnt set the ssh keys during install when it asked.


[07:25] <Finrod> Time is 1h25 in Chicago, Central Standard Time.  UTC is 7h25.  Finrod is in #ubuntu-youth
[07:26] <Finrod> ChatZilla Timestamp is now 01:26


[01:43] <teward> sdeziel: so fyi "public mirrors" end up in the country RRs.  So even if you're in {CC}.archive.ubuntu.com you end up being put through the pool.  Hence security.ubuntu.com as the default
[01:43] <teward> just to echo mdeslaur and others
[01:43] <teward> it's soemthing that's been that way forever, as the Mirrors team (not Security) explained initally
[01:44] <teward> (back when I did regular mirroring)
[19:35] <tommyfun> hey
[19:36] <tommyfun> I keep my ubuntu servers patched nightly with the unattended upgrades
[19:36] <tommyfun> the security team at my org scanned my 20.04 servers and triggered an alert that apache2 was insecure
[19:37] <tommyfun> but it's the latest one
[19:37] <tommyfun> they use nessus
[19:38] <tommyfun> if I put the latest apache2 dpkg on, will it fuck it up somehow?  break dependancies? not be upgradeable with unattended-upgrades?
[19:38] <arraybolt3> apache2 is in the Main repository, if you keep your system up-to-date you should be good.
[19:38] <arraybolt3> I'd run "sudo apt update && sudo apt full-upgrade" to be sure.
[19:38] <tommyfun> Or should I trust the security updates and tell them to kick rocks
[19:38] <arraybolt3> Security scanners are notoriously bad at scanning Ubuntu.
[19:38] <arraybolt3> They seem to scan the version numbers to check for vulns.
[19:38] <tommyfun> thanks
[19:38] <arraybolt3> Ubuntu uses old versions of software and backports fixes as needed.
[19:39] <arraybolt3> So the version numbers *look* insecure to some scanners, even though the vulns are fixed.
[19:39] <arraybolt3> You can use security.ubuntu.com to look up Ubuntu Security Notices to ensure that certain CVEs are patched.
[19:41] <tomreyn> yes, it can depend on how nessus determines the versions. they support two approaches - network scans (from external) or agent based (running on the system). the latter can make use of information provided by dpkg, such as which actual pakcage version is installed. whereas network scanning may only see the version the serive (apache) exposes, which is often just the base version, not providing information on which security patches were
[19:41] <tomreyn> applied.
[19:43] <tomreyn> serive -> service
[19:43] <arraybolt3> Oddly, though, security.ubuntu.com seems to be possibly missing some CVE info? For instance, I can see that apache2 isn't vulnerable to CVE-2022-23943 looking at Debian's security tracker and comparing the version numbers there to the version number in Ubuntu 22.10... but I can't find said CVE in the Ubuntu Security Notice list.
[19:43] -ubottu:#ubuntu-security- Out-of-bounds Write vulnerability in mod_sed of Apache HTTP Server allows an attacker to overwrite heap memory with possibly attacker provided data. This issue affects Apache HTTP Server 2.4 version 2.4.52 and prior versions. <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23943>
[19:43] <sdeziel> to avoid tripping version sniffers, you can tell Apache2 to disclose less with `ServerTokens Prod` and `ServerSignature Off`
[19:44] <tommyfun> yeah, I had the security.conf settings not to disclode anything but I thought that this might be the issue, becasue it can't tell
[19:44] <arraybolt3> Oh wait, now I found it.
[19:45] <arraybolt3> Meh. Wonder why I didn't find it at first.
[19:46] <tommyfun> One of the issues is/was with mod proxy, but I'm not even running it, my boss doesn't want their nessus agent on the server, but I don't have time to deal with these false positives
[19:47] <arraybolt3> tomreyn: Isn't there some sort of security scanner for Ubuntu specifically that Canonical has, something about OPAL or some such?
[19:47] <arraybolt3> *OVAL
[19:47] <arraybolt3> https://ubuntu.com/security/oval
[19:47] <arraybolt3> Found it.
[19:48] <tommyfun> I don't know.  Both of you have helped me enough.
[19:48] <tomreyn> arraybolt3: i'm not aware of Canonical producing a vulnerability scanner specifically for Ubuntu
[19:48] <tommyfun> thanks
[19:48] <tomreyn> tommyfun: what's the report you've been given?
[19:48] <arraybolt3> It wasn't a scanner, it's data *for* a scanner.
[19:48] <tommyfun> it was a nessus report
[19:49] <tomreyn> tommyfun: and the very finding is?
[19:49] <arraybolt3> Not sure if you can afford to uproot whatever you're using and try and use OpenSCAP, and I don't know enough to know if that's even a good idea or if the two are the same thing or close, but from what I've gleaned here, that might be useful.
[19:50] <tommyfun> sorry it's tenable
[19:50] <arraybolt3> tommyfun: I think he wants to know so that he can show the corresponding Ubuntu Security Notice.
[19:50] <arraybolt3> But you should be able to just plug in whatever CVE number it spit out into the USN database and it will tell you what update fixes it.
[19:50] <tommyfun> Apache 2.4.x < 2.4.55 Multiple Vulnerabilities: Upgrade to Apache version 2.4.55 or later.
[19:51] <tomreyn> this very finding you should be able to get rid of by using what sdeziel suggested
[19:52] <arraybolt3> I see there are vuln-patching updates as early as 1 February here https://ubuntu.com/security/notices/USN-5839-1
[19:52] <tommyfun> yeah, I was looking at that feb 1 notice
[19:53] <tommyfun> so if I installed the latest dpkg manually, does that break anything?
[19:53] <arraybolt3> You might break stuff installing things with dpkg. It should never be used manually except in exceptional circumstances.
[19:54] <arraybolt3> apt can apply updates safely and easily.
[19:54] <tommyfun> yeah, that's what I thought.
[19:54] <tommyfun> I could build a vm and test it, maybe later
[19:54] <tommyfun> thanks for all your help
[19:55] <tomreyn> this approach won't solve the issue for you in the long term
[19:55] <arraybolt3> tommyfun: If you're trying to only selectively patch just Apache, you can do that with apt.
[19:56] <arraybolt3> "sudo apt update && sudo apt install apache2" will update only just Apache and anything that needs to be updated in order for Apache to be updated.
[19:56] <tomreyn> there is something else you need to know, which is that while unattended-upgrades will update and reload affected services automatically, libraries may not immediately get updated, if they are still in use. but, based on the finding given, that's probbaly not what's happening here.
[20:00] <tomreyn> https://www.tenable.com/plugins/nessus/170113 -> the relevant info is "Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number."


[04:55] <Hitechcg> How long am I banned for?
[04:56] <rww> @btlogin
[04:59] <rww> Hitechcg: going to behave in there if I unban you?
[04:59] <Hitechcg> yeah
[05:00] <rww> alrighty. it's generally a lot harder to get unbanned if it becomes a repeat thing
[05:00] <rww> one sec
[05:00] <Hitechcg> it was a permaban?
[05:00] <rww> I've removed your ban. For future reference,
[05:00] <rww> !guidelines
[05:01] <rww> Bans don't have expiration dates by default. Some of us set them, some of us don't. This one didn't have one that I can see.
[05:04] <Hitechcg> oh, someone told me that a bot would automatically remove them eventually
[10:56] <ikonia> is ubottu still klined ?
[10:57] <DJones> I think so, it was klined, then rejoined and was klined again
[10:57] <DJones> Pricey: Can you unkline ubottu?
[10:58] <ikonia> do we know if anyone has sent an official request to the kline email to get it removed/find out why it was klined if there is a problem with it
[10:58] <ikonia> I doubt it's gone mental or anything, but it is possible
[10:59]  * Pricey looks
[10:59] <DJones> It looks as though it was during a mass split/rejoin period
[11:01] <Pricey> Looks like it's expired to me.
[11:01] <Pricey> "Banned due to too many  failed login attempts (SASL https://freenode.net/sasl/) in a short period
[11:01] <Pricey> "
[11:01] <ikonia> probably did go mad during a split then
[11:02] <Pricey> There may be other connections from that host, but make sure they have correct passwords & are set to identify to a specific account rather than the currently used nickname.
[11:02] <ikonia> will do
[11:03] <Pricey> Let me know if you're still getting the error when trying to reconnect, but I'm pretty sure you should be good to go.
[11:03] <ikonia> I'll see if one of the chaps with access can ask it to boot again
[13:56] <Pici> Pricey: thanks for taking a look the bots.
[13:56] <Pricey> Pici: All sorted now?
[13:56] <Pici> Pricey: yep
[13:56] <Pricey> Good stuff, no problem, I didn't do anything :)
[13:57] <Pricey> Those bans aren't very lengthy, just annoying enough to hopefully get people to check their auth settings if the're not malicious.
[14:05] <bazhang> It was for release 16.57.
[14:19] <Pici> very confuse
[14:49] <k1l> a TJ to the rescue
[16:37] <k1l> h1tl3r<EMAIL_ADDRESS>   obviously wrong nick
[16:51] <k1l> why do other distributions users sound like x/k/l/ubuntu is limiting the userexperience on purpose?
[16:53] <Pici> k1l: I'm not sure why you said that Ubuntu doesn't separate free and non-free, because thats exactly what the restricted and multiverse repositories are for
[17:22] <k1l> Pici: imho that is a different handling than fedora or debian do. iirc they do not even ship nvidia drivers while on ubuntu they do.
[19:19] <rww> k1l: Debian and Ubuntu have pretty much the same handling, except instead of restricted+multiverse it's contrib+non-free
[19:20] <rww> contrib being free stuff that depends on non-free stuff, and non-free being non-free
[19:20] <rww> the only other difference I can think of is that Debian splits out non-free firmware into a separate non-free package, which iirc Ubuntu doesn't do (but it's been ages)
[19:20] <rww> as far as I know, you are however correct about Fedora
[19:34] <Unit193> contrib doesn't have to depend, can simply recommend (I have one that does.)
[20:17] <Unit193> k1l: That ban will only last a day, though.
[20:17] <k1l> i didnt ban
[20:17] <Unit193> I know, you were going to, and that's the difference between you doing it and Drone`.
[20:19] <k1l> actually no. i did not call the kick+ban trigger. i thought it would be enough
[20:19] <Unit193> Ah, OK.  Nevermind. :3


[18:23] <acheronuk> could qtbase in proposed be hinted please? the pinentry amd64 test is regressed against itself, and not qtbase fault http://autopkgtest.ubuntu.com/packages/p/pinentry/eoan/amd64
[18:28] <teward> can someone badtest kopano-webapp for amd64, arm64, armhf, and i386?  The test logs in amd64, arm64, and i386 indicate that the web driver in use by Selenium is just crashing in the tests (via snaps) and armhf show shows a Snap / Chromium related crash issue.
[18:28] <teward> (it's blocking NGINX)
[19:23] <mitya57> By the way, I can confirm that pinentry test failure is not related to Qt. Looks like a race condition that started happening on amd64, but it was happening on !amd64 previously too, and on amd64 in ealier releases.


[08:33] <fabbione> Keybuk: you got your ubuntulog
[08:33] <Keybuk> thanks
[08:34] <fabbione> Keybuk: anyway the best is to just send me a mail
[08:35] <fabbione> becuase the bot is like -20 in my priority list :)
[08:35] <Keybuk> is that nice -20, or ... ? :p
[08:36] <fabbione> ehhe
[09:12] <Keybuk> infinity: random question; are we leading the initramfs-tools versions or are Debian?  ...  I'm making quite major changes, so it would feel more natural to release it was 0.40ubuntu1 or something
[09:22] <makx> ubuntu is behind atm.
[09:23] <Keybuk> fsvo "behind"
[09:23] <Keybuk> all the changes in your 039 are irrelevant for ubuntu
[09:23] <makx> we have changes jbailey ok'ed but didn't want to push yet for breezy
[09:24] <Keybuk> and replaced by those in our 040, which won't work for Debian
[09:24] <Keybuk> (or whatever version we use for it)
[09:24] <infinity> We haven't merged with Debian yet, nor have I had time to tell makx what Debian changes I think are utter crack so we can merge the other direction.
[09:24] <infinity> So, pick a version number at random, and make sure it has "ubuntu" in the name, and we'll sort it later. :/
[09:24] <Keybuk> infinity: ok
[09:25] <infinity> So, hurry the heck up. :)
[09:25] <Keybuk> am doing my changes right now :)  so the lock will be released once these are done and uploaded
[09:26] <makx> you still don't have a manpage for update-initramfs
[09:26] <Keybuk> infinity: one thing I'm considering ... would it make more sense to provide initramfs-tools hooks and scripts in udev, which will just get copied in, rather than hardcoding use of udev into initramfs-tools ?
[09:27] <makx> Keybuk: yes
[09:27] <makx> we already have an hooks/udev
[09:28] <makx> inifinity: please tell what is utter crack?
[09:28] <infinity> Keybuk : That would be beyond fine.
[09:28] <infinity> Keybuk : In fact, that's what we SHOULD be doing.
[09:28] <infinity> Keybuk : The less package-specific cruft we have in initramfs, the better.
[09:29] <infinity> Keybuk : If that approach can be done in both Debian and Ubuntu, our diffs may get very small again.
[09:29] <Keybuk> ok, because scripts/init-top/udev makes a lot of sense to me
[09:29] <Keybuk> along with hooks/udev to copy over things
[09:29] <infinity> (Which is one motivation for making it work that way)
[09:29] <Keybuk> and ship those in udev itself, rather than in initramfs-tools
[09:30] <infinity> makx : Nothing is "utter crack" so much as stuff that should be discussed.  I was being overly dramatic for effect. :)
[09:30] <infinity> Keybuk : Yes please.
[09:31] <makx> infinity: evms will move to it's package what else is bad?
[09:31] <infinity> evms was one, yes.
[09:31] <infinity> Realistically, anything that can be factored back out (and our own implementation was guilty of this before you started hacking on it) should be removed.
[09:32] <infinity> The more initramfs is kept as a flexible framework with very little actual "content", the better.
[09:32] <Keybuk> actually, now I think about it, it should be init-premount as otherwise it'll happen before module loading -- and conf/modules should happen first
[09:33] <infinity> I'm also wondering at what stage we should declare klibc a failed experiment, and just use glibc everywhere.
[09:33] <makx> do we have everything in busybox?
[09:33] <Keybuk> infinity: the klibc utilities are useful, but that's it
[09:33] <infinity> Keybuk : What does klibc ship that we couldn't get from turning on some busybox options?
[09:34] <infinity> (or building a few tiny binaries of our own, linked against glibc)
[09:34] <makx> would help a lot on Debian, klibc isn't ready for quite some archs
[09:35] <Keybuk> infinity: no idea, the binaries that come with klibc are tiny
[09:35] <Keybuk> we could just copy anything there we didn't have in busybox
[09:35] <Keybuk> run-init is probably the main one ;)
[09:38] <infinity> Reimplementing without klibc (whether or not we decide to use that branch) is definitely on my lis tof things to do.
[09:38] <infinity> So we'll see where that goes.
[09:38] <infinity> Right now, I should get back to making X build.
[10:09] <infinity> If yo ukeep fixing my bugs, I'll have to keep fixing Daniel's bugs, and the world will go all topsy-turvy!
[10:12] <Keybuk> who's bugs is daniels fixing?
[10:13] <infinity> See, that may be where it all falls apart.
[10:14] <Keybuk> and who is fixing my bugs?
[10:25] <Keybuk> infinity: hmm, do we want firmware in the initramfs or not?
[10:26] <fabbione> Keybuk: no, you don't
[10:26] <fabbione> otherwise initramfs will explode
[10:27] <Keybuk> what if they want an nfsroot on a network card that needs firmware?
[10:29] <fabbione> Keybuk: tough luck... some initramfs are already too big
[10:29] <fabbione> and netboot on some machines is broken for that
[10:38] <infinity> Well, PXE on wireless is never going to happen, but do we have wired cards that require firmware to go?
[10:39] <fabbione> only wireless
[10:39] <fabbione> afaik
[10:39] <infinity> fabbione : firmware wouldn't explode the initramfs.  Most firmware is way smaller than the driver it goes with.
[10:40] <fabbione> infinity: we are already fighting with oversize.. we need to put initramfs on a heavy diet
[10:40] <infinity> But, if we only ship firmware for wireless, it's not much of a win to have it in the initramfs IMO.
[10:40] <infinity> fabbione : Putting it on a diet is as simple as changing the mode used to build it.  It's undecided at the moment if we WANT to do that, though.
[10:40] <infinity> (The current mode has the advantage of being portable between hardware devices, whereas the smart detection modes mean if you chage your hardware, your system may not boot)
[10:41] <fabbione> infinity: ppc can't netboot.. it has been decided already :)
[10:41] <fabbione> starting from the amount of drivers will be in the udeb and so on...
[10:54] <Keybuk> Kamion: ping?
[10:56] <Keybuk> Kamion: (for your scrollback pleasure) ... could we nuke the d-i/base-config/debootstrap/whatever-does-it thing that adds /proc to /etc/fstab ... it's absolutely useless ;)
[11:01] <Kamion> it's nice to be able to 'mount /proc' without having to remember the arguments
[11:01] <Kamion> but file a bug on partman-target with rationale as to why it's actively bad to have it there
[11:04] <Keybuk> it's not so much actively bad, as misleading
[11:04] <Keybuk> it's never used by the main boot, so gives users the illusion that they can change it there and have some effect
[11:04] <Keybuk> and as /sys and /dev aren't alongside it, it looks strange
[11:05] <Kamion> need to also check that stuff in d-i doesn't rely on it
[11:05] <Kamion> (obviously it would be easy to change)
[01:24] <jbailey> Keybuk: wireless nfsroot will probably want firmware.
[01:25] <jbailey> fabbione: ppc can suck raw eggs. =)  What we did in Debian for initrd was to set ppc to dep and not the others.
[01:26] <fabbione> dep?
[01:26] <fabbione> dude.. i have a ppc
[01:26] <fabbione> and i use netboot
[01:27] <fabbione> initramfs must work
[01:27] <fabbione> or i am going to make an offer this channel can't refure
[01:27] <fabbione> refuse even
[01:29] <jbailey> So set your initramfs generator to dep mode.
[01:29] <jbailey> Just because that arch is broken doesn't mean the others need to be penalised against a very useful use case.
[01:30] <fabbione> i still need to figure who does root over wireless
[01:32] <makx> jbailey: please upload latest initramfs-tools :)
[01:37] <jbailey> makx: I'd prefer in general that 'sync with ubuntu' contained some level of details.
[01:38] <jbailey> It's not that important since Ubuntu is upstream for you.
[01:38] <jbailey> But since that's the only changelog file, you're actually dropping information there.
[01:39] <jbailey> There's no way to trace what's changed without a debdiff.
[01:39] <jbailey> makx: Uploaded.
[02:14] <Keybuk> I'm confused, why can't ppc netboot?  why does it have a maximum ramfs size?
[02:15] <fabbione> Keybuk: for some reasons OF can't load a file bigger than 6MB via tftp
[02:15] <Keybuk> sounds like a bug that can be fixed
[02:16] <Keybuk> just load the initramfs in 6MB chunks
[02:17] <jbailey> Keybuk: There seems to be a discussion about hostnames on the u-d.  Didn't we solve this problem at ubz?
[02:17] <jbailey> ISTR you or someone asking about it.
[02:17] <Keybuk> no?
[02:17] <Keybuk> wasn't me
[02:17] <jbailey> Hmm
[02:17] <jbailey> Colin's apparently enabled hostname now which makes it harder to get rid of busybox if we want to at some point.
[02:18] <Keybuk> do we want to get rid of busybox?
[02:19] <infinity> I don't.  busybox is love.
[02:19] <Keybuk> in busybox vs. klibc-utils, I err towards busybox IF we can get it to stop forking for its built-ins :)
[02:19] <infinity> Jeff is a purist, however, who thinks that eventually we can implement the whole thing as ed scripts.
[02:20] <jbailey> Keybuk: My idealist version is that it should be possibly to disable it and get a 20k initramfs in dep mode. =)
[02:20] <jbailey> possible, rather.
[02:21] <Keybuk> what shell would you use ?
[02:21] <Keybuk> and udev alone is about 150-200K
[02:21] <jbailey> Is it that big now?
[02:21] <jbailey> Hmm
[02:21] <jbailey> Okay, 100k then.
[02:21] <jbailey> initramfs' are gzip'd.
[02:22] <jbailey> Keybuk: There's no reason for things in there not to be ash friendly.
[02:22] <Keybuk> udevd is 55K, udevplug is 28K
[02:23] <Keybuk> all of the little helpers are about 240K together
[02:24] <Kamion> jbailey: harder to get rid of busybox> I don't understand how me enabling hostname makes it any harder?
[02:24] <Kamion> and busybox' shell *is* ash, near enough
[02:24] <infinity> You jus tgave us one more crutch?
[02:24] <Kamion> true
[02:25] <infinity> Not that I mind, terribly.
[02:25] <pitti> Keybuk: can we recognize ditital cameras by a device type argument, or do we need usermaps, just as with scanners?
[02:26] <jbailey> Kamion: What he said.  It's only an issue if there's still value in reducing the initramfs size by switching to really tiny utilities.
[02:26] <jbailey> Kamion: My argument is that there is, based on the fact that reading things over the network in grub is suck, as is reading off of flash.
[02:26] <infinity> I'm not sure there is much value in trying to make it tiny.
[02:27] <infinity> Making it not HUGE is good, but I dunno how tiny it needs to be.
[02:27] <Keybuk> pitti: where there's a usermap now, there's probably a good reason
[02:27] <infinity> Poeple booting from network and flash don't do it often enough to care about a few extra seconds' boot time.
[02:27] <Keybuk> you can do class-matching with the existing usermaps
[02:27] <infinity> (At least, they shouldn't be)
[02:27] <Keybuk> so I figure if they could, they would have
[02:27] <jbailey> infinity: Having an embedded device be usable in 5 to 10 seconds is good.  Loading the current sized initramfs off of CF was reported to be in the 1 to 2 minute range.
[02:28] <pitti> Keybuk: ok, so I'm going to merge libgphoto2 for now (just wanted to ask whether it woudd be a complete waste)
[02:28] <infinity> jbailey : I'd argue that our bug lies elsewhere, then, that read speed is inexcusable.
[02:29] <jbailey> infinity: Limitation of pc bios.  No dma, sucky short reads.
[02:29] <jbailey> That's why it's not a problem at runtime.
[02:30] <infinity> (And why are embedded device folk running Ubuntu kernels and bloated initrds anyway?)
[02:31] <Keybuk> pitti: I think we should keep both usermaps, we can support them for free; and only remove them if we're damned sure we can replace them for every device they use
[02:32] <jbailey> infinity: CF != embedded in every case.
[02:32] <pitti> Keybuk: ok; Debian's libgphoto generates its own udev rules from the usermap ATM
[02:32] <jbailey> infinity: It can be thinclient as well.
[02:32] <pitti> Keybuk: that certainly works, but we might be able to speed it up with grepmap
[02:32] <Keybuk> pitti: exactly, I think we should stick with the usermap simply because the conversion sucks
[02:32] <pitti> Keybuk: oh, it would be a conversion in the other way
[02:33] <Keybuk> how do you mean?
[02:33] <pitti> Keybuk: the former print-usb-usermap (which generated the usermap) now changed syntax to look like udev rules
[02:33] <pitti> Keybuk: of course we can revert to the older version for that
[02:33] <Keybuk> oh right, what's the source of that?
[02:33] <Keybuk> ie. where does it get the ids
[02:33] <infinity> jbailey : It could be, yes.  I did thin clients with IDE-CF once.  Of course, I also don't recall them being that shit-slow at loading kernels off the CF either, so...
[02:34] <Keybuk> for that one, it sounds like we should use the udev rules then -- call it /etc/udev/rules.d/85-gphoto.rules or something
[02:34] <Kamion> yenta_socket should be handled automatically now
[02:34] <Keybuk> Kamion: is there an event you can load them on?
[02:34] <Kamion> Keybuk: hard to tell - all my machines are yenta AFAIK
[02:34] <infinity> jbailey : Oh well.  I can see that there are corner cases for tiny initrds, but I'm not sure it's a case I'm inclined to optimise for.  People who really need a tiny boot can figure out how to make one.
[02:34] <infinity> (monolithic kernels, whatever)
[02:35] <Kamion> hm, well, I could move the dodgy logic from pcmcia-cs' init script into a udev rule that gets called on pcmcia_socket add
[02:35] <Keybuk> Kamion: grep for them in modules.alias
[02:35] <Kamion> Keybuk: I did; i82365 at least isn't there
[02:35] <jbailey> infinity: I'm not arguing to optimse for that.  Certainly I'm inclined to include busybox in every common case - I like having ls around if nothing else when I'm troubleshooting.
[02:35] <Kamion> nor is tcic
[02:36] <jbailey> infinity: But if there are reasonable things we can do (like poking the value into proc rather than using hostname) I think it's worth doing.
[02:36] <Keybuk> Kamion: a lot of the non-yenta bridges are ISA or equally antiquated, aren't they?
[02:37] <infinity> jbailey : Which one report claimed didn't work.
[02:37] <Kamion> Keybuk: i82365 is ISA; I can't quite figure out what the hell tcic is, but it at least only does PCMCIA not Cardbus
[02:38] <Kamion> i82092 is PCI
[02:38] <Kamion> (and in modules.alias)
[02:39] <Keybuk> the ISA ones are a bitch, because there's no way to detect them except with a stick
[02:39] <Keybuk> and some machines (usually Dells) don't like being poked with a stick
[02:41] <pitti> Keybuk: sorry, got distracted; I think the conversion tool parses it out of the C source
[02:41] <Keybuk> pitti: ok, use the existing conversion tool then :)  I thought you meant they had a tool to convert usermaps into udev.rules
[02:41] <Keybuk> so for gphoto, we should use udev.rules and write them to /etc/udev/rules.d/85-gphoto.rules
[02:41] <Keybuk> what does libsane do?
[02:42] <pitti> Keybuk: for gphoto that's exactly how Debian does it now
[02:42] <pitti> Keybuk: are the udev rules pre-parsed into memory structures, or are the text files parsed every time?
[02:42] <Keybuk> pre-parsed now
[02:42] <pitti> Keybuk: OTOH, udev parsing shouldn't be that much slower than grepmap, or is it?
[02:42] <Keybuk> note that the order matters, and our ordering is different to Debian's, so the filename might need to be different
[02:42] <Kamion> Keybuk: pcmcia-cs already has a pcic_probe and /etc/default/pcmcia that you can frob if you need to; all I need to do is check /etc/default/pcmcia and load what it says to load, more or less
[02:42] <Keybuk> Kamion: ok, we could steal that I guess
[02:43] <Kamion> yeah, I think what I'll do is write /lib/udev/pcmciautils that reads /etc/default/pcmcia and loads the module
[02:43] <makx> jbailey: thanks! :)
[02:43] <Kamion> and attach that to pcmcia_socket add
[02:44] <Keybuk> what adds pcmcia_socket ?
[02:45] <Keybuk> if the helper could output a list of modules, you can use a rule like:  PROGRAM="/lib/udev/pcmciautils", RUN+="/sbin/modprobe $result"
[02:45] <Keybuk> and make the helper exit 1 if there aren't modules
[02:45] <Keybuk> that's then consistent with the other things that do exactly that
[02:58] <pitti> Keybuk: Debian uses udev rule symlink 25_* (gphoto); so 85 is ok for us?
[02:58] <Keybuk> 85-gphoto.rules file is what we should have
[02:59] <Keybuk> hmm
[02:59] <Keybuk> hang on
[02:59] <Keybuk> what do these rules do, just assign permissions?
[02:59] <Keybuk> can you paste one?
[03:28] <Kamion> Keybuk: what adds pcmcia_socket> cs.c, I think, in an __init
[03:29] <Keybuk> right, so how does that get loaded?
[04:04] <Keybuk> pitti: so, yeah, paste a rule example couldya for gphoto?
[04:04] <pitti> Keybuk: I didn't continue the merge during the meeting, gimme some minutes
[04:04] <Keybuk> :(
[04:05] <Keybuk> I guess I could just steal the debian package and peek <g>
[04:07] <Keybuk> pitti: so, these rules are really sucky
[04:07] <Keybuk> could I suggest a _little_ tweak :)
[04:07] <Kamion> Keybuk: it's part of pcmcia_core; good question exactly what loads that first
[04:07] <pitti> sure
[04:07] <Keybuk> right now it generates something that looks like ...
[04:07] <Keybuk> BUS!="usb", ACTION!="add", GOTO="libgphoto2_rules_end"
[04:07] <Keybuk>   : rules here
[04:07] <Kamion> for PCI systems it'll be coldplugged as usual, since the world depends on it
[04:07] <Keybuk> LABEL="libgphoto2_rules_end"
[04:08] <Keybuk> so that has a problem already
[04:08] <Keybuk> you can't do BUS!= :)
[04:08] <Keybuk> change that to be SUBSYSTEM!="usb_device"
[04:08] <Keybuk> then the rules themselves, they look like
[04:08] <pitti> BUS != 'usb' looks a bit odd anyway?
[04:08] <Keybuk> SYSFS{idVendor}=="0553", SYSFS{idProduct}=="0202", RUN+="/etc/hotplug/usb/usbcam"
[04:08] <Kamion> we have a 'modprobe pcmcia' in the pcmcia_socket add udev rule for ISA systems etc., but I'm not sure what would cause that rule to actually get called on such systems
[04:08] <Keybuk> pitti: it's skipping the rules for anything not a usb add event
[04:08] <Kamion> I was hoping not to need an init script ...
[04:09] <pitti> ah, ok
[04:09] <Keybuk> and the script just assigns permissions to things
[04:09] <Keybuk> which is a bit doofus
[04:09] <Keybuk> so....
[04:09] <Keybuk> could we change the output to be something like
[04:09] <pitti> set the permissoins right away, yes
[04:09] <Keybuk> SUBSYSTEM!="usb_device", GOTO="libgphoto2_rules_end"
[04:10] <Keybuk> SYSFS{idVendor}=="0553", SYSFS{idProduct}=="0202", GROUP="plugdev", MODE="0660"
[04:10] <Keybuk> LABEL="libgphoto2_rules_end"
[04:10] <pitti> yes, that looks better
[04:10] <Keybuk> (and yes, I deliberately dropped the ACTION!=add thing)
[04:10] <pitti> I'll modify print-udev-rules-bla.c accordingly
[04:10] <Keybuk> then write the file as /etc/udev/rules.d/45-gphoto.rules
[04:10] <Keybuk> (45 not 85 so it doesn't get included in initramfs)
[04:10] <pitti> ok, sure
[04:11] <Keybuk> the rule numbers are set up in such a way that 50-xxx is the perfect place for user rules ... 20 assigns names, 40 permissions, 60 symlinks, 80 runs programs and 90 runs modprobe
[04:12] <Keybuk> initramfs doesn't have permissions, symlinks or programs ... so gets 0-39 and 90+
[04:14] <Keybuk> now, I shall make tea
[04:14] <Keybuk> then I shall get my laptop booting again, after I foolishly forgot to put udev.conf in the initramfs <g>
[05:02] <Kamion> ok, I'm going to give pcmciautils an init script that does the bridge module probe if it needs to; I don't see a way to do this within udev
[05:03] <Kamion> and I'll make it take a copy of /etc/default/pcmcia as /etc/default/pcmciautils so that I don't have to deal with pcmcia-cs.postrm removing the former
[05:03] <Keybuk> yeah, I don't think there is a way to do it with udev
[05:04] <Keybuk> udev reacts to events, if there's no event to react to, there's no way to do it
[05:04] <Keybuk> udev will correctly react to the modprobe, of course, so all you need to do is _start_ it
[05:04] <Keybuk> for most devices, the thing that starts stuff is udevplug, which walks sysfs and tickles everything the kernel's found so far
[05:05] <Keybuk> but if the kernel hasn't found legacy pcmcia buses, there needs to be a manual stick
[05:05] <Kamion> all the init script does is modprobe pcmcia_core, then if there's no /sys/class/pcmcia_socket/* yet modprobe $PCIC
[05:05] <Kamion> basically
[05:05] <jbailey> I thought all of the pccard love was supposed to just get folded in so that it behaved the same as any other pluggable bus (usb, ieee1394, etc..)
[05:05] <Kamion> jbailey: it does, but only for PCI bridges
[05:05] <Keybuk> jbailey: it has been
[05:05] <Kamion> then once the bridge is up, the rest is a regular hotpluggable bus
[05:05] <Keybuk> jbailey: you still need something to modprobe the drivers for the old ISA pcmcia bridges though
[05:05] <jbailey> Ah, okay.
[05:06] <Keybuk> Kamion: ok ... beware that the /sys thing won't turn up straight away
[05:06] <Kamion> Keybuk: no harm done if it doesn't, I think; I've stolen the code from pcmcia-cs.init to check whether there's a yenta bridge there by poking in /sys/bus/pci/devices/*/class
[05:06] <Keybuk> right
[05:06] <Kamion> and fixed it to detect i82092 as well, which is the only other PCI bridge I can see
[05:07] <Keybuk> that stuff's probably needless now
[05:07] <Keybuk> if there's a /sys/bus/pci/devices/*/class that's a yenta bridge, then yenta_socket will be loaded
[05:07] <Kamion> yeah, just a sanity-check to make sure we don't accidentally probe the wrong bridge
[05:07] <Keybuk> and you'll have /sys/bus/pcmcia
[05:07] <Keybuk> *nods*
[05:08] <Kamion> because apparently /etc/default/pcmcia is sometimes broken on old upgrades and says i82365 when it isn't
[05:08] <Kamion> and we check /sys/class/pcmcia_socket/* before any of this too, so if boot-time events loaded the bridge then none of this will happen anyway
[05:08] <Keybuk> ok, fixed udevplug bug, time for manual boot #3
[05:10] <Keybuk> ugh @ /sbin/udevplug -Bide -Bscsi -Bi2o -Busb -Bieee1394 /class/mem /class/misc /class/tty /class/vc /block
[05:10] <Keybuk> I'm so aliasing that to /sbin/udevplug --whatever-initramfs-needs
[05:12] <Keybuk> anyone know what the serio, eisa or MCA buses are?
[05:15] <HiddenWolf> eisa is/was a competitor to ps/2
[05:15] <jbailey> eisa was an extended isa bus.
[05:15] <jbailey> Supported some autoconfiguration, and a slightly wider bus path.
[05:15] <jbailey> The sockets could also take isa cards.
[05:15] <Keybuk> jbailey: anything on any of those we might need for initramfs?
[05:15] <Keybuk> ie. storage or hid controllers?
[05:15] <HiddenWolf> hm
[05:15] <jbailey> Keybuk: EISA *might* actually be autodetectable enough for initramfs.
[05:16] <Keybuk> /sys/bus/eisa/devices is empty on my system (at least on initial startup)
[05:16] <HiddenWolf> It was somewhat expensive to implement (though not as much as MCA), so it never became particularly popular in desktop PCs. However, it was reasonably successful in the server market,
[05:16] <jbailey> On a truly ancient system, yeah.  It was a good way of actually getting harddrive controllers in.  I think my alpha has eisa.  But it was popular in servers (and freaking expensive)
[05:16] <Keybuk> /sys/bus/MCA has turned up in 2.6.15 ... I think it wants to shout
[05:17] <jbailey> MCA is overloaded.
[05:17] <jbailey> Clasic MCA was a PS/2 architecture with autodetection.
[05:17] <Keybuk> I'll leave them out until someone bitches
[05:17] <jbailey> I think it's now something else.
[05:17] <Keybuk> we're already poking enough as it is
[05:18] <jbailey> I maintainer my argument that we don't actually care about anything pre-PCI for booting. =)
[05:18] <jbailey> maintain, rather =)
[05:18] <jbailey> Anything that old won't run gnome in any useful way.
[05:18] <Keybuk> what's i2o?
[05:18] <Keybuk> you put that in the spec when I wasn't looking
[05:18] <jbailey> It's a bus standard that was suppose to feature standarized drivers for high end hardware.
[05:19] <jbailey> I've never actually had one.  Tollef has, though.
[05:19] <Keybuk> does it have root filesystems on it?
[05:19] <jbailey> It does on his box.
[05:19] <jbailey> initramfs-tools theoretically supports it in Breezy.
[05:19] <Keybuk> ok
[05:19] <Keybuk> # /sbin/udevplug -Bide
[05:19] <Keybuk> udevplug[4499] : scan_bus: unable to open bus 'ide'
[05:19] <Keybuk> \o/
[05:20] <Keybuk> same thing for scsi, i2o, usb and ieee1394
[05:21] <Keybuk> (those bits are only for compile-your-own idiots ... those buses should be missing at this point, as we haven't probed the pci bus for storage controllers yet)
[05:21] <Keybuk> hmm, is it really /sys/bus/ieee1394 ?  I haven't got one
[05:21] <jbailey> jbailey@starshine:/sys/bus$ ls
[05:21] <jbailey> i2c  ide  ieee1394  macio  of_platform  pci  pcmcia  platform  scsi  usb  vio
[05:22] <Keybuk> i2c ?  is that different to i2o?
[05:22] <Keybuk> macio?  vio?  WHO INVENTED ALL THESE THINGS?! :)
[05:22] <Keybuk> my laptop has a /sys/bus/pci_express ... wonder whether we should look for controllers on that
[05:23] <jbailey> I think i2c is different, yes.
[05:23] <jbailey> I don't know how, though.
[05:23] <jbailey> jbailey@starshine:/sys/bus/i2c/drivers$ ls
[05:23] <jbailey> i2c_adapter  PMac Keywest Audio  therm_pm72
[05:23] <Keybuk> I2C (pronounce: I squared C) is a protocol developed by Philips. It is a
[05:23] <Keybuk> slow two-wire protocol (10-400 kHz), but it suffices for many types of
[05:23] <Keybuk> devices.
[05:23] <Keybuk> oh
[05:24] <Keybuk> it's the fan-speed thing
[05:24] <pitti> Keybuk: hey, look at that nice rule:
[05:24] <Kamion> macio and vio are similar-ish I think - at least, vio uses /proc/device-tree too
[05:24] <pitti> # USB PTP Class Camera
[05:24] <pitti> SYSFS{bDeviceClass}=="06", GROUP="plugdev", MODE="0660"
[05:24] <pitti> Keybuk: ^ *that*'s what rules should look like :)
[05:25] <Keybuk> pitti: yeah, that one should work for a lot of things -- provided it's within a SUBSYSTEM!="usb_device", GOTO="..." thing
[05:25] <Kamion> Keybuk: fan speed, some Mac sound devices, random other stuff on Macs too
[05:25] <pitti> Keybuk: yes, it is, I did the conversion
[05:25] <Keybuk> kewl
[05:25] <Keybuk> right, now for the biiig test
[05:26] <pitti> crw-rw---- 1 root plugdev 189, 260 2005-11-24 17:25 /dev/usbdev3.5
[05:26] <Keybuk> does /sbin/udevplug -Bpci -Iclass=0x010[01] * do the right thing?
[05:26] <Keybuk> hmm
[05:27] <Keybuk> that caused ide_core, alim15x3 and generic to be loaded
[05:27] <Keybuk> but, pointedly, no /dev/hda to appear
[05:27] <Keybuk> grr
[05:27] <pitti> Keybuk: now I'll try to convince libgphoto to actually talk to /dev/usbdev3.5 instead of /proc/bus/usb/003/004
[05:27] <pitti> s/4$/5/
[05:28] <Keybuk> pitti: it'll be /dev/bus/usb/003/004 with our naming rules
[05:28] <Keybuk> so you should just replace /proc with /dev
[05:29] <pitti> Keybuk: oh, ok, right now it's like above
[05:29] <pitti> but if that works in general, that should be fine
[05:31] <Keybuk> yeah, that's the "kernel-assigned" name for those devices
[05:31] <Keybuk> which is a bit boring
[05:32] <Keybuk> hmm
[05:32] <Keybuk> ok
[05:32] <Keybuk> /dev/hda, oh /dev/hda, wherefor art thou /dev/hda?
[05:35] <Keybuk> jbailey: ok, I'm clearly being stupid ... what provides those devices?
[05:36] <jbailey> Keybuk: Eh? It's in /sys/block
[05:36] <jbailey> What do you mean by what provides?
[05:36] <Keybuk> well
[05:36] <Keybuk> what module do I need to load?
[05:36] <Keybuk> they're not in /sys/block yet, because I haven't loaded the right module
[05:38] <jbailey> Oh
[05:38] <jbailey> your specific ide module
[05:38] <jbailey> ide-disk
[05:39] <jbailey> ide-generic
[05:39] <Keybuk> ok... so how do I know to load ide-disk? :P
[05:39] <jbailey> ide-generic must be last.
[05:39] <jbailey> You have to walk /proc/ide to get the info on each device.
[05:39] <Keybuk> no devices there yet ... you see
[05:40] <Keybuk> just /proc/ide/drivers
[05:40] <Keybuk> ohhh
[05:40] <Keybuk> I see the problem
[05:40] <jbailey> Right, but when you load cmd64x or whatever.
[05:40] <Keybuk> wtf is "generic"
[05:40] <jbailey> It'll be there.
[05:40] <Keybuk> not "ide-generic", "generic"
[05:40] <jbailey> Did they rename it?
[05:40] <Keybuk> no...
[05:40] <jbailey> And ide-generic doesn't have to be last, sorry, just has to be after any specific IDE drivers you want.
[05:40] <jbailey> But then /proc/ide will exist.
[05:41] <Keybuk> generic is what got loaded (along with ide-core and the specific module) when I walked the PCI bus
[05:41] <Keybuk> not ide-generic
[05:41] <jbailey> Ah.
[05:41] <jbailey> No idea what "generic" is.
[05:41] <jbailey> description=PCI driver module for generic PCI IDE
[05:42] <Keybuk> right, very odd
[05:42] <Keybuk> ok, so I need a rule in here somewhere to load ide-generic ... wonder how I'm going to shimmy that
[05:57] <pitti> Keybuk: how practical - our current libusb already checks for /dev/bus/usb before /proc/bus/usb :)
[05:57] <pitti> Keybuk: so I only need to teach it about /dev/usbdevX.Y
[05:57] <Kamion> ok, that's pcmciautils updated; the only thing I think pcmcia-cs is needed for now is setting up the resource database on installation, and possibly some CIS bits
[05:57] <Kamion> I'll look at those later
[05:58] <Keybuk> pitti: you probably don't need to do that
[05:58] <Keybuk> nobody is shipping without the /dev/bus/usb rules that I'm aware of
[05:58] <pitti> Keybuk: I could wait with the gphoto upload until you upload udev
[05:58] <pitti> Keybuk: we do at the moment :)
[05:58] <Keybuk> well, no, we don't TECHNICALLY :p
[05:59] <Keybuk> yeah, I'd wait and not support usbdevX.Y
[05:59] <Keybuk> hmm
[05:59] <pitti> Keybuk: ok, for testing I just modify my local udev rules, I guess
[05:59] <Keybuk> didn't we blacklist all of the framebuffer devices?
[06:00] <Keybuk> ahh
[06:00] <Keybuk> no
[06:00] <Keybuk> the old hotplug pci.agent just skipped them
[06:00] <Keybuk> hmm
[06:00] <Keybuk> udevplug doesn't do that, of course
[06:01] <Keybuk> I wonder whether there's some modprobe.d trick we can use to blacklist an entire class
[06:03] <pitti> Keybuk: yay, a symlink works nicely, great; thanks for your help
[06:04] <Keybuk> pitti: symlink?
[06:05] <pitti> Keybuk: /dev/bus/usb/003/008 -> /dev/usbdev3.8, just for testing
[06:05] <Keybuk> ahh
[06:05] <pitti> Keybuk: that's how your udev will create the devs?
[06:05] <Keybuk> it'll rename them
[06:05] <Keybuk> there won't be a /dev/usbdev3.8
[06:06] <Keybuk> (ie. it uses NAME= not SYMLINK+=)
[06:06] <pitti> Keybuk: I mean /dev/bus/usb/xxx/yyy
[06:06] <Keybuk> oh
[06:06] <Keybuk> right
[06:06] <Keybuk> yes
[06:06] <pitti> ok, cool
[06:06] <pitti> then everything is settled
[06:06] <Keybuk> is that what gphoto actually looks for?  it's not looking for /dev/bus/usb/3/8 ?
[06:06] <pitti> libsane uses libgphoto-port0, which uses libusb, which is prepared for your udev
[06:07] <pitti> Keybuk: I have to check the code if /3/8 is also supported
[06:07] <pitti> but since /proc/bus/usb always had three digits, that's what libusb currently looks for
[06:07] <Keybuk> cause I think that's how Debian named them (which I thought was a bug, so I prematurely fixed it just in case)
[06:10] <Keybuk> oooooh
[06:10] <Keybuk> my system has booted
[06:10] <pitti> Keybuk: 'k, /dev/bus/usb/3/9 works as well
[06:10] <Keybuk> pitti: ah, so it looks for both?
[06:10] <pitti> yes
[06:10] <Keybuk> which does it "prefer", looking at the code?
[06:10] <pitti> Keybuk: whatever comes first in asciibetical order
[06:11] <pitti> i. e. 00x, I suppose
[06:11] <Keybuk> oh right
[06:11] <pitti> oh, wait, that was a lie
[06:11] <pitti> it doesn't sort
[06:11] <pitti> so, whatever readdir() delivers first
[06:11] <pitti> not that it would matter so much
[06:12] <Keybuk> I mean which of /dev/bus/xxx/yyy, /dev/bus/x/y, /proc/bus/xxx/yyy does it look for first?
[06:12] <pitti> Keybuk: /dev is prefered over /proc, which is sane
[06:12] <pitti> Keybuk: the first two are indetermined
[06:12] <Keybuk> ok
[06:12] <pitti> Keybuk: it just walks the directory with readdir()
[06:12] <pitti> but that's fine AFAICS
[06:13] <Keybuk> oh, so it doesn't actually build the path?
[06:13] <pitti> the important part is /dev > /proc
[06:13] <Keybuk> right
[06:13] <Keybuk> so I now have 5 bugs
[06:14] <Keybuk> 1) ide-generic isn't loaded, so needs to be somehow
[06:14] <Keybuk> 2) /lib/udev/ide_media gets passed the wrong thing
[06:14] <Keybuk> 3) a typo in a rules file
[06:14] <Keybuk> 4) framebuffers need blacklisting
[06:14] <Keybuk> and
[06:14] <Keybuk> 5) kernel still panics
[06:19] <Keybuk> interestingly it did #5 quite a way down the boot sequence, when hal started
[06:19] <Keybuk> so maybe iz sysfs bug
[06:26] <Keybuk> jbailey: ping?
[06:26] <jbailey> Keybuk: pong
[06:26] <Keybuk> we utterly only support built-in IDE controllers or PCI IDE controllers, right?
[06:27] <Keybuk> or does ide-generic activate anything that the PCI walk didn't?
[06:27] <Keybuk> ie. should I put "modprobe ide-generic" in a udev rule if we find a PCI IDE controller, or does it need to be out of the main sequence?
[06:31] <Keybuk> hmm, deathly silence
[06:34] <jbailey> ide-generic should activate pretty much everything else that listens at the right addresses.
[06:34] <Keybuk> ok
[06:34] <jbailey> We added it in to support random embedded things and other bits that don't have the right chips.
[06:35] <Keybuk> the trouble is that a "modprobe ide-generic" won't wait
[06:35] <Keybuk> (for /dev/hda and stuff to appear)
[06:41] <Keybuk> right
[06:41] <Keybuk> modprobe -q ide-generic
[06:41] <Keybuk> udevstart -W
[06:41] <Keybuk> :)
[06:41] <Keybuk> uh s/udevstart/udevplug/
[06:44] <jbailey> LOL
[06:44] <Keybuk> hmm, so I noticed one bug with leaving udevd running until the real filesystem
[06:44] <Keybuk> we move /dev out of the way :)
[07:17] <jbailey> The idea was to cd /dev first.
[07:17] <jbailey> Should solve that, no?
[07:36] <Keybuk> no, because it would still try and mknod /dev/foo
[07:50] <Keybuk> is ok though
[07:50] <Keybuk> if we kill it just before we exec init, and start it straight after, that's pretty short
[07:50] <Keybuk> we don't need it for exec init ... that's way after mountroot
[09:23] <Mithrandir> hiya
[09:26] <Keybuk> heyhey
[09:26] <Mithrandir> jbailey: you pung?
[09:26] <jbailey> Mithrandir: Scott wanted to know about i2o
[09:26] <jbailey> Mithrandir: Since you've actually touched one, I was hoping you could answer better than I.
[09:26] <Keybuk> no, I just wanted to know how dead I'd be if I didn't broke it on boot ;)
[09:26] <Mithrandir> sure, what's the question?
[09:26] <Keybuk> uh, PROBE it on boot
[09:26] <Keybuk> hello, freud
[09:27] <Mithrandir> Keybuk: well, the system would be completely unbootable.
[09:27] <Keybuk> that's pretty much what I wanted to know
[09:27] <Keybuk> i2o controllers are PCI storage controllers?
[09:27] <jbailey> Keybuk: I don't know what Norweigians do when they're angry, but that's what you'd have to deal with.
[09:27] <Mithrandir> unless one, for some insane reason has / on something non-i2o, that is.
[09:27] <jbailey> Tax you, or something.
[09:27] <Keybuk> jbailey: Tollef bites
[09:27] <Mithrandir> I also slap people with x40s
[09:28] <Keybuk> Mithrandir: like IDE or SCSI?
[09:28] <Keybuk> ... with their X40
[09:28] <Mithrandir> yes, but why would you do that if you have an I2O controller?
[09:28] <Keybuk> I don't know what an i2o controller is
[09:28] <Keybuk> I've never seen one before
[09:28] <jbailey> Mithrandir: That's the part you can fill in that I can't. =)
[09:28] <Keybuk> SATA I think
[09:28] <jbailey> Keybuk: sata, probably. =)
[09:28] <Mithrandir> it's a disk controller, most often SCSI on the disk interface, but can be anything.
[09:28] <jbailey> Mithrandir: Aren't there i2o nics too?
[09:29] <Mithrandir> i2o is a standardised interface, so you only have to have one driver for all kinds of hardware
[09:29] <Mithrandir> jbailey: possibly.
[09:29] <Keybuk> ah, yes
[09:29] <Keybuk> another standardised interface
[09:29] <Keybuk> the nice thing about those is there are so many of them
[09:29] <Keybuk> you just need one driver for each bloody standardised interface
[09:29] <Mithrandir> yes :-)
[09:29] <Keybuk> ok
[09:30] <Mithrandir> it's like if you had a single SCSI card adapter which worked for all scsi cards, though.
[09:30] <Keybuk> I'll leave -Bi2o in then
[09:30] <Keybuk> not that should actually have anything on it at that point
[09:30] <Keybuk> that probe is for stuff that got loaded *before* we probed the PCI bus for storage controllers
[09:30] <Keybuk> usually "elmo woz ere" type things
[09:30] <jbailey> Mithrandir: (and then couldn't find any scsi cards)
[09:31] <Mithrandir> s/adapter/driver/, though
[09:31] <Mithrandir> Keybuk: also, devices show up in /dev/i2o/hdX and not as /dev/hdX.
[09:33] <Keybuk> do they?
[09:33] <Keybuk> O:-)
[09:33] <Keybuk> perhaps you should rephrase that
[09:33] <Keybuk> maybe "could you make the devices show up in /dev/i2o" ... :)
[09:34] <Mithrandir> they should show up as /dev/i2o/hdX, not /dev/hdX. :-P
[09:34] <Keybuk> should they?
[09:34] <Mithrandir> that's what all the docs say, that's what the kernel default is and so on, so yes, I absolutely think so.
[09:34] <Keybuk> there isn't a kernel default
[09:34] <Keybuk> hmm
[09:34] <Mithrandir> MAKEDEV default, then
[09:34] <Mithrandir> unless you have a good reason for them to show up somewhere else.
[09:35] <Keybuk> there isn't a rule for that in current udev.rules ... so how does that work?
[09:35] <Keybuk> *shrug*
[09:35] <Keybuk> I guess it just does
[09:35] <Keybuk> kernel probably does something sick like DEVNAME=i2o/hdX
[09:36] <Mithrandir> on my i2o box (which runs hoary), I have both /dev/i2o_hda and /dev/i2o/hda
[09:36] <Keybuk> kooky
[09:36] <Mithrandir> (as well as i2o_hda1, i2o/hda1, etc)
[09:37] <Mithrandir> yeah, I think just i2o/hdX is good
[09:37] <Keybuk> could you do a udevinfo -q all -n /dev/i2o_hda
[09:37] <Keybuk> and udevinfo -q all -n /dev/i2o/hda
[09:37] <Mithrandir> : tfheen@my ~ > udevinfo -q all -n /dev/i2o_hda
[09:37] <Mithrandir> device not found in database
[09:37] <Mithrandir> : tfheen@my ~ > udevinfo -q all -n /dev/i2o/hda
[09:37] <Mithrandir> P: /block/i2o!hda
[09:37] <Mithrandir> N: i2o/hda
[09:37] <Mithrandir> S:
[09:37] <Mithrandir> : tfheen@my ~ >
[09:37] <Mithrandir> blank line after the S:
[09:38] <Keybuk> udevinfo -a -p '/block/i2o!hda'
[09:40] <Mithrandir> loads
[09:40] <Mithrandir> http://pastebin.com/437435
[09:43] <Keybuk> interesting
[09:46] <Keybuk> well, I guess it works
[09:46] <Keybuk> unlike my IDE controller *sigh*
[09:46] <Mithrandir> I'm going to get that particular machine available for testing in a few days, so I can do any kinds of testing you want.
[09:46] <Mithrandir> it's probably going back into production in not too long, though, as it's a dual 250 and we like to keep those busy.
[09:47] <Keybuk> *nods*
[09:57] <Mithrandir> does that mean "please tell me when you've installed dapper on it and what breaks"?
[09:57] <Keybuk> yup
[09:57] <Keybuk> pretty much
[09:58] <Mithrandir> it'll be easy for me to give out access to the box when it's reinstalled, if you're interested.
[09:58] <Keybuk> sounds good
[09:59] <Keybuk> theoretically it should all be fine though
[09:59] <Keybuk> I can't see any special handling for i2o in Debian or SuSE's rules
[09:59] <Mithrandir> yeah, and in theory theory and practice are equal.
[09:59] <Keybuk> which probably means it was written a not-too-insane man
[09:59] <Keybuk> and the kernel actually knows how to drive it
[09:59] <Mithrandir> the original driver was written by a Mr. Cox.
[09:59] <Mithrandir> you might have heard of him.
[10:00] <Keybuk> indeed
[10:00] <Mithrandir> he's probably insane, but in the good sense of the word.
[10:00] <Keybuk> :o)


[00:11] <ananke> my first time with maas, and a stack of dell PE R710 systems. all systems are set to boot from pxe, and they enlist then power off. mass doesn't seem to be able to power them back on for comissioning though
[00:12] <ananke> it seems the nodes are shown in maas to use ipmi 2.0 over lan with IP <IP_ADDRESS>, which is the default idrac setting. however, there are no interfaces on the maas controller that would talk to that subnet. what gives? shouldn't maas set the IPs for idrac during enlisting?
[01:06] <mup> Bug #1754335 changed: [2.4, UI] Node action form takes a long time to disappear <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1754335>
[02:19] <Hey__> smartctl validate empty file  what does this mean?
[02:19] <Hey__> I am hitting the ipmi successfully.
[02:19] <Hey__> it says power on and its green
[02:20] <Hey__> but when it tries to comission.. nothing happens.. or the result is it fails.
[02:20] <Hey__> I manually added the node as I didn't see it in the Dashboared.
[03:21] <mup> Bug #1754335 opened: [2.4, UI] Node action form takes a long time to disappear <ui> <MAAS:Incomplete> <https://launchpad.net/bugs/1754335>
[12:37] <mup> Bug #1763010 opened: Block devices not discovered during commissioning <MAAS:New> <https://launchpad.net/bugs/1763010>
[12:40] <mup> Bug #1763010 changed: Block devices not discovered during commissioning <MAAS:Invalid> <https://launchpad.net/bugs/1763010>
[13:52] <parlos_> Good Morning
[13:52] <mup> Bug #1763010 opened: Block devices not discovered during commissioning <MAAS:Incomplete> <https://launchpad.net/bugs/1763010>
[13:58] <ananke> is maas supposed to set up automatically NAT between the controller and fabrics? my enlisting and comissioning fails, while the logs indicate that the nodes can't reach outside world
[14:00] <ananke> documentation is a bit sparse, or perhaps I'm not looking in the right place
[14:02] <roaksoax> ananke: nope
[14:02] <roaksoax> ananke: maas won't setup NAT
[14:03] <ananke> thank you, that may explain a lot of the issues I'm having
[14:04] <ananke> looks like eventually the nodes fetch stuff directly from maas, presumably using it as a proxy. however, once enlisted, maas doesn't show any relevant data as to the amount of cores/mem/etc on the nodes. it does have the right IPMI setup, and it can power cycle them
[14:06] <parlos_> Can/Does an deployed MAAS change/update how nodes are commissioned? Got a challenge... Suddenly nodes could not be commissioned, ended up in busybox... complaining some missing driver. But the nodes were commissioned before...
[14:07] <parlos_> No change on my behalf.. and now, when testing the issue again, they commission just fine..
[14:16] <ananke> parlos_: hah. I have yet been able to comission a single node
[14:16] <ananke> each node boots, loads the image, but then logs on maas show a metric ton of ureadahead errors
[14:16] <parlos_> Took me a while before I got it working too. Had a way too complicated network environment, >2 nics
[14:16] <ananke> eg: Apr 11 14:13:45 fast-stork ureadahead[1052]: ureadahead:/usr/lib/tmpfiles.d/x11.conf: Error retrieving chunk extents: Operation not supported
[14:17] <ananke> parlos_: I just have two nics: one for external network, another for internal (where all the nodes reside)
[14:17] <parlos_> Is this at the first boot? I.e. pre-commisson?
[14:17] <ananke> this is during comission. however, I'm not convinced enlisting works correctly either
[14:18] <ananke> because the nodes don't show cores/cpu/etc in the maas interface
[14:18] <parlos_> during enlistment it will not show any hw specs...(AFAIK)
[14:18] <ananke> ahh, ok
[14:21] <ananke> maas UI shows comissioning failed, and then for each module it has an empty log file
[14:21] <parlos_> :(
[14:22] <parlos_> do you have access to the console of the devices?
[14:22] <parlos_> my experience from first MAAS deployment, was that viewing the console helped.
[14:23] <ananke> I do, but I honestly am not sure what I would be looking at. for example the system just spent 5 mins waiting for something, then mass comissioning image proceeded with shutdown
[14:24] <parlos_> in my case, the device, me and maas disagreed on what was the first interface. Hence, it did the enlistment on interface X, then during commisioning it thought X was now Y...
[14:24] <parlos_> If it waits, then i guess it tries to reach an IP and it cant...
[14:25] <ananke> so here's full dump of /var/log/maas/rsyslog/<sample node>/date/messages: http://ix.io/17wV
[14:26] <ananke> I'm not sure if that's the right place to look at to determine what actual aspects of comissioning failed or not
[14:27] <roaksoax> ananke: yes maas has a caching proxy and by default apt would attempt to use it unless you disabled it
[14:27] <roaksoax> parlos_: could be a kernel issue
[14:28] <parlos_> did not change kernel...
[14:28] <ananke> roaksoax: nope, didn't disable it. however, it seems to try direct route first, before it tries the proxy. this is a fresh install of ubuntu 16.04 with maas 2.3.0
[14:30] <parlos_> ananke, are there multiple boots in that log?
[14:30] <ananke> parlos_: just one
[14:31] <ananke> ~9 minutes from start to finish
[14:33] <parlos_> Ok, its a bit confusing.. at 14:12:58 its looks that its the kernel boot, but prior to this we got ssh keys (before kernel??) could be wrong..
[14:34] <ananke> parlos_: indeed, that does look confusing. however, that's how the rsyslog on the maas controller seems to have recorded this
[14:38] <ananke> what user can I ssh as to the given node while it's being comissioned?
[14:39] <parlos_> nope....
[14:39] <parlos_> can you get a console via the BMC?
[14:40] <ananke> so what's the point of having 'Allow SSH access and prevent machine from powering off' check box for comissioning?
[14:41] <parlos_> dunno, have never tried it..
[14:41] <parlos_> I have the luxury to use iDrac so I have console access..
[14:41] <ananke> ahh: 'As long as you've added your SSH key to MAAS, you can simply connect with SSH to the node's IP with a username of ubuntu.'
[14:42] <ananke> parlos_: these systems have idrac express, so no remote console
[14:43] <parlos_> i got those too.. then I walk into the noisy room, and the KVM...
[14:43] <parlos_> What is your network cfg?
[14:43] <parlos_> for the nodes?
[14:44] <ananke> I have a dozen R710s that we were going to surplus, and instead I figured I can try maas/openstack/openshift/whatever on them
[14:44] <parlos_> :) got R715s..
[14:44] <ananke> parlos_: i have one system to act as the maas controller. it has two NICs: external and internal. internal is connected to a basic switch with a flat network
[14:45] <parlos_> and the nodes are connected to the switch with one nic, where is the BMC connecteD?
[14:45] <ananke> the rest of the r710s are then connected to that switch, with their primary interface. i set them to use only pxe boot, from that first nic. idrac is set to be shared lan mode
[14:45] <ananke> correct
[14:46] <parlos_> did you disable the other nics?
[14:46] <parlos_> (ok on idrac)
[14:46] <ananke> nope, since my plan was to eventually use those other nics for something else (perhaps external network)
[14:47] <ananke> and clearly, they do use that one interface, since they boot, get the initial image, and the maas controller receives logs from them
[14:48] <parlos_> ok, my setup is similar. But nic2 is connected to another switch. 3+4 are disabled.
[14:48] <ananke> so now the question is what exactly fails during the comissioning
[14:49] <parlos_> agree, but the log is not clear...
[14:50] <parlos_> Do you have some other HW  platform that you could test? as to see if there is an MAAS kernel to R710 issue?
[14:51] <ananke> parlos_: unfortunately, not in that data center. I have another rack full of gear in another location, but I haven't finished the setup yet
[14:52] <parlos_> I would however be surprised it it was a kernel-hw issue...  How are the discs configed?
[14:52] <parlos_> hw raid?
[14:52] <ananke> yes. perc 6i, two disks in each node with raid 1
[14:54] <ananke> so a very basic setup
[14:55] <ananke> I'll see if logging into the nodes while they're in the process of comissioning will yield any clues
[14:56] <parlos_> not r710 directly, but another guy had an issue with HP dl380, and it was a bios issue..to new..
[14:57] <ananke> I got all of the r710s up to bios 6.4.0/6.5.0, and tried to get all of the idracs updated too
[14:58] <parlos_> There is an issue/bug at https://bugs.launchpad.net/ubuntu/+source/ureadahead/+bug/1628438
[14:58] <parlos_> In MAAS does it list "Commision failed?"
[15:00] <ananke> yes
[15:01] <ananke> and I saw that bug earlier, sadly it leads to nowhere
[15:02] <parlos_> I'd try to get console access, and view the output. From the syslog we do not see the thing that caused the Error that resulted in a fail...
[15:05] <ananke> parlos_: I'm not sure I can even login to the console though
[15:05] <parlos_> you dont have to login, just watch the output..
[15:05] <ananke> as in, it's not like there is a login prompt
[15:06] <ananke> that's the thing. there's nothing out of the ordinary. and comissioning failed errors appear on the maas controller long time before the nodes finish and shut down
[15:08] <parlos_> It sounds to me that then node cannot properly talk to the maas server.. (for some reason).
[15:09] <parlos_> afaik, so it boots, starts some actions (based on the tftp/pexe info), then as some point it need to talk to the maas. The maas waits for this, and if this does not happen
[15:10] <parlos_> MAAS calls it failed, while the node timesout and tries again...eventually it gives up and shuts down.
[15:13] <parlos_> ok,. have to go. Have a nice day, and good luck!
[15:14] <srihas> hi guys, currently the network configuration on the depoloyed node is in /etc/network/interfaces.d/*.cfg rather than /etc/network/interfaces. Is there a way to tell MAAS to do it at  /etc/network/interfaces? thank you
[15:16] <mup> Bug #1763059 opened: [2.4] DHCP is being configured on a rack controller that is not set to run DHCP <MAAS:In Progress by blake-rouse> <https://launchpad.net/bugs/1763059>
[15:29] <roaksoax> srihas: no, network config is done by cloud-init and does it in interfaces.d/*.cfg
[15:30] <roaksoax> parlos: hceck that rackd.conf:maas_url has the IP of the region instead of localhost
[15:32] <srihas> roaksoax: I saw a bug that JUJU is looking at interfaces file, will it be a problem if I am going to dpeloy OpenStack with JUJU later on this node?
[15:50] <roaksoax> srihas: juju should be handling e/n/i.d/*.cfg just fine
[15:50] <srihas> roaksoax: thank you :)
[16:02] <ananke> is there a way to login from the console of a system that's in the process of being comissioned, other than the ssh?
[16:16] <ananke> ahh ffs, I see one of the potential problems
[16:17] <ananke> when I hit 'comission', maas powers on the system. before that system has a chance to even fully POST, maas issues a forced reboot via the ipmi
[16:17] <ananke> wtf
[16:19] <ananke> then it claims they failed comissioning, while the nodes are booted into some maas image
[16:19] <ananke> that's insane
[16:20] <ananke> why would maas wait so little time for them to post? is that a configurable option?
[16:28] <ananke> it power cycles them after roughly 60 seconds. that's crazy
[16:30] <ananke> I feel like this is a bug, since I never configured any timeout settings in maas
[16:35] <ananke> ahh ffs: https://bugs.launchpad.net/maas/+bug/1635107
[16:59] <roaksoax> ananke: /win 4
[16:59] <roaksoax> err
[16:59] <roaksoax> sry
[17:04] <mup> Bug #1763093 opened: Gateway can be choose in wrong subnet <MAAS:New> <https://launchpad.net/bugs/1763093>
[18:28] <Hey__> when I add a physical interface to a node I'm about to comission, I see Error: node must be connected to a network.
[18:28] <Hey__> Does the node need to have internet access?
[18:29] <Hey__> I mean.. its connected to an internal network with no internet access
[18:36] <roaksoax> Hey__: no
[18:36] <roaksoax> Hey__: if it is to *commission* no
[18:36] <roaksoax> if it is to deploy, yes
[18:47] <mup> Bug #1763147 opened: [2.4, UI] Overall service status' not updating correctly <MAAS:Triaged by blake-rouse> <https://launchpad.net/bugs/1763147>
[20:35] <mup> Bug #1763169 opened: [2.4, enhancement] Add UI option to allow/disallow proxy usage <MAAS:New> <https://launchpad.net/bugs/1763169>
[20:44] <mup> Bug #1763169 changed: [2.4, enhancement] Add UI option to allow/disallow proxy usage <MAAS:Triaged> <https://launchpad.net/bugs/1763169>
[20:47] <mup> Bug #1763169 opened: [2.4, enhancement] Add UI option to allow/disallow proxy usage <MAAS:Triaged> <https://launchpad.net/bugs/1763169>
[21:29] <Hey__> roaksoax, under Nodes > Interfaces I geat an error it says Error: Node  must be connected to a network.  but the node is connected
[21:30] <bladernr> roaksoax, blake_r, newell_ do you guys remember what file is handed out when a Power8 box PXE boots via MAAS?  is it the same pxelinux.0 file that x86 gets?
[21:30] <bladernr> or does it get a different file in /var/lib/maas/boot-resources/*
[21:40] <newell_> bladernr: power8 uses powernv afair
[21:41] <newell_> bladernr: which uses petitboot...which is the binary bootloader so no pxelinux.0 file needs to be downloaded.
[21:42] <bladernr> hrmmm... yeah, that's what I recall.  I'm looking at an openpower box (well, looking at a dump of the petitboot menu) and it's grabbing pxelinux.0 from MAAS.
[21:42] <bladernr> and then complains that some temp file is not a valid ELF binary
[21:42] <bladernr> meh, was just checking, the whole thing's a bit of a mess.
[21:42] <bladernr> thanks!
[21:44] <roaksoax>  bladernr: /var/lib/maas/dhcpd.conf will tell you what file is for power 8
[21:45] <bladernr> ahhh thanks roaksoax that's the confirmation I needed.
[21:46] <roaksoax> bladernr: https://pastebin.ubuntu.com/p/fKNqvd9v7G/
[22:19] <Hey__> I am having problems commissioning nodes.  I don't see the node in the Dashboard, I only see it in Observed under subnet. So I add it manually. adding the ipmi interfaces
[22:20] <Hey__> When I Select Commission, it runs for a while then fails.
[22:20] <Hey__> What logs do I check to see what the issue is?
[22:21] <Hey__> Events show Queried node's BMC - Power state quried o:on
[22:30] <Hey__> what power type do I use for hyper-v?
[22:33] <Hey__> ohh..i see. for that VM, I had to do it manually
[23:42] <mup> Bug #1763214 opened: [2.4, UI, vanilla]  Zone details page not formatted correctly <vanilla-transition> <MAAS:Triaged> <https://launchpad.net/bugs/1763214>
[23:42] <mup> Bug #1763215 opened: [2.4, UI, vanilla] Group by on 'Subnets' tab is wrapped <vanilla-transition> <MAAS:Triaged> <https://launchpad.net/bugs/1763215>
[23:45] <mup> Bug #1763216 opened: [2.4, UI, vanilla] Subnet in interfaces table is gone <vanilla-transition> <MAAS:Triaged> <https://launchpad.net/bugs/1763216>
[23:45] <mup> Bug #1763217 opened: [2.4, UI, vanilla] Delete subnet text is wrapped and missing warning icon <MAAS:Triaged> <https://launchpad.net/bugs/1763217>
[23:45] <mup> Bug #1763218 opened: [2.4, UI, vanilla] Delete range (inside subnet) text is wrapped <MAAS:Triaged> <https://launchpad.net/bugs/1763218>
[23:48] <mup> Bug #1763219 opened: [2.4, UI, vanilla] Delete fabric confirmation text is misplaced <vanilla-transaition> <MAAS:Triaged> <https://launchpad.net/bugs/1763219>
[23:48] <mup> Bug #1763220 opened: [2.4, UI, vanilla] Compose pod action form has misplaced buttons <MAAS:New> <https://launchpad.net/bugs/1763220>


[08:51] <JonathanD> Morning.
[09:14] <rmg51> Morning
[09:24] <JonathanD> Whats up rmg51
[09:24] <rmg51> as usual just us :-D
[09:25] <JonathanD> So it seems.
[09:25] <JonathanD> it's nice and cool right now...
[09:28] <rmg51> that won't last :P
[11:43] <waltman> 4:51 isn't morning. 4:51 is night.
[11:44]  * waltman yawns
[12:25] <InHisName> Not night any more, g'mawnin' to y'all
[12:43] <waltman> InHisName speaks the truth
[20:31] <InHisName> ubuntu question:  the clock and other icons on far right of top bar,  am I able to relocate them further to left ?   like 3/4 of the way rather than 100% of the way to the right ?