From: [EMAIL PROTECTED] on behalf of Charles Galpin
Sent: Thu 05/01/2006 16:52
To: [email protected]
Subject: Re: [Sisuite-users] Re: no devfs support when using 3.5.3
On Jan 5, 2006, at 7:36 PM, Bernard Li wrote:
> Hi
Charles:
>
> The RPMs are built on a x86_64 system and thus
only generated the
> x86_64 binaries - you'll need to rebuild the SRPM on
a x86 system.
Doh! I had completely ignored the x86_64 rpms, but now see
you have
them for initrd_template now. I understand :)
> You cannot
just copy the modules over because it has to match the
> kernel
version. The kernel version for x86 is 2.6.12.2 and I noticed
> that
support for Marvell SATA wasn't added until 2.6.13.
I should have
explained better. I made a symlink from /usr/src/linux to
the
systemimager-3.5.3/src/linux-2.6.10 dir and compiled the drivers
against that
kernel, then copy them over. I do this all the time on
boxes to get this
supported. It's how to package this up successfully
thats got me
stumped.
I did this with 2.6.10 and get some symbol errors for a few key
modules
(unrelated to my additions)
depmod: *** Unresolved symbols
in
/lib/modules/2.6.10-boel_v3.5.3/kernel/drivers/scsi/libata.ko
depmod:
*** Unresolved symbols
in
/lib/modules/2.6.10-boel_v3.5.3/kernel/fs/ext3/ext3.ko
and others.
Needless to say booting off this kernel just panics.
> I strongly
suggest you try the UYOK route.
Ok, but should I write a wrapper
script? I already tried
si_mkbootpackage and ran into the devfs issue so not
sure if the
UYOK.pm will do better (or if 3.6.3 is better) or how to get past
the
devfs issue :(
> But if you really want to recompile the
SystemImager kenel, a place to
> start is updating make.d/kernel.rul
changing the kernel version for
> i386 (as well using a correct URL to d/l
it), and also to make
> appropriate changes to patches/linux.i386.config
(most notably
> CONFIG_SCSI_SATA_MV=m).
OK, I hadn't thought to
upgrade the kernel. I'll give this a shot,
however i think some of the cards
I want to support like the arecas are
still not mainstream either. But very
good idea.
> In regards to mounting the initird.img, you should be
able to mount it
> on the loopback once you gunzip it - I can't remember
whether it's
> writeable or not, though.
I *swear* this didn't work
earlier, but
[EMAIL PROTECTED] linux-2.6.10]# pushd /tmp
/tmp
~/systemimager-3.5.3/src/linux-2.6.10
/usr/src/3w-9xxx/driver
~/systemimager-3.5.3/src/linux-2.6.10
/tmp
[EMAIL PROTECTED] tmp]#
cp
/usr/share/systemimager/boot/i386/standard/initrd.img
initrd.img.gz
[EMAIL PROTECTED] tmp]# gunzip initrd.img.gz
[EMAIL PROTECTED] tmp]#
mkdir x
[EMAIL PROTECTED] tmp]# mount -o loop initrd.img /tmp/x
[EMAIL PROTECTED]
tmp]# ls /tmp/x
bin etc linuxrc
new_root root tmp var
dev lib my_modules
proc sbin usr
[EMAIL PROTECTED] tmp]# touch
/tmp/x/i_love_bernard
touch: creating `/tmp/x/i_love_bernard': Permission
denied
Not writeable, but a whole lot further than I got before :) I
think
I'll give this a
shot.
Thanks!
charles
-------------------------------------------------------
This
SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for
problems? Stop! Download the new AJAX search engine that
makes
searching your log files as easy as surfing the web.
DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick
_______________________________________________
Sisuite-users
mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sisuite-users
