-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Pat,
Xa is working, so I'll answer.
Patrick J. LoPresti wrote: | 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.
Of course not. We developped some of our sources for a company. Therefore we have to write some sources new, to avoid any copyright-trouble. But it's currently in process and we hope that we'll finish next week.
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.
That's it. But there are some issues, if you use sfdisk and write the mbr hard with dd. Now we're using parted for partitioning and ms-sys to write the mbr. These are DOS compatible tools. Now we have only trouble with some harddisks (e.g. maxtor 40GB) if we operate in 'bishift' mode. ~ Switching to LBA mode (BIOS) solve this issue.
| | - Access to more information for deciding what to do; e.g., DHCP | options, SMBIOS data (like Dell service tag), and information | gathered via HTTP.
That's was the idea: We use the DHCP options to gather all installation parameters at runtime. We're also supporting DHCP User Classes. So you can suppport different clienttypes for different domaintypes with exact the same installtion environment and in the same subnet.
| - No more issues with DOS junk like silly memory management and | broken BIOSes.
I remember this junk....
| | (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?)
This would really be nice. One time, we tried out to boot from memory stick. We didn't solved this problem yet.
| | |>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.
It's already a plan to modularize it.
| | |>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.)
yep. it works.
| | |>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).
At the beginnig of 2002 we tried out the dosemu stuff. But dosemu couldn't start the winnt.exe. This was an issue at this time. Maybe this is fixed yet (does anybody knows?).
| | |>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?
It is already written. But here and there it's very specialized. We work on it to generalize it. But I hope, that we are able to send you a disk image next week (see above).
| | 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?
Good idea. (@till: Do you agree?)
Hagen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFAIozvJ31vBDLS4wQRAvZWAKCGfwUyjOKTGr3s3+aWohkz/IvPQQCgpqWz eec3jH6DTgll2ne6P3CP2n4= =CMe8 -----END PGP SIGNATURE-----
------------------------------------------------------- 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
