Justin, many thanks for reporting the issues. Both should be fixed in trunk, if you could test the release in the trunk it would be great (just to be sure if I did the right thing)!
You can download the code in the trunk simply with: svn checkout svn://[EMAIL PROTECTED]/var/lib/svn/systemimager/trunk or see http://svn.sisuite.org for more details. Thanks, -Andrea Justin Thiessen wrote: > 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
