Hello
How can you specify more than one udev rule with linuxrc? All examples I have found so far show only a single rule being specified.
I tried it with a space, but this does not seem to work. udev.rule="mac=de:ad:00:00:be:ef,name=eth0 mac=de:ad:00:00:be:ee,name=eth1"
Thanks Michael
How can you specify more than one udev rule with linuxrc?
Aha, only one rule per udev.rule but the parameter can be given multiple times: udev.rule="mac=de:ad:00:00:be:ef,name=eth0" udev.rule="mac=de:ad:00:00:be:ee,name=eth1"
Regards Michael
PS: Found via the sources http://gitorious.org/opensuse/linuxrc/blobs/master/util.c util_setup_udevrules() http://gitorious.org/opensuse/linuxrc/blobs/master/file.c case key_udevrule:
Hi
Given: SLES11 SP1 ( no patch ) , 32bit Task:, i try to install after an autoyast installation additional software by hand with zipper but getting right away resolve errors.
Example:
Trying to install nmap where libdnet1 & liblua5_1 provides what nmap requires. ( tests with --force-resolution show the same result )
~# /usr/bin/zypper --verbose -v --no-gpg-checks --non-interactive in --auto-agree-with-licenses nmap Verbosity: 2 Entering non-interactive mode. Entering 'no-gpg-checks' mode. Non-option program arguments: 'nmap' Initializing Target Checking whether to refresh metadata for SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152 Checking whether to refresh metadata for SDK Loading repository data... Reading installed packages... Force resolution: Yes Resolving package dependencies... Force resolution: Yes
Problem: nmap-4.75-1.26.i586 requires libdnet.so.1, but this requirement cannot be provided uninstallable providers: libdnet1-1.11-87.17.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] libdnet1-1.11-87.17.i586[http-10.11.8.3-bf69b41f] Solution 1: Following actions will be done: do not forbid installation of libdnet1-1.11-87.17.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] do not forbid installation of liblua5_1-5.1.4-1.15.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] Solution 2: Following actions will be done: do not forbid installation of libdnet1-1.11-87.17.i586[http-10.11.8.3-bf69b41f] do not forbid installation of liblua5_1-5.1.4-1.15.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] Solution 3: do not ask to install a solvable providing nmap Solution 4: break nmap by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/4/c] (c): c ...........................
Now i try to install liblua5_1 and libdnet1 but the --force option MUST be given
Example: /usr/bin/zypper -v -v --no-gpg-checks --non-interactive in --auto-agree-with-licenses --force liblua5_1 Verbosity: 2 Entering non-interactive mode. Entering 'no-gpg-checks' mode. Non-option program arguments: 'liblua5_1' Initializing Target Checking whether to refresh metadata for SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152 Checking whether to refresh metadata for SDK Loading repository data... Reading installed packages... Force resolution: No Resolving package dependencies... Force resolution: No
The following NEW package is going to be installed: liblua5_1 5.1.4-1.15 i586 SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152 SUSE LINUX Products GmbH, Nuernberg, Germany
1 new package to install. Overall download size: 83.0 KiB. After the operation, additional 187.0 KiB will be used. Continue? [y/n/?] (y): y committing Retrieving package liblua5_1-5.1.4-1.15.i586 (1/1), 83.0 KiB (187.0 KiB unpacked) Retrieving: http://10.11.8.3/export/suse/sles11sp1/x86/media.1/media [done] Retrieving: http://10.11.8.3/export/suse/sles11sp1/x86/suse/i586/liblua5_1-5.1.4-1.15.i5... [done] Installing: liblua5_1-5.1.4-1.15 [done] committingCommitResult 1 (errors 0, remaining 0, srcremaining 0, updateMessages 0)
Afterwards nmap can be installed.
But: If i remove the software and its dependencies via rpm -e - in this case nmap , libdnet1 & liblua5_1 i can install nmap right right away wiyhout any errors.
Is this a know bug or do i something wrong ?
Tia Hajo
I just found out that zipper gives a list of about 1200 "locked apps" . Command used is " zypper ll"
If i remove the lock for a all required dependencies of nmap like
# zypper rl libdnet1 liblua5_1
I can install nmap without problems. So its looks like that these " locks" cause the problem.
Does these looks have any purpose except to drive me crazy ?. Is there a bug in autoyast which does not removes these locks ?
Looking for insite
Hajo
Sorry for re-sending, for some reason my reply was rejected.
Am 15.07.2011 17:22 schrieb "Hans-Joachim Ehlers" HansJoachim.Ehlers@eumetsat.int:
Problem: nmap-4.75-1.26.i586 requires libdnet.so.1, but this requirement cannot be provided uninstallable providers: libdnet1-1.11-87.17.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] libdnet1-1.11-87.17.i586[http-10.11.8.3-bf69b41f] Solution 1: Following actions will be done: do not forbid installation of libdnet1-1.11-87.17.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] do not forbid installation of liblua5_1-5.1.4-1.15.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] Solution 2: Following actions will be done: do not forbid installation of libdnet1-1.11-87.17.i586[http-10.11.8.3-bf69b41f] do not forbid installation of liblua5_1-5.1.4-1.15.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] Solution 3: do not ask to install a solvable providing nmap Solution 4: break nmap by ignoring some of its dependencies
Now i try to install liblua5_1 and libdnet1 but the --force option MUST be given
But: If i remove the software and its dependencies via rpm -e - in this case nmap , libdnet1 & liblua5_1 i can install nmap right right away wiyhout any errors.
Is this a know bug or do i something wrong ?
Do you have these packages in <remove-packages>? If so, this is the same behavior we see on openSUSE, and I guess it is expected, even though it is a bit annoying.
(Background: We extensively use remove-packages to "block" more than 100 packages from being auto-added during installation, because we don't need them ("default" pattern iirc, we don't use "minimal" for some reason I don't remember right now). During later steps of the machine lifetime, we have exactly the same problem because these packages are forbidden.)
Is there a nicer way to block packages during install only? Forbidding them completely seems to be a bit counter-intuitive, assuming this is the same problem.
tty, 686f6c6d
on Friday 15 July 2011 Hans-Joachim Ehlers wrote:
Does these looks have any purpose except to drive me crazy ?
no, that was the only purpose ;)
No, seriously, back then, when I wrote that code for <remove-packages>, the taboo for packages was the only reliable way to tell the resolver "believe me, I don't want that package". The resolver always wanted to reselect the package unless it was on taboo. In the meantime the zypp resolver is a lot smarter and I should check that code again to replace it with something better because I think taboo is no longer needed unless you want to "remove-package" a package that is required by another one - then only taboo helps. I'll put that on my todo
. Is there a bug in autoyast which does not removes these locks ?
you can remove the /etc/zypp/locks file in an init-script or so. Then all locks should be gone.
Hi Uwe and 686f6c6d
you can remove the /etc/zypp/locks file in an init-script or so. Then all locks should be gone.
I have already extended our current init script to remove the looks via an
... # Remove all sw locks /usr/bin/zypper --non-interactive rl * ...
thanks Hajo
On Mon, Jul 18, 2011 at 10:34, Uwe Gansert ug@suse.de wrote:
on Friday 15 July 2011 Hans-Joachim Ehlers wrote:
Does these looks have any purpose except to drive me crazy ?
no, that was the only purpose ;)
No, seriously, back then, when I wrote that code for <remove-packages>, the taboo for packages was the only reliable way to tell the resolver "believe me, I don't want that package". The resolver always wanted to reselect the package unless it was on taboo. In the meantime the zypp resolver is a lot smarter and I should check that code again to replace it with something better because I think taboo is no longer needed unless you want to "remove-package" a package that is required by another one - then only taboo helps. I'll put that on my todo
In some cases, I find the locks quite helpful. Maybe just rename "remove-package" to "taboo-package" (or "(b)lock-package" or something like that) and write a new and shiny "remove-package"? I'd guess the number of people using (the current) remove-package for its locks is quite small, so the backward compatibilty issue would be quite small. Please, anybody using it that way, raise your voice now. (;
On Mon, Jul 18, 2011 at 10:54, Hans-Joachim Ehlers HansJoachim.Ehlers@eumetsat.int wrote:
you can remove the /etc/zypp/locks file in an init-script or so. Then all locks should be gone.
I have already extended our current init script to remove the looks via an /usr/bin/zypper --non-interactive rl *
The latter is the documented way to go, but if you use it on embedded hardware, it really makes a difference in terms of speed. While "rm /etc/zypp/locks" only takes a second to remove all (~500) locks, "zypper rl" takes about 25 minutes.
tty, 686f6c6d
on Tuesday 19 July 2011 686f6c6d wrote:
In some cases, I find the locks quite helpful. Maybe just rename "remove-package" to "taboo-package" (or "(b)lock-package" or something like that) and write a new and shiny "remove-package"?
yeah, the idea for a second key for taboo is good. But not for SLE11 SP2. I hope to add it for openSUSE 12.1
While "rm /etc/zypp/locks" only takes a second to remove all (~500) locks, "zypper rl" takes about 25 minutes.
wow. Not bad :)
autoinstall@lists.opensuse.org
-
686f6c6d -
Hans-Joachim Ehlers -
michael.leu＠mgb.ch -
Uwe Gansert