[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)

> indeed that's a possible workaround. well i assume that you are
> using a static /dev tree. in that case makedev handles which devices
> show up in /dev.

> as one can't populate every debian system with all possible devices,
> the maintainer maid a trade-off to cut after 8 discs, which should
> not be noticable for the vast majority.

*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.

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.

> 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.)

Of course none of this is to do with initrd-tools, however:

> 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


Attachment: mkinitrd.patch
Description: Binary data

Reply to: