Le mercredi 10 mars 2010 à 11:45 +0100, Karel Zak a écrit : > On Wed, Mar 10, 2010 at 10:58:33AM +0100, Pascal Terjan wrote: > > Le mercredi 10 mars 2010 à 04:58 +0100, Pascal Terjan a écrit : > > > Le mercredi 10 mars 2010 à 04:41 +0100, Pascal Terjan a écrit : > > > > Le mercredi 10 mars 2010 à 04:13 +0100, Pascal Terjan a écrit : > > > > > Le mercredi 10 mars 2010 à 00:12 +0100, Karel Zak a écrit : > > > > > > On Tue, Mar 09, 2010 at 08:51:16PM +0100, Pascal Terjan wrote: > > > > > > > Hi > > > > > > > > > > > > > > nash (from mkinitrd) no longer finds swap devices since we updated > > > > > > > libblkid to 2.17.1 > > > > > > > > > > > > > > It seems that size is always 0 in blkid_probe_set_device which means > > > > > > > that later blkid_probe_is_tiny is always true. > > > > > > > > > > > > I don't think so. The code calls stat() or blkdev_get_size() to get > > > > > > size if the size argument is zero. > > > > > > > > blkdev_get_size seems to expect an unsigned long long from BLKGETSIZE64 > > > > while it works on size_t despite its name > > > > > > It's 5am so I will get back to bed without exactly understanding the > > > issue, just wanted to add that I just tested and size is not 0 on > > > x86_64, only on my i586 machines > > > > OK, so there are 2 bugs: > > > > - size (and offset) is printed with %zd instead of %llu > > - BLKID_TINY_DEV flag is not reset in blkid_probe_set_device > > I found both bugs few minutes ago :-) > > But I think, it does not explain your problem, > > ./shlibs/blkid/samples/superblocks /dev/sda5 > > this command does not reuse the prober for more devices, so the > "tiny flag" should be not set. I had only checked that reported size was always zero, it actually correctly finds UUID so indeed the flag is not set > Note that there is small test program, try: > > ./lib/test_blkdev /dev/sda5 > > and see if it returns correct sizes. Yes it is correct And resetting the flag correctly fixes my original bug in nash -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
