Alexander Schuppisser <[EMAIL PROTECTED]> writes:
> We are developing a similar open-source project for large networks
> which is still somewhat different to your approach. We are thinking
> about a merge with unattended, but we don't know, if this is A)
> welcomed and B) how our sources are incorporatable to your
> concept...
I cannot answer (B) without seeing your sources. But as for (A), a
Linux boot disk has been on our "it would be nice" list for a long
time. It has come up on this mailing list before, and I am definitely
interested.
To recap, the major advantages of a Linux boot disk are:
- No need to reboot after partitioning.
- Access to more information for deciding what to do; e.g., DHCP
options, SMBIOS data (like Dell service tag), and information
gathered via HTTP.
- No more issues with DOS junk like silly memory management and
broken BIOSes.
(Perhaps I should add "wireless network support". Imagine a laptop
with only a wireless card and a USB port; but no Ethernet, no floppy,
and no CD. Imagine booting that laptop from a USB flash memory stick
and installing Windows over the wireless. How cool would that be?)
> Here is how we do the things: we boot with a linux bootfloppy which
> consists of a trimmed kernel with support for a lot of diffrent NICs
> (so no need for different floppy-images).
Nice! But there are a lot of NICs, so it is important that the
end-user be able to add (or download) support for their own.
Also, the network card is not the only problem... You have to worry
about SCSI and RAID drivers, too. This is the biggest advantage of
the DOS-based boot disk; it supports any hard drive controller
automatically. And if you boot using PXE, it supports any network
controller automatically, too, with a single floppy image.
With all the possible network and hard disk drivers, I think it is
important for any Linux-based approach to use a modular kernel and to
separate the "initial boot" disk from the "driver modules" disk, much
like any Linux installer does.
> The floppy contains also busy-box, a dhcp-client and samba(!) plus
> NFS-Support. After booting, a ash-shellscript gets started. The
> floppy gets its settings (namely the Win-share location and other
> relevant infos) from custom DHCP-Options from the DHCP-Server.
Cool! Does anybody know if Microsoft's DHCP server can be configured
with custom options? (We can always fall back to the current "prompt
the user with timeout" approach if the DHCP options are not
available.)
> From this point on, a (configurable) perl-script from the share
> takes over: The HD gets patrtitioned and FAT-formated. The
> win-setup-files are downloaded and stored to HD on the right
> partition. The HD gets prepared with syslinux as bootloader to
> start DOS to start Winnt.exe for the next reboot. The system will be
> then rebooted.
This ends up copying each file three times: Once within Linux to
populate the share, once by winnt.exe, and once by Windows Setup
itself after winnt.exe reboots.
I would rather run winnt.exe using dosemu from within Linux. So you
would not need to copy the setup files nor the boot sector; you would
just boot dosemu and let winnt.exe do that work (via lredir).
> After the windows installation, another perl-script gets startet by
> perl for windows. Perl for windows was installed during the
> installation of windows via the commandline.txt. This script then
> performs other tasks like joining-to-a-domain, installing winword
> and other packages, mailing the outcome of the installation etc.
We already have a structure in place for this part. But contributions
are always welcome!
> The advantage of this approach is that there is no need to configure
> the bootdisk and also no need of user-interaction during the whole
> setup-procedure. The bootdisk is formated as FAT. If special
> settings are needed, they therefore can be set under Windows in the
> Config-files on the floppy or better on the central perl-script on
> the fileserver.
It would be nice to have the option of answering configuration
questions on the server instead of on the client during installation.
But this is really a separate issue from using Linux on the boot disk.
Even the DOS boot disk runs Perl.
> Ufff.. All that explained, what kind of possibilities do you see for
> this project to contribute to unattended, maybe also as a second
> lag?
Is all of this code already written? Can I look at it?
I care about backwards compatibility with our existing system, so we
are not going to gut it completely. But even if we end up having
separate projects, we can certainly share some pieces, especially the
boot disk.
The first step, in my view, is to get our existing system working with
a Linux boot disk. The only hard part here, really, is dealing with
drivers. How would you feel about working together on a modular
Linux-based boot disk? We can worry later about whether you should
integrate the rest of your stuff or spawn your own project. (A good
boot disk will be useful to both of us in any event.)
- Pat
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
unattended-info mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unattended-info
