[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#317285: acknowledged by developer (Re: Bug#317285: initrd-tools: mkinitrd infinite recursion f RAID component device file missing)



On Thu, 07 Jul 2005, Kenneth C. Schalk wrote:

> *I* didn't make any choice about what kind of /dev tree to use.  The
> installer did.  I couldn't find any place to select devfs, and I
> didn't find any difference between choosing a 2.4 or 2.6 kernel when
> starting the installer.

the etch installer will use udev than that sort of troubles,
will not show up any more.
if you insist feel free to reopen and reassign as installation-reports
i guess debootstrap installs makedev.
 
> While I agree that it would be impractical to populate a static /dev
> tree with all possible devices, it *would* be practical to populate a
> static /dev tree with all physical partitions used in RAID devices
> configured from the installer's partitioner.

well there is no logic right now for that stuff.
 
> > sure, read the man of MAKEDEV(8) it tells you how to create those
> > needed nodes.
> 
> I did try that.  However, there's not really an opportunity to create
> additional device nodes during a from-scratch install.  I tried
> several different ways to do that before the installation of the
> kernel-image package, but didn't come up with one that worked.  (Hence
> my falling back on the approach of moving the drive for hdi to hda.)
well you can move to vc2 never had to invoke MAKEDEV, but i guess it
should be possible.
 
> > initrd can't possibly work for non existing device nodes.
> 
> I'm not suggesting that it should.  However, sitting in infinite
> recursion during an install for over an hour with no indication to the
> user of either progress or problems is profoundly unhelpful.  (I had
> to spend several days figuring out what was going wrong, and many
> people would not be capable of debugging this kind of issue.)  To me,
> such behavior does not seem acceptable, and I would argue that it is,
> in fact, a bug.
> 
> This particular problem could be detected and handled at several
> different points in the mkinitrd script.  I'm attaching a patch which
> shows at least two different ways to avoid this long-running infinite
> recursion.

well initrd-tools has other severe problems that will not be curred
as we are seeking for a complete remplacement.
there is no point in working on that cornercase.

--
maks




Reply to: