November 2011 - YaST Commits - openSUSE Mailing Lists

[yast-commit] r66733 - /trunk/autoinstallation/doc/xml/linuxrc.xml
by emap＠svn2.opensuse.org 07 Nov '11

07 Nov '11

Author: emap Date: Mon Nov 7 11:38:39 2011 New Revision: 66733 URL: http://svn.opensuse.org/viewcvs/yast?rev=66733&view=rev Log: edited by emap Modified: trunk/autoinstallation/doc/xml/linuxrc.xml Modified: trunk/autoinstallation/doc/xml/linuxrc.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/linuxrc… ============================================================================== --- trunk/autoinstallation/doc/xml/linuxrc.xml (original) +++ trunk/autoinstallation/doc/xml/linuxrc.xml Mon Nov 7 11:38:39 2011 @@ -18,7 +18,7 @@ <note> <para> If you run Linuxrc on an installed system, it will work slightly - different as it tries not to destroy your installation. As a consequence you + differently so as not to destroy your installation. As a consequence you cannot test all features this way. </para> </note> @@ -26,49 +26,49 @@ <section> <title>Passing parameters to Linuxrc</title> <para> - Unless Linuxrc is in manual mode it will look for an 'info' file in these + Unless Linuxrc is in manual mode, it will look for an <filename>info</filename> file in these locations: first <filename>/info</filename> on the floppy disk and if that does not - exsist for <filename>/info</filename> in the initrd. After that it parses the kernel - command line for parameters. You may change the 'info' file Linuxrc reads - using the <filename>info</filename> command line parameter. If you don't want - Linuxrc to read the kernel command line (say, because you need to give a - kernel parameter that accidentally is recognized by Linuxrc, too), use + exist, for <filename>/info</filename> in the initrd. After that it parses the kernel + command line for parameters. You may change the <filename>info</filename> file Linuxrc reads by + setting the <filename>info</filename> command line parameter. If you do not want + Linuxrc to read the kernel command line (e.g. because you need to specify a + kernel parameter that Linuxrc recognizes as well), use <emphasis>linuxrc=nocmdline</emphasis>. </para> <note> - <title>Change starting from SUSE Linux 10.2</title> + <title>Change since SUSE Linux 10.2</title> <para> - The info file is no longer implicitly read. You have to make it + The <filename>info</filename> file is no longer implicitly read. You have to make it explicit, like 'info=floppy:/info'. - </para> + </para><remark>emap 2011-11-07: That means the opening para is only valid for older version. Better modify.</remark> </note> <para> - Independent of the above, Linuxrc will always look for and parse a file - <filename>/linuxrc.config</filename>. You can use this file to change default - values, if you need to. But in general, use the <filename>info</filename> file - instead. Note that <filename>/linuxrc.config</filename> is read before any 'info' - file and even in manual mode. + Linuxrc will always look for and parse a file + <filename>/linuxrc.config</filename>. Use this file to change default + values if you need to. In general, it is better to use the <filename>info</filename> file + instead. Note that <filename>/linuxrc.config</filename> is read before any <filename>info</filename> + file, even in manual mode. </para> </section> <section id="info_file_format"> - <title>'info' file format</title> + <title><filename>info</filename> file format</title> <para> - Lines starting with '<emphasis>#</emphasis>' are comments, valid entries are of the form + Lines starting with '<emphasis>#</emphasis>' are comments, valid entries are of the form: </para> <screen> key: value </screen><para> - Note that <emphasis>value</emphasis> extends to the end of the line and so may contain spaces. + Note that <emphasis>value</emphasis> extends to the end of the line and therefore may contain spaces. <emphasis>key</emphasis> is matched case insensitive. </para> <para> - You can use the same key - value pairs on the kernel command line using the syntax + You can use the same key-value pairs on the kernel command line using the syntax <literal>key=value</literal>. - Lines that don't have the form described above are ignored. + Lines that do not have the form described above are ignored. </para> <para> - Valid keys are (values given are just examples) + The table below lists Valid keys. The given values are only examples. </para> <table frame='top'> @@ -103,7 +103,7 @@ <row><entry>BOOTPTimeout: 10</entry><entry> 10 seconds timeout for BOOTP requests</entry></row> <row><entry>DHCPTimeout: 60</entry><entry> 60 seconds timeout for DHCP requests</entry></row> <row><entry>TFTPTimeout: 10</entry><entry> 10 seconds timeout for TFTP connection</entry></row> - <row><entry>ForceRootimage: 0|1</entry><entry> load the installation system into ramdisk</entry></row> + <row><entry>ForceRootimage: 0|1</entry><entry> load the installation system into RAM disk</entry></row> <row><entry>Textmode: 0|1</entry><entry> start YaST in text mode</entry></row> <row><entry>Username: name</entry><entry> set user name (e.g. for FTP install)</entry></row> <row><entry>Password: password</entry><entry> set password (e.g. for FTP install)</entry></row> @@ -117,7 +117,7 @@ <row><entry>MemModules: 20000</entry><entry> delete all modules before starting YaST if free memory is below 20000 kB</entry></row> <row><entry>MemLoadImage: 50000</entry><entry> load installation system into ramdisk if free memory is above 50000 kB</entry></row> <row><entry>Manual: 0|1</entry><entry> start Linuxrc in manual mode</entry></row> - <row><entry>NoPCMCIA: 0|1</entry><entry> don't start card manager</entry></row> + <row><entry>NoPCMCIA: 0|1</entry><entry> do not start card manager</entry></row> <row><entry>Domain: zap.de</entry><entry> set domain name (used for name server lookups)</entry></row> <row><entry>RootImage: /suse/images/root</entry><entry> installation system image</entry></row> <row><entry>RescueImage: /suse/images/rescue</entry><entry> rescue system image</entry></row> @@ -128,14 +128,14 @@ <row><entry>VNCPassword: password</entry><entry> sets VNC server password</entry></row> <row><entry>UseSSH: 0|1</entry><entry> setup SSH server</entry></row> <row><entry>SSHPassword: password</entry><entry> sets SSH server password (this will not be the final root password!)</entry></row> - <row><entry>AddSwap: 0|3|/dev/hda5</entry><entry> if 0, do never ask for swap; if the argument is a positive number <emphasis>n</emphasis>, - activate the <emphasis>n</emphasis>'th swap partition; is the argument is a partition name, activate this swap partition</entry></row> + <row><entry>AddSwap: 0|3|/dev/hda5</entry><entry> if 0, never ask for swap; if the argument is a positive number <emphasis>n</emphasis>, + activate the <emphasis>n</emphasis>'th swap partition; if the argument is a partition name, activate this swap partition</entry></row> <row><entry>Exec: command</entry><entry> run <emphasis>command</emphasis></entry></row> <row><entry>USBWait: 4</entry><entry> wait 4 seconds after loading USB modules</entry></row> <row><entry>Insmod: module params</entry><entry> load this module</entry></row> <row><entry>Loghost: 10.10.0.22</entry><entry>Enable remove logging via syslog</entry></row> - <row><entry>y2confirm</entry><entry>overrides the confirm parameter in a profile and pops up the confirm proposal (available since SUSE Linux 10.1 / SLES10)</entry></row> + <row><entry>y2confirm</entry><entry>overrides the confirm parameter in a profile and requests confirmation of installation proposal (available since SUSE Linux 10.1/SLES10)</entry></row> </tbody> </tgroup> </table> @@ -152,7 +152,7 @@ </listitem> <listitem> <para>netsetup=xxx,yyy</para> - <para>just xxx and yyy</para> + <para>only xxx and yyy</para> </listitem> <listitem> <para> netsetup=+xxx,-yyy</para> @@ -161,7 +161,7 @@ </itemizedlist> <para> - <emphasis>xxx</emphasis> could have the following values: dhcp, hostip, + <emphasis>netsetup</emphasis> can have the following values: dhcp, hostip, gateway, netmask, nameserver. nameserverN asks for N nameservers (max. 4). </para> -- To unsubscribe, e-mail: yast-commit+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-commit+help(a)opensuse.org

1 0

[yast-commit] r66732 - /trunk/autoinstallation/doc/xml/Installation.xml
by emap＠svn2.opensuse.org 07 Nov '11

07 Nov '11

Author: emap Date: Mon Nov 7 11:04:43 2011 New Revision: 66732 URL: http://svn.opensuse.org/viewcvs/yast?rev=66732&view=rev Log: edited by emap Modified: trunk/autoinstallation/doc/xml/Installation.xml Modified: trunk/autoinstallation/doc/xml/Installation.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/Install… ============================================================================== --- trunk/autoinstallation/doc/xml/Installation.xml (original) +++ trunk/autoinstallation/doc/xml/Installation.xml Mon Nov 7 11:04:43 2011 @@ -9,33 +9,33 @@ Introduction </title> <para> - After the system has booted and the control file has been retrieved, - &yast2; performs configuration of the system according to the information - provided in the control file. All the configuration is summarized in a window that is shown by - default and should be deactivated if a full automatic installation is - needed. + After the system has booted into an automatic installation and the + control file has been retrieved, &yast; configures the system according + to the information provided in the control file. All configuration + settings are summarized in a window that is shown by default and should + be deactivated if a fully automatic installation is needed. </para> <para> - When &yast2; has reached the point where the summary of the configuration is shown, - &yast2; has only probed hardware and prepared the system for - auto-installation, thus, nothing has been changed in the system yet, so - that in case of any error, the process still can be aborted. + By the time &yast; displays the summary of the configuration, &yast; has + only probed hardware and prepared the system for + auto-installation. Nothing has been changed in the system yet. In case + of any error, you can still abort the process. </para> <para> A system should be automatically installable without the need to have - any graphic adaptor or monitor. Having a monitor attached to the - client machine is nevertheless recommended to follow the process and - to get feedback in case of any errors. Choosing between the Qt and the - Ncurses interfaces is possible. For headless - clients, system messages can be monitored using the serial console. + any graphic adaptor or monitor. Having a monitor attached to the client + machine is nevertheless recommended so you can supervise the process and + to get feedback in case of errors. Choose between the Qt<remark>emap 2011-11-07: Should this read 'graphical' or 'X11'?</remark> and the text-based + Ncurses interfaces. For headless clients, system messages + can be monitored using the serial console. </para> <section id="Installation.Interface.X11"> <title> - X11 Interface + X11 Interface (graphical) </title> <para> - This is the default interface while auto-installing. No special + This is the default interface while auto-installing. No special variables are required to activate it. </para> </section> @@ -44,23 +44,23 @@ Serial console </title> <para> - You can start installing a system using the serial console by adding - the keyword console (i.e. console=ttyS0) to the command line of the - kernel. This will start linuxrc in console mode and later in the - process, &yast2; also is started in serial console mode. + Start installing a system using the serial console by adding the + keyword "console" (i.e. console=ttyS0) to the command line of the + kernel. This starts linuxrc in console mode and later &yast; in serial + console mode. </para> </section> <section id="Installation.Interface.Ncurses"> <title> - Text based YaST2-Installation + Text-based &yast; Installation </title> <para> This option can also be activated on the command line. This will start - YaST2 in <emphasis>Ncurses</emphasis> mode. To start &yast2; in text + YaST2 in <emphasis>Ncurses</emphasis> mode. To start &yast; in text mode, add <emphasis>textmode=1</emphasis> on the command line. </para> <para> - Starting &yast2; in text mode is recommended when installing a client + Starting &yast; in text mode is recommended when installing a client with less than 64 MB or when X11 is not being configured at all, especially on headless machines. </para> @@ -68,12 +68,12 @@ </section> <section id="bootmedium"> - <title>Choosing the right Boot Medium</title> + <title>Choosing the Right Boot Medium</title> <para> - There are different methods for booting the client. The computer can boot from - its network interface card (NIC) to receive the boot images via &dhcp; /TFTP - or a suitable kernel as well as an initrd image are loaded from a - floppy or a boot-able CD-ROM. + There are different methods for booting the client. The computer can + boot from its network interface card (NIC) to receive the boot images + via &dhcp; or TFTP. Alternatively a suitable kernel and initrd image can + be loaded from a floppy or a bootable CD-ROM. </para> <section> <title> @@ -81,21 +81,22 @@ </title> <para> For testing/rescue purposes or because the NIC does not have a PROM or PXE - you can build a boot floppy to use with &autoyast2;. Using a floppy + you can build a boot floppy to use with &ay;. Using a floppy to initiate an auto-install process is limited due to the size of the data a floppy can hold. However, it is still possible to use floppies when auto-installing a single, disconnected machine. </para> <para> - Floppies can be used to store the control file, especially when using - the original &company-suse; CD-ROMs for a single, disconnected machine. Using the + Floppies can also store the control file, especially when using + the original &company-suse; CD-ROMs for a single, disconnected machine. Via the kernel command line, you can specify the location of the control file on the floppy. - </para> + </para><remark>emap 2011-11-07: Would people still use floppies these days? I'd expect USB sticks to be a lot more common.</remark> <para> - Even without specifying any command line options, it is still possible to initiate the - auto-install process by placing a control file on a floppy with a - special, pre-defined file name. (<filename>autoinst.xml</filename>) &yast2; will check for + Even without specifying any command line options, it is still possible + to initiate the auto-install process by placing a control file on a + floppy with the pre-defined file name + <filename>autoinst.xml</filename>. &yast; will check for <filename>autoinst.xml</filename> upon startup and if it was found it will switch from interactive to automated installation. </para> @@ -104,15 +105,15 @@ <section> <title>Booting from CD-ROM</title> <para> - You can use the original &company-suse; CD-ROMs in combination with other - media, i.e. with a floppy to hold the control file or in combination - with network where the control file can be located. + You can use the original &company-suse; CD-ROMs in combination with + other media. For example, the control file can be provided via a + floppy or a specified location on the network. </para> <para> - It is also possible to create customized CD-ROMs to hold only the - package you need in addition to the control file which also can be - saved on the CD-ROM. This method requires creation of CD-ROMs - every time you wish to change the configuration though. + Alternatively, create a customized CD-ROM that holds only the package + you need <remark>emap 2011-11-07: Why not name the + package?</remark>and the control file. If you need to change the + configuration, you'll have to create a new CD-ROM. </para> </section> @@ -123,8 +124,9 @@ will boot then without a physical media like a boot floppy or CDROM. </para> <para> - Here is a small example of a "/srv/tftp/pxelinux.cfg/default" file: - </para> + Here is an example of a + <filename>/srv/tftp/pxelinux.cfg/default</filename> file: + </para><remark>emap 2011-11-07: Update the example to SLES11?</remark> <screen> default SLES9 @@ -138,12 +140,12 @@ LOCALBOOT 0 </screen> <para> - It's recommended to add the vga=... parameter with a valid value for graphical + We recommended you add the vga=... parameter with a valid value for graphical installations, to trigger an installation with the frame buffer device instead of the vesa driver or ncurses mode. </para> <para> - Here is as a small example my "/etc/dhcp.conf" file: + Here is as an example of a <filename>/etc/dhcp.conf</filename> file: </para> <screen> option domain-name-servers 192.168.66.1; @@ -173,21 +175,20 @@ } </screen> <para> - A problem you might run into if you do installation via PXE is, that the + A problem you might run into if you do installation via PXE is that the installation will run into an endless loop, because after the first reboot, - the machine is doing PXE boot again and will restart the installation instead - of booting from harddisc for the second stage of the installation. + the machine is doing PXE boot again and restarts the installation instead + of booting from hard disk for the second stage of the installation. </para> <para> - This problem can be solved in different ways. One way is to use a http server - to provide the autoyast profile and instead of a static profile, a CGI script - on the webserver is run that provides the profile and then changes the TFTP server - configuration then for this special host, so that the next PXE boot from that - machine will be from harddisc by default. + This problem can be solved in different ways. One way is to use an http server + to provide the &ay; profile. And, instead of a static profile, run a CGI script + on the web server that provides the profile and changes the TFTP server + configuration for your target host. Then the next PXE boot of the + machine will be from hard disk by default. </para> <para> - Another way is to use autoyast to upload a new PXE boot configuration for that host. - That is done via autoyast profile like this: + Another way is to use &ay; to upload a new PXE boot configuration for the target host via the profile: </para> <screen> <![CDATA[ @@ -207,54 +208,54 @@ ]]> </screen> <para> - This will upload a new configuration for the actual machine to the tftp server short + This entry will upload a new configuration for the target host to the tftp server shortly before the first reboot happens. In most installations the TFTP daemon runs as user - "nobody". You have to make sure that that user has write permissions to the "pxelinux.cfg" - directory if you use that mechanism. - So if your machine got the IP address "192.168.66.195" a file "C0A842C3" will - be uploaded and if the machine reboots and will get the same IP address - via DHCP again, the new configuration will be used that has the harddisc as - a default boot media. - </para> - <para> - Of course this requires that the machine will get the same IP address again after the - reboot and if you want to do another autoinstallation for that machine, you have to - remove the file from the TFTP server. - </para> - <para> - Since openSUSE 11.2 (not SLES11) you can configure the filename too that will be uploaded. - If you use the "magic" __MAC__ filename, the filename will be the mac address of your machine like this "01-08-00-27-79-49-ee". - A missing filename creates the IP address filename like in the past. + "nobody". You have to make sure this user has write permissions to the <filename>pxelinux.cfg</filename> + directory. + So if your machine has the IP address "192.168.66.195", a file <filename>C0A842C3</filename> will + be uploaded. When the machine reboots and receives the same IP address + via DHCP, the new configuration will be used, telling the target host to book from hard disk. + </para> + <para> + If you want to do another auto-installation on the same machine, you + have to remove the file from the TFTP server. + </para> + <para> + Since openSUSE 11.2 (not SLES11), you can also configure the filename + that will be uploaded. If you use the "magic" __MAC__ filename, the + filename will be the mac address of your machine like this + "01-08-00-27-79-49-ee". If the filename setting is missing, the IP + address will be used for the filename. </para> </section> </section> <section id="invoking_autoinst"> <title id="invoking_autoinst.title"> - Invoking the Auto-Installation process + Invoking the Auto-Installation Process </title> <section> - <title>Command line Options</title> + <title>Command Line Options</title> <para> - Adding the command line variable <emphasis>autoyast</emphasis> will make - <emphasis>linuxrc</emphasis> start in automated mode. - <command>Linuxrc</command> searches for a configuration file, which + Adding the command line variable <emphasis>autoyast</emphasis> causes + <emphasis>linuxrc</emphasis> to start in automated mode. + <command>linuxrc</command> searches for a configuration file<remark>emap 2011-11-07: Is this the profile? Better elaborate on this config file.</remark>, which should be distinguished from the main control file in the following places: </para> <itemizedlist> <listitem> - <para>In the root directory of the initial ram-disk used for booting - the system up</para> + <para>in the root directory of the initial RAM disk used for booting + the system,</para> </listitem> <listitem> - <para>In the root directory of the floppy</para> + <para>in the root directory of the floppy.</para> </listitem> </itemizedlist> <para> The configuration file used by <command>linuxrc</command> can have the - following keywords (for a detailed description of how linuxrc works and + following keywords (for a detailed description of how <command>linuxrc</command> works and other keywords, see <quote><xref linkend='appendix.linuxrc' endterm="appendix.linuxrc.title"></xref></quote> ): </para> @@ -272,20 +273,18 @@ <tbody> - <row><entry>netdevice</entry><entry>Which network device to use for - network setup (Device used for &bootp; / &dhcp; requests)</entry></row> - <row><entry>server</entry><entry>Which server to contact for source directory (NFS Server)</entry></row> + <row><entry>netdevice</entry><entry>Network device to use for + network setup (for &bootp; and &dhcp; requests)</entry></row> + <row><entry>server</entry><entry>Server (NFS) to contact for source directory</entry></row> <row><entry>serverdir</entry><entry>Directory on NFS Server </entry></row> <row><entry>hostip</entry><entry>When empty, client sends &bootp; request, otherwise client is configured with entered IP configuration.</entry></row> <row><entry>netmask</entry><entry>Netmask</entry></row> <row><entry>gateway</entry><entry>Gateway</entry></row> <row><entry>nameserver</entry><entry>Nameserver</entry></row> - <row><entry>insmod</entry><entry>Kernel modules to load.</entry></row> + <row><entry>insmod</entry><entry>Kernel modules to load</entry></row> <row> <entry>autoyast</entry> - <entry>Location of the the control file to be used for the - automatic installation, i.e - <emphasis>autoyast=http://192.168.2.1/profiles/</emphasis></entry> + <entry>Location of the the control file for automatic installation, i.e. <emphasis>autoyast=http://192.168.2.1/profiles/</emphasis></entry> </row> <row> @@ -294,13 +293,12 @@ </row> <row> <entry>instmode</entry> - <entry>Installation mode, i.e. nfs, http etc. (Not needed if + <entry>Installation mode, i.e. nfs, http etc. (not needed if <emphasis>install</emphasis> is set)</entry> </row> <row> <entry>y2confirm</entry> - <entry>even with <confirm>no</confirm> in the profile, the confirm proposal comes up. - This is available since SUSE Linux 10.1 / SLES10 + <entry>Even with <confirm>no</confirm> in the profile, the confirm proposal comes up (available since SUSE Linux 10.1/SLES10). </entry> </row> </tbody> @@ -311,36 +309,36 @@ <para> These variables and keywords will bring the system up to the point - where &yast2; can take over with the main control file. Currently, the + where &yast; can take over with the main control file. Currently, the source medium is automatically discovered, which in some cases makes it possible to initiate the auto-install process without giving any instructions to - linuxrc. + <command>linuxrc</command>. </para> <para> The traditional <command>linuxrc</command> configuration file (<filename>info</filename>) has the function of giving the client enough information about the installation server and - the location of the sources. In most cases this file is not needed; it is however - needed in special network environments where &dhcp; / &bootp; are not - used or when special kernel modules have to be loaded. + the location of the sources. In most cases, this file is not needed; it is however + needed in special network environments where &dhcp; and &bootp; are not + used or when special kernel modules have to be loaded. </para> <para> All linuxrc keywords can be passed to <command>linuxrc</command> using the kernel command - line. The command line can for example also be set when creating network boot-able + line. The command line can also be set when creating network bootable images or it can be passed to the kernel using a specially configured - &dhcp; server in combination with Etherboot or &pxe;. + &dhcp; server in combination with Etherboot or &pxe;.<remark>emap 2011-11-07:Obscure paragraph. What is set in the command line? And what is the 'it' that can be passed to the kernel? Probably not the command line itself.</remark> </para> <para> - The format of the special command line variable - <emphasis>autoyast</emphasis> can be used as described in table <quote><xref + The command line variable + <emphasis>autoyast</emphasis> can be used in the format described in table <quote><xref linkend="commandLineAutoYaST" endterm="commandLineAutoYaST.title"></xref></quote> </para> <table frame='top' id="commandLineAutoYaST"> - <title id="commandLineAutoYaST.title">Command line variables for AutoYaST</title> + <title id="commandLineAutoYaST.title">Command Line Variables for &ay;</title> <tgroup cols='2'> <thead> <row> @@ -350,27 +348,27 @@ </row> </thead> <tbody> - <row><entry>autoyast=default</entry><entry>Default auto-installation option </entry></row> + <row><entry>autoyast=default</entry><entry>Default auto-installation option.</entry></row> <row><entry>autoyast=file://<path></entry><entry>Looks for - control file in specified path (relative to source root + control file in specified path (relative to source root directory, i.e. <emphasis>file:///autoinst.xml</emphasis> if in - the top directory of a CD-ROM and you did an installation from CD)</entry></row> + the top directory of a CD-ROM and you did an installation from CD).</entry></row> <row> <entry> autoyast=device://<device>/<file></entry><entry>Looks - for control file on a storage device. (only device name needed - without full path, i.e. /dev/sda1 is wrong, instead use sda1). - Since openSUSE 11.2 (not SLES11) you can leave out the device to trigger - AutoYaST's search routine over all devices. (autoyast=device:///my.xml) + for control file on a storage device (only device name needed + without full path, i.e. /dev/sda1 is wrong, use only sda1 instead). + Since openSUSE 11.2 (not SLES11) you can omit specifying the device and trigger + &ay; to search all devices (autoyast=device:///my.xml). </entry> </row> <row> <entry>autoyast=floppy://<path></entry> - <entry>Looks for control file in the floppy (Useful when booting - from CD). Since SLES10 SP1 and later the fallback is looking on USB devices too</entry> + <entry>Looks for control file on a floppy (useful when booting + from CD). Since SLES10 SP1 and later the fallback is looking on USB devices.</entry><remark>emap 2011-11-07: Ah, here are USB devices. I think we could use more about this instead of floppies.</remark> </row> <row> <entry>autoyast=nfs://<server>/<path></entry> @@ -378,31 +376,31 @@ </row> <row> <entry>autoyast=http://[user:password@]<server>/<path></entry> - <entry>Retrieves the control file from a web server using the HTTP protocol.</entry> + <entry>Retrieves the control file from a web server using the HTTP protocol.</entry> </row> <row> <entry>autoyast=https://[user:password@]<server>/<path></entry> - <entry>Retrieves the control file from a web server using HTTPS (encrypted connection) protocol (possible since SL 10.1 and SLES10</entry> + <entry>Retrieves the control file from a web server using HTTPS (encrypted connection) protocol (possible since SL 10.1 and SLES10).</entry> </row> <row> <entry>autoyast=tftp://<server>/<path></entry> - <entry>Retrieve the control file with TFTP</entry> + <entry>Retrieve the control file via TFTP.</entry> </row> <row> <entry>autoyast=ftp://[user:password@]<server>/<path></entry> - <entry>Retrieve the control file with FTP</entry> + <entry>Retrieve the control file via FTP.</entry> </row> <row> <entry>autoyast=usb://<path> (since SLES10 SP1)</entry> - <entry>Retrieve the control file from USB devices (autoyast will search on all USB devices it can find)</entry> + <entry>Retrieve the control file from USB devices (&ay; will search all connected USB devices).</entry> </row> <row> <entry>autoyast=relurl://<path> (since openSUSE 11.0)</entry> - <entry>Retrieve the control file from the installation source (install=....)</entry> + <entry>Retrieve the control file from the installation source (install=....).</entry> </row> <row> <entry>autoyast=slp (since openSUSE 11.2, not SLES 11)</entry> - <entry>Query the location of the profile from an SLP server (service:autoyast:...). Since openSUSE 11.3 you can add a "description=" attribute so you can "translate" the URL into something more readable</entry> + <entry>Query the location of the profile from an SLP server (service:autoyast:...). Since openSUSE 11.3 you can add a "description=" attribute so you can "translate" the URL into something more readable.</entry> </row> <row> <entry>autoyast=cifs://<server>/<path> (since openSUSE 11.2, not SLES 11)</entry> @@ -410,49 +408,49 @@ </row> <row> <entry>autoyast=label://<label>/<path> (since openSUSE 11.3, not SLES 11)</entry> - <entry>Looks for control file on a device that has the label</entry> + <entry>Searches for control file on a device with the specified label</entry> </row> </tbody> </tgroup> </table> <para> Several scenarios for auto-installation are possible using different - types of infrastructure and source media. The simplest way is by using - the source media from the &company-suse; Box. In that case you have + types of infrastructure and source media. The simplest way is to use + the source media from &company-suse;. In that case you have either a DVD with all &company-suse; packages or a set of CD-ROMs. To initiate the auto-installation process however, the auto-installation command line variable should be entered at system boot-up and the control file should - be accessible to YaST2. The following list of scenarios explains how - the control file can be supplied and the setup needed for the - auto-installation process to be successful. + be accessible to &yast;. The following list of scenarios explains how + the control file can be supplied as well as the setup needed for the + auto-installation process to succeed. </para> <itemizedlist> <listitem> <para> - Using &company-suse; original CD-ROMs from &company-suse; Linux box: + Using original CD-ROMs from &company-suse;: </para> <para> To use the original CD-ROMs, you need a media with the control - file, the control file can reside on the following locations: + file. The control file can reside in the following locations: </para> <orderedlist> <listitem> <para> <emphasis>Floppy</emphasis>: Control file accessible via the - <emphasis>autoyast=floppy</emphasis> option. &yast2; also searches + <emphasis>autoyast=floppy</emphasis> option. &yast; also searches upon startup for a file named <filename>autoinst.xml</filename>. If such a file is found, YaST2 will switch into auto-installation mode even if no special command line variables were supplied. (See <quote><xref linkend="autoinstall.singlesystem" - endterm="autoinstall.singlesystem.title"></xref></quote> ) + endterm="autoinstall.singlesystem.title"></xref></quote>.) </para> </listitem> <listitem> <para> <emphasis>Network</emphasis>: Control file accessible via the <emphasis>autoyast=nfs://..</emphasis>, - <emphasis>autoyast=ftp://..</emphasis> + <emphasis>autoyast=ftp://..</emphasis>, <emphasis>autoyast=http://..</emphasis> or <emphasis>autoyast=tftp://..</emphasis> options. </para> @@ -471,22 +469,22 @@ original &company-suse; CD-ROMs. </para> <para> - Using CD-ROMs for autoinstallation, it is required to instruct the - installer to use the CD-ROM for installation and not try to find - the installation files on the network. This can be accomplished by - adding the <emphasis>instmode=cd</emphasis> option to the kernel - command line (this can be done by adding the option to the - isolinux.cfg file on the CD). + When using CD-ROMs for auto-installation, it is necessary to + instruct the installer to use the CD-ROM for installation and not + try to find the installation files on the network. This can be + accomplished by adding the <emphasis>instmode=cd</emphasis> option + to the kernel command line (this can be done by adding the option + to the isolinux.cfg file on the CD).<remark>emap 2011-11-07: A bit strange since an installation via network would have to be set up, first.</remark> </para> </listitem> <listitem> <para> - Using NFS and Floppy, Network or CD-ROM for system boot-up. + Using NFS and Floppy, Network or CD-ROM for system boot-up.<remark>emap 2011-11-07: Isn't this listitem already covered above? </remark> </para> <para> This option is the most important one due to the fact that installations of PC farms are normally done using NFS servers and other - network services like &bootp; / &dhcp; . The control file can reside in + network services like &bootp; and &dhcp;. The control file can reside in the following places: </para> <orderedlist> @@ -512,40 +510,40 @@ </itemizedlist> <note> - <title>Disabling network and DHCP</title> - <para>To disable network during installations where network is not - needed or not available, for example when auto-installing from - CD-ROMs use the linuxrc option <emphasis>netsetup</emphasis> to - set network configuration behavior. To disable network setup use - <emphasis>netsetup=0</emphasis> </para> + <title>Disabling Network and DHCP</title> + <para>To disable the network during installations where it is not + needed or unavailable, for example when auto-installing from + CD-ROMs, use the linuxrc option <emphasis>netsetup</emphasis> to + set the network configuration behavior. To disable network setup use + <emphasis>netsetup=0</emphasis>.</para> </note> <para> - If <emphasis>autoyast=default</emphasis> is defined, &yast2; will look + If <emphasis>autoyast=default</emphasis> is defined, &yast; will look for a file named <filename>autoinst.xml</filename> in the following three places: </para> <orderedlist> <listitem> <para> - The root directory of the floppy disk. + the root directory of the floppy disk, </para> </listitem> <listitem> <para> - The root directory of the installation medium. + the root directory of the installation medium, </para> </listitem> <listitem> <para> - The root directory of the initial ram disk used to boot the system. + the root directory of the initial RAM disk used to boot the system. </para> </listitem> </orderedlist> <para> - With all autoyast invocation options, excluding + With all &ay; invocation options, excluding <emphasis>default</emphasis>, it is possible to specify the location of the control file in the following ways: </para> @@ -561,7 +559,7 @@ </listitem> <listitem> <para> - Specify a directory where several control files are located + Specify a directory where several control files are located: </para> <screen> autoyast=http://192.168.1.1/control-files/ @@ -573,7 +571,7 @@ </listitem> </orderedlist> <para> - If only the path prefix variable is defined, &yast2; will fetch the + If only the path prefix variable is defined, &yast; will fetch the control file from the specified location in the following way: </para> <orderedlist numeration="arabic"> @@ -585,10 +583,10 @@ </listitem> <listitem> <para> - If that file is not found, it will remove one hex digit and try - again. This action is repeated till the file with the correct name - is found. Ultimately, it will try looking for a file with the MAC - address of the clients as the file name (mac should have the + If this file is not found, &yast; will remove one hex digit and try + again. This action is repeated until the file with the correct name + is found. Ultimately, it will try looking for a file with the MAC + address of the client as the file name (mac should have the following syntax: <emphasis>0080C8F6484C</emphasis>) and if not found a file named <filename>default</filename> (in lower case). @@ -636,14 +634,11 @@ Auto-installing a Single System </title> <para> - The easiest way to auto-install a system without any network connection - is by using the standard CD-ROMs that come in the &company-suse; Linux box. Using the - CD-ROMs in combination with a floppy disk lets you getting started with - &autoyast2; very fast and without spending much time configuring - installation server and network environments. + The easiest way to auto-install a system without any network + connection is to use the original &company-suse; CD-ROMs and a floppy + disk. You do o need to set up an installation server nor the network + environment. </para> - - <para> Create the control file and name it <filename>autoinst.xml</filename>. Copy the file @@ -654,15 +649,15 @@ mcopy autoinst.xml a: </screen> - </section> + </section><remark>emap 2011-11-07: This section should be merged with the previous one on auto-install with the original CDs and floppy, with all redundant information dropped.</remark> <section> - <title>Combining linuxrc <emphasis>info</emphasis> file with &yast2; control file</title> + <title>Combining linuxrc <emphasis>info</emphasis> file with &yast; control file</title> <para> If you choose to pass information to <emphasis>linuxrc</emphasis> using the <emphasis>info</emphasis> file, it is possible to integrate the - keywords in the XML control file. In the case the file has to be + keywords in the XML control file. In this case the file has to be accessible to linuxrc and has to be named <emphasis>info</emphasis>. </para> <para> @@ -707,10 +702,10 @@ </screen> </example> <para> - Note that the autoyast keyword must point to the same file, i.e. if it + Note that the "autoyast" keyword must point to the same file. If it is on a floppy, then the protocol <emphasis>floppy</emphasis> has to be - used. In other cases where the <emphasis>info</emphasis> file is stored - in the initial ram-disk, the <emphasis>file</emphasis> option has to be used. + used. If the <emphasis>info</emphasis> file is stored + in the initial RAM disk, the <emphasis>file</emphasis> option has to be used. </para> </section> </section> @@ -719,58 +714,55 @@ System Configuration </title> <para> - The system configuration during auto-installation can be seen as the - most important part of the whole process. Customizing a system to your - environment needs is what makes an auto-installation system attractive, - not the installation part. + The system configuration during auto-installation is the most important + part of the whole process. Customizing a system according to your + environment and needs is what makes an auto-installation system + attractive, not the installation part.<remark>emap 2011-11-07: Last sentence doesn't make sense. A system can be customized just as well via an interactive YaST installation.</remark> </para> <para> As you have seen in the previous chapters, almost anything can be configured automatically on the target system. In addition to the - pre-defined directives, you can always use post-scripts to change other - things in the system. Additionally you can change any system variables and - if required, copy complete configuration files into the target system. + pre-defined directives, you can always use post-scripts to change other + things in the system. Additionally you can change any system variables, + and if required, copy complete configuration files into the target + system. </para> <section> <title> Post-Install and System Configuration </title> <para> - The Post-Installation and the System Configuration are initiated directly after the last - package is installed in the target system and is continued after the - system has booted for the first time. + The post-installation and system configuration are initiated directly + after the last package is installed on the target system and continue + after the system has booted for the first time. </para> <para> - Before the system is booted for the first time, &yast2; writes all data - collected during installation into the system and finally it writes the - boot loader in the specified location. In addition to these regular - tasks, which are also done when performing a regular installation, YaST2 - executes the <emphasis>chroot-scripts</emphasis> as specified in the - control file. Note that these scripts are executed while the system is - still not mounted. + Before the system is booted for the first time, &ay; writes all data + collected during installation and writes the boot loader in the + specified location. In addition to these regular tasks, &ay; executes + the <emphasis>chroot-scripts</emphasis> as specified in the control + file. Note that these scripts are executed while the system is not yet + mounted. </para> <para> If a different kernel than the default is installed, a hard reboot will be required. A hard reboot can also be forced during auto-installation, - independent of the installed kernel. This can be accomplished using the + independent of the installed kernel. Use the <emphasis>reboot</emphasis> property of the - <emphasis>general</emphasis> resource. (See <link - linkend="CreateProfile.General">General Options</link>) + <emphasis>general</emphasis> resource (see <link + linkend="CreateProfile.General">General Options</link>). </para> </section> <section> <title>System Customization</title> <para> Most of the system customization is done in the second stage of the - installation. &yast2; provides most of the important resources needed to - bring up a system to a usable , general state. However, you may have - other requirements for the installed system. If the required - customizations can't be done using &yast2; resources, then the - post-install scripts can be used to accomplish this task. + installation. If you require customizations that cannot be done using + &ay; resources, use post-install scripts for further modifications. </para> <para> You can define an unlimited number of custom scripts in the control - file either by editing the control file or by using the configuration + file, either by editing the control file or by using the configuration system. </para> </section> -- To unsubscribe, e-mail: yast-commit+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-commit+help(a)opensuse.org

