Hi all:
I would just like to report that following dann's suggestions I have
code which copies udev configuration from the OS to the initrd and it
worked fine under Fedora Core 7 Test 2 (which uses 2.6.20 kernel).
It does copy a lot of configurations that may not be relevant, so we
may consider trimming the list of configuration files which we copy
over (but the naming may be non-standard).
I did notice that it took a bit longer to boot up, but this could be
related to using cramfs but I am not sure since I am using a VM as the
image server.
IMHO we should do a bit more testing before shooting this down, as
this seems to be a simple and possibly workable solution.
Just my $0.02.
Cheers,
Bernard
On 3/19/07, dann frazier <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 19, 2007 at 09:30:14AM +0100, Andrea Righi wrote:
> > the idea to copy the distro specific udev configuration is great, but
> > it's not so simple to realize. The main problem is that potentially
> > a generic udev config can require a lot of packages, and we can't
> > include all the possible dependencies into the initrd or in the BOEL
> > binaries... moreover a lot of udev configs seem to be based on specific
> > distro configuration paths (like /etc/sysconfig for RH and SuSE), so we
> > should find a way to resolve also these kind of dependencies...
>
> oh well, thanks for looking into it. Another option is to have your
> own unified udev config that aims to do the right thing for all
> distros - should be possible, but not so fun to maintain.
> (Of course, you can always use the distro's udev config in the /a
> chroot after you've layed down the image, but that's clearly too late
> for most things).
>
> Its indeed a messy problem, especially in this new world of
> easily-configurable names. I'd even expect distros to move to static
> naming schemes at install time to avoid the non-deterministic
> enumeration problem. For example, I already mount a lot of devices
> like so:
>
> /dev/disk/by-id/usb-Samsung_Samsung_YP-U2J_0002F9D64B890581-part1
> /media/samsung vfat user,noauto
>
> Which of course makes names pretty useless altogether, since unique
> IDs are specifically designed to not appear on 2 different devices
> that are otherwise identical.
>
> The right way to solve this may actually be to develop a footprinting
> infrastructure to figure out which disks in the image map to which
> disks on the autoinstallclient, using name as only one piece of input.
> And of course add the flexibility for end-users to specify this
> mapping in a way that lets them specify this mapping using whatever
> criteria they care about e.g.:
> * usb disk of at least 100G with an ID that matches the regex
> /^usb-Samsung_Samsung_YP-U2J_.*$/
> * 2nd scsi disk on the first channel of a controller that uses the
> sym53c8xx driver
> * plain old disk name == sda
>
> I could easily see this type of thing being added to the disk field in
> autoinstallscript.conf. e.g., define <disk> sections that associate
> desired properties of a disk with some logical name ("myrootdisk"),
> <fsinfo> sections that describe file systems and mount points, as well
> as the desired logical <disk> name.
>
> > IMHO the simplest way to fix the disk naming issue is a post-install
> > script that detects from the udev config of the installed image which
> > "naming style" will be used. Depdending on this naming style the script
> > fixes /etc/fstab, /boot/grub/menu.lsf (or /etc/lilo.conf), etc...
>
> sounds like a reasonable thing to do inside systemconfigurator, since
> it already messes with some of these files and need to know the right
> names itself.
>
> Of course, this is all hot air from someone who hasn't done any
> significant work on SIS in years :)
> --
> dann frazier
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sisuite-devel mailing list
> sisuite-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sisuite-devel
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
sisuite-devel mailing list
sisuite-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
