[00:53] I'm having difficulty connecting to my printer. I set up a USB connected printer attached to my print server using CUPS. From my desktop, I let it find the printer connected to the server (Server and Desktop are on the same LAN). I can print a test page from CUPS connected to the server (192.168.0.xx:631, but I cannot print a test page from CUPS connected to my desktop (localhost:631). Ideas? [00:59] check cups logs on both systems? [02:05] Sarnold: got it working. Thaks [02:05] petersfreeman: nice, what was it? === ashleyd is now known as ashd [03:02] Hey guys, I am in a situation hopefully you can help me. So for some reason I decided to make my boot partition 400gb. I am wanting to move that 400gb of free space from sda1 to sda6, is there a way for me to do that? or what would I have to do. === lala is now known as Guest10289 [05:49] hello all === zz_DenBeiren is now known as DenBeiren === zz_DenBeiren is now known as DenBeiren [06:46] win 6 === pHcF_ is now known as pHcF [08:11] Good morning. [12:06] dannf: I'm going to release security updates for mysql, can you confirm that the packages in -proposed are all tested? [12:08] dannf: also, since we always ship the latest upstream mysql, I'm not sure how we're supposed to maintain those patches...have they been submitted upstream? [12:09] They are proposed and not yet finally tested. If they are tested fully. They are moved out of proposed. [12:57] hi there [12:57] need help for ubuntu server [12:58] our Raid1 sytem failed to start after a power loose in our place [13:03] anybody here? [13:06] !patience [13:06] Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/ [13:07] no boot paste.ubuntu.com [13:08] You might want to state your actual problem though. Volunteers tend not to want to commit to helping someone with open ended problems because they tend to take an open ended amount of time. [13:08] no boot http://paste.ubuntu.com/11887633/ [13:08] softraid [13:27] kevin070982: Did you boot a live stick, is your data still there? [13:33] i will boot via live stick in few minutes [13:33] still downloading one [13:33] the question is what is the best way to make the raid work again [13:33] seems to me that the bootloader didn^t load the raid partition [13:36] First see if the data is still there. See what the damage is. === ashleyd is now known as ashd [13:47] mdeslaur: the only thing that still needs testing is the trusty update, which FTBFS due to an unrelated issue. there's a fix for that in the sru queue. [13:48] mdeslaur: oracle is looking at fixing it - they can't take my fix because it's a port from mariadb that wasn't contributed under the OCA (noted in the dep3) [13:49] mdeslaur: trusty mysql-5.5 is good, mysql-5.6 is the one in the SRU queue [13:52] dannf: all I care about is mysql-5.5/trusty, mysql-5.5/utopic and mysql-5.6/vivid [13:52] dannf: are those tested? [13:52] mdeslaur: yes they are [13:54] o/ [13:54] dannf: http://paste.ubuntu.com/11887850/ to catch up from #ubuntu-hardened [13:55] (sorry I didn't notice this concurrent conversation) [13:55] dannf: so I wasn't part of the original discussion with regards to those patches...I added my concerns to the bug [13:55] but rbasak has now told me it's been discussed [13:56] dannf: so my understanding is that if I prepare a new mysql version and the patches don't apply I just ignore them? [13:57] mdeslaur: that would cause memory corruption for ppc64el/arm64 users [13:57] of course, that is likely to regress users who think mysql is usable in trusty [13:57] so i don't think ignoring them is a good approach [13:57] dannf: right, so are you commiting to getting me updated and tested patches for each new mysql release as soon as it comes out? [13:58] My understanding was that if dannf's team can't fix it, then we wouldn't hold up a security update for the other archs. [13:58] I can't selectively publish archs [13:58] unless it FTBFS [13:58] Right, so that would mean regressing arm64 etc. [13:59] rbasak, dannf: if the patches do appear to apply, and it builds, do I release the new version without testing on ppc64el and arm64? [14:00] I'd say yes. [14:00] mdeslaur: to the extent reasonable, yes (i commit to updating), but that does need some time [14:00] Again, I apologise for not speaking to you before. I don't want to see this as a done thing - if that doesn't work for you, we should speak and reconsider. [14:00] mdeslaur, rbasak +1 - if it applies, go for it [14:02] * dannf understands this is a bad situation - wish i could do more, but nothing i can personally do since i don't hold copyright on the fix [14:02] but i can poke oracle again and ask about status [14:03] I wonder if we should reconsider Oracle MySQL's place in main on the basis of this issue. [14:04] On one hand the patch author won't sign Oracle's agreement, but on the other hand it's Oracle that won't take the patch and haven't fixed the bug. [14:04] Combined with them not providing security patches. [14:05] rbasak: while that's a good discussion for the dev release, it doesn't change anything with regards to the stable releases that I have to update in the next couple of days [14:05] mdeslaur: understood. If you're still unhappy, I think we should reconsider carrying the patch. [14:06] adding these patches to trusty means every three months for the next 4 years the patches need to get rebased and tested on the latest mysql version [14:07] mdeslaur: until oracle releases an update with a proper fix, yeah - which they are working on [14:07] right [14:08] ok, so here's the plan: 1- rbasak please find someone in the sru team to release the packages currently in -proposed ( mysql-5.5/trusty, mysql-5.5/utopic and mysql-5.6/vivid) [14:08] either today or tomorrow [14:09] that way, those will be available for ppc64el nd arm64 [14:09] I will prepare updates for the new versions with the patches [14:09] If they apply, fine, if they don't, I'll ping dannf [14:10] I may publish the updates anyway, just not for the two archs that FTBFS [14:10] mdeslaur: can you point me at the new release/patches/whatever, so i can look at the risk ahead of time? [14:10] depending if dannf can quickly get me updated patches [14:10] dannf: that would be the 5.5.44 and 5.6.25 new upstream versions from mysql's site [14:10] rbasak: arges approved the srus, i can ask if he'll flush -proposed for us [14:11] OK. I'd like to delegate chasing the SRU team to dannf, if dannf you're OK with that. [14:11] Though, this assumes that mdeslaur you're happy with this situation. [14:11] If you're not and think we should reconsider carrying the patches in the first place, then we should do that before releasing the SRUs. [14:11] well, I can't say I'm happy with the situation...this definitely makes things more complicated, and has a chance of regression users of those archs [14:12] but if those archs are broken anyway... [14:14] if dannf and/or his team are willing to drop everything when a security notice is published to get the patches working for a new version within a day or two, then that's fine [14:15] I take the view that the patches can't be allowed to hold up security updates for the other architectures, and nor can we expect mdeslaur's team to fix it. [14:15] So that means dannf's team gets the opportunity to fix it when necessary, or if not, then the affected architectures regress. [14:15] i can't commit anyone else from my team - but, unless i'm unreachable, i can commit myself to that [14:16] hey guys, I have a service i'm making that can have multiple instances running on the same box. how should i represent that in systemd? [14:16] Luke: http://0pointer.de/blog/projects/instances.html [14:17] rbasak: wow thanks [14:17] that was fast [14:17] rbasak: I hope this wasn't the first google result ;-P [14:17] Luke: https://encrypted.google.com/search?hl=en&q=systemd%20multiple%20units [14:17] haha [14:17] But you do need to know what terms to Google for :) [14:17] rbasak, dannf: ok, so we're on the same page? [14:17] i didn't think "instance" was the right word [14:18] it would be nice if we had a way to at least not release broken builds on those archs in the situation that we can't. i'd hate to knowingly release broken builds to someone's stable environment [14:18] rbasak: instance brings up the same first result /me is embarrassed [14:18] ty [14:19] dannf: I suppose the patches could FTBFS and then users will be held back on that arch. But we'd need to check what the Arch: all packages do in terms of versioned dependencies. [14:19] dannf: is there a quilt trick to get it to apply the arch specific patches to see? [14:19] rbasak: oh, argh, I didn't think about the Arch: all [14:19] dannf: but that also means that affected arches will never get a security update. So which is worse? [14:20] mdeslaur: ln -s debian/patches/arch-specific/patches-arm64 patches-amd64 [14:20] rbasak: tough to say in general - one is definitely going to break them though, the other (security) is status quo [14:21] but security could certainly be worse in some situations of course [14:21] and w/ mysql, we don't really know what the security issues are :( [14:21] Maybe the fact that we're considering this should mean that we shouldn't carry the patch and consider MySQL broken on the affected arches until an upstream fix arrives. [14:22] I'm seriously reconsidering my position here. [14:22] rbasak: that feels like we're saying x86 is more supported than other archs, which isn't what we communicate [14:23] it's quite unfortunate that this is with the mysql package...pretty much any other package in the archive where we can backport security fixes this wouldn't have been an issue [14:23] if there was corruption in an LTS main package on x86, wouldn't we carry a patch? [14:23] dannf: I feel like we're saying that in the case of Oracle MySQL, upstream policies mean that for us to keep it in main arches are supported only as well as upstream support them. [14:24] dannf: for src:mysql-*, I'm not sure, because of upstream policies it's a special case. [14:24] It only remains in main because upstream has a good track record on this (until now). [14:24] http://www.ubuntu.com/about/about-ubuntu/conduct - "We expect participants in the project to resolve disagreements constructively. When they cannot, we escalate the matter to structures with designated leaders to arbitrate and provide clarity and direction." [14:25] I'm tempted to say that we're getting to the point where we need a TB decision in order to be decisive. [14:25] * dannf feels like we have a working model (dannf will port) and a backup plan (will drop patches) - i don't see why dropping those patches would be better, unless there's no reasonable grace period to give me to port [14:26] counter argument is that right now we don't have working packages on those archs - but i don't know that that is obvious to any users. the builds are there. [14:26] they will just secretly eat your data [14:26] right, that is why I'm conflicted [14:27] 1) I don't like the bus factor in that. I feel that we should have a team commitment to port the patches. [14:28] 2) Falling back to the backup plan means regressing users, who might elect to use an alternative if they know in advance, rather than receiving a regression. So the existence (and need for) the backup plan gives me doubt. Are the chances of needing it great enough that we shouldn't consider builds on these arches to be usable? [14:28] i'm sure we can get others on my team to commit to the raw porting - my only concern is w/ the actual packaging [14:30] dannf: ideally someone on your team would maintain a tested PPA for each new upstream version of mysql with the patches applied, and tested [14:30] and i should be open to my potential conflict of interest - i'm paid to support arm64 customers who want to deploy this [14:30] so when oracle's quarterly security advisory goes out, I can pluck the updated patches out of the PPA [14:31] mdeslaur: that seems reasonable [14:32] Aren't a significant proportion of upstream releases from security advisories (ie. not available earlier)? [14:32] seems to me they come out earlier than the security advisories [14:32] I'm trying to find that out now [14:33] Even though we had the MRE approved, I've not had the time to keep up to date with new upstream releases. [14:33] 5.5.44 came out on 2015-05-29 [14:33] and they published the security advisory for it this week [14:33] is there an announce list for new releases? [14:34] Ah, so they release first and then tell people what security fixes (if any) were in it six weeks later? I didn't realise that. [14:35] If that's true then it seems to me that if we did keep up with the MREs then you'd just need to pocket copy to -security [14:35] I'd have to rebuild in -security [14:36] Ah, OK [14:36] So...does this mean that dannf's team will do the MREs for us? :) [14:36] heh [14:37] IT'S A TRAP! [14:37] ;) [14:37] :) [14:37] It does seem like the logical conclusion though! [14:38] dannf: sorry for making this seem complicated, but this sort of thing has happened before...and while everyone has good intentions, at some point down the road when code gets refactored, nobody has time to do the work anymore [14:39] and that's when we're stuck with the hard decision [14:39] so I just want to make sure we're on the same page if it comes to that and we do need to regress our users [14:39] mdeslaur: right, part of our agreement here was to make sure we had a long term plan - i.e., oracle will care/provide a fix. we have that commitment, but no ETA [14:39] oh, that's good news [14:40] we've got them hw to test with, etc - we're poking them about status today [14:41] ok, I wasn't aware that there was a commitment there...that definitely alleviates my concern a bit to know that these could possibly be upstream in the next few versions [14:43] as for us doing MREs - i don't think that's necessarily a bad idea for this period. of course, if builds/tests fail for unrelated reasons, that's something we'd need help with [14:44] though i'm still not sure on how to get informed about a new release [14:44] I'd expect my team to help with anything MRE related, though priority would be up to my manager. [14:44] (and thus time) [14:44] ok, so the patches do apply to the new 5.5 and 5.6 [14:44] As for being informed about a new release, I don't really know either. [14:45] Perhaps we should set something up to watch uscan. [14:45] That'd be useful for other packages too. [14:45] yeah, or script something to monitor dev.mysql.com [14:45] perhaps there's a mailing list, I'm not sure [14:46] i can ask oracle [14:49] rbasak: mdeslaur: at this point, are you both ok w/ me asking sru-team to push those updates out? [14:49] dannf: I wonder if it's an idea to write out what we've agreed first to make sure that everyone is in agreement? [14:50] yeah, adding a comment to the bug to state what we've agreed would be ideal [14:50] once we've stated it here [14:50] Maybe start in a pad to avoid confusing updates in the bug. [14:51] right [14:51] sure. 1) dannf's team will figure out how to be notified of micro releases and maintain a ppa of test builds that we use to validate on arm64 [14:51] oh, pad is fine [14:52] rbasak: do you have a pad? [14:53] mdeslaur, dannf: http://pad.ubuntu.com/mysql-arm64-corruption-patch [14:53] (I just created it) [14:56] * rbasak wonders why everyone is a shade of pink today [14:58] btw, i'll run this by my manager this morning to make sure we can deal w/ the bus factor === DenBeiren is now known as zz_DenBeiren [14:58] mdeslaur, rbasak and are these updates always quarterly? [14:58] dannf: the security notices are quarterly [14:58] dannf: the mysql updates happen at any time I believe [14:59] ie: there can be 2 updates between security notices [14:59] ok [14:59] so you can plan when you're going to update your PPA, as long as it's done before the security notice is published, which is usually at a pre-determined date [14:59] does that make sense? [15:00] mdeslaur: yes. is there a security notice list, or should i ask oracle about that too? [15:00] dannf: http://www.oracle.com/technetwork/topics/security/alerts-086861.html [15:00] the dates, and the notices are listed there [15:00] no next date is 20 October 2015 [15:01] So arm64/ppc64el users are at some risk of regression as it's not an upstream patch. Should we release note this? [15:01] (although of course it's going into Trusty too, for which release notes are already published) [15:02] dannf: so _if_ a new version is published at the same time as the security notice (I don't think that happens), is a 2 day delay enough? [15:03] rbasak: hrm, is changelog not enough? [15:03] rbasak: not sure where else to put it [15:04] mdeslaur: changelog will have to do I guess. My thought is to inform users of the risk _before_ it happens. [15:04] (as it might affect DB or platform choice) [15:04] rbasak: if we do have to drop the patches, we can add a notice to the USN text [15:04] That would certainly be useful. [15:05] mdeslaur: i suspect a 2 *working day* delay would be enough [15:05] rbasak: ok, added to pad [15:05] dannf: ah, right, that's what I meant, I'll clarify [15:09] I'm satisfied, are you rbasak, dannf? [15:09] +1 [15:09] +1 [15:09] awesome [15:10] I'll add the info to the bug [15:10] I'm sorry I was in a meeting [15:10] dannf: is the mention of your commitment from oracle in the pad an issue? [15:10] mdeslaur: let me confirm w/ my manager first, if that's ok - should be within this hour [15:10] can someone tell me why the patches aren't upstreamable? certainly, upstream would want these to work well on those archs? [15:10] (speaking of mysql) [15:10] dannf: yes, definitely [15:10] jdstrand: the patch author declines to sign Oracle's agreement. [15:10] who is the patch author? [15:11] jdstrand: mariadb devs [15:11] meh [15:11] jdstrand: it's a licensing issue, but dannf's team does have a commitment from Oracle to fix the issue themselves [15:11] is there an upstream bug with mysql so they can clean room patch it? [15:11] ok [15:11] jdstrand: yes, there's a bug [15:11] http://bugs.mysql.com/bug.php?id=76135 [15:11] so this situation is 'temporary' [15:11] jdstrand: yes, and they have engaged - but i don't know the status, we're asking today [15:12] alright, whatever you've come up with between you and mdeslaur is fine with me [15:12] jdstrand: are you ok with what's in the pad? [15:12] I just wasn't clear on that point [15:12] can you paste the link? [15:12] jdstrand: http://pad.ubuntu.com/mysql-arm64-corruption-patch [15:12] http://pad.ubuntu.com/mysql-arm64-corruption-patch [15:12] http://pad.ubuntu.com/mysql-arm64-corruption-patch [15:12] * jdstrand reads [15:12] Did you get that? [15:13] It's http://pad.ubuntu.com/mysql-arm64-corruption-patch :-P [15:13] hehe [15:13] wait, what was the link? [15:13] :P [15:13] jdstrand: http://pad.ubuntu.com/mysql-arm64-corruption-patch :-P [15:14] jdstrand: http://pad.ubuntu.com/mysql-arm64-corruption-patch [15:14] ah, right. thanks! :) [15:14] hehe [15:14] nerd humour [15:14] do we have an idea of when Oracle will fix it? eg, is there a reasonable expectation that it will be fixed for next quarter's update? [15:15] I agree with the agreement :) [15:16] please put it in the sru bug so they are aware too [15:17] jdstrand: yes, that is the intention, as soon as dannf's manager signs off on it [15:17] great [15:27] rbasak: incoming PM, unrelated [16:06] mdeslaur, rbasak, jdstrand : andrewc added some CYA text to the top, but otherwise approves. can we retroactively add this to the trusty release notes? [16:07] * rbasak scrolls back to find the link [16:07] dannf: you might need to s/we/ with something to make it clear. [16:08] I don't know whether retroactively changing the release notes is a thing [16:08] There are point release release notes though [16:08] Maybe a question for the release team. [16:08] ok [16:09] I think it does make sense to alert users to the issue through the release notes in principle [16:10] so maybe just queue it up for the next point release if it hasn't been fixed properly by then [16:10] I'll ask in #ubuntu-release [16:37] jcastro: FYI https://lists.ubuntu.com/archives/technical-board/2015-July/002125.html thanks to teward [16:39] git comm\o/ [16:39] whoops, I mean, yay! \o/ [16:39] lol [16:39] jcastro: copy-paste fail? :P [16:39] indeed [16:40] more like window focus fail [16:40] we really need a focus-follows-eyes window manager [16:40] :P [16:41] or direct neural communication with systems [16:43] in any case this is up at the TB now, so we can only hope at this point :P [16:45] Don't worry, the TB are on our side. They want Ubuntu to continue to be awesome too :-) [16:46] dannf: cool, can I paste that into the SRU bug? [16:47] mdeslaur: yeah [16:48] thanks dannf, rbasak! [16:49] rbasak: btw, is there an existing PPA/group that makes sense for these pre-release builds, or should i just shove one under ~ce-hyperscale? [17:04] dannf: there's https://launchpad.net/~mysql-ubuntu [17:04] dannf: however that isn't Canonical only, so I don't think we can get a devirt PPA there. [17:05] I'm not sure of the current status of virt/scalingstack builders for arm64 and ppc64el. Might be worth enquiring. [17:34] Hi all, newbie here, simple question. I access my server via ssh. When I first started I did the manual username/password and I would always get the default MOTD. Now I login by key authentication and no more MOTD. I even went into sshd_config and changed PrintMOTD to 'yes'. It prints last login but not MOTD. What gives? [17:36] As a side note I've been doing key based login for a while now and I just happened to notice that I miss the motd. [18:09] Stuxnet: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/543767 [18:09] Launchpad bug 543767 in openssh (Ubuntu) "ssh logins doesn't show the MOTD when connecting with public key authorisation" [Low,Expired] [18:12] Oh okay well at least I know it's a bug. Why is it expired? Can it be reported again? [18:13] I'm reading... [18:14] Stuxnet: just add a comment of your own. it doesn't seem right to me. i presume you are running 14.04? [18:15] Stuxnet: as a workaround you can always call motd from your init shell files. the bug mentions how [18:17] Yes 14.04. I think I found the problem, about to test... [18:18] Okay so [18:18] I had to set UsePAM to yes in sshd_config and now it prints the motd [18:19] Apparently the motd is generated with PAM [18:20] These guys say that as long as challenge response authentication and password authentication are set to no and public key authentication is set to yes then it's fine [18:21] Thanks guys! [18:30] Stuxnet: ok, i read it too quickly then [18:36] I'm using an internal mirror of Ubuntu 14.04 (amd64 architecture only), and I'm finding that I have to run "dpkg --remove-architecture i386" in order for things to work on 64-bit installs of Trusty. Is this expected? If so, is there a setting/way to automate this? [18:36] yes [18:36] there are 32bit packages required for some things [18:37] so to mirror only the 64bit packages would cause an issue [18:37] patdk-wk: Can you elaborate on the required 32-bit packages? [18:37] well, I have lots of 32bit that is required for my usage [18:37] due to using 32bit compiled software on my 64bit system [18:38] patdk-wk: Let's assume that I'll only be using 64-bit software (these are stripped down server builds). Does that change the picture? [18:39] patdk-wk: Or is that assumption flawed? In other words, is it not possible to use only 64-bit software/packages on a typical Ubuntu Server build? [18:40] you must have done something [18:41] my desktop machine and some of my servers have a mixture of 64 and 32bit installed [18:41] but my servers that I don't run outside binaries on, my pure basic ones true open source ones [18:41] are purely 64bit [18:41] dpkg --print-foreign-architectures [18:41] that command says i386 on my desktop [18:41] but normally nothing on my servers [18:42] meaning only 64bit packages are installed [18:42] patdk-wk: When I run "dpkg --print-foreign-architectures" on the server(s), the result is empty (meaning only 64-bit packages are installed). [18:42] dpkg -l will also show you what packages are i386 [18:43] patdk-wk: However, when I try to use the amd64-only internal mirror, it will fail until I run "dpkg --remove-architecture i386". This is even though "dpkg --print-architecture" returns *only* "amd64". [18:43] are you sure that is right? [18:43] for me I get [18:43] dpkg --remove-architecture i386 [18:43] dpkg: error: unknown option --remove-architecture [18:44] patdk-wk: it's in the manpage [18:44] patdk-wk: This is 14.04.2 [18:44] I was on 12.04 by accident :) [18:44] patdk-wk: No worries :-) [18:44] patdk-wk: https://pbin.dark-net.net/view/raw/3d72be32 <--- just for the future :) [18:45] dpkg --remove-architecture i386 [18:45] dpkg: warning: cannot remove non-foreign architecture 'i386' [18:45] that one is still running 14.04.0 [18:45] patdk-wk: That's what I just got, but I'd already run it once, so I'm guessing the command isn't idempotent and tries to do something again. [18:45] I should update it, it's just my source code repo, behind lots of firewalls :) [18:46] well,I have never run that command before [18:46] so by default atleast, i386 is not installed [18:46] patdk-wk: In any case, do you know of any file/setting that is modified by that command that I could track? This would allow me to use Ansible to run that command and then track if the command has been run before. [18:46] you must have pulled something in, like say, java [18:47] I don't know [18:49] patdk-wk: I'm using a plain jane Vagrant box I built myself using a standard Ubuntu Server 14.04 installation. I'll dig in a bit more---thanks for your help. [18:50] updated to 14.04.2, still no i386 [18:51] 1190 packages installed [18:51] mine are build using the normal, minimal-install virtual machine option, from the iso's [18:59] slowe: you can answer this yourself by running strace and seeing which files dpkg --remove-architecture i386 removes. [18:59] slowe: I used to rm -f /etc/dpkg/dpkg.cfg.d/multiarch to do the same thing. [19:00] jrwen: Thanks, I'll give strace a go. /etc/dpkg/dpkg.cfg.d/multiarch doesn't exist on these systems, though. [19:02] slowe: did you already run dpkg --remove-arch... on those systems? [19:03] jrwen: Nope. This is on a fresh instance of a Ubuntu 14.04 Vagrant box, and "dpkg --print-foreign-architectures" does report "i386". [19:04] slowe: Ok, thanks. [19:04] jrwen: However, I see a package called "multiarch-support"...going to try removing that to see if that does anything. (This is a Vagrant box, so no big deal if it blows up.) [19:05] jrwren: That won't work. Wants to remove most of the packages on the system. :-) [19:08] how did you install? [19:08] minimal install? or just normal? [19:08] I can't think of anytime I have done a normal, non-minimal install [19:09] Found it...dpkg architectures are stored in /var/lib/dpkg/arch, each architecture on a separate line. [19:11] Removing "i386" from that line fixes the original issue AFAICT (internal amd64-only mirror works as expected with no errors). Now to automate this with Ansible... === slowe is now known as slowe[away] [19:18] slowe[away]: works for me. I do it very often. [19:22] slowe[away]: why the desire to remove foreign arch? [19:38] Anyone here ever seen /dev/sda as "hp ilo internal sd-card". I can't get kickstart to install lvm correctly because it always wants to install it there even when I tell it to install it to /dev/sdb which is my hdd. [19:38] Yes, almost every of our servers behaves like that. [19:38] what's your workaround? [19:39] Either pull the sd card, or install to the /dev/cciss/ raid controller logical volumes you created before. [19:40] that's nto exactly what I wanted to hear, but I appreciate the help. Looks like a trip to the datacenter tomorrow. [19:41] I assume you have no raid controller then? [19:42] I'm not really sure how to point it to /dev/cciss/. Should I define that in the kickstart file? === Lcawte|Away is now known as Lcawte [19:53] I'm doing a network install now without any automation. In the beginning I did a rmmod usb_storage and when it came to the partition section, it didn't see it. I'm going to try to incorporate that into the automated kickstart file. === Lcawte is now known as Lcawte|Away === slowe[away] is now known as slowe [20:02] jrwren: Sorry, had to step out for a bit. Need to remove foreign arch because internal amd64-only mirror won't work otherwise (apt-get reports can't find binary-i386 packages). [20:03] slowe: did you try prefixing your apt entries with e.g. deb [arch=amd64] http://.... ? [20:03] sarnold: In sources.list? [20:03] slowe: yeah [20:04] https://wiki.debian.org/Multiarch/HOWTO [20:05] sarnold: No, hadn't tried that. Will give that a try! Is there a strong advantage one way or the other? [20:06] tgeek: First, make sure you have the required hardware :) [20:06] I do [20:07] Then remember to create a logical volume on your raid controller before installing an OS. [20:07] Or automate it, using kickstart and an external script. [20:07] slowe: heh, no, this was the easier way I found for dealing with a similar problem [20:08] sarnold: Fair enough :-) [20:08] slowe: though perhaps it's nice i fyou've got multiple deb sources, and one of them is e.g. amd64 only, but your system still needs the 32 bit stuff from other mirrors [20:08] sarnold: Sure, that makes sense === Karunamon|2 is now known as Karunamon === WReTcH is now known as Guest84644 [22:35] anyone know how to start a systemd user service as a non-root user? [22:44] anyone ever hear of a server randomly stop logging to syslog? [22:44] or dmesg [22:46] teward: I have not [23:01] ianorlin: nor have I, it's new to me to see that [23:01] meh, not super important since all that's there is bind9 [23:08] you can't stop logging to dmesg, that is just not possible [23:08] unlessthe kernel crashed [23:08] now not logging to syslog is simple [23:08] don't have syslog running, or have a read-only filesystem [23:08] or bad permissions, or [23:16] or a race condition between the log rotation and the logging system closing and opening the new file -- see if the logs are going to the .0 or .1 file instead [23:20] yes, but still the *dmesg* command should always work [23:20] dmesg log, totally different story [23:22] yeah, dmesg should always work, but the benefit there is only the kernel gets to write to it :) [23:22] yes [23:46] patdk-lap: no dmesg either, which is REALLY odd [23:46] and i rebooted the server just in case [23:47] so maybe it's a perms problem [23:47] the dmesg command? [23:47] no output [23:47] nor did /var/log/dmesg have anything [23:47] which was really od [23:47] odd* [23:47] well /var/log/dmesg would be expected [23:47] if syslog isn't working [23:47] would the `dmesg` command still output? [23:48] it should [23:48] and if it doesn't [23:48] unless something like /dev was messed up [23:48] should i drop a nuke on the server? [23:48] or apparmor gone nuts [23:48] wouldn't put it past this VPS image [23:48] but it was doing those before [23:48] it's a vps? [23:48] openvz but yes [23:48] oh probably shouldn't work then [23:48] heh [23:48] i know syslog was working though [23:49] because bind9 would report there [23:49] ya, that is different and *probably* easy to fix [23:49]