June 2021 - Uyuni Users - openSUSE Mailing Lists

by David Mace

Hi, I've just used: `spacewalk-common-channels -u admin -p pass -k unlimited -a x86_64 'opensuse_leap15_3*'` to create the Leap 15.3 channels in Uyuni (2021.05). However if I compare to a Leap 15.3 client it did not import these repos: repo-backports-update - http://download.opensuse.org/update/leap/15.3/backports/ repo-sle-update - http://download.opensuse.org/update/leap/15.3/sle/ Is that intentional or should I create these channels/repos manually? Thanks David

4 days, 4 hours

2
1
0 0

How do I apply a highstate to a group of systems?

by Allen Beddingfield

I have created a state channel, with an init.sls entered that deploys a package, and pulls in a couple of files that are attached to the state channel. If I add that state channel to a system, and apply the highstate to that system, it works. However, what I need is a way to apply the highstate to a group of systems. What I want to do is to attach this to about 100 systems, and have it deploy - without having to individually go to each system and click "apply high state". Surely there is a way to do this? With config channels, I would deploy files by adding all the systems, selecting the files to deploy, and deploying them to all systems. I don't see any option from the state channel to apply it to all systems. Am I missing something obvious? Thanks. Allen B. -- Allen Beddingfield Systems Engineer Office of Information Technology The University of Alabama Office 205-348-2251 allen(a)ua.edu

5 days

3
4
0 0

Autoinstall EL8 warnings for deprecated ks options

by jordi＠priscoelectronica.com

Hello, Just FYI, while autoinstalling almalinux8 hosts in Uyuni 2021.05 I get the following warnings: Jun 15 06:52:45 localhost dracut-cmdline[346]: Warning: 'ks=http://X.X.X.X/cblr/svc/op/autoinstall/profile/almalinux8-x86_64:1:Organization' Jun 15 06:52:45 localhost dracut-cmdline[346]: Warning: ks has been deprecated. All usage of Anaconda boot arguments without 'inst.' prefix have been deprecated and will be removed in a future major release. Please use inst.ks instead. Jun 15 06:52:45 localhost dracut-cmdline[346]: Warning: 'kssendmac=' Jun 15 06:52:45 localhost dracut-cmdline[346]: Warning: kssendmac has been deprecated. All usage of Anaconda boot arguments without 'inst.' prefix have been deprecated and will be removed in a future major release. Please use inst.ks.sendmac instead. best regards, Jordi

5 days, 11 hours

1
0
0 0

Centos 8 module updates - how are people dealing with this?

by Simon Avery

Hello, The recent Centos 8.4 release appears to have triggered more issues for us, and made me review how we manage our Centos 8 clients. We plan to move to Rocky soon but the same issue will persist there. Currently: Uyuni syncs Centos repos. My workaround so far has been to run "dnf -y update" on a schedule to each client instead of patching from within Uyuni as we do with Centos7. This pulls packages from the Uyuni mirror and has largely worked okay, but not any longer - lots of module related issues on all C8 clients since I updated the repos to 8.4. I'm not clear exactly why this has triggered this problem re-appearing, but it has. My understanding of this is that Uyuni doesn't update the module metadata when it populates its repositories, so the clients can't see this and fail. I've read about the Uyuni method of using the Content Lifecycle and have trialled this. This does work, but we don' t particularly want to be manually doing this for each Centos update or patch cycle. We're not big enough to warrant a corporate approval cycle for Centos, so updates are directly applied to our servers. (This has resulted in relatively few issues) The only other method I can think of is to change the clients to having local .repo files and pull updates directly from the Centos mirror. This obviously negates some of the benefits Uyuni brings to package management, but would work reliably. So I'm wondering - how are the other Centos/Alma/Oracle/Rocky 8 users of Uyuni applying updates, and how have you overcome the module problems? Simon Avery Linux Systems Administrator

1 week, 2 days

6
15
0 0

FW: Uyuni Community Hours

by Pau Garcia

________________________________________ From: Pau Garcia <pau.garcia(a)suse.com> Sent: Wednesday, June 9, 2021 1:46:18 PM (UTC+01:00) Brussels, Copenhagen, Madrid, Paris To: users(a)lists.uyuni-project.org; devel(a)lists.uyuni-project.org; announce(a)lists.uyuni-project.org Cc: Victor Zhestkov; Stefan Bluhm; Karl Tarvas; Dan Čermák; Bidault, Philippe; Richard Schaertel Subject: Uyuni Community Hours When: Friday, June 25, 2021 4:00 PM-5:00 PM. Where: Join us one more month to learn and discuss about Uyuni! The latest developments around Uyuni are presented and the community can ask question, provide feedback, request or suggest features or enhancements, etc to the Product Owner and members of the development team. Agenda will be published in the Uyuni wiki: https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours NB: Uyuni Community Hours are held every last Friday of the month, at 4pm CET. Meetings are recorded and published in the Uyuni YouTube channel: https://www.youtube.com/channel/UCB0SkZFAw9vPCFeUIYqZQ5A ________________________________________________________________________________ Microsoft Teams meeting Join on your computer or mobile app Click here to join the meeting<https://teams.microsoft.com/l/meetup-join/19%3ameeting_MjNhOWQzOTktZTk0MS00…> Or call in (audio only) +34 917 94 59 77,,418209063#<tel:+34917945977,,418209063#> Spain, Madrid Phone Conference ID: 418 209 063# Find a local number<https://dialin.teams.microsoft.com/58c3986f-4c3a-4b77-b4e8-f431171ef66d?id=…> | Reset PIN<https://mysettings.lync.com/pstnconferencing> Learn More<https://aka.ms/JoinTeamsMeeting> | Meeting options<https://teams.microsoft.com/meetingOptions/?organizerId=83d1ce03-a2c8-4530-…> ________________________________________________________________________________

1 week, 4 days

1
0
0 0

Uyuni Community Hours

by Pau Garcia

Join us one more month to learn and discuss about Uyuni! The latest developments around Uyuni are presented and the community can ask question, provide feedback, request or suggest features or enhancements, etc to the Product Owner and members of the development team. Agenda will be published in the Uyuni wiki: https://github.com/uyuni-project/uyuni/wiki/Uyuni-Community-Hours NB: Uyuni Community Hours are held every last Friday of the month, at 4pm CET. Meetings are recorded and published in the Uyuni YouTube channel: https://www.youtube.com/channel/UCB0SkZFAw9vPCFeUIYqZQ5A ________________________________________________________________________________ Microsoft Teams meeting Join on your computer or mobile app Click here to join the meeting<https://teams.microsoft.com/l/meetup-join/19%3ameeting_MjNhOWQzOTktZTk0MS00…> Or call in (audio only) +34 917 94 59 77,,418209063#<tel:+34917945977,,418209063#> Spain, Madrid Phone Conference ID: 418 209 063# Find a local number<https://dialin.teams.microsoft.com/58c3986f-4c3a-4b77-b4e8-f431171ef66d?id=…> | Reset PIN<https://mysettings.lync.com/pstnconferencing> Learn More<https://aka.ms/JoinTeamsMeeting> | Meeting options<https://teams.microsoft.com/meetingOptions/?organizerId=83d1ce03-a2c8-4530-…> ________________________________________________________________________________

1 week, 4 days

1
0
0 0

RE: Update 2020.x to 2021.5 failed

by Haupt, Torsten

Hi, I made a new snapshot and installed the mentioned packages. spacewalk-service stop zypper up apache-commons-el Loading repository data... Reading installed packages... Resolving package dependencies... The following package is going to be REMOVED: jakarta-commons-el The following package is going to be upgraded: apache-commons-el 1 package to upgrade, 1 to remove. Overall download size: 115.8 KiB. Already cached: 0 B. After the operation, 127.0 KiB will be freed. Continue? [y/n/v/...? shows all options] (y): Retrieving package apache-commons-el-1.0-lp152.2.3.1.noarch (1/1), 115.8 KiB (122.0 KiB unpacked) Retrieving delta: ./noarch/apache-commons-el-1.0-lp152.1.1_lp152.2.3.1.noarch.drpm, 6.5 KiB Retrieving: apache-commons-el-1.0-lp152.1.1_lp152.2.3.1.noarch.drpm .....................................................................................................................................[done] Applying delta: ./apache-commons-el-1.0-lp152.1.1_lp152.2.3.1.noarch.drpm ...............................................................................................................................[done] Checking for file conflicts: ............................................................................................................................................................................[done] (1/1) Installing: apache-commons-el-1.0-lp152.2.3.1.noarch ..............................................................................................................................................[done] zypper up subscription-matcher Loading repository data... Reading installed packages... Resolving package dependencies... Problem: subscription-matcher-0.26-6.1.uyuni.noarch requires (mvn(com.thoughtworks.xstream:xstream) >= 1.4.15 with mvn(com.thoughtworks.xstream:xstream) <= 1.5), but this requirement cannot be provided not installable providers: xstream-1.4.15-lp152.2.3.1.noarch[repo-update] xstream-1.4.16-lp152.2.6.1.noarch[repo-update] xstream-1.4.15-lp152.2.3.1.noarch[uyuni-server-stable] Solution 1: install xstream-1.4.16-lp152.2.6.1.noarch (with vendor change) obs://build.opensuse.org/systemsmanagement:Uyuni --> openSUSE Solution 2: do not install subscription-matcher-0.26-6.1.uyuni.noarch Solution 3: break subscription-matcher-0.26-6.1.uyuni.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 1 Resolving dependencies... Resolving package dependencies... The following NEW package is going to be installed: xpp3-minimal The following 2 packages are going to be upgraded: subscription-matcher xstream The following package is going to change vendor: xstream obs://build.opensuse.org/systemsmanagement:Uyuni -> openSUSE 2 packages to upgrade, 1 new, 1 to change vendor. Overall download size: 828.7 KiB. Already cached: 0 B. After the operation, additional 70.1 KiB will be used. Continue? [y/n/v/...? shows all options] (y): Retrieving package xpp3-minimal-1.1.4c-lp152.5.1.noarch (1/3), 34.9 KiB ( 28.5 KiB unpacked) Retrieving: xpp3-minimal-1.1.4c-lp152.5.1.noarch.rpm ....................................................................................................................................................[done] Retrieving package xstream-1.4.16-lp152.2.6.1.noarch (2/3), 542.6 KiB (636.0 KiB unpacked) Retrieving: xstream-1.4.16-lp152.2.6.1.noarch.rpm .......................................................................................................................................................[done] Retrieving package subscription-matcher-0.26-6.1.uyuni.noarch (3/3), 251.3 KiB (255.3 KiB unpacked) Retrieving: subscription-matcher-0.26-6.1.uyuni.noarch.rpm ..............................................................................................................................................[done] Checking for file conflicts: ............................................................................................................................................................................[done] (1/3) Installing: xpp3-minimal-1.1.4c-lp152.5.1.noarch ..................................................................................................................................................[done] (2/3) Installing: xstream-1.4.16-lp152.2.6.1.noarch .....................................................................................................................................................[done] (3/3) Installing: subscription-matcher-0.26-6.1.uyuni.noarch ............................................................................................................................................[done] spacewalk-service start Starting spacewalk services... Running DB schema upgrade. This may take a while. Call the following command to see progress: journalctl -f -u uyuni-check-database.service Done. journalctl -f -u uyuni-check-database.service -- Logs begin at Thu 2019-02-07 15:13:46 CET. -- Jun 04 09:36:32 smduyuni systemd[1]: Stopped Uyuni check database. -- Reboot -- Jun 04 09:37:55 smduyuni systemd[1]: Starting Uyuni check database... Jun 04 09:37:56 smduyuni spacewalk-startup-helper[1392]: Your database schema already matches the schema package version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 04 09:37:56 smduyuni spacewalk-startup-helper[1392]: Schema upgrade: [susemanager-schema-4.2.14-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 04 09:37:56 smduyuni systemd[1]: Started Uyuni check database. Jun 04 09:38:58 smduyuni systemd[1]: Stopped Uyuni check database. Jun 04 09:39:57 smduyuni systemd[1]: Starting Uyuni check database... Jun 04 09:39:58 smduyuni spacewalk-startup-helper[5663]: Your database schema already matches the schema package version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 04 09:39:58 smduyuni spacewalk-startup-helper[5663]: Schema upgrade: [susemanager-schema-4.2.14-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 04 09:39:58 smduyuni systemd[1]: Started Uyuni check database. Each time I restart the service, the schema upgrade starts again. I think, these packages are not the problem. Torsten From: Haupt, Torsten [mailto:Torsten.Haupt@lhw.mlu.sachsen-anhalt.de] Sent: Friday, June 4, 2021 9:31 AM To: Strahil Nikolov <hunter86_bg(a)yahoo.com>; Julio Gonzalez <jgonzalez(a)suse.com> Cc: uyuni-users(a)opensuse.org Subject: [EXTERN] RE: {SpamCheck LSA} RE: Update 2020.x to 2021.5 failed Hi, there was no question to install all packages. Or should I install the three packages, I didn’t installed because of the vendor change? Can I install it at this point? Torsten From: Strahil Nikolov [mailto:hunter86_bg@yahoo.com] Sent: Friday, June 4, 2021 9:23 AM To: Haupt, Torsten <Torsten.Haupt(a)lhw.mlu.sachsen-anhalt.de<mailto:Torsten.Haupt@lhw.mlu.sachsen-anhalt.de>>; Haupt, Torsten <Torsten.Haupt(a)lhw.mlu.sachsen-anhalt.de<mailto:Torsten.Haupt@lhw.mlu.sachsen-anhalt.de>>; Julio Gonzalez <jgonzalez(a)suse.com<mailto:jgonzalez@suse.com>> Cc: uyuni-users(a)opensuse.org<mailto:uyuni-users@opensuse.org> Subject: {SpamCheck LSA} RE: Update 2020.x to 2021.5 failed Hi Thorsten, can you clone the VM and test installing all packages (answer yes to all) Best Regards, Strahil Nikolov On Fri, Jun 4, 2021 at 10:20, Haupt, Torsten <Torsten.Haupt(a)lhw.mlu.sachsen-anhalt.de<mailto:Torsten.Haupt@lhw.mlu.sachsen-anhalt.de>> wrote: Hi, well, I had a snapshot of the VM and I returned to the point before upgrade. The installed version was 2020.11 on openSUSE Leap 15.2. I use the upgrade guide at https://www.uyuni-project.org/uyuni-docs/uyuni/upgrade/server-minor-upgrade… I did: spacewalk-service stop zypper refresh zypper patch --with-optional Loading repository data... Reading installed packages... Resolving package dependencies... The following 11 NEW patches are going to be installed: openSUSE-2021-291 openSUSE-2021-354 openSUSE-2021-361 openSUSE-2021-365 openSUSE-2021-614 openSUSE-2021-616 openSUSE-2021-703 openSUSE-2021-744 openSUSE-2021-822 openSUSE-2021-827 openSUSE-2021-831 The following 40 packages are going to be upgraded: e2fsprogs gstreamer gstreamer-lang gstreamer-plugins-base gstreamer-plugins-base-lang libcom_err2 libcom_err2-32bit libext2fs2 libgpgme11 libgstallocators-1_0-0 libgstapp-1_0-0 libgstaudio-1_0-0 libgstfft-1_0-0 libgstgl-1_0-0 libgstpbutils-1_0-0 libgstreamer-1_0-0 libgstriff-1_0-0 libgsttag-1_0-0 libgstvideo-1_0-0 libnetpbm11 libpq5 libvirt-bash-completion libvirt-client libvirt-libs m4 netpbm openssh openssh-askpass-gnome openssh-helpers postgresql10 postgresql10-contrib postgresql10-server postgresql12 postgresql12-contrib postgresql12-llvmjit postgresql12-server sed sed-lang tcl tk 40 packages to upgrade. Overall download size: 39.2 MiB. Already cached: 0 B. After the operation, additional 23.7 KiB will be used. Continue? [y/n/v/...? shows all options] (y): I did a reboot, that all applications uses the new versions. At this point the website was okay. I restarted with a spacewalk-service stop. zypper up Loading repository data... Reading installed packages... The following 3 package updates will NOT be installed: Uyuni-Server-release subscription-matcher xstream The following product update will NOT be installed: "Uyuni Server" The following NEW package is going to be installed: apache-commons-el The following 136 packages are going to be upgraded: apache2-mod_xsendfile bind-formula c3p0 caasp-management-node-formula caasp-management-settings-formula cobbler concurrent cpu-mitigations-formula dhcpd-formula drools dwr ehcache golang-github-QubitProducts-exporter_exporter golang-github-lusitaniae-apache_exporter golang-github-prometheus-node_exporter golang-github-wrouesnel-postgres_exporter grafana-formula guava hibernate5 ical4j jabberd jabberd-sqlite jade4j jcommon jsch kie-api kie-soup libgsasl-lang libgsasl7 libudns0 locale-formula mgr-libmod mgr-osa-dispatcher mgr-push netty nutch-core openvpn-formula optaplanner patterns-uyuni_server perl-Mail-RFC822-Address perl-Satcon perl-Term-Completion perl-Term-Size prometheus-exporters-formula prometheus-formula prometheus-jmx_exporter prometheus-jmx_exporter-tomcat pxe-default-image-opensuse15 py26-compat-msgpack-python py26-compat-salt py26-compat-tornado python-dmidecode python3-dmidecode python3-hwdata python3-mgr-osa-common python3-mgr-osa-dispatcher python3-mgr-push python3-rhnlib python3-spacewalk-certs-tools python3-spacewalk-client-tools python3-suseRegisterInfo python3-urlgrabber python3-uyuni-common-libs release-notes-uyuni reprepro salt-netapi-client simple-core simple-xml sitemesh smdba spacecmd spacewalk-admin spacewalk-backend spacewalk-backend-app spacewalk-backend-applet spacewalk-backend-config-files spacewalk-backend-config-files-common spacewalk-backend-config-files-tool spacewalk-backend-iss spacewalk-backend-iss-export spacewalk-backend-package-push-server spacewalk-backend-server spacewalk-backend-sql spacewalk-backend-sql-postgresql spacewalk-backend-tools spacewalk-backend-xml-export-libs spacewalk-backend-xmlrpc spacewalk-base spacewalk-base-minimal spacewalk-base-minimal-config spacewalk-branding spacewalk-certs-tools spacewalk-client-tools spacewalk-common spacewalk-config spacewalk-html spacewalk-java spacewalk-java-config spacewalk-java-lib spacewalk-java-postgresql spacewalk-postgresql spacewalk-reports spacewalk-search spacewalk-setup spacewalk-setup-jabberd spacewalk-taskomatic spacewalk-utils struts supportutils-plugin-salt supportutils-plugin-susemanager suseRegisterInfo susemanager susemanager-frontend-libs susemanager-schema susemanager-sls susemanager-sync-data susemanager-tftpsync susemanager-tools susemanager-web-libs system-lock-formula tagsoup tftpd-formula tika-core tomcat-taglibs-standard-1_2_5 uyuni-base-common uyuni-base-server uyuni-build-keys uyuni-build-keys-web uyuni-cluster-provider-caasp uyuni-doc-indexes uyuni-docs_en uyuni-docs_en-pdf virtual-host-gatherer virtual-host-gatherer-VMware virtualization-host-formula vsftpd-formula The following pattern is going to be upgraded: uyuni_server 136 packages to upgrade, 1 new. Overall download size: 227.0 MiB. Already cached: 0 B. After the operation, additional 6.9 MiB will be used. Continue? [y/n/v/...? shows all options] (y): During update following question appears: Checking for file conflicts: ...........................................................................................................................................................................[error] Detected 1 file conflict: File /usr/share/java/commons-el.jar from install of apache-commons-el-1.0-lp152.1.1.noarch (Main Repository) conflicts with file from package jakarta-commons-el-1.0-2.6.uyuni.noarch (@System) File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content. Continue? [yes/no] (no): I choosed "yes" Because some packages were not update automatically, I updated them manually zypper update Uyuni-Server-release Loading repository data... Reading installed packages... Resolving package dependencies... The following package is going to be upgraded: Uyuni-Server-release The following product is going to be upgraded: Uyuni Server 2020.11-0 -> 2021.05-0 The following product is going to change vendor: Uyuni Server openSUSE -> obs://build.opensuse.org/systemsmanagement:Uyuni 1 package to upgrade. Overall download size: 8.6 KiB. Already cached: 0 B. After the operation, additional 1.0 B will be used. Continue? [y/n/v/...? shows all options] (y): zypper update subscription-matcher Loading repository data... Reading installed packages... Resolving package dependencies... Problem: subscription-matcher-0.26-6.1.uyuni.noarch requires (mvn(com.thoughtworks.xstream:xstream) >= 1.4.15 with mvn(com.thoughtworks.xstream:xstream) <= 1.5), but this requirement cannot be provided not installable providers: xstream-1.4.15-lp152.2.3.1.noarch[repo-update] xstream-1.4.16-lp152.2.6.1.noarch[repo-update] xstream-1.4.15-lp152.2.3.1.noarch[uyuni-server-stable] Solution 1: install xstream-1.4.16-lp152.2.6.1.noarch (with vendor change) obs://build.opensuse.org/systemsmanagement:Uyuni --> openSUSE Solution 2: do not install subscription-matcher-0.26-6.1.uyuni.noarch Solution 3: break subscription-matcher-0.26-6.1.uyuni.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 2 Resolving dependencies... Resolving package dependencies... Nothing to do. I didn't installed this update, because of the vendor change from uyuni to openSUSE. zypper up xstream Loading repository data... Reading installed packages... There is an update candidate for 'xstream' from vendor 'openSUSE', while the current vendor is 'obs://build.opensuse.org/systemsmanagement:Uyuni'. Use 'zypper install xstream-1.4.16-lp152.2.6.1.noarch' to install this candidate. Resolving package dependencies... Nothing to do. I didn't installed this update, because of the vendor change from uyuni to openSUSE. zypper up apache-commons-el Loading repository data... Reading installed packages... Resolving package dependencies... The following package is going to be REMOVED: jakarta-commons-el The following package is going to be upgraded: apache-commons-el 1 package to upgrade, 1 to remove. Overall download size: 115.8 KiB. Already cached: 0 B. After the operation, 127.0 KiB will be freed. Continue? [y/n/v/...? shows all options] (y): n I didn't installed this package, because oft he question above. spacewalk-service start Starting spacewalk services... Running DB schema upgrade. This may take a while. Call the following command to see progress: journalctl -f -u uyuni-check-database.service journalctl -f -u uyuni-check-database.service -- Logs begin at Thu 2019-02-07 15:13:46 CET. -- Jun 03 20:27:41 smduyuni systemd[1]: Stopped Uyuni check database. Jun 03 20:43:32 smduyuni systemd[1]: Starting Uyuni check database... Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Schema upgrade: [susemanager-schema-4.2.3-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Searching for upgrade path to: [susemanager-schema-4.2.14-1] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Searching for upgrade path to: [susemanager-schema-4.2.14] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Searching for start path: [susemanager-schema-4.2.3-1] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Searching for start path: [susemanager-schema-4.2.3] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: The path: [susemanager-schema-4.2.3] -> [susemanager-schema-4.2.4] -> [susemanager-schema-4.2.5] -> [susemanager-schema-4.2.6] -> [susemanager-schema-4.2.7] -> [susemanager-schema-4.2.8] -> [susemanager-schema-4.2.9] -> [susemanager- schema-4.2.10] -> [susemanager-schema-4.2.11] -> [susemanager-schema-4.2.12] -> [susemanager-schema-4.2.13] -> [susemanager-schema-4.2.14] Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Planning to run schema upgrade with dir '/var/log/spacewalk/schema-upgrade/schema-from-20210603-204341' Jun 03 20:43:41 smduyuni spacewalk-startup-helper[7339]: Executing spacewalk-sql, the log is in [/var/log/spacewalk/schema-upgrade/schema-from-20210603-204341-to-susemanager-schema-4.2.14.log]. Jun 03 22:50:00 smduyuni spacewalk-startup-helper[7339]: [1.9K blob data] Jun 03 22:50:01 smduyuni spacewalk-startup-helper[7339]: [2.0K blob data] Jun 03 22:50:02 smduyuni spacewalk-startup-helper[7339]: [1.9K blob data] Jun 03 22:50:02 smduyuni spacewalk-startup-helper[7339]: The database schema was upgraded to version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 03 22:50:02 smduyuni systemd[1]: Started Uyuni check database. The Website is not available again. I stopped the spacewalk-service again and startet it without luck. Jun 04 09:14:29 smduyuni systemd[1]: Stopped Uyuni check database. Jun 04 09:14:35 smduyuni systemd[1]: Starting Uyuni check database... Jun 04 09:14:36 smduyuni spacewalk-startup-helper[8318]: Your database schema already matches the schema package version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 04 09:14:36 smduyuni spacewalk-startup-helper[8318]: Schema upgrade: [susemanager-schema-4.2.14-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 04 09:14:36 smduyuni systemd[1]: Started Uyuni check database. So, the same problem like the last run. Greets Torsten > -----Original Message----- > From: Julio Gonzalez [mailto:jgonzalez@suse.com<mailto:jgonzalez@suse.com>] > Sent: Thursday, June 3, 2021 2:55 PM > To: uyuni-users(a)opensuse.org<mailto:uyuni-users@opensuse.org>; users(a)lists.uyuni-project.org<mailto:users@lists.uyuni-project.org> > Cc: Haupt, Torsten <Torsten.Haupt(a)lhw.mlu.sachsen-anhalt.de<mailto:Torsten.Haupt@lhw.mlu.sachsen-anhalt.de>> > Subject: [EXTERN] Re: Update 2020.x to 2021.5 failed > > Without knowing the X, it's hard to know what's going on for sure. > > But to me, it looks like you missed one of the manual steps to be applied to > upgrade from 2020.X to 2021.05. Have a look at the release notes and make > sure you follow all the instructions between your 2020.X and 2021.05. > > My main suspect is one of the libraries that now must come from Leap. Without > that changed applied to the server, the WebUI is know to show 404. > > However if 2020.X is too old, it could be it was based on Leap 15.1, and needs to > run the script to migrate to Leap 15.2. But should not be the case if 2020.X is > from the end of last year. > > > On miércoles, 2 de junio de 2021 19:58:20 (CEST) Haupt, Torsten wrote: > > Hi, > > > > I didn't made every uyuni update the last months, but now I did it and > > it failed. I think my installed version was from end oft he last year. > > I followed the instructions on the website and all patches and updates > > were installed. The schema update with the first service start last > > several hours, but it fineshed. But the Uyuni site is not available; > > only the tomcat error "HTTP Status 404 - nicht gefunden Type Status > > Report Beschreibung The origin server did not find a current > > representation for the target resource or is not willing to disclose > > that one exists." appears. I restarted the services and the whole > > server without success. > > > > Every time I do a "spacewalk-service start" the message "Starting > > spacewalk services... > > Running DB schema upgrade. This may take a while. > > Call the following command to see progress: journalctl -f -u > > uyuni-check-database.service Done." appears. > > > > journalctl -f -u uyuni-check-database.service > > -- Logs begin at Thu 2019-02-07 15:13:46 CET. -- Jun 02 11:56:41 > > smduyuni systemd[1]: Stopped Uyuni check database. > > Jun 02 11:56:44 smduyuni systemd[1]: Starting Uyuni check database... > > Jun 02 11:56:44 smduyuni spacewalk-startup-helper[22859]: Your > > database schema already matches the schema package version > > [susemanager-schema-4.2.14-1.1.uyuni]. Jun 02 11:56:44 smduyuni > > spacewalk-startup-helper[22859]: Schema upgrade: > > [susemanager-schema-4.2.14-1.1.uyuni] -> > > [susemanager-schema-4.2.14-1.1.uyuni] Jun 02 11:56:44 smduyuni > systemd[1]: > > Started Uyuni check database. Jun 02 19:42:08 smduyuni systemd[1]: > > Stopped Uyuni check database. Jun 02 19:42:11 smduyuni systemd[1]: > > Starting Uyuni check database... Jun 02 19:42:11 smduyuni spacewalk-startup- > helper[24088]: > > Your database schema already matches the schema package version > > [susemanager-schema-4.2.14-1.1.uyuni]. Jun 02 19:42:11 smduyuni > > spacewalk-startup-helper[24088]: Schema upgrade: > > [susemanager-schema-4.2.14-1.1.uyuni] -> > > [susemanager-schema-4.2.14-1.1.uyuni] Jun 02 19:42:12 smduyuni > systemd[1]: > > Started Uyuni check database. > > > > It is always the same schema upgrade. > > > > > > less /var/log/tomcat/catalina.2021-06-02.log > > 02-Jun-2021 19:42:14.398 SEVERE [main] > > org.apache.catalina.startup.HostConfig.deployDirectory Error deploying > > web application directory [/srv/tomcat/webapps/rhn] > > java.lang.IllegalStateException: Error starting child > > at > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java: > > 720) at > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690 > > ) at > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) > > at > > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java > > :1132 > > ) at > > org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java: > > 1865) at > > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executor > > s.jav > > a:515) at > > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > > at > > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExe > > cutor > > Service.java:75) at > > java.base/java.util.concurrent.AbstractExecutorService.submit(Abstract > > Execu > > torService.java:118) at > > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.ja > > va:10 > > 44) at > > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) > > at > > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1575) at > > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java: > > 309) > > at > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBas > > e.jav > > a:123) at > > org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java: > > 423) at > > org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366 > > ) at > > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.jav > > a:936 > > ) at > > org.apache.catalina.core.StandardHost.startInternal(StandardHost.java: > > 841) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at > > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.j > > ava:1 > > 384) at > > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.j > > ava:1 > > 374) at > > java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > > at > > org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExe > > cutor > > Service.java:75) at > > java.base/java.util.concurrent.AbstractExecutorService.submit(Abstract > > Execu > > torService.java:140) at > > org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.jav > > a:909 > > ) at > > org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.j > > ava:2 > > 62) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at > > org.apache.catalina.core.StandardService.startInternal(StandardService > > .java > > :421) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at > > org.apache.catalina.core.StandardServer.startInternal(StandardServer.j > > ava:9 > > 30) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeM > > ethod > > AccessorImpl.java:62) at > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Del > > egati > > ngMethodAccessorImpl.java:43) at > > java.base/java.lang.reflect.Method.invoke(Method.java:566) at > > org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at > > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: > > org.apache.catalina.LifecycleException: Failed to start component > > [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/rhn > > ]] at > > org.apache.catalina.util.LifecycleBase.handleSubClassException(Lifecyc > > leBas > > e.java:440) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) > > at > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java: > > 717) ... 37 more > > Caused by: java.lang.NullPointerException > > at > > org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScan > > ner.j > > ava:382) at > > org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner > > .java > > :195) at > > org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(C > > ontex > > tConfig.java:1971) at > > org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java > > :1129 > > ) at > > org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig > > .java > > :775) at > > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig > > .java > > :301) at > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBas > > e.jav > > a:123) at > > org.apache.catalina.core.StandardContext.startInternal(StandardContext > > .java > > :5044) at > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > > ... 38 more > > 02-Jun-2021 19:42:14.400 INFO [main] > > org.apache.catalina.startup.HostConfig.deployDirectory Deployment of > > web application directory [/srv/tomcat/webapps/rhn] has finished in > > [982] ms > > 02-Jun-2021 19:42:14.421 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["http-nio-127.0.0.1-8080"] 02-Jun-2021 19:42:14.601 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["ajp-nio-127.0.0.1-8009"] 02-Jun-2021 19:42:14.749 INFO [main] > > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > > ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 02-Jun-2021 19:42:14.881 INFO [main] > > org.apache.catalina.startup.Catalina.start Server startup in [1,660] > > milliseconds > > > > Further logs and infos I would provide. > > > > Greets > > Torsten > > > -- > Julio González Gil > Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com<mailto:jgonzalez@suse.com>

1 week, 5 days

3
3
0 0

Update 2020.x to 2021.5 failed

by Haupt, Torsten

Hi, I didn't made every uyuni update the last months, but now I did it and it failed. I think my installed version was from end oft he last year. I followed the instructions on the website and all patches and updates were installed. The schema update with the first service start last several hours, but it fineshed. But the Uyuni site is not available; only the tomcat error "HTTP Status 404 - nicht gefunden Type Status Report Beschreibung The origin server did not find a current representation for the target resource or is not willing to disclose that one exists." appears. I restarted the services and the whole server without success. Every time I do a "spacewalk-service start" the message "Starting spacewalk services... Running DB schema upgrade. This may take a while. Call the following command to see progress: journalctl -f -u uyuni-check-database.service Done." appears. journalctl -f -u uyuni-check-database.service -- Logs begin at Thu 2019-02-07 15:13:46 CET. -- Jun 02 11:56:41 smduyuni systemd[1]: Stopped Uyuni check database. Jun 02 11:56:44 smduyuni systemd[1]: Starting Uyuni check database... Jun 02 11:56:44 smduyuni spacewalk-startup-helper[22859]: Your database schema already matches the schema package version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 02 11:56:44 smduyuni spacewalk-startup-helper[22859]: Schema upgrade: [susemanager-schema-4.2.14-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 02 11:56:44 smduyuni systemd[1]: Started Uyuni check database. Jun 02 19:42:08 smduyuni systemd[1]: Stopped Uyuni check database. Jun 02 19:42:11 smduyuni systemd[1]: Starting Uyuni check database... Jun 02 19:42:11 smduyuni spacewalk-startup-helper[24088]: Your database schema already matches the schema package version [susemanager-schema-4.2.14-1.1.uyuni]. Jun 02 19:42:11 smduyuni spacewalk-startup-helper[24088]: Schema upgrade: [susemanager-schema-4.2.14-1.1.uyuni] -> [susemanager-schema-4.2.14-1.1.uyuni] Jun 02 19:42:12 smduyuni systemd[1]: Started Uyuni check database. It is always the same schema upgrade. less /var/log/tomcat/catalina.2021-06-02.log 02-Jun-2021 19:42:14.398 SEVERE [main] org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web application directory [/srv/tomcat/webapps/rhn] java.lang.IllegalStateException: Error starting child at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:720) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:705) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1132) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1865) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1044) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:429) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1575) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:421) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474) Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/rhn]] at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717) ... 37 more Caused by: java.lang.NullPointerException at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:382) at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:195) at org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:1971) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1129) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:775) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5044) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 38 more 02-Jun-2021 19:42:14.400 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/srv/tomcat/webapps/rhn] has finished in [982] ms 02-Jun-2021 19:42:14.421 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-127.0.0.1-8080"] 02-Jun-2021 19:42:14.601 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-127.0.0.1-8009"] 02-Jun-2021 19:42:14.749 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 02-Jun-2021 19:42:14.881 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [1,660] milliseconds Further logs and infos I would provide. Greets Torsten

2 weeks, 2 days

3
5
0 0

2021

2020

2019

2018

Uyuni Users June 2021