On Thu, Sep 8, 2011 at 2:05 PM, David W Noon <dwn...@ntlworld.com> wrote: > On Thu, 8 Sep 2011 12:56:44 -0400, Canek Peláez Valdés wrote about Re: > [gentoo-user] /dev/sda* missing at boot: > >> On Thu, Sep 8, 2011 at 12:44 PM, David W Noon <dwn...@ntlworld.com> >> wrote: > [snip] >> > I expect to switch my simpler systems away from udev to mdev. This >> > loses some functionality of udev, but that isn't needed on the >> > simpler hardware configurations. So mdev could be the simplest >> > solution to the design flaws creeping into udev. >> >> Maybe. I would not bet on it, but any new technical experiment is >> worth trying, I believe. I will stick with the kernel-blessed option >> of udev, though. > > 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. 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. >> > A very real problem with a large initramfs/initrd is maintaining the >> > software embedded in the image file. If it contains duplicates of >> > e2fsck, reiserfsck, glibc, libpthread, etc., then these typically >> > need to be upgraded whenever the primary copy is upgraded. The >> > bigger the initramfs becomes, the bigger the maintenance headache >> > it inflicts. >> >> Dracut automatizes this. Is a non-problem. > > If dracut actually worked ... What doesn't work for you? > [snip] >> mount -o remount,rw / >> do stuff... >> mount -o remount,ro / >> >> Really, I don't see the problem. > > 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. >> > Similarly, /etc/mtab needs to remain writeable, as symlinking it >> > to /proc/mounts (or /proc/self/mounts) won't always work for >> > programs that parse /etc/mtab. This is because /proc/mounts >> > contains additional mount options that are fairly Linux-specific, >> > whereas /etc/mtab should be vanilla UNIX. >> >> I really, really don't care about non-Linux systems. But that's me, >> anyone else can use wathever they want. Just don't expect everyone to >> be happy with the lowest common feature set. >> >> Having said that, which programs do you use that need to parse mtab? > > 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? In my experience that sounds like a problem with the jobs. But hey, that only was an option (making / ro). You have several options, already discussed. And again, it's not the regular use-case. The devs don't need to worry about your use-case (or my use-case); they worry about the global picture (or at least should). You can either roll with that or maintain it yourself. If I were you, I would try to change those jobs. Otherwise, I would use an initramfs. Either way, I would fix it. > [snip] >> Just don't expect the limited resources of the Gentoo devs to be able >> to test and support your special configuration. > > :-)) > > They already don't do that. Well, then you already know what to do. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
