Bug#595218: upgrade-reports: [amd64][lenny->squeeze][20100902] almost successful
On Thu, 2 Sep 2010, zoltan herman wrote: > This problem appeared at me when there were a scsi and a sata on my computer. > I installed the Lenny and I got the same error during the boot what you > report about (A PATA/IDE HDD solve my problem in the end). The internal disks are SATA, and I have some 'scsi' devices connected, over fibre channel. I don't think hda/sda device naming is the problem though, if that's what you mean. I am pretty sure I installed grub to the right device. > What facilities does it offer when you enter "e" (edit) in the grub menu and > push "(hd" at the root row? I don't get the grub menu displayed. > Have you got any USB HDD in the computer? No. There are 6 internal disks, and three FC-connected external disks. I am using what the BIOS thinks is the second disk. > What do you see after the detect disk when you start the Squeeze installer in > detect mode? I think I've tried the equivalent of this, booting the squeeze installer in rescue mode and mounting the root partition, so I could try running grub-install. The kernel definitely sees the disks and mounts the one I wanted ok. Thanks, Vince -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#586182:
The issue on this particular system is that the binding file resides on /var which isn't available early enough for /etc/init.d/multipath-tools-boot. In that case the paths got assigned new names during each boot which causes the problem. A workaround is to use the multipath-tools-boot package so the path discovery happens in the initramfs with the bindings file available. (a copy is placed in /var/lib/multipath/bindings of the initramfs.) The workaround works. Whew. This might also explain why using user-unfriendly names is regarded as more robust. The renaming process works correctly, but somehow not all of the /dev/mapper/mpathN block special files are created. Here's an excerpt showing a successful set up for mpath1: (grep -e rename -e bindings -e mpath[01234] /var/log/syslog) Jul 7 10:18:58 install multipathd: Found matching wwid [2220e0001558b5168] in bindings file. Setting alias to mpath1 Jul 7 10:18:58 install multipathd: sdb: ownership set to mpath1 Jul 7 10:18:58 install multipathd: sdi: ownership set to mpath1 Jul 7 10:18:58 install multipathd: sdl: ownership set to mpath1 Jul 7 10:18:58 install multipathd: sdo: ownership set to mpath1 Jul 7 10:18:58 install multipathd: mpath1: pgfailback = -2 (controller setting) Jul 7 10:18:58 install multipathd: mpath1: pgpolicy = multibus (controller setting) Jul 7 10:18:58 install multipathd: mpath1: selector = round-robin 0 (controller setting) Jul 7 10:18:58 install multipathd: mpath1: features = 1 queue_if_no_path (controller setting) Jul 7 10:18:58 install multipathd: mpath1: hwhandler = 0 (controller setting) Jul 7 10:18:58 install multipathd: mpath1: rr_weight = 1 (internal default) Jul 7 10:18:58 install multipathd: mpath1: minio = 100 (controller setting) Jul 7 10:18:58 install multipathd: mpath1: no_path_retry = 20 (controller setting) Jul 7 10:18:58 install multipathd: 2220e0001558b5168: rename mpath3 to mpath1 Jul 7 10:18:58 install multipathd: mpath1: load table [0 27343744512 multipath 1 queue_if_no_path 0 1 1 round-robin 0 4 1 8:16 100 8:128 100 8:176 100 8:224 100] and a little later... Jul 7 10:18:58 install multipathd: DEVLINKS=/dev/block/254:1 /dev/disk/by-id/dm-name-mpath1 /dev/disk/by-id/dm-uuid-mpath-2220e0001558b5168 /dev/disk/by-id/scsi-m The same occurs for mpath0. Something slightly different happens for mpath2: Jul 7 10:18:58 install multipathd: Found matching wwid [222de000155468f10] in bindings file. Setting alias to mpath2 Jul 7 10:18:58 install multipathd: sdc: ownership set to mpath2 Jul 7 10:18:58 install multipathd: sdj: ownership set to mpath2 Jul 7 10:18:58 install multipathd: sdm: ownership set to mpath2 Jul 7 10:18:58 install multipathd: sdp: ownership set to mpath2 Jul 7 10:18:58 install multipathd: mpath2: pgfailback = -2 (controller setting) Jul 7 10:18:58 install multipathd: mpath2: pgpolicy = multibus (controller setting) Jul 7 10:18:58 install multipathd: mpath2: selector = round-robin 0 (controller setting) Jul 7 10:18:58 install multipathd: mpath2: features = 1 queue_if_no_path (controller setting) Jul 7 10:18:58 install multipathd: mpath2: hwhandler = 0 (controller setting) Jul 7 10:18:58 install multipathd: mpath2: rr_weight = 1 (internal default) Jul 7 10:18:58 install multipathd: mpath2: minio = 100 (controller setting) Jul 7 10:18:58 install multipathd: mpath2: no_path_retry = 20 (controller setting) Jul 7 10:18:58 install multipathd: mpath2: set ACT_RELOAD (path group topology change) Jul 7 10:18:58 install multipathd: mpath2: domap (0) failure for create/reload map and there's no DEVLINKS output for mpath2. The domap (0) failure recurs a four times. Each time multipathd goes back to the "Found matchin wwid..." line and repeats all the steps shown. The fourth attempt goes like this: Jul 7 10:18:58 install multipathd: Found matching wwid [222de000155468f10] in bindings file. Setting alias to mpath2 Jul 7 10:18:58 install multipathd: sdc: ownership set to mpath2 Jul 7 10:18:58 install multipathd: sdj: ownership set to mpath2 Jul 7 10:18:58 install multipathd: sdm: ownership set to mpath2 Jul 7 10:18:58 install multipathd: sdp: ownership set to mpath2 Jul 7 10:18:58 install multipathd: mpath2: pgfailback = -2 (controller setting) Jul 7 10:18:58 install multipathd: mpath2: pgpolicy = multibus (controller setting) Jul 7 10:18:58 install multipathd: mpath2: selector = round-robin 0 (controller setting) Jul 7 10:18:58 install multipathd: mpath2: features = 1 queue_if_no_path (controller setting) Jul 7 10:18:58 install multipathd: mpath2: hwhandler = 0 (controller setting) Jul 7 10:18:58 install multipathd: mpath2: rr_weight = 1 (internal default) Jul 7 10:18:58 install multipathd: mpath2: minio = 100 (controller setting) Jul 7 10:18:58 install multipathd: mpath2: no_path_retry = 20 (controller setting) Jul 7 10:18:58 install multipathd: mpath2: set ACT_RELOAD (path group topology change) Jul 7 10:18:58 install multipathd: mpath2
Bug#552787: #552787 [i386][squeeze][20091026-21:55] unable to install lenny from daily
On Fri, 6 Nov 2009, Frans Pop wrote: > On Friday 06 November 2009, Frans Pop wrote: > > > Found the problem, which is documented but it's somewhat difficult > > > to parse. This change in my preseed file fixed the issue: > > > > > > - d-i mirror/udeb/suite string lenny > > > + d-i mirror/udeb/suite string testing > > > > This is not a bug. If you had not set this at all, then the installer > > would just have done the correct thing. By setting it to a value (and > > thus overriding the correct default set at build time) that does not > > match which suite the installer was built from, you broke things > > yourself. > > Actually, I suspect that you had an old daily image (which is based on > *unstable*) that still used the 2.6.31-1 kernel while the udebs for that > kernel no longer existed in unstable because they had been updated to > 2.6.31-2. > > So, two options: > - either you really did have an incorrect preseed file > - or you had an outdated image The image I was using was datestamped 20091026-21:55, so it was not so old at the time (28th Oct). I got it from the official dailies site (linked on the d-i 'home page'). > That setting mirror/udeb/suite to testing worked, was merely a coincidence > and not a correct fix (because the only technically correct setting for a > daily built image would have been sid or unstable). Well it's kind of tough to figure out when the archive is in flux and the documentation is misleading. Thanks for taking the time to look at this and figure out what happened. Can we go back a step. I want to install lenny with the 'squeeze' installer. Are you saying all I need to preseed is suite=lenny on the boot line? Kind regards, Vince -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553309: (no subject)
retitle 553309 partman-auto-raid: clarify how to set up lvm+raid thanks -- 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!