|
Hi Niels,
How are you going with your Stage0 solution?
After giving it some consideration, I have to say that I am probably looking for a simpler solution if one exists :-) I am not a developer and therefore do not have all the necessary skills to write my own loader, etc, which is what I think you are proposing, right?
While I am comfortable at a high level with the concepts associated with the the loader environment in stage1, and can kind of muddle my way through the C that makes up the loader, at this stage I cannot personally justify the cost in time associated with getting my head around the loader and its environment to a point where I could reproduce it.
That being said, I hope I have properly understood what you are proposing and am not barking up the wrong tree :-)
I wonder if it is necessary to replace the stage1 image entirely. I am inclined to hack things together when I cannot find an elegant or supported solution to a problem.
For instance, would it be possible to put a wrapper of sorts around the loader binary that performed the required tasks before passing control to the loader? Of course, this would depend upon a number of things including what state the stage1 environment was in when the loader was executed by init.
Can you please outline how you propose to construct this Stage0 solution in a little more detail? Are you indeed proposing to make custom mods to init and/or loader, or are you thinking of something else?
Regards,
Matt
----------------------- Original Message -----------------------
From: Matthew Richards <Matthew.Richards@xxxxxxxxxxxxxxxxx>
Cc:
Date: Mon, 22 Sep 2008 23:07:05 +1000
Subject: re[2]: Can the install method be contained within a kickstart file that is referenced via a %include option
Hi Niels,
This certainly sounds promising. It has been a while since I have been into stage1 of the installer (think RH73 days) so I do not recall exactly how the early stages of the installer string together but I will look into this and get back to you with any comments I have. Regards, Matt ----------------------- Original Message ----------------------- From: Niels de Vos <niels.devos@xxxxxxxxxxxxxxxxxx> To: Discussion of Development and Customization of the Red Hat Linux Installer <anaconda-devel-list@xxxxxxxxxx> Cc: Date: Mon, 22 Sep 2008 14:33:04 +0200 Subject: Re: Can the install method be contained within a kickstart file that is referenced via a %include option This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1CD7799D50048DB8F38AEA59 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Matt, Matthew Richards wrote: > The USB drive is identified differently depending upon the hardware=20 > configuration of the system with which it is booted. Generally > speaking if the system has only IDE disks then the USB drive becomes > /dev/sda. If the system has a SCSI or SATA disk then the USB drive > becomes /dev/sdb, etc. I'm having the same problem here... The solution I'm thinking of is a little bit different. It started as a solution for installing over the network where it is required to have static ip-addresses configured, but booting (installation) over PXE is required. In this case the static IP-address is given on the commandline in a pxelinux.cfg. (Backgound for the wondering readers: booting and 100% functionality without delays if there are network problems.) The solution needs one extra step/stage. Normally anaconda does a two stage installation. Stage1 is the loader, stage2 the installer in Python which contains a nice GUI. The extra step used is in our case stage0. Stage0 is an initrd which does a minimal setup of the hardware and some small ks.cfg editing with sed. After preparing ks.cfg, the original initrd from the install-set is downloaded, extracted and 'started'. In my opinion, in a stage0 like the above it would be possible to detect SATA/IDE/USB drives and replace/change ks.cfg with correct values. Any thoughts? Niels --------------enig1CD7799D50048DB8F38AEA59 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFI15CB5KAkGQPO/QoRAshfAJ4/s8u9voUI52Qt8aoG/QfTBH1YwACfUBBY WGNpBHcg9Lb+0XYOWGCqXEA= =hokA -----END PGP SIGNATURE----- --------------enig1CD7799D50048DB8F38AEA59-- --===============1199916769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list --===============1199916769==-- --===============1199916769== Content-Type: text/plain; charset="us-ascii"; charset="us-ascii" _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list --===============1199916769==-- <html><body><pre> _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list </pre></body></html> _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list |
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