1 0

[yast-commit] r66731 - in /branches/SuSE-Code-11-SP2-Branch/qt-pkg: VERSION.cmake package/yast2-qt-pkg.changes src/YQPkgDependenciesView.cc
by tgoettlicher＠svn2.opensuse.org 07 Nov '11

07 Nov '11

Author: tgoettlicher Date: Mon Nov 7 10:17:32 2011 New Revision: 66731 URL: http://svn.opensuse.org/viewcvs/yast?rev=66731&view=rev Log: fixed typo Modified: branches/SuSE-Code-11-SP2-Branch/qt-pkg/VERSION.cmake branches/SuSE-Code-11-SP2-Branch/qt-pkg/package/yast2-qt-pkg.changes branches/SuSE-Code-11-SP2-Branch/qt-pkg/src/YQPkgDependenciesView.cc Modified: branches/SuSE-Code-11-SP2-Branch/qt-pkg/VERSION.cmake URL: http://svn.opensuse.org/viewcvs/yast/branches/SuSE-Code-11-SP2-Branch/qt-pk… ============================================================================== --- branches/SuSE-Code-11-SP2-Branch/qt-pkg/VERSION.cmake (original) +++ branches/SuSE-Code-11-SP2-Branch/qt-pkg/VERSION.cmake Mon Nov 7 10:17:32 2011 @@ -1,3 +1,3 @@ SET(VERSION_MAJOR "2") SET(VERSION_MINOR "21") -SET(VERSION_PATCH "2") +SET(VERSION_PATCH "3") Modified: branches/SuSE-Code-11-SP2-Branch/qt-pkg/package/yast2-qt-pkg.changes URL: http://svn.opensuse.org/viewcvs/yast/branches/SuSE-Code-11-SP2-Branch/qt-pk… ============================================================================== --- branches/SuSE-Code-11-SP2-Branch/qt-pkg/package/yast2-qt-pkg.changes (original) +++ branches/SuSE-Code-11-SP2-Branch/qt-pkg/package/yast2-qt-pkg.changes Mon Nov 7 10:17:32 2011 @@ -1,4 +1,10 @@ ------------------------------------------------------------------- +Mon Nov 7 10:15:47 CET 2011 - tgoettlicher(a)suse.de + +- Fixed typo (bnc #727521) +- 2.21.3 + +------------------------------------------------------------------- Wed Apr 27 17:05:04 CEST 2011 - tgoettlicher(a)suse.de - Added translation markers for RPM fields (bnc #686502) Modified: branches/SuSE-Code-11-SP2-Branch/qt-pkg/src/YQPkgDependenciesView.cc URL: http://svn.opensuse.org/viewcvs/yast/branches/SuSE-Code-11-SP2-Branch/qt-pk… ============================================================================== --- branches/SuSE-Code-11-SP2-Branch/qt-pkg/src/YQPkgDependenciesView.cc (original) +++ branches/SuSE-Code-11-SP2-Branch/qt-pkg/src/YQPkgDependenciesView.cc Mon Nov 7 10:17:32 2011 @@ -110,7 +110,7 @@ row( _("Obsoletes:"), pkg->dep( zypp::Dep::OBSOLETES ) ) + row( _("Recommends:"), pkg->dep( zypp::Dep::RECOMMENDS ) ) + row( _("Suggests:"), pkg->dep( zypp::Dep::SUGGESTS ) ) + - row( _("Enances:"), pkg->dep( zypp::Dep::ENHANCES ) ) + + row( _("Enhances:"), pkg->dep( zypp::Dep::ENHANCES ) ) + row( _("Supplements:"), pkg->dep( zypp::Dep::SUPPLEMENTS ) ) ); @@ -140,7 +140,7 @@ row( _("Obsoletes:"), p1->dep( zypp::Dep::OBSOLETES ), p2->dep( zypp::Dep::OBSOLETES ) ) + row( _("Recommends:"), p1->dep( zypp::Dep::RECOMMENDS ), p2->dep( zypp::Dep::RECOMMENDS ) ) + row( _("Suggests:"), p1->dep( zypp::Dep::SUGGESTS ), p2->dep( zypp::Dep::SUGGESTS ) ) + - row( _("Enances:"), p1->dep( zypp::Dep::ENHANCES ), p2->dep( zypp::Dep::ENHANCES ) ) + + row( _("Enhances:"), p1->dep( zypp::Dep::ENHANCES ), p2->dep( zypp::Dep::ENHANCES ) ) + row( _("Supplements:"), p1->dep( zypp::Dep::SUPPLEMENTS ), p2->dep( zypp::Dep::SUPPLEMENTS ) ) ); -- To unsubscribe, e-mail: yast-commit+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-commit+help(a)opensuse.org

1 0

[yast-commit] r66730 - /trunk/qt-pkg/src/YQPackageSelector.cc
by tgoettlicher＠svn2.opensuse.org 07 Nov '11

07 Nov '11

Author: tgoettlicher Date: Mon Nov 7 09:20:44 2011 New Revision: 66730 URL: http://svn.opensuse.org/viewcvs/yast?rev=66730&view=rev Log: minor fix Modified: trunk/qt-pkg/src/YQPackageSelector.cc Modified: trunk/qt-pkg/src/YQPackageSelector.cc URL: http://svn.opensuse.org/viewcvs/yast/trunk/qt-pkg/src/YQPackageSelector.cc?… ============================================================================== --- trunk/qt-pkg/src/YQPackageSelector.cc (original) +++ trunk/qt-pkg/src/YQPackageSelector.cc Mon Nov 7 09:20:44 2011 @@ -1720,7 +1720,7 @@ _ignoreAlreadyRecommendAction->setChecked( settings.value("Options/IgnoreRecommendedPackagesForAlreadyInstalledPackages", - false )); + false ).toBool() ); pkgIgnoreAlreadyRecommendedChanged(_ignoreAlreadyRecommendAction->isChecked()); -- To unsubscribe, e-mail: yast-commit+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-commit+help(a)opensuse.org

1 0

[yast-commit] r66729 - /trunk/autoinstallation/doc/xml/KDumpSection.xml
by emap＠svn2.opensuse.org 06 Nov '11

06 Nov '11

Author: emap Date: Sun Nov 6 18:26:08 2011 New Revision: 66729 URL: http://svn.opensuse.org/viewcvs/yast?rev=66729&view=rev Log: edited by emap Modified: trunk/autoinstallation/doc/xml/KDumpSection.xml Modified: trunk/autoinstallation/doc/xml/KDumpSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/KDumpSe… ============================================================================== --- trunk/autoinstallation/doc/xml/KDumpSection.xml (original) +++ trunk/autoinstallation/doc/xml/KDumpSection.xml Sun Nov 6 18:26:08 2011 @@ -25,36 +25,34 @@ </title> <note> - <title>FIXME Title</title> + <title>FIXME Title</title><remark>emap 2011-11-06: Add title, maybe: Availability?</remark> <para> This feature is only available since SLES 11 (not openSUSE 11.1). It is not available - on the <emphasis>zSeries</emphasis> (<emphasis>s390x</emphasis>) architecture! + on the <emphasis>zSeries</emphasis> (<emphasis>s390x</emphasis>) architecture. </para> </note> <para> With kdump the system is able to create crashdump files if the whole system (i.e., the - kernel) crashes. That crash dump files contain the memory contents while the system crashed. - Such core files can be analyzed later by the support or a (kernel) developer to find the - reason why the system crashed. It's mostly useful for servers where you cannot - easily reproduce such crashes on another system and where it's important that the - problem gets fixed. + kernel) crashes. Crash dump files contain the memory contents while the system crashed. + Such core files can be analyzed later by support or a (kernel) developer to find the + reason for the system crash. Kdump is mostly useful for servers where you cannot + easily reproduce such crashes but it is important to get the + problem fixed. </para> <para> - The only downside of enabling kdump is that this costs you between 64 MiB and - 128 MiB of System RAM (on "normal" sized systems) that needs to be reserved to - be used by kdump in the case the system crashes and the dump needs to be generated. + The only downside: enabling kdump costs you between 64 MiB and + 128 MiB of system RAM (on "normal" sized systems), reserved for kdump in case the system crashes and the dump needs to be generated. </para> - <para>This section only describes how to setup kdump with &autoyast;. It does not describe - how kdump works in general and also does not describe each small detail. Refer to - the kdump(7) manual page which is in the package named <emphasis>kdump</emphasis> or to - the <ulink url="http://en.opensuse.org/Kdump">openSUSE Kdump documentation</ulink>. + <para>This section only describes how to set up kdump with &ay;. It does not describe + how kdump works. For details, refer to + the kdump(7) manual page, contained in the <emphasis>kdump</emphasis> package, or to <ulink url="http://en.opensuse.org/Kdump">openSUSE Kdump documentation</ulink>. </para> <para> - At first, let's present an overall example for the kdump configuration: + The following example shows a general kdump configuration. </para> &example.kdump; @@ -64,36 +62,37 @@ <title>Memory Reservation</title> <para> - As already mentioned above, it's necessary to reserve some memory at bootup for - kdump. Because that memory must be reserved very early during the boot process, - the configuration is done via a kernel command line parameter called - <literal>crashkernel</literal>. That memory will be used to load a second kernel - in that memory that will be executed without rebooting if the first kernel - crashes. That kernel also has a special initrd which contains all programs - that are necessary to save the dump to network or disk, send the notification - email and finally reboot. + The first step is to reserve memory for kdump at boot-up. Because the + memory must be reserved very early during the boot process, the + configuration is done via a kernel command line parameter called + <literal>crashkernel</literal>. The reserved memory will be used to + load a second kernel which will be executed without rebooting if the + first kernel crashes. This second kernel has a special initrd, which + contains all programs necessary to save the dump over the network or + to disk, send a notification e-mail, and finally reboot. </para> <para> - You can enable or disable that the <literal>crashkernel</literal> parameter is - written for the default boot kernel with the <literal>add_crash_kernel</literal> - tag and you can specify the value of the <literal>crashkernel</literal> parameter - using the <literal>crash_kernel</literal> tag. + Enable or disable that the <literal>crashkernel</literal> + parameter is written for the default boot kernel with the + <literal>add_crash_kernel</literal> tag. You can specify the value + of the <literal>crashkernel</literal> parameter using the + <literal>crash_kernel</literal> tag.<remark>emap 2011-11-06: Does this para make sense? Seems a bit obscure.</remark> </para> <para> - For the memory reservation there are two things to specify: The <emphasis>amount</emphasis> - of reserved memory (such as <literal>64M</literal> to reserve 64 MiB of memory from + To reserve memory for kdump, specify the <emphasis>amount</emphasis> + (such as <literal>64M</literal> to reserve 64 MiB of memory from the RAM) and the <emphasis>offset</emphasis>. The syntax is - <literal>crashkernel=AMOUNT@OFFSET</literal>. Luckily the kernel is able to auto-detect the - right offset for you nowadays (with the exception of the Xen hypervisor where you have to - specify <emphasis>16M</emphasis> as offset), so you don't have to worry about that too much. - You can just specify <literal><crash_kernel>crashkernel=64M</crash_kernel></literal> + <literal>crashkernel=AMOUNT@OFFSET</literal>. The kernel can auto-detect the + right offset (with the exception of the Xen hypervisor, where you have to + specify <emphasis>16M</emphasis> as offset). + Simply specify <literal><crash_kernel>crashkernel=64M</crash_kernel></literal> and the right thing will happen. </para> <para> - For the <emphasis>amount</emphasis> of memory, following values are recommended: + For the <emphasis>amount</emphasis> of memory, the following values are recommended: </para> <table frame="top"> @@ -140,32 +139,31 @@ </table> <para> - To make things even more complicated, there's a so-called <emphasis>extended - command line syntax</emphasis> where you can specify the amount of reserved - memory dependent of the System RAM. That is good if you share one &autoyast; - profile for multiple installations or when you often remove or install memory + You can also use the <emphasis>extended + command line syntax</emphasis> to specify the amount of reserved + memory depending on the System RAM. That is useful if you share one &ay; + profile for multiple installations or if you often remove or install memory on one machine. The syntax is: </para> <screen>BEGIN_RANGE_1-END_RANGE_1:AMOUNT_1,BEGIN_RANGE_2-END_RANGE_2:AMOUNT_2@OFFSET</screen> <para> - In that syntax <literal>BEGIN_RANGE_1</literal> is the start of the first + <literal>BEGIN_RANGE_1</literal> is the start of the first memory range (for example: <literal>0M</literal>) and <literal>END_RANGE_1</literal> - is the end of the first memory range (and can be empty in case "infinity" should - be assumed) and so on. So for example + is the end of the first memory range (can be empty in case "infinity" should + be assumed) and so on. For example <literal>256M-2G:64M,2G-:128M</literal> means to reserve 64 MiB of crashkernel - memory when the system has between 256 MiB and 2 GiB RAM and to reserve - 128 MiB of crashkernel memory when the system has above 2 GiB RAM. + memory if the system has between 256 MiB and 2 GiB RAM and to reserve + 128 MiB of crashkernel memory if the system has more than 2 GiB RAM. </para> <para> - The following table contains the settings that are necessary for the - memory reservation: + The following table shows the settings necessary to reserve memory: </para> <table frame='top'> - <title>XML representation of the memory reservation settings</title> + <title>XML Representation of the Memory Reservation Settings</title> <tgroup cols="3"> <thead> <row> @@ -177,13 +175,13 @@ <tbody> <row> <entry>add_crash_kernel</entry> - <entry><para>If the memory should be reserved, that basically enables or disables kdump. + <entry><para>Set to "true" if memory should be reserved and kdump enabled. </para><screen><add_crash_kernel config:type="boolean">true</add_crash_kernel></screen></entry> <entry>required</entry> </row> <row> <entry>crash_kernel</entry> - <entry><para>The syntax of the crashkernel command line as discussed above. + <entry><para>Use the syntax of the crashkernel command line as discussed above. </para><screen><crash_kernel>256M:64M</crash_kernel></screen></entry> <entry>required</entry> </row> @@ -206,24 +204,24 @@ </title> <para> - The element <literal>KDUMP_SAVEDIR</literal> holds an URL to where the dump - is saved. Following methods are possible: + The element <literal>KDUMP_SAVEDIR</literal> specifies the URL to + where the dump is saved. The following methods are possible: </para> <itemizedlist mark='opencircle'> <listitem> <para> - <literal>file</literal> to save to the local disk + <literal>file</literal> to save to the local disk, </para> </listitem> <listitem> <para> - <literal>ftp</literal> to save to an FTP server (without encryption) + <literal>ftp</literal> to save to an FTP server (without encryption), </para> </listitem> <listitem> <para> - <literal>sftp</literal> to save to an SSH2 SFTP server + <literal>sftp</literal> to save to an SSH2 SFTP server, </para> </listitem> <listitem> @@ -242,24 +240,25 @@ For details see the kdump(5) manual page. Two examples are: <literal>file:///var/crash</literal> (which is the default location according to FHS) and <literal>ftp://user:password@host:port/incoming/dumps</literal>. - Below that directory, a directory name that contains a time stamp will be created - in which the dumps are saved. + A subdirectory, with the time stamp contained in the name, will be created and the dumps saved there. </para> <para> - When the dump is saved to the local disk, <literal>KDUMP_KEEP_OLD_DUMPS</literal> - can be used to delete old dumps automatically. This setting takes a number that - specifies how much old dumps should be kept. If the partition has less than - <literal>KDUMP_FREE_DISK_SIZE</literal> megabytes free disk space after saving the - dump, the dump is not copied at all. + When the dump is saved to the local disk, + <literal>KDUMP_KEEP_OLD_DUMPS</literal> can be used to delete old + dumps automatically. Set it to the number of old dumps that should + be kept. If the target partition would end up with less free disk + space than specified in <literal>KDUMP_FREE_DISK_SIZE</literal>, the + dump is not saved.<remark>emap 2011-11-06: Replaced 'copied' with + 'saved'.</remark> </para> <para> - If you would not like only to save the dump but also the whole kernel and - (if installed) the debug information of the kernel to that directory to have - everything you need (except all kernel modules and the debugging information - of all kernel modules) to analyze the dump in one directory, you can set + If you want to save the whole kernel and the debug + information (if installed) to the same directory, set <literal>KDUMP_COPY_KERNEL</literal> to <literal>true</literal>. + You'll have everything you need to analyze the dump in one directory + (except kernel modules and their debugging information). </para> </section>  @@ -270,25 +269,24 @@ </title> <para> - The size of kernel dumps is uncompressed and unfiltered as large as your system has RAM. - To get smaller files (for example, to send it to support), you can compress the whole - dump file afterwards. However, the drawback is that the dump has to be uncompressed - afterwards before opening, so the disk space needs to be there in any case. + The kernel dump is uncompressed and unfiltered. It can get as + large as your system RAM. To get smaller files, compress the dump file afterwards. The dump has to be + decompressed before opening.<remark>emap 2011-11-06: Can we delete this? If the disk space is really smaller than the RAM, it's probably not a smart idea to save the dump on the disk.</remark> </para> <para> - To use page compression which compresses every page and allows dynamic decompression + To use page compression, which compresses every page and allows dynamic decompression with the crash(8) debugging tool, set <literal>KDUMP_DUMPFORMAT</literal> to - <literal>compressed</literal> (which is actually the default). + <literal>compressed</literal> (default). </para> <para> - To filter the dump, you have to set the <literal>KDUMP_DUMPLEVEL</literal>. Then not all - memory is saved to disk but only memory that does not fulfill some criteria. I.e. you - may want to leave out pages that are completely filled by zeroes as they don't - contain any useful information. 0 produces a full dump and 31 is the smallest dump. - The manual page kdump(5) and makedumpfile(8) contain a table that lists for - each value which pages will be saved. + You may not want to save all memory pages, for example those filled + with zeroes. To filter the dump, set the + <literal>KDUMP_DUMPLEVEL</literal>. 0 produces a full dump and 31 is + the smallest dump. The manual pages kdump(5) and makedumpfile(8) + list for each value which pages will be saved. </para> </section> @@ -299,7 +297,7 @@ Summary </title> <table frame='top'> - <title>XML representation of the dump target settings</title> + <title>XML Representation of the Dump Target Settings</title> <tgroup cols="3"> <thead> <row> @@ -317,7 +315,7 @@ </row> <row> <entry>KDUMP_COPY_KERNEL</entry> - <entry><para>If not only the dump itself should be saved to <literal>KDUMP_SAVEDIR</literal> but + <entry><para>Set to "true", if not only the dump should be saved to <literal>KDUMP_SAVEDIR</literal> but also the kernel and its debugging information (if installed). </para><screen><KDUMP_COPY_KERNEL>false</KDUMP_COPY_KERNEL></screen></entry> <entry>optional</entry> @@ -325,8 +323,9 @@ <row> <entry>KDUMP_FREE_DISK_SIZE</entry> <entry> - <para>The number of megabytes that should always be free after saving the dump. If that - space would be below that value, the dump will not be copied. + <para>Disk space in megabytes that must remain free after + saving the dump. If not enough space is available to write the dump and keep the required disk space free, the + dump will not be saved. </para><screen><KDUMP_FREE_DISK_SIZE>64</KDUMP_FREE_DISK_SIZE></screen></entry> <entry>optional</entry> </row> @@ -334,8 +333,7 @@ <entry>KDUMP_KEEP_OLD_DUMPS</entry> <entry> <para>The number of dumps that are kept (i.e., not deleted) if <literal>KDUMP_SAVEDIR</literal> - points to a local directory. Specify 0 if you don't want to delete dumps at all and - specify -1 if all dumps (except the one that is just saved) should be deleted. + points to a local directory. Specify 0 if you do not want any dumps to be automatically deleted, specify -1 if all dumps except the current one should be deleted. </para><screen><KDUMP_KEEP_OLD_DUMPS>4</KDUMP_KEEP_OLD_DUMPS></screen></entry> <entry>optional</entry> </row> @@ -354,36 +352,29 @@ </title> <para> - It's useful to get notified via email that a machine has crashed and a dump has been - saved. That way you can for example setup a dump server in a company and trigger - some actions by that email automatically like calling the administrator from home - to check if everything runs again. + Configure email notification, if you want to be informed when a machine crashes and a dump is saved. </para> <para> - Because the dump is saved in a special initrd environment, we cannot use a local - mail server just to send that notification email. However, it's better to send - that email in the initrd just because it's more likely that we have a working network - connection here (which we need in the netdump case to save the dump away anyway) - compared that the server comes up again and everything is working. + Because kdump runs in the initrd, a local + mail server cannot send the notification email. An SMTP server needs to be specified (see below).<remark>emap 2011-11-06: Removed major section that didn't make sense. Please check if my changes here are correct.</remark> </para> - <para>You have to provide at least exactly one address in - <literal>KDUMP_NOTIFICATION_TO</literal> and zero, one or more addresses - in <literal>KDUMP_NOTIFICATION_CC</literal>. Please note that you can only - specify the address here, not a real name or some other fancy stuff. + <para>You have to provide exactly one address in + <literal>KDUMP_NOTIFICATION_TO</literal>. More addresses can be specified in + in <literal>KDUMP_NOTIFICATION_CC</literal>. Only + use email addresses in both cases, not a real name. </para> <para> - To actually send the email, we need <literal>KDUMP_SMTP_SERVER</literal> and + Specify <literal>KDUMP_SMTP_SERVER</literal> and (if the server needs authentication) <literal>KDUMP_SMTP_USER</literal> and - <literal>KDUMP_SMTP_PASSWORD</literal>. Please note that TSL or SSL are not supported. - That may be added in future. + <literal>KDUMP_SMTP_PASSWORD</literal>. Support for TSL or SSL is not available but may be added in the future. </para>  <table frame='top'> - <title>XML representation of the email notification settings</title> + <title>XML Representation of the Email Notification Settings</title> <tgroup cols="3"> <thead> <row> @@ -397,32 +388,30 @@ <entry>KDUMP_NOTIFICATION_TO</entry> <entry> <para> - Exactly one email address (and only an address) to which the mail + Exactly one email address to which the email should be sent. Additional recipients can be specified in <literal>KDUMP_NOTIFICATION_CC</literal>. - </para><screen><KDUMP_NOTIFICATION_TO>bwalle(a)suse.de</KDUMP_NOTIFICATION_TO></screen></entry> - <entry>optional (email notification is disabled if empty)</entry> + </para><screen><KDUMP_NOTIFICATION_TO>bwalle(a)suse.de</KDUMP_NOTIFICATION_TO></screen></entry><remark>emap 2011-11-06: Do we really want to use an actual email address here?</remark> + <entry>optional (notification disabled if empty)</entry> </row> <row> <entry>KDUMP_NOTIFICATION_CC</entry> - <entry><para>Zero, one or more recipients that are in the Cc line of the notification mail. + <entry><para>Zero, one or more recipients that are in the cc line of the notification email. </para><screen><KDUMP_NOTIFICATION_CC>spam(a)suse.de devnull(a)suse.de</KDUMP_NOTIFICATION_CC></screen></entry> <entry>optional</entry> </row> <row> <entry>KDUMP_SMTP_SERVER</entry> <entry><para> - Host name of the SMTP server that will be used for the mail delivery. Please note - that the SMTP authentication is supported (see <literal>KDUMP_SMTP_USER</literal> - and <literal>KDUMP_SMTP_PASSWORD</literal>) but TSL and SSL are <emphasis>not</emphasis> - supported. + Host name of the SMTP server used for mail delivery. SMTP authentication is supported (see <literal>KDUMP_SMTP_USER</literal> + and <literal>KDUMP_SMTP_PASSWORD</literal>) but TSL and SSL are <emphasis>not</emphasis>. </para><screen><KDUMP_SMTP_SERVER>email.suse.de</KDUMP_SMTP_SERVER></screen></entry> - <entry>optional (email notification is disabled if empty)</entry> + <entry>optional (notification disabled if empty)</entry> </row> <row> <entry>KDUMP_SMTP_USER</entry> <entry><para> - User name that is used together with <literal>KDUMP_SMTP_PASSWORD</literal> + User name used together with <literal>KDUMP_SMTP_PASSWORD</literal> for SMTP authentication. </para><screen><KDUMP_SMTP_USER>bwalle</KDUMP_SMTP_USER></screen></entry> <entry>optional</entry> @@ -430,7 +419,7 @@ <row> <entry>KDUMP_SMTP_PASSWORD</entry> <entry><para> - Password that is used together with <literal>KDUMP_SMTP_USER</literal> + Password used together with <literal>KDUMP_SMTP_USER</literal> for SMTP authentication. </para><screen><KDUMP_SMTP_PASSWORD>geheim</KDUMP_SMTP_PASSWORD></screen></entry> <entry>optional</entry> @@ -444,7 +433,7 @@  <section id="CreateProfile.kdump.kernel"> <title> - Kdump kernel settings + Kdump Kernel Settings </title> <para> @@ -452,7 +441,7 @@ If you don't want to use the auto-detection mechanism to find out which kernel is used (see the kdump(5) manual page that describes the algorithm which is used to find the kernel), you can specify the version of a custom kernel - in <literal>KDUMP_KERNELVER</literal>. If you set that to + in <literal>KDUMP_KERNELVER</literal>. If you set it to <literal>foo</literal>, then the kernel located in <filename>/boot/vmlinuz-foo</filename> or <filename>/boot/vmlinux-foo</filename> (in that order on platforms that have a <filename>vmlinuz</filename> file) @@ -460,10 +449,9 @@ </para> <para> - You can even specify the command line which will be used to boot the kdump kernel. - Normally the boot command line is used minus some settings that hurt in the - kdump case (like the <literal>crashkernel</literal> parameter itself) plus - some settings that are needed in the kdump case (see the manual page kdump(5)). + You can specify the command line used to boot the kdump kernel. + Normally the boot command line is used minus some settings that make no sense with kdump (like the <literal>crashkernel</literal> parameter) plus + some settings needed by kdump (see the manual page kdump(5)). If you just want some additional parameters like a overwritten console setting then use <literal>KDUMP_COMMANDLINE_APPEND</literal>. If you know what you're doing and you want to specify the whole command line, set <literal>KDUMP_COMMANDLINE</literal>. @@ -471,7 +459,7 @@  <table frame='top'> - <title>XML representation of the kernel settings</title> + <title>XML Representation of the Kernel Settings</title> <tgroup cols="3"> <thead> <row> @@ -483,7 +471,7 @@ <tbody> <row> <entry>KDUMP_KERNELVER</entry> - <entry><para>Version string for the kernel that will be used for kdump. Leave it + <entry><para>Version string for the kernel used for kdump. Leave it empty to use the auto-detection mechanism (strongly recommended). </para><screen><KDUMP_KERNELVER>2.6.27-default</KDUMP_KERNELVER></screen></entry> <entry>optional (auto-detection if empty)</entry> @@ -498,10 +486,9 @@ <entry>KDUMP_COMMANDLINE</entry> <entry><para> Overwrite the automatically generated kdump command line. Use with care. - Normally <literal>KDUMP_COMMANDLINE_APPEND</literal> is the setting you're - looking for. + In most cases, <literal>KDUMP_COMMANDLINE_APPEND</literal> should suffice. </para><screen><KDUMP_COMMANDLINE_APPEND>root=/dev/sda5 maxcpus=1 irqpoll</KDUMP_COMMANDLINE></screen></entry> - <entry>optional (email notification is disabled if empty)</entry> + <entry>optional</entry><remark>emap 2011-11-06: I don't think the email stuff belongs here.</remark> </row> </tbody> </tgroup> @@ -512,12 +499,12 @@  <section id="CreateProfile.kdump.expert"> <title> - Expert settings + Expert Settings </title>  <table frame='top'> - <title>XML representation of the expert settings</title> + <title>XML Representation of the Expert Settings</title> <tgroup cols="3"> <thead> <row> @@ -537,7 +524,7 @@ </row> <row> <entry>KDUMP_VERBOSE</entry> - <entry><para>Bitmask that specifies how to verbose the kdump process should be. + <entry><para>Bitmask that specifies how verbose the kdump process should be. Read kdump(5) for details. </para><screen><KDUMP_VERBOSE>3</KDUMP_VERBOSE></screen></entry> <entry>optional</entry> -- To unsubscribe, e-mail: yast-commit+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-commit+help(a)opensuse.org

1 0

[yast-commit] r66728 - /trunk/autoinstallation/doc/xml/SoundSection.xml
by emap＠svn2.opensuse.org 06 Nov '11

06 Nov '11

Author: emap Date: Sun Nov 6 15:52:18 2011 New Revision: 66728 URL: http://svn.opensuse.org/viewcvs/yast?rev=66728&view=rev Log: edited by emap Modified: trunk/autoinstallation/doc/xml/SoundSection.xml Modified: trunk/autoinstallation/doc/xml/SoundSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/SoundSe… ============================================================================== --- trunk/autoinstallation/doc/xml/SoundSection.xml (original) +++ trunk/autoinstallation/doc/xml/SoundSection.xml Sun Nov 6 15:52:18 2011 @@ -22,8 +22,8 @@ Sound devices </title> <para> - An example of sound configuration created using the configuration - system is shown below. + An example of the sound configuration created using the configuration + system is shown below.<remark>emap 2011-11-06: Should system read section? A little cryptic.</remark> </para> &example.sound; </section> -- To unsubscribe, e-mail: yast-commit+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-commit+help(a)opensuse.org

1 0

[yast-commit] r66727 - /trunk/autoinstallation/doc/xml/PrinterSection.xml
by emap＠svn2.opensuse.org 06 Nov '11

06 Nov '11

Author: emap Date: Sun Nov 6 15:49:17 2011 New Revision: 66727 URL: http://svn.opensuse.org/viewcvs/yast?rev=66727&view=rev Log: edited by emap Modified: trunk/autoinstallation/doc/xml/PrinterSection.xml Modified: trunk/autoinstallation/doc/xml/PrinterSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/Printer… ============================================================================== --- trunk/autoinstallation/doc/xml/PrinterSection.xml (original) +++ trunk/autoinstallation/doc/xml/PrinterSection.xml Sun Nov 6 15:49:17 2011 @@ -22,10 +22,10 @@ Printer </title> <para> -The YaST printer module was made anew from scratch for openSUSE 11.1 and SUSE Linux Enterprise Server/Desktop 11. Currently the AutoYaST support for printing is limited to basic settings how the CUPS printing system is used on a client workstation to print via network. +The &yast; printer module has been rewritten from scratch for openSUSE 11.1 and SUSE Linux Enterprise Server/Desktop 11. Currently, &ay; support for printing is limited to basic settings for how the CUPS printing system is used on a client workstation to print via network. </para> <para> -Currently there is no AutoYaST support to set up local print queues. In particular when a USB printer is connected to a client workstation it is no longer possible to have a predefined configuration because USB printers are no longer accessed via a generic USB device node like "/dev/usb/lp0" but via a model specific device URI like "usb://ACME/FunPrinter?serial=1a2b3c". There is a serial number included so that a USB printer device URI works only for one particular device. Usually it is not possible to know the correct USB device URI in advance because it is determined by the CUPS backend "usb" during runtime when the particular device is connected depending on the actual values which the printer reports via the USB. +There is no &ay; support for setting up local print queues. In particular, when a USB printer is connected to a client workstation, it is no longer possible to have a predefined configuration, because USB printers are no longer accessed via a generic USB device node like "/dev/usb/lp0" but via a model-specific device URI like "usb://ACME/FunPrinter?serial=1a2b3c". There is a serial number included so that a USB printer device URI works only for one particular device. Usually it is not possible to know the correct USB device URI in advance, because it is determined by the CUPS backend "usb" during runtime when the particular device is connected, depending on the actual values which the printer reports via the USB. </para> <para> Intrinsic design of CUPS for printing in the network: @@ -34,28 +34,28 @@ The CUPS daemon process (cupsd) of a CUPS network print server sends information about its print queues to a list of IP addresses (host addresses and/or broadcast addresses). </para> <para> -On client workstations (hosts that only send print jobs to servers) also a cupsd runs which listens to information from servers. There is a list of servers from which information is accepted. By default, information is accepted from all servers. +On client workstations (hosts that only send print jobs to servers) a cupsd also runs and listens to information from servers. There is a list of servers from which information is accepted. By default, information is accepted from all servers. </para> <para> -In this way, the queues of the server are available on the clients. Users on the clients can browse the queues on various servers. Therefore it is called "Browsing" and all what is to do on a client workstation to use CUPS in its default Browsing mode is to run the cupsd. The matching settings in the cupsd configuration file (/etc/cups/cupsd.conf) are "Browsing On" and "BrowseAllow all". +The queues of the server are available on the clients. Users on the clients can browse the queues on various servers. Therefore it is called "Browsing". A client workstation only needs to run cupsd to use CUPS in its default Browsing mode. The matching settings in the cupsd configuration file (/etc/cups/cupsd.conf) are "Browsing On" and "BrowseAllow all". </para> <para> -To limit from which CUPS servers browsing information is accepted, a setting like "BrowseAllow @LOCAL" accepts browsing information only from CUPS servers in the local network. +If you want to limit from which CUPS servers browsing information is accepted, use "BrowseAllow". For example, "BrowseAllow @LOCAL" accepts browsing information only from CUPS servers in the local network. </para> <para> -Multiple "BrowseAllow" entries like "BrowseAllow 192.168.100.1" and "BrowseAllow 192.168.200.0/255.255.255.0" can be used to accept browsing information only from particular hosts and/or networks. +Multiple "BrowseAllow" entries like "BrowseAllow 192.168.100.1" and "BrowseAllow 192.168.200.0/255.255.255.0" can be used to accept browsing information only from particular hosts or networks. </para> <para> -CUPS Browsing information is recieved via UDP port 631. You may have to check firewall settings accordingly. +CUPS browsing information is received via UDP port 631. You may have to check firewall settings accordingly. </para> <para> -Alternatively if there is only one single CUPS server in the network, there is no need to use CUPS Browsing and have a CUPS daemon running on each client workstation. +Alternatively, if there is only one single CUPS server in the network, there is no need to use CUPS browsing and have a CUPS daemon running on each client workstation. </para> <para> -Instead it is simpler to specify the CUPS server and access it directly by an entry like "ServerName 192.168.100.99" in /etc/cups/client.conf (only one such entry can be set). In this case the specified server is directly accessed so that a local running cupsd on a client workstation is no longer used so that it does no longer make sense to have it running. +Instead it is simpler to specify the CUPS server and access it directly by an entry like "ServerName 192.168.100.99" in /etc/cups/client.conf (only one such entry can be set). A locally running cupsd on a client workstation is ignored. In this case it makes no sense to have it running. </para> <para> -The following is an example of a configuration section. The <cups_remote_server> entry contains the value of a ServerName entry in /etc/cups/client.conf. The <server_settings> section contains all values of the cupsd configuration file (/etc/cups/cupsd.conf) so that a complete <server_settings> section is required to get a reasonable cupsd configuration installed. +The following is an example of a configuration section. The <cups_remote_server> entry contains the value of a ServerName entry in /etc/cups/client.conf. The <server_settings> section contains all values of the cupsd configuration file (/etc/cups/cupsd.conf). A complete <server_settings> section is required to get a reasonable cupsd configuration installed. </para> -- To unsubscribe, e-mail: yast-commit+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-commit+help(a)opensuse.org

1 0

[yast-commit] r66726 - /trunk/autoinstallation/doc/xml/SysconfigSection.xml
by emap＠svn2.opensuse.org 06 Nov '11

06 Nov '11

Author: emap Date: Sun Nov 6 15:20:31 2011 New Revision: 66726 URL: http://svn.opensuse.org/viewcvs/yast?rev=66726&view=rev Log: edited by emap Modified: trunk/autoinstallation/doc/xml/SysconfigSection.xml Modified: trunk/autoinstallation/doc/xml/SysconfigSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/Sysconf… ============================================================================== --- trunk/autoinstallation/doc/xml/SysconfigSection.xml (original) +++ trunk/autoinstallation/doc/xml/SysconfigSection.xml Sun Nov 6 15:20:31 2011 @@ -19,7 +19,7 @@ <section id="createprofile.sysconfig"> - <title>System variables (Sysconfig)</title> + <title>System Variables (Sysconfig)</title> <para> Using the sysconfig resource, it is possible to define configuration variables in the sysconfig repository @@ -29,8 +29,9 @@ </para> <para> - Refer to the handbook for more details about the many - configuration options available in <filename>/etc/sysconfig</filename> + Refer to the handbook<remark>emap 2011-11-06: Add proper reference or at + least the name of the manual.</remark> for more details about the many + configuration options available in <filename>/etc/sysconfig</filename>. </para> <para> The following example shows how a variable can be set using the sysconfig -- To unsubscribe, e-mail: yast-commit+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-commit+help(a)opensuse.org

1 0

[yast-commit] r66725 - /trunk/autoinstallation/doc/xml/ScriptsSection.xml
by emap＠svn2.opensuse.org 06 Nov '11

06 Nov '11

