On Thu, Sep 8, 2011 at 12:44 PM, David W Noon <dwn...@ntlworld.com> wrote: > On Wed, 7 Sep 2011 23:33:35 -0400, Canek Peláez Valdés wrote about Re: > [gentoo-user] /dev/sda* missing at boot: > >> On Wed, Sep 7, 2011 at 9:37 PM, David W Noon <dwn...@ntlworld.com> >> wrote: > [snip] >> > The more I think about this merge of / and /usr, the dumber I think >> > the idea is. As I wrote in an earlier message on this list, the >> > initramfs will be many times larger than the kernel itself. >> > Indeed, my /boot partition is only 32 MiB, and that will be too >> > small to contain all the extra libraries and programs to run the >> > initramfs script. >> >> I don't see any problem with an initramfs larger than the kernel. It >> will handle a lot of stuff. But if you don't want to change your /boot >> partition, then don't upgrade to new kernels. > > It is not the kernel that is the problem. It is udev. > > 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. > 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. >> Change happens. > > I think a more appropriate observation is: change is inevitable, but > progress isn't. To progress you need to try (and sometimes fail). udev is the third iteration to handle /dev in the kernel; maybe mdev is a better option, but I'm highly sceptical. >> >> > Mounting it read-only >> >> > seems the only sensible one, and then I think is better to go all >> >> > the way and mount / read-only. >> >> >> >> Putting /etc on a read-only filesystem seems a really bad idea. >> > >> > To say the least. >> >> It works, > > Putting /etc on a read-only mount works?? I take it you don't run any > database servers. Every time I add a new database to PostgreSQL it > requires (for my needs) at least 1 new tablespace be created with its > own mount point. This requires me to add at least 1 line to /etc/fstab > so that the new tablespace(s) is/are mounted before PostgreSQL starts > after a re-boot. This becomes impossible if /etc is read-only. mount -o remount,rw / do stuff... mount -o remount,ro / Really, I don't see the problem. > 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? >> and it makes life easier for upstream. Which are the ones >> writting the code. > > It allows people developing udev scripts to use programs and > libraries that are not [currently] on rootfs inside their scripts. If I > don't use those scripts, I don't care. And rightly so. Then by all means try mdev and other solutions. Maybe one (or all) of them will result in the dominant technology in the future. Maybe it will allow you to not use an initramfs, and ignore udev, and to keep /usr separated from /. Just don't expect the limited resources of the Gentoo devs to be able to test and support your special configuration. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
