Bug#605759: [s390/hercules] disk partitioning failed: no /dev/dsda1
Niko Tyni <ntyni@debian.org> writes:
> On Thu, Dec 16, 2010 at 05:37:55PM +0100, Ferenc Wagner wrote:
>
>> Niko Tyni <ntyni@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.
Reply to: