[01:43] <T3DY> Such a dead group
[02:35] <hallyn> zul: meh, i think my libvirt preinst/postinst bits to handle starting libvirt-guests is wrong altogether.
[02:36] <hallyn> zul: i think it needs to drop the preinst bit ,and just unconditionally start libvirt-guests.  which also has wrong name for libvirtd service.
[07:36] <lordievader> Good morning.
[14:15] <teward> general question: I have a computer upon which I installed Ubuntu Server 14.04.3.  /etc/network/interfaces has `allow-hotplug eth0` and `iface eth0 inet dhcp` in it, but on boot it doesn't get configuration done for the network / IP.  Manual execution of `dhclient` makes it negotiate correctly.
[14:15] <teward> any ideas of diagnosing?
[14:20] <lordievader> Check the logs.
[14:21] <teward> which logs :P
[14:21]  * teward yawns
[14:22] <lordievader> dmesg, messages, syslog, etc
[14:24] <teward> mmmm
[14:25] <teward> nothing informative in dmesg, syslog.  except that pre-start terminated with status 1, and post-stop terminated with 100
[14:25] <teward> kernel earlier on also complains it terminated with status 1 twice
[14:25] <teward> but it doesn't appear informative of any specifics :/
[14:26] <lordievader> Pre/post start of what?
[14:26] <lordievader> Networking?
[14:27] <teward> mhm
[14:27]  * teward yawns
[14:27] <teward> sorry, i'm still waking up >.<
[14:27] <lordievader> Is that a yes?
[14:27] <teward> yes, it is
[14:27] <lordievader> teward: There is your problem.
[14:28] <teward> lordievader: uninformative error codes are uninformative.  any idea where they're documented?
[14:29] <lordievader> Err, no idea.
[14:29] <lordievader> Upstart keeps logs though.
[14:30] <teward> upstart's logs were helpful
[14:30] <teward> apparently it said invalid option placement.
[14:30] <teward> looking at the interfaces file, i had to open it in a different editor, but it found rogue ascii
[14:30] <teward> that answers the problem xD
[14:30] <teward> (neither nano nor vi nor vim showed the ascii.  hex editor found it ;P)
[14:45] <TJ-> teward: i usually find 'less' is good for spotting those random control codes, unless using 'less -r'
[14:49] <teward> ,,,
[14:49] <teward> mmm*
[14:49] <teward> yeah, well, meh
[14:49] <teward> found it, fixed it, problem solved :)
[17:03] <tgm4883> Trying to mount a hosts directory into an lxc container using the command listed as an example when running lxc config (which is "lxc config device add container1 mntdir disk source=/share/c1 path=opt"). I get no errors on the command line, but nothing in that folder is present when I do an ls from inside the container. Is there something else that needs to
[17:03] <tgm4883> be done?
[17:12] <tgm4883> Hmm, apparently it has to be stopped to add it
[18:50] <hallyn> zul: smb: does http://paste.ubuntu.com/12594504/ make sense to you?
[19:02] <zul> hallyn: oooks ok to me
[19:03] <hallyn> zul: does what i'm saying and doing make sense?
[19:03] <zul> yeah
[19:05] <hallyn> cool, thanks
[19:05] <hallyn> i'll push in a bit when i feel more couragious
[21:12] <Karunamon> hi folks, does anyone in here know anything enough about mdraid to explain why it can't see a mirrored drive from another system?
[21:14] <lordievader> Karunamon: Have you assembled them?
[21:17] <patdk-lap> have you put the disks from the other system into this one?
[21:17] <Karunamon> the one disk, yes
[21:17] <Karunamon> the other one is toast
[21:18] <Karunamon> if i do an mdadm -E /dev/sdb1, it sees the drive as part of an array, but the problem i'm having is actually getting the cursed thing mounted
[21:20] <lordievader> Karunamon: Probably since the other disk is not found it wont assemble it automatically, you have to do that manually.
[21:20] <Karunamon> an --assemble --scan shows me "/dev/sdb1 has wrong uuid"
[21:21] <TJ-> Karunamon: does the current system also have md arrays? If so, does the metadata on both have the same device node name (e.g. md0) ?
[21:21] <Karunamon> TJ-,no other arrays on the system
[21:25] <Karunamon> hm, there it goes. Apparently an earlier command had dumped a line for a non existent array into mdadm.conf
[21:25] <Karunamon> cleared that, --assemble --scan, and we're good
[21:25] <Karunamon> of course now the filesystem does not want to mount
[21:33] <Karunamon> so it's XFS.. (this much I know from memory), but it can't be mounted because it's trying to read beyond the end of the disk?
[21:36] <Karunamon> 262144 (sectors? blocks?) beyond the end
[21:39] <TJ-> Are you sure the original array was only RAID-1 ?
[21:39] <Karunamon> 100% positive. There were four drives in the old system, two RAID1 sets
[21:40] <bekks> Two raid1 sets or one raid10 set?
[21:40] <Karunamon> two raid1 sets (one was for the system, the other was for bulk storage)
[21:40] <TJ-> Karunamon: OK, it could be a HPA (Host Protected Area) issue I suppose.
[21:40] <Karunamon> i'm also sure this is the case since I set it up that way because there were two 500g drives and two 250g drives :)
[21:41] <Karunamon> oh boy.. this got complicated, then
[21:41] <Karunamon> because the drive is being accessed via a raw device mapping on an esx server connected as a single disk logical device on a HP raid controller >_<
[21:41] <TJ-> Karunamon: is the raw drive partitioned, or pure MD without a partition table?
[21:42] <Karunamon> it's partitioned, the first partition is the mdraid device
[21:45] <TJ-> Karunamon: which metadata version is the MD using (that affects where the metadata is in the underlying partition)
[21:45] <Karunamon> 1.2
[21:47] <TJ-> Did the error message about reading beyond end of device come from the kernel log? Can you show the exact message (and any surrounding messages that are relevant) ?
[21:49] <Karunamon> It did come from the kernel (per syslog), but what's there is pretty scant
[21:49] <Karunamon> lemme paste it
[21:51] <Karunamon> https://gist.github.com/4052b9be877070e2a5b7
[21:52] <Karunamon> the first one was during an attempt to mount, the second was during an xfs_repair attempt
[21:54] <TJ-> Karunamon: "capacity change from 0 to 499837108224" matches "limit=986244352" (in 512-byte sectors).
[21:55] <Karunamon> TJ-: so it's mdadm who has the wrong idea as to the size this thing should be
[21:55] <TJ-> Karunamon: what does "hdparm -N /dev/sdX" report about HPA?
[21:56] <Karunamon>  max sectors   = 0/1, HPA is enabled
[21:56] <TJ-> Karunamon: aha, so HPA = yes, but "0/1" ... that's not right!
[21:56] <Karunamon> there could be some strangeness because of the convoluted way this drive is mounted
[21:57] <TJ-> Karunamon: is it on a USB controller?
[21:57] <Karunamon> Worse. So this system is a VM, it's using a raw device mapping in ESXi to access the drive, itself connected to a raid controller as a single disk device
[21:58] <Karunamon> and before you ask: it's a SAS drive, and I don't have any other gear onhand to read those
[22:00] <Karunamon> so some quick searching.. this sounds like an automatic HPA unlocking thing that ubuntu had some issues with a while back?
[22:00] <TJ-> Karunamon: hmmm, can you use hdparm from the host?
[22:00] <Karunamon> it was unlocked on the previous system, and not here, so the end of the drive is seemingly missing?
[22:01] <Karunamon> not on the host unfortunately
[22:01] <TJ-> Karunamon: Yes. There's a trick many sysadmins uses to avoid this. When creating an MD device not allocating all the raw device, to allow HPA to be on/off without a problem. Not much help now of course :)
[22:02] <TJ-> Karunamon: what does this report? "hdparm --dco-identify /dev/sdX" ?
[22:12] <Karunamon> https://gist.github.com/16e60ab28ad2f02c8663
[22:12] <Karunamon> @TJ-
[22:13] <Karunamon> I'm thinking I could bring this drive into work if there's something to mutter at hdparm to get that hpa disabled
[22:13] <Karunamon> and get it plugged into real hardware
[22:14] <TJ-> Karunamon: looks like ESXi is getting in the way