On Thu, Sep 8, 2011 at 4:25 PM, David W Noon <dwn...@ntlworld.com> wrote: > On Thu, 8 Sep 2011 15:13:55 -0400, Canek Peláez Valdés wrote about Re: > [gentoo-user] /dev/sda* missing at boot: > >> On Thu, Sep 8, 2011 at 2:05 PM, David W Noon <dwn...@ntlworld.com> >> wrote: > [snip] >> > I don't know if the kernel offers any particular blessing to any >> > hotplug handler. >> >> udev is the device manager for the Linux kernel. It replaced devfs. > > One can use mdev just as readily as udev. > >> It's related, but doesn't (necessarily) need to be the same that the >> user space part. >> >> Yeah, udev is mandatory in the kernel, unless you use a traditional >> /dev directory. > > But udev isn't actually part of the kernel. Only hotplug support is > actually in the kernel. The udev daemon is started during the sysinit > run-level and it connects itself to hotplug support.
And what do you think the udev daemon speaks to? > [snip] >> >> Dracut automatizes this. Is a non-problem. >> > >> > If dracut actually worked ... >> >> What doesn't work for you? > > Since dracut is not yet stable, I don't have any problems with it > because I don't use it. But it does have quite a few open bugs in > Gentoo's Bugzilla, and I suspect many more in other distro's bug > trackers. Well, dracut's job is not rocket science. >> > During the "do stuff" phase, /usr is also writeable, which is >> > undesirable on production systems. That's the *original* problem >> > with merging a read-only /usr with /. [We seem to be going in >> > circles with this one.] >> >> It's the same when you upgrade the system. If you don't allow rw in >> /user *ever*, then you are not allowed to upgrade. Which I was chewed >> up because I said it was an alternative. > > Production systems have strictly scheduled change-control windows, > usually only once or twice a year. Having to schedule database changes > to match application change-control would not be workable. That is > why /etc cannot be mounted read-only and still have /usr secured as > read-only. This brings us back to a requirement that / and /usr be > physically separate filesystems. > > [snip] >> > I have about 6 or 7 backup jobs that run during the night and >> > parse /etc/mtab to see if they need to place a copy of the backup >> > onto an external medium. These examine the mount options and don't >> > understand the non-standard options offered by Linux >> > in /proc/mounts. >> >> Really? You cannot grep -v those options to another file and make the >> jobs read this other file? > > I would use gawk rather than grep. But since I have code that already > works, why should I need to develop a new script? > >> In my experience that sounds like a problem with the jobs. > > They work currently. So you want all the new functionality, but without needing to do anything. I want pink ponies too. Just not gonna happen. > Moreover, my rootfs is not read-only. It is not desirable to have the > rootfs mounted read-only because of this problem and the other > problems it causes. But for production systems it is desirable for /usr > to be mounted read-only and only made writeable during a change-control > window. Then use an initramfs and get /usr separated. You can do it on one of your twice a year down times. > [snip] >> > They already don't do that. >> >> Well, then you already know what to do. > > Indeed I do. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
