Niko Tyni <nt...@debian.org> writes: > On Thu, Dec 16, 2010 at 05:37:55PM +0100, Ferenc Wagner wrote: > >> Niko Tyni <nt...@debian.org> writes: >> >>> Hercules s390 emulator installation failed at disk partitioning; >>> new partitions don't seem to show up in /dev. >> >> Thanks for the detailed but to-the-point report. This may be a kernel, >> a udev or a partman issue. Could you please try backing out of the >> partitioning menu to the main menu, start a shell in the installer >> environment with the appropriate menu item and do the partitioning >> yourself by fdasd or whatever's needed? Then please check if the new >> partitions show up in /proc/partitions and under /dev. This would help >> us narrowing down the case. > > It works fine if I create the partition manually with fdasd.
Thanks, that's good info. Now the question is why parted_server failed to refresh the DASD partitions. It's a pity you didn't attach /var/log/partman. Could you please attach it to the bug report, preferably together with /var/log/syslog? You could get them by selecting "Save debug logs" from the installer main menu. Wait, see below. > Furthermore, if I try to create a partition first with the d-i interface > (getting the error) and then invoke fdasd and write out a trivial no-op > such as change the volume serial from LIN120 to LIN120, /dev/dasda1 > appears. So libparted commits the partition, only fails to notify the kernel. > It looks to me like the problem is that d-i does not manage to reread > the partition table. Agreed. > I'm not sure if I understand the architecture correctly here, but > maybe the problem is this change in parted 2.3 ? > > libparted: remove now-worse-than-useless _kernel_reread_part_table > Now that we're using BLKPG properly, there's no point in using the > less-functional BLKRRPART ioctl to make the kernel reread the > partition > table. > More importantly, this function would fail when any partition is in > use, in spite of our having carefully vetted them via BLKPG ioctls. > > I see fdasd (as of s390-tools 1.8.3-3) uses BLKRRPART and not BLKPG. > > The timeline would also fit the successful reports #569209 and #575682. This looks a fairly plausible theory, and the outcome is even more interesting, search for DASD in git log libparted/arch/linux.c. As I understand it, 9fa0e180 may even fix this problem. > I suppose I can try to hack parted to use BLKRRPART again and see if > that helps, but it's probably going to take a few days as I need to > get the emulator up and running first so I can rebuild the udeb. Probably you'd be better off backporting the relevant changes to 2.3-4 and testing that. -- Good luck, Feri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
