Andrea,

Many thanks.

I built 3.7.3 as a debian package, using the debian build files
with the version numbers edited appropriately.

I believe (as of this morning) I have it working, although I
haven't tested all functionality - just pulling images and
installing them.

As a helpful note to anyone else trying this:
------------------------------------------------------------------------

The only real issues I found were with the i386 boot package,
which I built on a debian sarge system with the systemimager
build deps installed as per the README file.

(issue #1)
-----------------
Libraries in the boel_binaries tarball are not guaranteed to
contain all the symbols needed for executables in the initrd.
Since unpacking the boel_binaries tarball results in some of
the libraries included in the initrd being overwritten, this
causes several things to fail.

Explicitly, mkstemp64 was missing in the boel_binaries version
of libc.so.6, but present in the initrd version.  Busybox needs
this to provide (among other things) 'ash' functionality.

This is easily fixed by adding the initrd bin/ and sbin/ paths
to the mklibs invocation in boel_binaries.inc file in make.d/

I'm actually kind of amazed I haven't been bitten by this before, since
as far as I can tell, the mklibs invocation in the boel_binaries build
process has the same flaw in version 3.6.3.  I suppose it was just
lucky that the symbols needed overlapped perfectly.

(issue #2)
-----------------
/lib/libnss_files* library files are linked to /lib/tls/i686/cmov/libc.so.6
on my sarge build box.  This version of libc.so.6 provides
_nss_files_parse_pwent, whereas /lib/libc.so.6 does not.  Unfortunately,
I do not know enough about the different versions of libc.so.6 to feel
confident replacing one with the other.  I simply chose to make sure that
/lib/tls/i686/cmov/libc.so.6 was included with the boel_binaries 
tarball, and
provided an ld.so.cache file in case there were any problems resolving it.

This fixed that problem.  Without the change, the install script was still
exiting with errors when those symbols were needed.

Thanks again.

Justin


Andrea Righi wrote:
> Justin,
>
> it would be better to start from 3.7.4... a lot of problems you found
> should be fixed in that release. Even if it's tagget as "unstable" 3.7.4
> is surely more stable than 3.6.3, since it includes *a lot* of
> bugfixes... unfortunately at the moment I've not a testing machine with
> Debian, so it's quite difficult for me to check the particular problems
> for Debian, but if you want to start a bugfix activity with the last
> release I'll be happy to help you.
>
> Cheers,
> -Andrea
>
> Justin Thiessen wrote:
>   
>> Greetings,
>>
>> I'm working on updating our install of systemimager.  We've been running 
>> debian versions 3.2.3-6 and 3.4.0-2
>> from debian stable.
>>
>> I downloaded 3.6.3-2 from debian testing and experienced several issues:
>>
>>
>> (i386-boot issues)
>>
>> modprobe is borked in th i386-boot deb.  This may just be a problem in 
>> the debian build.
>> It errors out during the install, complaining about glibc 2.0.  Insmod 
>> works, so I hardcoded that
>> plus the dependencies into /etc/init.d/* and the install scripts.  This 
>> works but is not ideal.
>>
>> Building 3.6.3-2 from source on amd64 resulted in the following issues:
>>
>> (amd64-boot issues)
>>
>> /lib and /lib64 are unique directories.  The install does not create a 
>> library cache file (ld.so.cache), so the linker in the install relies on 
>> all libraries being in the trusted directories.  Unfortunately, since 
>> the only trusted directory is /lib, anything which needs a library in 
>> /lib64 fails.  I simply collapsed the /lib64 directory into /lib, and 
>> symlinked /lib64 to /lib,
>> which makes the filesystem look more like a typical debian install.  
>> This works, but is probably not ideal.
>>
>> (si_mkbootpackage issues)
>>
>> The biggest win for us would be gaining the ability to use 
>> si_mkbootpackage to create custom install kernels and initrds.  
>> Unfortunately, the script as present in 3.6.3-2 exhibits a number of 
>> problems.
>>
>> * depends on devfs, which disappears after linux 2.6.12.  We need a 
>> newer kernel for hardware support.  I did not try to switch to udev 
>> support, although it might have not been too tough.  I just populated a 
>> /dev directory with the appropriate entries.
>> * the regexp that is supposed to determine the kernel version (2.4 vs 
>> 2.6) fails, and no modules get copied into the initrd.  I fixed this, but...
>> * discover is old enough that it doesn't know much about our hardware.  
>> forcing modules to be probed (and having static /dev entries) gets items 
>> working, but is kludgy.
>>
>> Other issues:
>> ----------------------
>> the install script edits /etc/fstab to match actual hard drives, but 
>> does not edit /etc/lilo.conf.  I can fix this easily, but, again, should 
>> I just update to the latest source?
>>
>> Are these fixed in the latest source release?
>>
>> And would it be more practical to start from 3.7.3(4)?  I'd be happy to 
>> contribute any fixes back to the project.
>>
>>
>>
>> Sincerely,
>>
>> Justin Thiessen
>> --------------------------
>> [EMAIL PROTECTED]
>>
>>     
>
> -------------------------------------------------------------------------
> 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-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sisuite-users
>   


-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sisuite-users

Reply via email to