Author: emap Date: Sun Nov 6 15:15:59 2011 New Revision: 66725 URL: http://svn.opensuse.org/viewcvs/yast?rev=66725&view=rev Log: edited by emap Modified: trunk/autoinstallation/doc/xml/ScriptsSection.xml Modified: trunk/autoinstallation/doc/xml/ScriptsSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/Scripts… ============================================================================== --- trunk/autoinstallation/doc/xml/ScriptsSection.xml (original) +++ trunk/autoinstallation/doc/xml/ScriptsSection.xml Sun Nov 6 15:15:59 2011 @@ -17,58 +17,57 @@ ]> <section id="createprofile.scripts"> - <title>Custom user scripts</title> + <title>Custom User Scripts</title> <para> By adding scripts to the auto-installation process you can customize the - installation for your needs and take control in different stages of the - installation. + installation according to your needs and take control in different + stages of the installation. </para> <para> In the auto-installation process, five types of scripts can be executed and they will be described here in order of "appearance" during the installation. </para> - <remark>FIXME: Is this a title?</remark> + <remark>FIXME: Is this a title?</remark><remark>emap 2011-11-06: Don't think so.</remark> <para>All scripts have to be in the <scritps> section.</para> - <itemizedlist> - <listitem><para><emphasis>pre-scripts</emphasis> (very early, before anything else really happened)</para></listitem> - <listitem><para><emphasis>postpartitioning-scripts</emphasis> (after partitioning and mounting to /mnt but before RPM installation - since openSUSE 11.2)</para></listitem> + <listitem><para><emphasis>pre-scripts</emphasis> (very early, before anything else really happens)</para></listitem> + <listitem><para><emphasis>postpartitioning-scripts</emphasis> (after partitioning and mounting to /mnt but before RPM installation—since openSUSE 11.2)</para></listitem> <listitem><para><emphasis>chroot-scripts</emphasis> (after the package installation, before the first boot)</para></listitem> <listitem><para><emphasis>post-scripts</emphasis> (during the first boot of the installed system, no services running)</para></listitem> - <listitem><para><emphasis>init-scripts</emphasis> (during the first boot of the installed system, all servies up and running)</para></listitem> + <listitem><para><emphasis>init-scripts</emphasis> (during the first boot of the installed system, all services up and running)</para></listitem> </itemizedlist> <section id="pre-install.scripts"> <title>Pre-Install Scripts</title> <para> - Executed before &yast2; does any real change to the system - (Before partitioning and package installation but after the hardware detection) + Executed before &yast; does any real change to the system + (before partitioning and package installation but after the hardware detection). </para> <para> - You can use the pre-script to modify your profile and let autoyast read it again. - If you want to do that, you can find your profile in "/tmp/profile/autoinst.xml". - Do what you want to do with that file and store the modified version in - "/tmp/profile/modified.xml". Autoyast will read that modified script then again after - the pre-script is done. + You can use a pre-script to modify your profile and let &ay; reread it. + Find your profile in "/tmp/profile/autoinst.xml". Adjust the file and + store the modified version in "/tmp/profile/modified.xml". &ay; will + read the modified file after the pre-script finishes. </para> <para> - With SUSE Linux 10.0 and all following versions it's possible to change the partitioning with fdisk - in your pre-script. With pre 10.0 versions of SUSE Linux (like SLES9), that was not possible. + With SUSE Linux 10.0 and all later versions, it is possible to change + the partitioning with fdisk in your pre-script. With pre-10.0 versions + of SUSE Linux (like SLES9), this was not possible. </para> - <note><title>Pre-Install Scripts with confirmation</title> + <note><title>Pre-Install Scripts with Confirmation</title> <para> Pre-scripts are executed at an early stage of the installation. This means if you have requested to confirm the installation, the - pre-scripts will be executed before the confirmation screen - shows up. (<emphasis>profile/install/general/mode/confirm</emphasis>) + pre-scripts will be executed before the confirmation screen + shows up (<emphasis>profile/install/general/mode/confirm</emphasis>). </para> </note> <para> - The following elements must be between the <scripts><pre-scripts config:type="list"><script> ... </script></pre-scripts>...</scripts> tags + The following elements must be between the <scripts><pre-scripts config:type="list"><script> ... </script></pre-scripts>...</scripts> tags. </para> <table frame='top'> - <title>pre script XML representation</title> + <title>Pre-script XML Representation</title> <tgroup cols="3"> <thead> <row> @@ -80,67 +79,68 @@ <tbody> <row> <entry>location</entry> - <entry><para>you can define a location from where the script gets fetched. - Locations can be the same like for the profile (http,ftp,nfs,...). + <entry><para>Define a location from where the script gets fetched. + Locations can be the same as for the profile (http, ftp, nfs, etc.). </para><screen><location>http://10.10.0.1/myPreScript.sh</location></screen></entry> - <entry>either <location> or <source> must be defined</entry> + <entry>Either <location> or <source> must be defined.</entry> </row> <row> <entry>source</entry> - <entry><para>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want - to put the whole shell script into the XML profile, look at the location parameter.</para> + <entry><para>The script itself (source code), encapsulated in + a CDATA tag. If you do not want to put the whole shell script + into the XML profile, refer to the location parameter.</para> <screen><source> <![CDATA[ echo "Testing the pre script" > /tmp/pre-script_out.txt ]]> </source></screen></entry> - <entry>Either <location> or <source> must be defined</entry> + <entry>Either <location> or <source> must be defined.</entry> </row> <row> <entry>interpreter</entry> - <entry><para>the interpreter that must be used for the script. Supported options are shell and perl. + <entry><para>Specify the interpreter that must be used for the script. Supported options are shell and perl. </para><screen><interpreter>perl</interpreter></screen></entry> - <entry>optional (default is shell)</entry> + <entry>Optional (default is "shell").</entry> </row> <row> <entry>filename</entry> - <entry><para>the filename of the script. It will be stored in a temporary directory under /tmp/... + <entry><para>The filename of the script. It will be stored in a temporary directory under /tmp/... </para><screen><filename>myPreScript5.sh</filename></screen></entry> - <entry>optional. The default is the type of the script (pre-scripts) in this case. If you have more than one script, you should set the filename to a reasonable value</entry> + <entry>Optional. Default is the type of the script (pre-scripts in this case). If you have more than one script, you should set the filename to a reasonable value.<remark>emap 2011-11-06: Should this read: If you have more than one script, choose a reasonable filename? Or: select the correct file?</remark></entry> </row> <row> <entry>feedback</entry> - <entry><para>if this boolean is true, stdout and stderr of the script will be shown in a popup that the - user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so + <entry><para>If this boolean is "true", stdout and stderr of the script will be shown in a popup, which the + user has to confirm via the OK button. If stdout and stderr are empty, no popup is shown and therefore no confirmation is needed. </para><screen><feedback config:type="boolean">true</feedback></screen></entry> - <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> + <entry>Optional, default is "false". This option was introduced with SL 10.1/SLES10.</entry> </row> <row> <entry>feedback_type</entry> - <entry><para>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. + <entry><para>This can be "message", "warning" or "error". Set the timeout for these popups in the <report> section. </para><screen><feedback_type>warning</feedback_type></screen></entry> - <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> + <entry>Optional, if missing, an always blocking popup is used. This option was introduced with openSUSE 11.2 (not SLES11).</entry> </row> <row> <entry>debug</entry> - <entry><para>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings + <entry><para>If this is "true", every single line of a shell script is logged. Perl scripts are run with warnings turned on. </para><screen><debug config:type="boolean">true</debug></screen></entry> - <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> + <entry>Optional, default is "true". This option was introduced with SL 10.1/SLES10.</entry> </row> <row> <entry>notification</entry> - <entry><para>This text will be shown in a popup for the time the script is running in the background - </para><screen><notification>Please wait while script is running ...</notification></screen></entry> - <entry>optional. If not configured, no notification popup will be shown. This option was invented with openSUSE 11.3/SLES11 SP2 (not SLES10)</entry> + <entry><para>This text will be shown in a popup for the time the script is running in the background. + </para><screen><notification>Please wait while script is running...</notification></screen></entry> + <entry>Optional, if not configured, no notification popup will be shown. This option was introduced with openSUSE 11.3/SLES11 SP2 (not SLES10).</entry> </row> <row> <entry>rerun</entry> - <entry><para>a script is only run once. So even if you use ayast_setup to run a XML file multiple times, the script is only run once. You can change that with this boolean. + <entry><para>A script is only run once. Even if you use ayast_setup to run a XML file multiple times, the script is only run once. Change this default behavior by setting this boolean to "true". </para><screen><rerun config:type="boolean">true</rerun></screen></entry> - <entry>optional. The default is false which makes scripts only run one time</entry> + <entry>Optional, default is "false" (scripts only run once).</entry> </row> </tbody> </tgroup> @@ -151,18 +151,17 @@ <section id="postpartitioning-install.scripts"> <title>Postpartitioning Scripts</title> <note> - <para>Available starting from openSUSE 11.2 only (not SLES11).</para> + <para>Available since openSUSE 11.2 only (not SLES11).</para> </note> <para> - Executed after &yast2; did the partitioning and wrote the fstab. The empty system is mounted to /mnt already. - This type of script is available since openSUSE 11.2 (not SLES11). + Executed after &yast; has done the partitioning and written the fstab. The empty system is mounted to /mnt already. </para> <para> The following elements must be between the <scripts><postpartitioning-scripts config:type="list"><script> ... </script></postpartitioning-scripts>...</scripts> tags </para> <table frame='top'> - <title>postpartitioning script XML representation</title> + <title>Postpartitioning Script XML Representation</title> <tgroup cols="3"> <thead> <row> @@ -174,67 +173,68 @@ <tbody> <row> <entry>location</entry> - <entry><para>you can define a location from where the script gets fetched. - Locations can be the same like for the profile (http,ftp,nfs,...). + <entry><para>Define a location from where the script gets fetched. + Locations can be the same as for the profile (http, ftp, nfs, etc.). </para><screen><location>http://10.10.0.1/myScript.sh</location></screen></entry> - <entry>either <location> or <source> must be defined</entry> + <entry>Either <location> or <source> must be defined.</entry> </row> <row> <entry>source</entry> - <entry><para>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want - to put the whole shell script into the XML profile, look at the location parameter. + <entry><para>The script itself (source code), encapsulated in + a CDATA tag. If you don't want to put the whole shell script + into the XML profile, refer to the location parameter. </para><screen><source> <![CDATA[ echo "Testing postpart script" > /mnt/postpart_test.txt ]]> </source></screen></entry> - <entry>Either <location> or <source> must be defined</entry> + <entry>Either <location> or <source> must be defined.</entry> </row> <row> <entry>interpreter</entry> - <entry><para>the interpreter that must be used for the script. Supported options are shell and perl. + <entry><para>The interpreter that must be used for the script. Supported options are shell and perl. </para><screen><interpreter>perl</interpreter></screen></entry> - <entry>optional (default is shell)</entry> + <entry>Optional, default is "shell".</entry> </row> <row> <entry>filename</entry> - <entry><para>the filename of the script. It will be stored in a temporary directory under /tmp/... + <entry><para>The filename of the script. It will be stored in a temporary directory under /tmp/... </para><screen><filename>myScript5.sh</filename></screen></entry> - <entry>optional. The default is the type of the script (postpartitioning-scripts in this case). If you have more than one script, you should set the filename to a reasonable value</entry> + <entry>Optional, default is the type of the script (postpartitioning-scripts in this case). If you have more than one script, set the filename to a reasonable value.<remark>emap 2011-11-06: Should this read: If you have more than one script, choose a reasonable filename? Or: select the correct file?</remark></entry> </row> <row> <entry>feedback</entry> - <entry><para>if this boolean is true, stdout and stderr of the script will be shown in a popup that the - user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so + <entry><para>If this boolean is "true", stdout and stderr of the script will be shown in a popup, which the + user has to confirm via the OK button. If stdout and stderr are empty, no popup is shown and therefore no confirmation is needed. </para><screen><feedback config:type="boolean">true</feedback></screen></entry> - <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> + <entry>Optional, the default is "false". This option was introduced with SL 10.1/SLES10.</entry> </row> <row> <entry>feedback_type</entry> - <entry><para>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. + <entry><para>This can be "message", "warning" or "error". Set the timeout for these popups in the <report> section. </para><screen><feedback_type>warning</feedback_type></screen></entry> - <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> + <entry>Optional, if missing, an always blocking popup is used. This option was introduced with openSUSE 11.2 (not SLES11).</entry> </row> <row> <entry>debug</entry> - <entry><para>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings + <entry><para>If this is "true", every single line of a shell script is logged. Perl scripts are run with warnings turned on. </para><screen><debug config:type="boolean">true</debug></screen></entry> - <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> + <entry>Optional, default is "true". This option was added with SL 10.1/SLES10.</entry> </row> <row> <entry>notification</entry> - <entry><para>This text will be shown in a popup for the time the script is running in the background - </para><screen><notification>Please wait while script is running ...</notification></screen></entry> - <entry>optional. If not configured, no notification popup will be shown. This option was invented with openSUSE 11.3/SLES11 SP2 (not SLES10)</entry> + <entry><para>This text will be shown in a popup for the time the script is running in the background. + </para><screen><notification>Please wait while script is running...</notification></screen></entry> + <entry>Optional, if not configured, no notification popup will be shown. This option was added with openSUSE 11.3/SLES11 SP2 (not SLES10).</entry> </row> <row> <entry>rerun</entry> - <entry><para>a script is only run once. So even if you use ayast_setup to run a XML file multiple times, the script is only run once. You can change that with this boolean. + <entry><para>A script is only run once. Even if you use ayast_setup to run a XML file multiple times, the script is only run once. Set this boolean to "true" if you want to change this default behavior. </para><screen><rerun config:type="boolean">true</rerun></screen></entry> - <entry>optional. The default is false which makes scripts only run one time</entry> + <entry>Optional, default is false (scripts only run once).</entry> </row> </tbody> </tgroup> @@ -244,20 +244,17 @@ <section id="chroot.scripts"> - <title>Chroot environment scripts</title> - <para>Chroot scripts are executed before the machine reboots for the first time. - Actually chroot scripts are two differnt kind of script with - one name. You can execute chroot script before the installation chroots into - the installed system and configures the boot loader and you can execute a script - after the chroot into the installed system has happend (look at the "chrooted" parameter for that). Both types of scripts are - executed before yast2 boots for the first time. + <title>Chroot Environment Scripts</title> + <para>Chroot scripts are executed before the machine reboots for the first time. You can execute chroot scripts before the installation chroots into + the installed system and configures the boot loader or you can execute a script + after the chroot into the installed system has happened (look at the "chrooted" parameter for that). </para> <para> The following elements must be between the <scripts><chroot-scripts config:type="list"><script> ... </script></chroot-scripts>...</scripts> tags </para> <table frame='top'> - <title>chroot script XML representation</title> + <title>Chroot Script XML Representation</title> <tgroup cols="3"> <thead> <row> @@ -269,74 +266,73 @@ <tbody> <row> <entry>location</entry> - <entry><para>you can define a location from where the script gets fetched. - Locations can be the same like for the profile (http,ftp,nfs,...). + <entry><para>Define a location from where the script gets fetched. + Locations can be the same as for the profile (http, ftp, nfs, etc.). </para> <screen><location>http://10.10.0.1/myChrootScript.sh</location></screen> </entry> - <entry>either <location> or <source> must be defined</entry> + <entry>Either <location> or <source> must be defined.</entry> </row> <row> <entry>source</entry> - <entry><para>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want - to put the whole shell script into the XML profile, look at the location parameter. - </para><screen><source> -<![CDATA[ -echo "Testing the chroot script" > /tmp/chroot_out.txt -]]> -</source></screen></entry> - <entry>either <location> or <source> must be defined</entry> + <entry><para>The script itself (source code), encapsulated in + a CDATA tag. If you do not want to put the whole shell script + into the XML profile, use the location parameter. + </para><screen><source> <![CDATA[ echo "Testing the + chroot script" > /tmp/chroot_out.txt ]]> + </source></screen></entry> + <entry>Either <location> or <source> must be defined.</entry> </row> <row> <entry>chrooted</entry> - <entry><para>this value can be true or false. "False" means that the installed system is still mounted at "/mnt" and no chrooting has happened till now. The bootloader is not installed too at that stage. "True" means, we did a chroot into /mnt, so we are now in the installed system. The bootloader is installed and if you want to change anything in the installed system, you don't have to use the "/mnt/" prefix anymore. + <entry><para>This value can be "true" or "false". If set to "false", the installed system remains mounted at "/mnt" and no chroot happens. The bootloader is not installed either at this stage. Set to "true" means, a chroot into /mnt is performed, where the installed system is mounted. The bootloader is installed, and if you want to change anything in the installed system, you don't have to use the "/mnt/" prefix anymore. </para><screen><chrooted config:type="boolean">true</chrooted></screen></entry> - <entry>optional (the default is false)</entry> + <entry>Optional, default is "false".</entry> </row> <row> <entry>interpreter</entry> - <entry><para>the interpreter that must be used for the script. Supported options are shell and perl.and if you are in a chrooted=true condition, you can use python too if it's installed. + <entry><para>The interpreter that must be used for the script. Supported options are shell and perl. If you are in a chrooted=true condition, you can also use python if installed. </para><screen><interpreter>perl</interpreter></screen></entry> - <entry>optional (default is shell)</entry> + <entry>Optional, default is shell.</entry> </row> <row> <entry>filename</entry> - <entry><para>the filename of the script. It will be stored in a temporary directory under /tmp/... + <entry><para>The filename of the script. It will be stored in a temporary directory under /tmp/... </para><screen><filename>myPreScript5.sh</filename></screen></entry> - <entry>optional. The default is the type of the script (chroot-scripts) in this case. If you have more than one script, you should set the filename to a reasonable value</entry> + <entry>Optional, default is the type of the script (chroot-scripts in this case). If you have more than one script, you should set the filename to a reasonable value.<remark>emap 2011-11-06: Should this read: If you have more than one script, choose a reasonable filename? Or: select the correct file?</remark></entry> </row> <row> <entry>feedback</entry> - <entry><para>if this boolean is true, stdout and stderr of the script will be shown in a popup that the - user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so + <entry><para>If this boolean is "true", stdout and stderr of the script will be shown in a popup, which the + user has to confirm via the OK button. If stdout and stderr are empty, no popup is shown and therefore no confirmation is needed. </para><screen><feedback config:type="boolean">true</feedback></screen></entry> - <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> + <entry>Optional, default is "false". This option was added with SL 10.1/SLES10.</entry> </row> <row> <entry>feedback_type</entry> - <entry><para>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. + <entry><para>This can be "message", "warning" or "error". Set the timeout for these popups in the <report> section. </para><screen><feedback_type>warning</feedback_type></screen></entry> - <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> + <entry>Optional, if missing, an always blocking popup is used. This option was introduced with openSUSE 11.2 (not SLES11).</entry> </row> <row> <entry>debug</entry> - <entry><para>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings + <entry><para>If this is true, every single line of a shell script is logged. Perl scripts are run with warnings turned on. </para><screen><debug config:type="boolean">true</debug></screen></entry> - <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> + <entry>Optional, default is "true". This option was added with SL 10.1/SLES10.</entry> </row> <row> <entry>notification</entry> - <entry><para>This text will be shown in a popup for the time the script is running in the background - </para><screen><notification>Please wait while script is running ...</notification></screen></entry> - <entry>optional. If not configured, no notification popup will be shown. This option was invented with openSUSE 11.3/SLES11 SP2 (not SLES10)</entry> + <entry><para>This text will be shown in a popup for the time the script is running in the background. + </para><screen><notification>Please wait while script is running...</notification></screen></entry> + <entry>Optional, if not configured, no notification popup will be shown. This option was added with openSUSE 11.3/SLES11 SP2 (not SLES10).</entry> </row> <row> <entry>rerun</entry> - <entry><para>a script is only run once. So even if you use ayast_setup to run a XML file multiple times, the script is only run once. You can change that with this boolean. + <entry><para>A script is only run once. Even if you use ayast_setup to run a XML file multiple times, the script is only run once. You can change the default behavior by setting this boolean to "true". </para><screen><rerun config:type="boolean">true</rerun></screen></entry> - <entry>optional. The default is false which makes scripts only run one time</entry> + <entry>Optional, default is "false" (scripts only run once).</entry> </row> </tbody> </tgroup> @@ -346,21 +342,21 @@ <section id="post-insall.scripts"> <title>Post-Install Scripts</title> <para> - These scripts are executed after AutoYaST has completed the + These scripts are executed after &ay; has completed the system configuration and after it has booted the system for the first time. </para> <para> - It is possible to execute the post scripts in an earlier phase while - the installation network is still up and before AutoYaST configures - the system. To run network enabled post scripts, the boolean - property <emphasis>network_needed</emphasis> has to be set to true. + It is possible to execute post scripts in an earlier phase while + the installation network is still up and before &ay; configures + the system. To run network-enabled post scripts, the boolean + property <emphasis>network_needed</emphasis> has to be set to "true". </para> <para> - The following elements must be between the <scripts><post-scripts config:type="list"><script> ... </script></post-scripts>...</scripts> tags + The following elements must be between the <scripts><post-scripts config:type="list"><script> ... </script></post-scripts>...</scripts> tags. </para> <table frame='top'> - <title>post script XML representation</title> + <title>Post Script XML Representation</title> <tgroup cols="3"> <thead> <row> @@ -372,75 +368,75 @@ <tbody> <row> <entry>location</entry> - <entry><para>you can define a location from where the script gets fetched. - Locations can be the same like for the profile (http,ftp,nfs,...) but then you need a running network interface of course + <entry><para>Define a location from where the script gets fetched. + Locations can be the same as for the profile (http, ftp, nfs, etc.). </para> <screen><location>http://10.10.0.1/myPostScript.sh</location></screen> </entry> - <entry>either <location> or <source> must be defined</entry> + <entry>Either <location> or <source> must be defined.</entry> </row> <row> <entry>source</entry> - <entry><para>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want - to put the whole shell script into the XML profile, look at the location parameter. + <entry><para>The script itself (source code), encapsulated in a CDATA tag. If you do not want + to put the whole shell script into the XML profile, use the location parameter. </para><screen><source> <![CDATA[ echo "Testing the chroot script" > /tmp/chroot_out.txt ]]> </source></screen></entry> - <entry>either <location> or <source> must be defined</entry> + <entry>Either <location> or <source> must be defined.</entry> </row> <row> <entry>network_needed</entry>  - <entry><para>this value can be true or false. On "false" the script will run after the yast modules like the user configuration and everything else are done. The network is configured but still not up and running. With this value on "true", the script runs before(!) all yast modules are configured. So there is no local user and no network is configured but the installation network is still up and running (of course only if you did a network installation). + <entry><para>This value can be "true" or "false". On "false" the script will run after the &yast; modules like the user configuration and everything else are done. The network is configured but not up and running yet. With this value set to "true", the script runs before all &yast; modules are configured. So there is no local user and no network is configured but the installation network is still up and running (if you did a network installation). </para><screen><network_needed config:type="boolean">true</network_needed></screen></entry> - <entry>optional (the default is false)</entry> + <entry>Optional, default is "false".</entry> </row> <row> <entry>interpreter</entry> - <entry><para>the interpreter that must be used for the script. Supported options are shell, perl and python if it's installed. + <entry><para>The interpreter that must be used for the script. Supported options are shell, perl and python if installed. </para><screen><interpreter>perl</interpreter></screen></entry> - <entry>optional (default is shell)</entry> + <entry>Optional, default is shell.</entry> </row> <row> <entry>filename</entry> - <entry><para>the filename of the script. It will be stored in a temporary directory under /tmp/... + <entry><para>The filename of the script. It will be stored in a temporary directory under /tmp/... </para><screen><filename>myPostScript5.sh</filename></screen></entry> - <entry>optional. The default is the type of the script (post-scripts) in this case. If you have more than one script, you should set the filename to a reasonable value</entry> + <entry>Optional, default is the type of the script (post-scripts in this case). If you have more than one script, set the filename to a reasonable value.<remark>emap 2011-11-06: Should this read: If you have more than one script, choose a reasonable filename? Or: select the correct file?</remark></entry> </row> <row> <entry>feedback</entry> - <entry><para>if this boolean is true, stdout and stderr of the script will be shown in a popup that the - user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so + <entry><para>If this boolean is "true", stdout and stderr of the script will be shown in a popup, which the + user has to confirm via the OK button. If stdout and stderr are empty, no popup is shown and therefore no confirmation is needed. </para><screen><feedback config:type="boolean">true</feedback></screen></entry> - <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> + <entry>Optional, default is "false". This option was added with SL 10.1/SLES10.</entry> </row> <row> <entry>feedback_type</entry> - <entry><para>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. + <entry><para>This can be "message", "warning" or "error". Set the timeout for these popups in the <report> section. </para><screen><feedback_type>warning</feedback_type></screen></entry> - <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> + <entry>Optional, if missing, an always blocking popup is used. This option was added with openSUSE 11.2 (not SLES11).</entry> </row> <row> <entry>debug</entry> - <entry><para>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings + <entry><para>If this is "true", every single line of a shell script is logged. Perl scripts are run with warnings turned on. </para><screen><debug config:type="boolean">true</debug></screen></entry> - <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> + <entry>Optional, default is "true". This option was added with SL 10.1/SLES10.</entry> </row> <row> <entry>notification</entry> - <entry><para>This text will be shown in a popup for the time the script is running in the background - </para><screen><notification>Please wait while script is running ...</notification></screen></entry> - <entry>optional. If not configured, no notification popup will be shown. This option was invented with openSUSE 11.3/SLES11 SP2 (not SLES10)</entry> + <entry><para>This text will be shown in a popup for the time the script is running in the background. + </para><screen><notification>Please wait while script is running...</notification></screen></entry> + <entry>Optional, if not configured, no notification popup will be shown. This option was introduced with openSUSE 11.3/SLES11 SP2 (not SLES10).</entry> </row> <row> <entry>rerun</entry> - <entry><para>a script is only run once. So even if you use ayast_setup to run a XML file multiple times, the script is only run once. You can change that with this boolean. + <entry><para>A script is only run once. Even if you use ayast_setup to run a XML file multiple times, the script is only run once. Change this default behavior by setting this boolean to "true". </para><screen><rerun config:type="boolean">true</rerun></screen></entry> - <entry>optional. The default is false which makes scripts only run one time</entry> + <entry>Optional, default is "false" (scripts only run once).</entry> </row> </tbody> </tgroup> @@ -450,11 +446,10 @@ <section id="init.scripts"> <title>Init Scripts</title> <para> - These scripts are executed during the initial boot process and after - &yast2; has finished. The final scripts are executed using a special - <emphasis>init.d</emphasis> script which is executed only - once. The final scripts are executed toward the end of the boot - process and after network has been intialized. + These scripts are executed when &yast; has finished, during the + initial boot process after the network has been initialized. These + final scripts are executed using a special + <emphasis>init.d</emphasis> script executed only once. </para> <para> Init scripts are configured using the tag <emphasis>init-scripts</emphasis> and @@ -465,7 +460,7 @@ </para> <table frame='top'> - <title>init script XML representation</title> + <title>Init script XML representation</title> <tgroup cols="3"> <thead> <row> @@ -477,35 +472,35 @@ <tbody> <row> <entry>location</entry> - <entry><para>you can define a location from where the script gets fetched. - Locations can be the same like for the profile (http,ftp,nfs,...) but then you need a running network interface of course + <entry><para>Define a location from where the script gets fetched. + Locations can be the same as for the profile (http, ftp, nfs, etc.). </para> <screen><location>http://10.10.0.1/myInitScript.sh</location></screen> </entry> - <entry>either <location> or <source> must be defined</entry> + <entry>Either <location> or <source> must be defined.</entry> </row> <row> <entry>source</entry> - <entry><para>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want - to put the whole shell script into the XML profile, look at the location parameter. + <entry><para>The script itself (source code), encapsulated in a CDATA tag. If you do not want + to put the whole shell script into the XML profile, use the location parameter. </para><screen><source> <![CDATA[ echo "Testing the init script" > /tmp/init_out.txt ]]> </source></screen></entry> - <entry>either <location> or <source> must be defined</entry> + <entry>Either <location> or <source> must be defined.</entry> </row> <row> <entry>filename</entry> - <entry><para>the filename of the script. It will be stored in a temporary directory under /tmp/... + <entry><para>The filename of the script. It will be stored in a temporary directory under /tmp/... </para><screen><filename>mynitScript5.sh</filename></screen></entry> - <entry>optional. The default is the type of the script (init-scripts) in this case. If you have more than one script, you should set the filename to a reasonable value</entry> + <entry>Optional, default is the type of the script (init-scripts in this case). If you have more than one script, set the filename to a reasonable value.<remark>emap 2011-11-06: Should this read: If you have more than one script, choose a reasonable filename? Or: select the correct file?</remark></entry> </row> <row> <entry>rerun</entry> - <entry><para>a script is only run once. So even if you use ayast_setup to run a XML file multiple times, the script is only run once. You can change that with this boolean. + <entry><para>A script is only run once. Even if you use ayast_setup to run a XML file multiple times, the script is only run once. Change this default behavior by setting this boolean to "true". </para><screen><rerun config:type="boolean">true</rerun></screen></entry> - <entry>optional. The default is false which makes scripts only run one time</entry> + <entry>Optional, default is "false" (scripts only run once).</entry> </row> </tbody> </tgroup> @@ -513,16 +508,16 @@ <para> - When added to the control file manually, the - scripts have to be included in a <emphasis>CDATA</emphasis> element to avoid confusion with - the file syntax and other tags defined in the control file. + When added to the control file manually, scripts have to be included in + a <emphasis>CDATA</emphasis> element to avoid confusion with the file + syntax and other tags defined in the control file. </para> </section> <section id="script_examples"> - <title>Script example</title> + <title>Script Example</title> <example> - <title>Post script configuration</title> + <title>Post Script Configuration</title> <screen> <xi:include href="examples/example.scripts.xml" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"/> @@ -532,11 +527,11 @@ <para> After installation is finished, the scripts and the output logs can be found in the directory <filename>/var/adm/autoinstall</filename>. The - scripts are located in <filename>scripts</filename> and the output logs of the - scripts are located in the <filename>log</filename> directory. + scripts are located in the subdirectory <filename>scripts</filename> and + the output logs in the <filename>log</filename> directory. </para> <para> - The log is the output resulting when executing the shell scripts using + The log is the output when executing the shell scripts using the following command: </para> <screen> -- To unsubscribe, e-mail: yast-commit+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-commit+help(a)opensuse.org

