[Sisuite-devel] [Oscar-devel] [Fwd: Re: Fedora Core 7 support]

[Bernard Li]

Hi Allan:

Okay, figured it out -- I guess starting with 2.6.20, all HDs are treated as
'sdX', so if SystemImager thinks that your HD is 'hdX' then you will get the
kernel panic when the client boots.

The workaround for now, is to boot the imaged client into rescue mode,
modify /boot/grub/menu.lst (hdX -> sdX) and also /etc/fstab. This will
allow the client to boot up.

This sounds like something that needs to be taken care of by SIS... if the
golden image is running 2.6.20+ kernel, then we need to do the above
mentioned fixup.

Cheers,

Bernard

I built an image on Fedora Core 7 Test 2 i386 and netbooted my client, it
has no problem retrieving the kernel even though it is a symlink -- I am not
sure why it doesn't work for you.
However, after successful imaging, the client rebooted and it kernel
panicked, complaining about mounting /proc, /sys, etc. -- I'll look into
this later (is this similar to your problem with the SATA2 drives?)
I did encounter some weirdness during installation, it completely missed
installation of the sis package -- I had to manually run yume-opkg against
sis and then it was installed.
BTW, I have checked in your RPMs for fc7-x86_64, tomorrow's nightly should
include them. However, I don't think you have sent all the RPMs have you?
For instance, the RPMs for sis weren't there -- can you please rebuild
atftp, udpcast etc.? Take note that there are newer SRPMs in trunk now...
I have created 2 subdirectories in /tmp/rpms in our repository, so please
deposit newly built RPMs in the appropriate directory.
Thanks!
Bernard

[dann frazier]

Post by Bernard Li
Okay, figured it out -- I guess starting with 2.6.20, all HDs are treated as
'sdX', so if SystemImager thinks that your HD is 'hdX' then you will get the
kernel panic when the client boots.
The workaround for now, is to boot the imaged client into rescue mode,
modify /boot/grub/menu.lst (hdX -> sdX) and also /etc/fstab. This will
allow the client to boot up.
This sounds like something that needs to be taken care of by SIS... if the
golden image is running 2.6.20+ kernel, then we need to do the above
mentioned fixup.

This is probably a distro-specific udev config, so kernel-rev only
isn't enough info. Right answer is to use the distro's udev config.

[Bernard Li]

Post by dann frazier
This is probably a distro-specific udev config, so kernel-rev only
isn't enough info. Right answer is to use the distro's udev config.

I guess this would work with UYOK, but is there a way to also "solve"
this for the default ramdisk that we ship with SystemImager?

Thanks,

Bernard

[dann frazier]

Post by Bernard Li

Post by dann frazier
This is probably a distro-specific udev config, so kernel-rev only
isn't enough info. Right answer is to use the distro's udev config.

I guess this would work with UYOK, but is there a way to also "solve"
this for the default ramdisk that we ship with SystemImager?

for the benefit of the list, my suggestion on IRC was to use a recent
version of udev in the ramdisk and transfer udev config files from the
image before starting it up.

[Andrea Righi]

Post by dann frazier

Post by Bernard Li

Post by dann frazier
This is probably a distro-specific udev config, so kernel-rev only
isn't enough info. Right answer is to use the distro's udev config.

I guess this would work with UYOK, but is there a way to also "solve"
this for the default ramdisk that we ship with SystemImager?

for the benefit of the list, my suggestion on IRC was to use a recent
version of udev in the ramdisk and transfer udev config files from the
image before starting it up.

Dann,

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...

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...

Regards,
-Andrea

[dann frazier]

Post by Andrea Righi
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.

Post by Andrea Righi
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 :)

[Bernard Li]

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

Post by dann frazier

Post by Andrea Righi
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
/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
* 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.

Post by Andrea Righi
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
https://lists.sourceforge.net/lists/listinfo/sisuite-devel

[Andrea Righi]

Post by dann frazier

Post by Andrea Righi
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
/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
* 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.

Post by Andrea Righi
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 :)

Maybe the simplest solution is to add an option to si_prepareclient to
choose if we want to use the default udev config or to copy the config
that runs in the golden client.

We could add an option like --udev-config DIR. If specified the
/etc/udev of the initrd will be replaced with the content of DIR. In
this way we're able to use it also with si_mkbootpackage (usually used
in the image server to create kernel+initrd.img package), for example to
specify the udev config of an image (--udev-config
/var/lib/systemimager/images/my_image/etc/dev).

Unfortunately with this approach is the user that has to select the
correct udev configuration, and potentially in some cases there'll be
not a correct configuration: when default config doesn't work and the
image config has unresolved dependencies... but for now this is the
simplest approach that I see...

Regards,
-Andrea