Re: diskles-image-*
>>>>> "Adam" == Adam Di Carlo <adam@onshore.com> writes:
Adam> Well, you can work with us (debian-boot) and we can try to
Adam> make sure that base2_2.tgz is what you need...
Thanks. Should we discuss this via debian-boot@lists.debian.org
(or whatever it is called)? Feel free to copy this message
as required.
>> In designing my postinst script, I had to do all tasks that are
>> required in order to make the NFS-image bootable, that aren't
>> done by the image itself.
>>
>> For slink, this was (simplified, comments removed):
>>
>> if [ -f /sbin/unconfigured.sh ]; then
>> /var/lib/dpkg/info/timezones.postinst configure #create
>> /etc/init.d/network file that configures localhost chmod 755
>> /etc/init.d/network chmod go+w /tmp /var/tmp cd /dev;
>> /dev/MAKEDEV generic rm /sbin/unconfigured.sh fi
For now, I might just remove the call to
/var/lib/dpkg/info/timezones.postinst
at least that should mean I can upload a "working" version of diskless
to master. I think this was the only real problem with this script.
Adam> Hmm... These are pretty much all things which are currently
Adam> handled by dbootstrap. I think we should make an effort so
Adam> that base2_2.tgz, even w/o dbootstrap's "configure base
Adam> system" option, is in some sort of reasonable state. Should
Adam> we provide defaults for all of the above? Would you be
Adam> willing to patch against our CVS's basefile.sh and get it
Adam> done that way?
Either some reasonable defaults and/or a script that will prompt
the user for the required information (as required, eg for
selecting the timezone - I am not sure if this is still an issue
for potato).
Adam> Well, the question is how *should* it be, and how best to
Adam> make it so.
Agreed.
>> The base2_2.tgz file should be easy to fix, I am not sure what
>> the significance of the numbers mean, but I can just check for
>> any files that match base*.tgz (for instance).
Adam> The numbers represent the major and minor Debian release
Adam> numbers. Slink was 2.1, hamm was 2.0, potato is 2.2. Woody
Adam> may be 2.3 or 3.0.
Ok. Wonder why I didn't realize that before...
>> The only real solution I can think of is to have a file on the
>> base2_2.tgz that does configuration automatically. So then my
>> script would look like:
>>
>> if [ -f /sbin/configure-image ]; then /sbin/configure-image rm
>> /sbin/configure-image endif
>>
>> Which would mean that all the messy, version specific code, is
>> where it belongs, within the base image. The same script, could
>> be used when installing from the boot disk, too. However, this
>> affects packages outside my own, so I thought I should post
>> here to get the opinion of other developers.
>>
>> Any ideas? What should I do?
Adam> I think you're right that this would be the best thing to
Adam> do. That just means that someone should take the
Adam> configuration stuff, and port it *out* of dbootstrap, and
Adam> into something else (either C code using newt like the new
Adam> tasksel, or else debconf-tiny compatible stuff --
Adam> debconf-tiny is probably going to be pushed into base).
debconf-tiny sounds like it might be the best approach. More
standard. I have no idea though what debconf-tiny is, or how to
program debconf even - these are issues I am going to find out soon.
It has been a while since I looked at this configuration stuff.
Wondering aloud: Are there any parts that are not appropriate for
NFS-Root systems? Probably the network configuration is redundant (the
NFS-Root kernel automatically detects this at startup). The loopback
(ie localhost) device must be configured though. I can't think of
anything else. Not sure about module support - that might not be such
a good idea, as it is run on the wrong computer. Maybe whatever script
does this should support some option to disable parts that aren't
required.
--
Brian May <bam@debian.org>
--
To UNSUBSCRIBE, email to debian-testing-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: