[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Getting working d-i from svn including udebs

I have been unsuccessful in getting a working d-i for use with a custom debian cd due to di-/kernel mismatches and builds that don't. I have tried using the latest sarge branch

svn co svn://svn.debian.org/d-i/branches/d-i/sarge debian-installer

and then, from the debian-installer directory and after installing all
build dependencies (found via dpkg-checkbuilddeps, and the ones like automake and autoconf that aren't depended on but are documented on the wiki)

./scripts/buildscript -r /usr/bin/fakeroot -rr /usr/bin/sudo

This chunks along, and appears to work, however, after I build my cd and attempt to install I get at 'no partitionalble media found' error at the partitioning stage. I've noticed that the logs say something about libparted 1.6 but there is no parted package in the debian-installer/packages directory.

Another possibility that has been suggested to me is a kernel/d-i mismatch, however I am, as you can see, using the udebs that are in the subversion repository (in fact I make sure there are no other udebs to confuse the issue when building my cd).

Because that wasn't working, I figured that maybe I needed to use a release rather than the current sarge branch, so I checked out and attempted to build

svn co svn://svn.debian.org/d-i/tags/d-i/rc2 d-i-rc2

This failed with a fatal error saying that there were modules in more than one udeb. On this list I was told that this was a kernel version problem that was fixed, but if the rc2 tag is to mean getting a working d-i rc2 then the packages need to match what was used with rc2, which is obviously not the case since the rc2 cds work but the subversion checkout and full build does not.

I'm rather frustrated because d-i doesn't seem to have coherent way of making sure one gets a working source base (d-i+udebs) to build a cd with, *and* if one tries to use a d-i from installer-i386 and udebs from the standard testing pool, one frequently ends up with d-i/kernel mismatches (this was what I was trying at first).

I'm more than a little concerned by the fact that a checkout of rc2 does not get one a working d-i. That is, I thought, the purpose of a tagged 'release'. A non-working working branch I can live with; that happens, but when something that is supposed to be a working snapshot doesn't I'd call that a major bug, and unless someone gives me a good reason not to, I'll probably file a bug against d-i for this.

Reply to: