Strange as it may sound for an "auto" installation program, I'd love to be able to leave out a section (such as partitioning, etc.) and know that if it isn't there, autoyast will ask the user, just like a normal install. I'm trying to make an autoyast xml for literally a hundred different types of hardware, and it's a literal impossiblity because of all the differences. Letting the "normal" installer handle hardware issues, etc. and just forcing my package listing and scripts is all I really need! --Jon Robison On Thu, 2003-09-18 at 16:38, Anas Nashif wrote: darby wrote:
Hi, Had a couple of items I'd like to throw out there as potential wist list features for yast2/autoyast: * Pipe the standard output of the "custom scripts" to the yast gui interface during install. For scripts that can take awhile, this would provide some helpfull feedback on their progress.
Yeah, had this in mind, although it possible already now using chvt.
* Add a dhcp server option to "network services". What do you mean exactly? Being able to configure a DHCP server automatically?
* Automatic detection and installation of network and sound cards. This would be very helpfull for sites that are doing autoyast installs on large amounts of heterogeneous (sp?) hardware.
Network should work now (upcoming release) and sound will be following. Anas
Thanks, Darby
-- To unsubscribe, e-mail: suse-autoinstall-unsubscribe@suse.com For additional commands, e-mail: suse-autoinstall-help@suse.com
On Friday 19 September 2003 15:20, Robison, Jonathon (M.) wrote:
Strange as it may sound for an "auto" installation program, I'd love to be able to leave out a section (such as partitioning, etc.) and know that if it isn't there, autoyast will ask the user, just like a normal install.
I'm trying to make an autoyast xml for literally a hundred different types of hardware, and it's a literal impossiblity because of all the differences. Letting the "normal" installer handle hardware issues, etc. and just forcing my package listing and scripts is all I really need!
Well, here's a previous answer which is basically a different tack on teh same question: == begin == Peets wrote:
I'm looking at defining a default package selection only - i.e. establishing a sort of extra installation selection beyond 'minimal', 'graphical' etc. The aim is to leave the normal SuSE installation process for Pro 8.2 intact but to pre-set the package selection to one that will be the default loadset for a particular class of desktops (I can't go automatic as the hardware is, er, rather varied ;-).
The problem is that I'm not able to identify in the AutoYAST dos how to stop AutoYast from being 'auto' - all I want is to pre-set the selected packages in the detailed package selecton of YAST and keep everything else precisely as is, i.e. manual and flexible.
Autoyast is Automated and you cant stop it from being automated. If you want only to change the package selection, you can change the selection files in suse/setup/descr and make them the way you want. However you need to test for consistency and dependencies and make sure all RPMs are there.
If someone could point out some docs or HOWTOs where this is detailed I'd be very happy, the AutoYAST dos don't go into detail on avoiding automation ;-)
=== end === Looks like there is a deployment support gap between YAST and AutoYAST. The simplest way for *any* deployment would have been the ability to build a system precisely with the required packages, and then to somehow save that selection as a list. This obviously assumes a 'read pre-select' as well, but AFAIK there is presently no straightforward process to preserve an accurate package selection other than via a rather extensive manipulation of data. Hence the AutoYAST question as it has a 'clone this system' option - it's just too good and wants to do everything ;-). So we need a 'clone this package selection' that we maybe can just feed into YAST (I know what you mean by 'heterogenous' ;-) - even maybe cross platform .. /// P ///
Peets wrote:
On Friday 19 September 2003 15:20, Robison, Jonathon (M.) wrote:
Strange as it may sound for an "auto" installation program, I'd love to be able to leave out a section (such as partitioning, etc.) and know that if it isn't there, autoyast will ask the user, just like a normal install.
I'm trying to make an autoyast xml for literally a hundred different types of hardware, and it's a literal impossiblity because of all the differences. Letting the "normal" installer handle hardware issues, etc. and just forcing my package listing and scripts is all I really need!
Well, here's a previous answer which is basically a different tack on teh same question:
== begin == Peets wrote:
I'm looking at defining a default package selection only - i.e. establishing
a
sort of extra installation selection beyond 'minimal', 'graphical' etc. The aim is to leave the normal SuSE installation process for Pro 8.2 intact but to pre-set the package selection to one that will be the default loadset for a particular class of desktops (I can't go automatic as the hardware is, er, rather varied ;-).
The problem is that I'm not able to identify in the AutoYAST dos how to stop AutoYast from being 'auto' - all I want is to pre-set the selected packages in the detailed package selecton of YAST and keep everything else precisely as is, i.e. manual and flexible.
Autoyast is Automated and you cant stop it from being automated. If you want only to change the package selection, you can change the selection files in suse/setup/descr and make them the way you want. However you need to test for consistency and dependencies and make sure all RPMs are there.
If someone could point out some docs or HOWTOs where this is detailed I'd be very happy, the AutoYAST dos don't go into detail on avoiding automation ;-)
=== end ===
Looks like there is a deployment support gap between YAST and AutoYAST. The simplest way for *any* deployment would have been the ability to build a system precisely with the required packages, and then to somehow save that selection as a list. This obviously assumes a 'read pre-select' as well, but AFAIK there is presently no straightforward process to preserve an accurate package selection other than via a rather extensive manipulation of data.
Hence the AutoYAST question as it has a 'clone this system' option - it's just too good and wants to do everything ;-). So we need a 'clone this package selection' that we maybe can just feed into YAST (I know what you mean by 'heterogenous' ;-) - even maybe cross platform ..
This is actually already supported in the package manager itself. You can read a previously saved file in the package manager. This is has nothing to do with AutoYaST however.. The main goal of autoyast is full automation and it will continue to be fully automated. However we know exactly about the needs described here for a semi-automated or even an installtion with user supplied defaults. Its only a matter of time :-) Anas
/// P ///
participants (3)
-
Anas Nashif -
Peets -
Robison, Jonathon (M.)