[opensuse-autoinstall] Setting up printers with autoyast
I'm a new to autoyast (2 weeks). I've setup an install procedure for my hosts
but I still fail to setup properly the printer.
I have a "lpadmin" and a "lpoptions" commands working when run as root after the
final reboot.
I've setup a post-scripts to do this automaticaly but it always fail with:
"lpadmin: Unable to connect to server: Connection refused"
Even if my post-script requires network and start cupsd.
<post-scripts config:type="list">
<script>
<debug config:type="boolean">true</debug>
<filename>imprimantes</filename>
* Can the script run as an init-script ?
If not:
* Make sure no firewall is active during post script execution
* Make sure cups is ALREADY configured and running ( In case cups is needed )
* Use nmap to check all required ports.
* Your say "... socket://batA1-most1.hmg.inpg.fr.:9100 ..." - is the dot "." after ".fr" correct ?
*Does the name batA1-most1.hmg.inpg.fr is FQDN ? If yes try to use the IP - thus bypass name resolution.
In my environment i use pretty much init scripts since all AYAST stuff is done at that time, The node has rebooted and everything should function what was under AYAST control.
Just my thought
Hth
Hajo
-----Original Message-----
From: Patrick Begou [mailto:Patrick.Begou@hmg.inpg.fr]
Sent: Friday, November 25, 2011 10:20 AM
To: opensuse-autoinstall@opensuse.org
Subject: [opensuse-autoinstall] Setting up printers with autoyast
I'm a new to autoyast (2 weeks). I've setup an install procedure for my hosts
but I still fail to setup properly the printer.
I have a "lpadmin" and a "lpoptions" commands working when run as root after the
final reboot.
I've setup a post-scripts to do this automaticaly but it always fail with:
"lpadmin: Unable to connect to server: Connection refused"
Even if my post-script requires network and start cupsd.
<post-scripts config:type="list">
<script>
<debug config:type="boolean">true</debug>
<filename>imprimantes</filename>
Yes, the problem was the point at the end of the FQDN ! May be an error while editing the profile as the command was initialy pasted from an other text file without this syntax error. With the error message I was focusing on cupsd not listening or a network problem. Now my install procedure is fully working. Autoyast seams very promising for me. Just have to read more for rules and other numerous functionalities. My final goal is to provide automatic install of the users workstations, starting from PXE boot for new hosts, after a system crash (ex: loss of electrical power) or system disk replacement without any command issued by the user or the admin. Thanks a lot for your help, Hans Joachim. Patrick Hans-Joachim Ehlers a écrit :
* Can the script run as an init-script ?
If not: * Make sure no firewall is active during post script execution * Make sure cups is ALREADY configured and running ( In case cups is needed ) * Use nmap to check all required ports. * Your say "... socket://batA1-most1.hmg.inpg.fr.:9100 ..." - is the dot "." after ".fr" correct ? *Does the name batA1-most1.hmg.inpg.fr is FQDN ? If yes try to use the IP - thus bypass name resolution.
In my environment i use pretty much init scripts since all AYAST stuff is done at that time, The node has rebooted and everything should function what was under AYAST control.
Just my thought
Hth Hajo
-----Original Message----- From: Patrick Begou [mailto:Patrick.Begou@hmg.inpg.fr] Sent: Friday, November 25, 2011 10:20 AM To: opensuse-autoinstall@opensuse.org Subject: [opensuse-autoinstall] Setting up printers with autoyast
I'm a new to autoyast (2 weeks). I've setup an install procedure for my hosts but I still fail to setup properly the printer. I have a "lpadmin" and a "lpoptions" commands working when run as root after the final reboot. I've setup a post-scripts to do this automaticaly but it always fail with:
"lpadmin: Unable to connect to server: Connection refused"
Even if my post-script requires network and start cupsd.
<post-scripts config:type="list"> <script> <debug config:type="boolean">true</debug> <filename>imprimantes</filename>
true <notification>Please wait while setting up printers ...</notification> <interpreter>shell</interpreter> <source><![CDATA[ #!/bin/sh service cups start lpadmin -p laser5M -m manufacturer-PPDs/hplip/hp-laserjet_4050_series-ps.ppd.gz -u allow:all -L "Salle A116" -v socket://batA1-most1.hmg.inpg.fr.:9100 -E lpoptions -d laser5M -o PageSize=A4 -o HPOption_Duplexer=True -o InstalledMemory=36MB -o HPOption_Tray3=True -o HPOption_Disk=HardDisk -o Duplex=DuplexNoTumble ]]> </source> </script> </post-scripts>Any suggestion is welcome.
Patrick
-- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
... PXE boot for new hosts, after a system crash (ex: loss of electrical power) or
I think many people using pxe,dhcp and autoyast to deploy their system. Autoyast is a very nice tool. ( Thanks Uwe ! )
Thanks a lot for your help, Hans Joachim. You get what you give but you must not always give what you get ;-)
Have a nice weekend Hajo -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
On Fri, Nov 25, 2011 at 02:27:44PM +0100, Patrick Begou wrote:
Now my install procedure is fully working. Autoyast seams very promising for me. Just have to read more for rules and other numerous functionalities. My final goal is to provide automatic install of the users workstations, starting from PXE boot for new hosts, after a system crash (ex: loss of electrical power) or system disk replacement without any command issued by the user or the admin.
Unless you want the system to re-image every time it boots, this might be kind of hard. Or if you have a way of having autoyast detect the system is current and ok, then boot off disk. One thing we're doing here is using the basic menuing that pxelinux allows and setting a default pxe file with a simple menu. If the user hits return (or waits 10 seconds) it'll just exit pxe and boot off the disk. We've setup some simple boot menus that will allow them to self-serve an upgrade/re-image when desired though. Since we control the pxelinux menu, we can keep it very simple and have it pass the info into autoyast to install the image the user needs[*]. We're using it as a jumping off point to install a couple different distributions now (I mostly support our massive suse base though) including even letting the windows admins kick their box over into the windows imaging stuff. [*]I actually hacked the com32 C code and added in 2 custom fields myself too. I can have the menu pop up the desired hostname and user name and those are added into the cmdline at installation and parsed by our pre/chroot/post scripts in autoyast. -- Mike Marion-Unix SysAdmin/Staff IT Engineer-http://www.qualcomm.com The Matrix is going down for reboot now! Stopping reality: ....OK The system is halted. -- yet another sig stolen from /. -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
I'll also look for an alternative solution with grub: I have a cluster runing Rocks Cluster distribution based on RedHat and Kickstart. At this time, I've not read in detail how boot works but there are two entries in menu.lst: One for a normal boot and a second for a reinstall. When the node boots, I think it sets the default to reinstall. So if the node crashes, next boot is reinstall. A normal shutdown should set default to normal boot. Of course, on a workstation, the user can choose the normal reboot even after a crash if he is in front of his workstation at boot time. And if there are no system at all on the disk, I think I can switch to PXE boot (after a System disk replacement). This is how I would like to process... changing the pxelinux code seams a little bit complicated for me... But thanks for this alternative idea for managing automatic reinstall. Patrick Mike Marion wrote:
On Fri, Nov 25, 2011 at 02:27:44PM +0100, Patrick Begou wrote:
Now my install procedure is fully working. Autoyast seams very promising for me. Just have to read more for rules and other numerous functionalities. My final goal is to provide automatic install of the users workstations, starting from PXE boot for new hosts, after a system crash (ex: loss of electrical power) or system disk replacement without any command issued by the user or the admin. Unless you want the system to re-image every time it boots, this might be kind of hard. Or if you have a way of having autoyast detect the system is current and ok, then boot off disk.
One thing we're doing here is using the basic menuing that pxelinux allows and setting a default pxe file with a simple menu. If the user hits return (or waits 10 seconds) it'll just exit pxe and boot off the disk. We've setup some simple boot menus that will allow them to self-serve an upgrade/re-image when desired though. Since we control the pxelinux menu, we can keep it very simple and have it pass the info into autoyast to install the image the user needs[*]. We're using it as a jumping off point to install a couple different distributions now (I mostly support our massive suse base though) including even letting the windows admins kick their box over into the windows imaging stuff.
[*]I actually hacked the com32 C code and added in 2 custom fields myself too. I can have the menu pop up the desired hostname and user name and those are added into the cmdline at installation and parsed by our pre/chroot/post scripts in autoyast.
-- =============================================================== | Equipe M.O.S.T. | http://most.hmg.inpg.fr | | Patrick BEGOU | ------------ | | LEGI | mailto:Patrick.Begou@hmg.inpg.fr | | BP 53 X | Tel 04 76 82 51 35 | | 38041 GRENOBLE CEDEX | Fax 04 76 82 52 71 | =============================================================== -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
Here is what we are using to reinstall broken clients...
PXE boot:
- have a "default" boot menu (in ./pxelinux.cfg/default)
- have a "auto-reinstall" menu (in
./pxelinux.cfg/
I'll also look for an alternative solution with grub: I have a cluster runing Rocks Cluster distribution based on RedHat and Kickstart. At this time, I've not read in detail how boot works but there are two entries in menu.lst: One for a normal boot and a second for a reinstall. When the node boots, I think it sets the default to reinstall. So if the node crashes, next boot is reinstall. A normal shutdown should set default to normal boot. Of course, on a workstation, the user can choose the normal reboot even after a crash if he is in front of his workstation at boot time. And if there are no system at all on the disk, I think I can switch to PXE boot (after a System disk replacement).
This is how I would like to process... changing the pxelinux code seams a little bit complicated for me...
But thanks for this alternative idea for managing automatic reinstall.
Patrick
Mike Marion wrote:
On Fri, Nov 25, 2011 at 02:27:44PM +0100, Patrick Begou wrote:
Now my install procedure is fully working. Autoyast seams very promising for me. Just have to read more for rules and other numerous functionalities. My final goal is to provide automatic install of the users workstations, starting from PXE boot for new hosts, after a system crash (ex: loss of electrical power) or system disk replacement without any command issued by the user or the admin. Unless you want the system to re-image every time it boots, this might be kind of hard. Or if you have a way of having autoyast detect the system is current and ok, then boot off disk.
One thing we're doing here is using the basic menuing that pxelinux allows and setting a default pxe file with a simple menu. If the user hits return (or waits 10 seconds) it'll just exit pxe and boot off the disk. We've setup some simple boot menus that will allow them to self-serve an upgrade/re-image when desired though. Since we control the pxelinux menu, we can keep it very simple and have it pass the info into autoyast to install the image the user needs[*]. We're using it as a jumping off point to install a couple different distributions now (I mostly support our massive suse base though) including even letting the windows admins kick their box over into the windows imaging stuff.
[*]I actually hacked the com32 C code and added in 2 custom fields myself too. I can have the menu pop up the desired hostname and user name and those are added into the cmdline at installation and parsed by our pre/chroot/post scripts in autoyast.
On Tue, Nov 29, 2011 at 11:49:40AM +0100, Joschi Brauchle wrote:
PXE boot: - have a "default" boot menu (in ./pxelinux.cfg/default) - have a "auto-reinstall" menu (in ./pxelinux.cfg/
)
We do something similar but split between desktops and servers. We tend to have servers always pxe boot. We use mac addressed files to start the install, and in the chroot use tftp to update the hosts file(s) to change them to boot off disk so they don't just loop through the installer. HPs we tend to leave to not default to pxe, because older ilos had an issue with the curses menu hanging if they went through the default file and then tried to boot off disk. They're easy enough to use a binary from HP that you can use on reboot with pxe as the arg to have it immediately reboot into a pxe boot... and I mean immediate (no actual OS shutdown, which is fine when you're going to re-image anyway). Desktops we instruct the user to hit F12 (mostly HPs) to pxe when they want the self-serve menu system we've setup and are just beginning to get out there.
Also, I dont see why one would need to hack the code of menu.c32. You can ask those question (like new hostname/default username) with the AutoYast <ask> functionality, where you can also provide default values. The hostname could also be provided via DHCP/DDNS/DNS.
Yeah, I went this route so that installs were something that asked 2 questions up front then the entire autoyast process was hands off. Plus I hadn't messed with the autoyast ask stuff at the time either. :) But that's another way to go. -- Mike Marion-Unix SysAdmin/Staff IT Engineer-http://www.qualcomm.com "...In my phone conversation with Microsoft's lawyer I copped to the fact that just maybe his client might see me as having been in the past just a bit critical of their products and business practices. This was too bad, he said with a sigh, because they were having a very hard time finding a reporter who both knew the industry well enough to be called an expert and who hadn't written a negative article about Microsoft." -- Robert X. Cringely -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
@all Since this email list is so quiet ( have not got an email since weeks ) i would like to mention the latest Docu ( Date 23 Jan 2012 ) from Uwe ( Thanks a lot Uwe ) for OpenSuse 12.1 and Autoyast http://www.suse.de/~ug/autoyast_doc/ cheers Hajo -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
On 26.01.2012 17:57, Hans-Joachim Ehlers wrote:
Since this email list is so quiet ( have not got an email since weeks )
yes, it has been really quiet in the last few weeks. Well for me, it means that everything seems to work fine ;) For the moment SLES11 SP2 is a hot topic but that's in bugzilla.
i would like to mention the latest Docu ( Date 23 Jan 2012 ) from Uwe ( Thanks a lot Uwe ) for OpenSuse 12.1 and Autoyast
and thanks to the docu team for helping me with that. -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net listening to: "Sanctuary" by mind.in.a.box -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
Its seems that my choice of freedom is going to vanish. At least i am not able to login as root via the GUI on OpenSuse 12.1 . ( Workaround is to set DISPLAYMANAGER_AUTOLOGIN="root" ;-) ) Getting serious. I ADDED the entry DISPLAYMANAGER_ROOT_LOGIN_LOCAL="yes" and set DISPLAYMANAGER_SHUTDOWN="all" in /etc/sysconfig/displaymanager and restarted the node. But no luck. Does somebody knows what i am missing ? Note: DEFAULT_VM is lxde Tia Hajo P.S In case somebody asked why i want to do so: The anwser : Because i want ! -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
Am 26.01.2012 17:57, schrieb Hans-Joachim Ehlers:
@all
Since this email list is so quiet ( have not got an email since weeks ) i would like to mention the latest Docu ( Date 23 Jan 2012 ) from Uwe ( Thanks a lot Uwe ) for OpenSuse 12.1 and Autoyast
http://www.suse.de/~ug/autoyast_doc/
cheers Hajo
Yes, thanks a lot!!! Regards, Ivan -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
On 26.01.2012 17:57, Hans-Joachim Ehlers wrote:
i would like to mention the latest Docu ( Date 23 Jan 2012 )
now on http://doc.opensuse.org/ too -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
Hi, I currently switching from kde3 (OSS 11.1 ) to xfce (OSS 12.1) because of kde4 . (Its a mess with their handling of NFS or clustered based home directories ) But since we need to be able to login from the Suse Login Screen to another host (via XDMCP ) only kdm seems to support this feature(chooser ) . At least its the only i got working. This means i have to install "kdm" but by default a crap of kde software gets selected as well. Thus on the command line i can use something like: $ zypper in --no-recommends kdm Which at least does installs only the current minimum ( > 40 rpms (sic) ) Thus the question: How do i enable the option "--no-recommends" in autoyast by default ? Tia Hajo Its looks like Linux gets more like MS Windows 15 years ago. Just usable on a single machine best with no network. -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
On 14.02.2012 20:31, Hans-Joachim Ehlers wrote:
Thus the question: How do i enable the option "--no-recommends" in autoyast by default ?
unfortunately that's not so easy That would require autoyast to run over all available packages and set a so called SoftLock. That's too expensive. For patterns autoyast can do that but not for packages. If you use SLES11 SP2 and/or openSUSE 12.1 there might be a funny workaround that I did not try myself but might work. You can create a file in a pre-script: <pre-scripts config:type="list"> <script> <interpreter>shell</interpreter> <source><![CDATA[ mkdir /etc/zypp echo "[main] solver.onlyRequires = true " > /etc/zypp/zypp.conf ]]></source> that will turn off the recommends in the resolver. The bad thing is, the pre-script is executed too late. Zypp has already read the config then. on openSUSE 12.1 and SLES11 SP2 you can restart yast by creating a file with a pre-script /var/lib/YaST2/restart_yast and if autoyast finds that file after the pre-script run, it'll terminate yast and restart it. So on 12.1 SLES11SP2 you can add a "touch /var/lib/YaST2/restart_yast" to your pre-script. On SLES11 SP1 and pre-12.1 you can not go that way. The only way there is to create a driverupdate that contains the zypp.conf. That works for 12.1 and SLES11 SP2 too of course. A third way (untested too) is to install the kdm in the post-packages section and modify the zypp.conf of the installed system with a chroot-script. Everything I suggested here is untested by me, so I'd be glad to get feedback if it works for you :) Good luck ;) -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net listening to: "Ursprung Paradoxon" by Stillste Stund -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
I just took a look at /etc/zypp/zypp.conf .... ## ## Whether required packages are installed ONLY ## So recommended packages, language packages and packages which depend ## on hardware (modalias) will not be regarded. ## ## Valid values: boolean ## Default value: false ## # solver.onlyRequires = false ... And i think the approach to delete later some packages is more secure. I do not want to miss some important packages during installation. BTW: In case of later SW installation - Is there a environment variable that has the same function as the "solver.onlyRequires = true" in /etc/zypp/zypp.conf ? Currently i use "zypper in --no-recommends ... $ListOfSoftware" but in case of ayast installation using xml files i would have to change the /etc/zypp/zypp.conf which i would try to prevent. Tia Hajo -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
On 16.02.2012 17:18, Hans-Joachim Ehlers wrote:
Is there a environment variable that has the same function as the "solver.onlyRequires = true" in /etc/zypp/zypp.conf ?
none that I know of -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net listening to: "Seven Lives" by In Strict Confidence -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
Hi Is it possible to initiate a boot after all init scripts has been run ? If not - is there a special execution order for the init scripts ? In this case i could create my "own" final reboot script which will be the last script to execute. Tia Hajo -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
On 22.02.2012 15:49, Hans-Joachim Ehlers wrote:
Is it possible to initiate a boot after all init scripts has been run ?
see:
http://www.suse.de/~ug/autoyast_doc/configuration.html#CreateProfile.General
If not - is there a special execution order for the init scripts ? In this case i could create my "own" final reboot script which will be the last script to execute.
the scripts are excuted in the order of their names how the "sort" command orders them. -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net listening to: "Pong" by Eisenfunk -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
Thanks a lot to all.
The following was set
On 23.02.2012 16:41, Hans-Joachim Ehlers wrote:
But due to a very long running autoyast init_script i thought it would never reboot. Also during this step runlevel 5 was already active
I think you can avoid that by setting /etc/sysconfig/boot RUN_PARALLEL="no"
Or is there a autoyast way to see the output from the various scripts during their run ?
no, there is no special autoyast way to show the output of init-scripts -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
On Feb 23, 2012, at 10:00 AM, Uwe Gansert wrote:
Or is there a autoyast way to see the output from the various scripts during their run ?
no, there is no special autoyast way to show the output of init-scripts
While it would be nice if there were, I've worked around it by modifying /etc/init.d/autoyast in a post-script: ==== <post-scripts config:type="list"> <script> <!-- changes to /etc files: NFSv4 domain, sysctl, etc. --> <filename>confs.sh</filename> <source> <![CDATA[#!/bin/sh test -f /etc/idmapd.conf && perl -pi -e 's/(^Domain = ).*/\1my.nfs4.domain/' /etc/idmapd.conf cat >> /etc/sysctl.conf << EOF # name core files <proc_name>.core kernel.core_pattern = %e.core EOF # apply settings from sysctl.conf /sbin/sysctl -p # make init-scripts show output to screen perl -pi -e 's,2&>,2>&1 | tee ,' /etc/init.d/autoyast ]]> </source> </script> </post-scripts> ==== Note the perl line -- this changes 'sh -x $script 2&> $LOG_DIR/$BASENAME.log' to 'sh -x $script 2>&1 | tee $LOG_DIR/$BASENAME.log'. On SLES 11 and openSUSE 11.x at least this causes init script output to be displayed on the console -- not sure about openSUSE 12.1 with its systemd. Andrew Daugherity Systems Analyst Division of Research, Texas A&M University -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
On 23.02.2012 17:00, Uwe Gansert wrote:
On 23.02.2012 16:41, Hans-Joachim Ehlers wrote:
But due to a very long running autoyast init_script i thought it would never reboot. Also during this step runlevel 5 was already active
I think you can avoid that by setting /etc/sysconfig/boot RUN_PARALLEL="no"
(This is set to "no" on our site since 11.2.) If your reboot still doesn't work, try the general option forceboot in your autoyast install.xml. Did the trick for me.
Or is there a autoyast way to see the output from the various scripts during their run ?
You have good control of in and output of scripts using systemd control files. openSUSE 12.1 comes with a wide selection of them. /lib/systemd/system/YaST2-Firstboot.service provided inspiration for me, for example. check out man systemd.exec for more information about that. You could use syslogd to log the output of those scripts to a special facility -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
Hello, On Feb 23 16:41 Hans-Joachim Ehlers wrote (excerpt):
... due to a very long running autoyast init_script i thought it would never reboot.
I think this is of interest here: Two days ago I filed a feature request for "Progress bar while scripts run in AutoYaST" https://fate.novell.com/313245 I don't know it this URL is public accessible therefore here a (shortened) quotation of my request: ------------------------------------------------------------ I ask for a feature in AutoYaST so that a script which is run by AutoYaST can provide progress feedback to AutoYaST so that AutoYaST can show a progress bar while scripts run. Custom user scripts in AutoYaST can run for an arbitrary long time. For example an image script that is doing the installation as described at http://www.suse.com/~ug/autoyast_changes_SLES10_SLES11.html can run for a longer time. Therefore I think it is important to have the option that scripts can provide progress feedback to AutoYaST so that AutoYaST can show a progress bar while scripts run. ------------------------------------------------------------
Or is there a autoyast way to see the output from the various scripts during their run ?
This would require that (Auto)-YaST is still running while the scripts run so that the running (Auto)-YaST can receive output from the scripts and show it to the user. As far as I know YaST (but I am not at all a YaST expert) there is no generic way in YaST to have concurrency. Therefore you can currently see the output after a script has finished but not while it runs. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
Hello, On Feb 24 09:26 Johannes Meixner wrote (excerpt):
... I think it is important to have the option that scripts can provide progress feedback to AutoYaST so that AutoYaST can show a progress bar while scripts run. ... This would require that (Auto)-YaST is still running while the scripts run so that the running (Auto)-YaST can receive output from the scripts and show it to the user.
As far as I know YaST (but I am not at all a YaST expert) there is no generic way in YaST to have concurrency.
Therefore you can currently see the output after a script has finished but not while it runs.
As I have it written here, it is a contradiction in itself. Therefore I like to explain why the special case of a progress bar while scripts run is possible: In the YaST programming language YCP there is the DownloadProgress widget and in this particular case there is concurrency. While the DownloadProgress widget is shown, YaST watches a file (the file which is to be downloaded) how it grows and according to how the file grows the DownloadProgress widget shows its download progress bar. To do this a reasonable estimated value for the maximum size of that file must be known in advance and this value is passed to the DownloadProgress widget so that it knows what "100%" (and therefore also any lower percentage value) means for its download progress bar. Implementation example: In yast2-printer I run scripts which need a longer time and in such cases I let the script write progress information (e.g. debug or log information) into a file and in YCP I (mis)-use the DownloadProgress widget for that file, see /usr/share/YaST2/modules/Printer.ycp with a simple static busy message as fallback for ncurses where the DownloadProgress widget is not available. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org
participants (9)
-
Daugherity, Andrew W -
Hans-Joachim Ehlers -
Ivan De Masi -
Johannes Meixner -
Joschi Brauchle -
Matthias Danzl -
Mike Marion -
Patrick Begou -
Uwe Gansert