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

Re: [RFC] No longer create full set of static devices during install



On Sunday 11 November 2007, Joey Hess wrote:
> Frans Pop wrote:
> > The create_devices function in base-installer has been simplified a lot
> > because it no longer actually has to create any device nodes anymore.
> > It now takes care of the bind mount to /target/dev and does some
> > apt-install calls for RAID, LVM and crypto installs.
> > (Suggestions for a better name for this function welcome!)
>
> setup_dev

Done. Still does not really cover the apt-install of dmraid and such...

> > Are there still any arches that don't use udev for default installs?
>
> On arm, ads_cf doesn't currently use udev in d-i, but I'm probably going
> to change that, and ads_cf shouldn't hold up any ongoing progress in d-i
> anyway. AFAIK that's the last user of userdevfs.

OK.

> > +	mkdir -p /dev/.static/dev
>
> /dev/static is supposed to be mode 700. udev will currently fix up
> the existing permissions when it's installed, but to avoid subtly
> breaking if udev's postinst changed, I'd make it mode 700 to start with.
>
> I wonder if we need to include this directory in /dev at all. udev
> should create it, and migrate devices to it, if it doesn't already
> exist.

For an installed system it's created by /etc/init.d/udev on boot. Thing is 
that because I now bind mount /dev/ on top of /target/dev/, anything 
created in /target/dev/ during installation would get lost on the reboot.

So I think we should mimic /dev/.static in the D-I environment to preserve 
any static devices created during installation; unless we decide we don't 
really care of course, which is probably valid too.

I did just see that my implementation was a bit too simplistic.
/dev/.static needs to be a bind mount in its own right (see /dev/MAKEDEV).
I can probably come up with a cleaner implementation. I'll also have to add 
some additional code to ensure things remain idempotent.

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: