Re: initrd, lvm, and devfs
Alex Owen [EMAIL PROTECTED] writes: Some of us have woody running on LVM1... well I have this with 2.4 Debian kernel and LVM1. For LVM1 to work with a kernel that has devfs compiled in (debian kernels for woody do) then /dev/ has to be a mounted devfs. For people such as myself sarge as it stands will provide a 2.4.27 kernel with devfs and LVM1... This will allow us to upgrade to sarge fairy painlessly. Debian-installer on the other hand will install sarge on LVM2 and that gives people in my position the hint that we need to migrate to LVM2 during the lifetime of sarge (and probably 2.6 kernels too). Debian kernels (2.4.x) are already patched with the device mapper patches and are fully lvm2 capable. Since lvm2 understands lvm1 metadata you can just update to lvm2 userspace tools, create a new initrd and reboot. During the testing of etch (ie when etch is testing) debian will hit this removal of devfs problem... this will not affect sarge (Assuming sarge _IS_ released by then). etch is the place to fix the problem. The fix will be in 4 parts... (1) the kernel package will have no devfs! (2) initrd-tools will be fixed to support the kernel packages. (3) udev can provide compatability links for devfs names if needed. (4) debian-installer will be ported to use udev rather than devfs Without devfs the syntax of e.g. /proc/partitions changes and anything parsing those files needs to adapt back to the old syntax. People who wish to use non-debian stable kernels on sarge (when it is released) will have to backport these fixes from etch to sarge... much as I have had to from sarge to woody to get LVM1 to work on woody! Taking these in reverse... (4) from what I've seen of the d-i work the d-i folks know that a port from devfs to udev is on the post sarge todo list. (3) udev can alredy provide devfs style device nodes... can it do compatability links? (2) this thread has alerted initrd-tools people... I hope! (1) this thread has alerted kernel people... I hope! The only remaining question is are the devfs device names burned into the LVM2 metadata stored on disk somewhere??? I suspect not... I think that LVM2 uses somekind of UUID to identify devices that form part of an LVM2 VG. If this UUID business is the case then do we need (3) ??? I've used lvm2 with and without devfs and switched between them without problems. It's just a matter of changing fstabd and the likes. Hopefully by the time etch arrives as stable there will be a sane upgrade for sarge-LVM2 people to become etch-LVM(n1) people. I hope this is a usefull contribution and not just a brain dump! Alex Owen Debian User and SysAdmin MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd, lvm, and devfs
On Mon, Jan 17, 2005 at 08:03:42PM +1100, Russell Coker wrote: Devfs is regarded as obsolete in the kernel source. The current initrd images produced by initrd-tools does the following for a LVM system: mount -nt devfs devfs /dev vgchange -a y umount /dev This relies on a kernel with devfs compiled in to boot a system with an LVM root file system. I think that we should not rely on obsolete kernel features (IE devfs) for any boot option that is supported by the installer (IE LVM). This problem is solved in Fedora by having udev in the initrd, I think that we should use the same solution. Also I think that we should consider when we want to drop support for devfs in the kernel-image packages. At some stage this feature has to be removed as increasing amounts of kernel code don't work well with it. Agreed. But please let's get sarge out first, ok? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd, lvm, and devfs
Op ma, 17-01-2005 te 20:03 +1100, schreef Russell Coker: Devfs is regarded as obsolete in the kernel source. The current initrd images produced by initrd-tools does the following for a LVM system: mount -nt devfs devfs /dev vgchange -a y umount /dev This relies on a kernel with devfs compiled in to boot a system with an LVM root file system. I think that we should not rely on obsolete kernel features (IE devfs) for any boot option that is supported by the installer (IE LVM). In that case, we should probably drop debian-installer altogether, as it uses DevFS throughout :-) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd, lvm, and devfs
In that case, we should probably drop debian-installer altogether, as it uses DevFS throughout :-) Documentation/feature-removal-schedule.txt in 2.6.11-rc1: What: devfs When: July 2005 Files: fs/devfs/*, include/linux/devfs_fs*.h and assorted devfs function calls throughout the kernel tree Why:It has been unmaintained for a number of years, has unfixable function calls throughout the kernel tree Why:It has been unmaintained for a number of years, has unfixable races, contains a naming policy within the kernel that is against the LSB, and can be replaced by using udev. Who:Greg Kroah-Hartman [EMAIL PROTECTED] so unless Debian wants to stay with stoneage kernels you're better of starting to fix D-I. That beeing said D-I people have been told repeatedly that basing an installer on devfs is a bad idea long time ago, but let's not warm that up again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initrd, lvm, and devfs
On Monday 17 January 2005 20:34, Christoph Hellwig [EMAIL PROTECTED] wrote: so unless Debian wants to stay with stoneage kernels you're better of starting to fix D-I. That beeing said D-I people have been told repeatedly that basing an installer on devfs is a bad idea long time ago, but let's not warm that up again. Fortunately changing from devfs to udev is not particularly difficult. I suggest just grabbing code from Fedora, these things work pretty well in Fedora. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
