=== evand is now known as evand|vacation === superm1|away is now known as superm1 === superm1 is now known as superm1|away [12:31] cjwatson: Do you have any time in the next two hours or so that you can spare me to talk about libparted? [12:32] cjwatson: I'm somewhat unsure as to what I may have to do to tell it about dmraid. [12:34] TheMuso: I have an interview in half an hour and need to prepare, but perhaps right after that? [12:34] cjwatson: Thats fine by me. [12:34] The two hours I refer to is the amount of time until I'm likely to head to bed. [13:03] TheMuso: I've just realised my interview is at 1300 UTC not BST (whoops!), so I'm free now [13:04] TheMuso: how does dmraid show up in terms of devices? IIRC it looks just like device-mapper devices at that level [13:05] TheMuso: and the other end of the question is what special things libparted needs to do with dmraid devices [13:20] cjwatson: Sorry, thought you were interviewing, so was away doing other things. :) [13:21] cjwatson: Dmraid devices are simply device mapper devices, major 254, and minor can be anything. The node names can also be different, depending on the controller, and any possible assigned name/date from the BIOS. [13:22] cjwatson: One way to identify them would be their UUIDs, which is possible via the devmapper API IIRC. The UUIDs for the devmapper stuff are unique, in that they start with DMRAID- [13:22] cjwatson: As to what libparted needs to do, it has to treat them like a proper hard disk, in that the master node is the MBR/partition table of the device, and the other nodes are partitions. [13:25] does it need to call the reread-partition-table ioctls on the disk-like device? [13:25] what is the scheme for transforming disk-like device names into partition-like device names? is it regular? [13:25] Not if no changes have been made, no. Dmraid does that when setting up the devices. [13:26] I mean if changes have been made - for example if you ask libparted to create a new partition on the disk-like device [13:26] cjwatson: By transofmring, do you mean something like sda/sdb? If so, they simply stay as they are, and a devmapper mapping is set up with new nodes in /dev/mapper. [13:26] I mean the process for getting from /dev/sdb to /dev/sdb5 [13:26] cjwatson: Oh in that case, yes the partition table will have to be reread and the devmapper nodes updated accordingly. [13:27] are the devmapper calls that libparted already does for dm devices good enough for that? [13:28] I would think so, but they are for single devices, like LVM etc, so not entirely sure without taking another look. [13:29] it sounds like the main thing you have to do is tell libparted/arch/linux.c:_device_get_part_path about the device name transformation rules [13:29] I *think* most of the rest should just work [13:30] the decision about whether to use partition devices or not is largely taken on the basis of what sort of partition table (if any) is on the disk-like device [13:30] A standard MS-DOS partition table. [13:31] right, so you probably just need to teach it how to find the partition nodes [13:32] Right, I thought as much. Somewhat difficult due to node names not being usable to help with that... Although given we nknow the master node, we can work out partitions from there possibly. [13:33] the disk device should be accessible at the time you need to ask this question, so you should be able to use the devmapper API safely [13:34] Ok. [13:35] I'll have to look at the code on a fresher state of mind than what I am in currently, but things make sense. [13:39] cjwatson: Actually one thin I'm not sure of, when yousaid I'd have to teach it about the device nodes, do you mean in the function you referred to above, _device_get_part_path, or is that likely to have to be done in one of the devmapper related functions? [13:39] I meant in _device_get_part_path itself [13:40] Oh ok. [13:40] you might need to write a devmapper-based helper function to figure out whether the device is dmraid or not though [13:40] Yeah, I can likely base it on UUID. === superm1|away is now known as superm1 === superm1 is now known as superm1|away === superm1|away is now known as superm1 [15:59] netcfg: cjwatson * r626 ubuntu/debian/ (changelog control): Build for lpia. [15:59] * xivulon "finished" coding the python win32 wrapper [15:59] :) now I can actually do the python wubi gui [16:03] netcfg: cjwatson * r627 ubuntu/debian/changelog: releasing version 1.44ubuntu2 [16:57] debian-installer: cjwatson * r950 ubuntu/ (19 files in 17 dirs): Add support for lpia. [17:18] tasksel: cjwatson * r1360 fix-seen-handling/ (debian/changelog tasksel-debconf): [17:18] tasksel: Fix seen flag handling: you can now preseed tasksel/first without [17:18] tasksel: setting the seen flag in order to set defaults while still displaying [17:18] tasksel: the question. [18:55] grub-installer: cjwatson * r737 ubuntu/ (debian/changelog grub-installer): merge Dustin's fix for LP: #33649 [18:56] grub-installer: cjwatson * r738 ubuntu/grub-installer: move write_grub definition to before its use [19:01] grub-installer: cjwatson * r739 ubuntu/grub-installer: more portable shell arithmetic [19:03] grub-installer: cjwatson * r740 ubuntu/debian/changelog: releasing version 1.32ubuntu2 [19:19] debian-installer: cjwatson * r951 ubuntu/debian/changelog: releasing version 20080522ubuntu9 [19:52] cjwatson: hey there [19:52] cjwatson: i was planning on patching grub-install in the same manner [19:53] cjwatson: after we agreed upon an algorithm that works in grub-installer [19:53] cjwatson, did you and evand|vacation come to a conclusion on that issue with intrepid and recovering from the hard drive before evand|vacation headed off to vacation? === superm1 is now known as superm1|away [23:19] cjwatson: okay, i have a patch against grub's util/grub-install.in [23:20] cjwatson: should I put that in the debian/patches/ dir, or edit the file directly in bzr? === superm1|away is now known as superm1 === superm1 is now known as superm1|away === superm1|away is now known as superm1