1 0

[yast-commit] r66724 - /trunk/autoinstallation/doc/xml/UsersSection.xml
by emap＠svn2.opensuse.org 06 Nov '11

06 Nov '11

Author: emap Date: Sun Nov 6 13:25:26 2011 New Revision: 66724 URL: http://svn.opensuse.org/viewcvs/yast?rev=66724&view=rev Log: edited by emap Modified: trunk/autoinstallation/doc/xml/UsersSection.xml Modified: trunk/autoinstallation/doc/xml/UsersSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/UsersSe… ============================================================================== --- trunk/autoinstallation/doc/xml/UsersSection.xml (original) +++ trunk/autoinstallation/doc/xml/UsersSection.xml Sun Nov 6 13:25:26 2011 @@ -28,16 +28,16 @@ </para> <para> At least the root user should be configured during - auto-installation, which will insure you will be able to login after - installation is finished and of course it will insure nobody else can login - into the system (in case the password is not set). + auto-installation so you can login after the + installation is finished. It will also ensure nobody else can login + to the system (in case the password is not set). </para> - <para>The two users in the following example are added during system + <para>The two users in the following example are added during system configuration.</para> <example> <title> - User configuration + User Configuration </title> <screen> <xi:include href="examples/example.users.xml" parse="text" @@ -46,10 +46,11 @@ </example> <para> The last example shows the minimal information required for adding - users. More options are available for a more customized user account - management. The data in <filename>/etc/default/useradd</filename> is - used to determine the home directory of the user to be created in - addition to other parameters. + users. Additional options are available for a more customized user + account management. The data in + <filename>/etc/default/useradd</filename> is used to determine the + home directory of the user to be created as well as other + parameters. </para> </section> -- To unsubscribe, e-mail: yast-commit+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-commit+help(a)opensuse.org

1 0