Bug#510911: multipath-tools: bad side effects with FC devices
thanks for the quick reply. On Tue, Jan 06, 2009 at 08:50:28AM +1100, Vincent McIntyre wrote: Other things I noticed: - fdisk works ok # fdisk -l /dev/sdc Disk /dev/sdc: 1505.9 GB, 1505973239808 bytes 64 heads, 32 sectors/track, 1436208 cylinders Units = cylinders of 2048 * 512 = 1048576 bytes Device Boot Start End Blocks Id System /dev/sdc1 1 1436208 1470676976 83 Linux Once you use multipath you have to access multipathed devices via /dev/mapper/ or via /dev/disk/by-id/. Not doing this is the only bug here I can see. ok, then that's the problem. There are no multipathed devices on this system, so I was not expecting multipath-tools to 'do' anything. Is there something in the package documentation that would have explained this point to me? I may have missed it. Christophe's documentation says 'Last update : Dec 2004', which does not inspire confidence that it is still even vaguely relevant, particularly since udev has evolved so much over the interim. The URL for the FAQ has changed, it should be http://christophe.varoqui.free.fr/faq.html (patch attached) - once booted, /dev/mapper is left in a very odd state indeed: # ls -l /dev/mapper brw-rw 1 root disk 254, 8 2009-01-05 14:35 3600039307d390100fef00a2d brw-rw 1 root disk 254, 9 2009-01-05 14:35 3600039307d390100fef00a2d1 brw-rw 1 root disk 254, 7 2009-01-05 14:35 3600039307da90100fef00a2d It seems multipath tools picked up your devices correctly. What did you expect to happen? I expected multipath-tools to leave the device alone, or at least allow the system to mount and be able to access the data as before, since I had not 'told' the package about these devices. I had not configured /etc/multipath.conf, that file did not exist. Nor was there an /etc/default/multipath-tools. On a system where we _do_ have multipathed storage, the devices are referred to as /dev/mapper/mpath0p1, /dev/mapper/mpath1p1, etc. So when I was looking at the /dev/mapper directory I was thinking that somehow some configuration had not completed, and that the files named using the WWN would be replaced by something 'friendlier' (for example the filesystem label, which is what was being used in the /etc/fstab, or /dev/mapper/mpath0). The behaviour of 'mount' and 'umount' was also extremely confusing. The device is not mounted and cannot be umounted but is 'busy'. Why does 'lsof' not show what is keeping the device 'busy'? It might help if /dev/sdc1 was not created at all, since it can't be used to access the device. But I see in [2] that this is a decision taken by the kernel. The underlying bug here is probably my lack of understanding. But at the moment I don't see how to improve my understanding with the information available in the package. Some suggestions: * if the package is able (at installation time) to detect devices that it will start to manage at the next reboot, it would be helpful to give a debconf warning about this and point people to /usr/share/doc. I don't think there is such a warning now. * provide your paragraph in /usr/share/doc: Once you use multipath you have to access multipathed devices via /dev/mapper/ or via /dev/disk/by-id/. For example, in /etc/fstab one could write: /dev/mapper/ /data/foo_1 ext3 defaults 0 0 * it would help to explain what the WWN-named files in /dev/mapper are. I've had a go at a patch for this and the point above. * alternatively, or as well, provide a default /etc/multipath.conf that ignores/blacklists every device on the system, so multipath-tools won't attempt to manage anything until the system owner takes a positive action and configures the package. You may well ask 'wtf did you install the package in the first place?'. I was having a look-see to see what the package did when it was installed, before trying it out on a system that does have multipathed storage. I neglected to uninstall it again and was penalized heavily for this. You're doing a great job on this package, hope these comments help. Cheers Vince [1] http://christophe.varoqui.free.fr/usage.html [2] http://christophe.varoqui.free.fr/refbook.html--- /usr/share/doc/multipath-tools/FAQ 2006-03-14 02:12:08.0 +1100 +++ /tmp/FAQ2009-01-07 09:03:32.0 +1100 @@ -1,4 +1,5 @@ -More at http://christophe.varoqui.free.fr/wiki/wakka.php?wiki=FAQ +More at http://christophe.varoqui.free.fr/faq.html +See also http://christophe.varoqui.free.fr/usage.html 1. How to set up System-on-multipath ? == --- /usr/share/doc/multipath-tools/FAQ 2006-03-14 02:12:08.0 +1100 +++ /tmp/FAQ2009-01-07 09:13:05.0 +1100 @@ -63,3 +63,22 @@ current/default config like so: lvm dumpconfig > /etc/lvm/lvm.conf (tip from Christophe Saout) + +4. What are these weird numbers in /dev/mapper? +=
Bug#549439: pkgreport.cgi - internal server errors when using include= parameter
Thanks for your prompt reply. Neither of those are valid selection requests, unfortunatly. What exactly are you trying to do? I am experimenting with pulling out groups of bugs using usertags. Specifically I was attempting to make some of the urls in [2], that claim to pull out arch-specific bugs, actually work. I can't find any documentation for how to construct such URLs more advanced than setting users= and tag= in the URL. Reading the source of pkgreport.cgi[3] suggests not much of the vision actually ended up getting implemented, but I am having trouble following the code. I'm happy to help write something that documents the current functionality. One thing I have been trying to figure out is how to get the usertags defined for a given bug report to be displayed in the browser. Ubuntu have this feature in b.u.o and I think it's useful. I can't see any knob in the browser interface that lets me turn this on. Is there a reason they are not being displayed? I would also like to be able to display all the usertags set by a given user. If I just set users= in the URL, but omit tag=, I'd get all bugs tagged by that user but would then have to compile the usertags. It seems it would be easy for pkgreport.cgi to do that for me and show it as a line at the top of the summary display. Cheers Vince [2] http://wiki.debian.org/DebianInstaller/Bugs [3] http://bugs.debian.org/debbugs-source/mainline/cgi/pgkreport.cgi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549439: pkgreport.cgi - internal server errors when using include= parameter
Thanks for your patient answers. I am experimenting with pulling out groups of bugs using usertags. Specifically I was attempting to make some of the urls in [2], that claim to pull out arch-specific bugs, actually work. Assuming the architecture specific bits are done by usertags that are against the debian-b...@lists.debian.org user, you can just do the following: http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-b...@lists.debian.org;tag=amd64;users=debian-b...@lists.debian.org sure, I realised I could use that method. However I was interested to check whether for example this URL (taken from [1]) would/could ever work: http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-b...@lists.debian.org;include=alpha which amounts to wondering what the include= keyword does for you. I can't find any documentation for how to construct such URLs more advanced than setting users= and tag= in the URL. Reading the source of pkgreport.cgi[3] suggests not much of the vision actually ended up getting implemented, but I am having trouble following the code. The only bit that isn't implemented is the ability to enter users= and other bits in the url selection at the bottom. ok, that helps quite a bit. I'm happy to help write something that documents the current functionality. That'd be great. What form would be most useful? A distinct file or a patch to e.g. [2]? One thing I have been trying to figure out is how to get the usertags defined for a given bug report to be displayed in the browser. If you give the user in the users field, they're displayed as if they were actual tags. Really? I mean here when I am looking at one particular bug, eg the url http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214790 This is the first hit in the general search for usertags http://bugs.debian.org/cgi-bin/bugreport.cgi?users=debian-b...@lists.debian.org so it would seem there should be usertags to show. Yet I can't see any usertags in the display of the individual bug. I tried the obvious http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214790;users=debian-b...@lists.debian.org and got a 500 error. I tried a newer bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326109;users=debian-b...@lists.debian.org; and I aslo get a 500 error. I would also like to be able to display all the usertags set by a given user. If I just set users= in the URL, but omit tag=, I'd get all bugs tagged by that user but would then have to compile the usertags. It seems it would be easy for pkgreport.cgi to do that for me and show it as a line at the top of the summary display. It actually already does that at the top of the display: Ah. I am pretty sure it wasn't doing that for me before, when I started asking all these dumb questions. I tried again just now, and got the list of tags. Yay. Have you updated the running code in between? I found also that this: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-b...@lists.debian.org;include=alpha "works", where it did not before. By "works" I mean that the Options section shows a whole stack of 'tagged' selectors, that I did not see before. So now I think I am starting to get this. Then I tried: lynx -mime_header -source http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=alpha;users=debian-b...@lists.debian.org and got the attached file (pkgreport.cgi.usertag.test1.txt). I see the Summary and the Options sections but no, er, bug numbers listed. Yet the Summary says there are bugs to display. If I do the obvious thing and hit the 'submit' button on the displayed page, the URL changes to http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=alpha and I get "No reports found!". If I select unarchived & archived in the Misc options - the URL changes to http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;tag=alpha and I get "No reports found!". If I do the same thing for the i386 architecture, I do get some bug numbers displayed, but far fewer than what the summary states. (pkgreport.cgi.usertag.test2.txt) The URLs http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-b...@lists.debian.org;tag=i386 http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-b...@lists.debian.org;tag=i386;archive=both; both yield the same result. Assuming there's not some reason for this behaviour, this should probably be broken out into a separate bug. Kind regards, Vince [1] http://wiki.debian.org/DebianInstaller/Bugs [2] http://bugs.debian.org/debbugs-source/mainline/html/Access.html.inHTTP/1.1 200 OK Date: Mon, 05 Oct 2009 05:07:30 GMT Server: Apache Connection: close Content-Type: text/html; charset=utf-8 Bugs tagged alpha -- Debian Bug report logs Debian Bug report logs: Bugs tagged alpha No reports found!