Thanks to several people for the advice. It is now 5 hours with no visible change although postgres is certainly busy... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14080 postgres 20 0 3232908 2.918g 2.856g R 99.34 24.89 350:24.35 postgres Files in /var/lib/pgsql/data/pg_stat_tmp/ are constantly changing I will leave it running overnight. I think it would be helpful for the scripts involved in this process to make some sort of report back to the user on progress from time to time! T *Please note I am not normally in the office on Mondays or Fridays* ___________________________________________________________ TIM SHAW - Deputy Director - Network Services Medical Sciences Division - University of Oxford email : tim.shaw@medsci.ox.ac.uk tel : +44 (0)1865 289480
Julio González Gil <jgonzalez@suse.com> 04/03/2021 17:28 >>>
Most likely it's not stuck. At the release notes there's a note for the 2021.01 entry about the PostgreSQL upgrade taking up to several hours depending on the environment. On jueves, 4 de marzo de 2021 17:24:08 (CET) Tim Shaw wrote:
Hello
Just upgrading today from 2020.03. Yes ‑ from last March. All seems to be
going well but...
The database migration from 10 to 12 has been sitting without any obvious progress for over an hour ‑ is it stuck?
The processes are still running:
13756 ? Ss 0:00 /bin/bash
/usr/sbin/spacewalk‑startup‑helper
check‑database 13768 ? S 0:08 /usr/bin/perl
/usr/bin/spacewalk‑schema‑upgrade ‑y 14078 ? S 0:00 psql ‑U
uyuni ‑d uyuni ‑h localhost ‑p 5432 ‑v ON_ERROR_STOP=ON ‑f ‑
And the screen running the upgrade says:
15:03:44 Successfully upgraded database to postgresql 12. 15:03:44 Tune new postgresql configuration... INFO: Database configuration has been changed. INFO: Wrote new general configuration. Backup as /var/lib/pgsql/data/postgresql.2021‑03‑04‑15‑03‑46.conf INFO: Wrote
new
client auth configuration. Backup as /var/lib/pgsql/data/pg_hba.2021‑03‑04‑15‑03‑46.conf INFO: Configuration has
been changed, but your database is right now offline. Database is offline System check finished 15:03:46 Successfully tuned new postgresql configuration. 15:03:46 Starting spacewalk services... 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
But this hasn't changed for over an hour:
spacewalk:~ # journalctl ‑f ‑u uyuni‑check‑database.service
‑‑ Logs begin at Thu 2021‑03‑04 13:50:15 GMT. ‑‑
Mar 04 15:03:58 spacewalk spacewalk‑startup‑helper[13756]: Schema upgrade:
[susemanager‑schema‑4.1.7‑1.1.uyuni] ‑>
[susemanager‑schema‑4.2.8‑1.3.uyuni] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for upgrade path to:
[susemanager‑schema‑4.2.8‑1] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for upgrade path to:
[susemanager‑schema‑4.2.8] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for start path:
[susemanager‑schema‑4.1.7‑1] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for start path:
[susemanager‑schema‑4.1.7] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: The path: [susemanager‑schema‑4.1.7] ‑>
[susemanager‑schema‑4.1.8] ‑> [susemanager‑schema‑4.1.9] ‑>
[susemanager‑schema‑4.1.10] ‑> [susemanager‑schema‑4.1.11] ‑>
[susemanager‑schema‑4.2.0] ‑> [susemanager‑schema‑4.2.1] ‑>
[susemanager‑schema‑4.2.2] ‑> [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] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Planning to run schema upgrade with dir
'/var/log/spacewalk/schema‑upgrade/schema‑from‑20210304‑150358' Mar 04
15:03:58 spacewalk spacewalk‑startup‑helper[13756]: Executing
spacewalk‑sql, the log is in
[/var/log/spacewalk/schema‑upgrade/schema‑from‑20210304‑150358‑to‑susemanag
er‑schema‑4.2.8.log]. Mar 04 15:04:01 spacewalk
spacewalk‑startup‑helper[13756]: [2.0K blob data] Mar 04 15:04:03 spacewalk
spacewalk‑startup‑helper[13756]: [2.0K blob data]
Should I be more patient? Advice welcome!
T
*Please note I am not normally in the office on Mondays or Fridays* ___________________________________________________________ TIM SHAW ‑ Deputy Director ‑ Network Services
Medical Sciences Division ‑ University of Oxford
email : tim.shaw@medsci.ox.ac.uk
tel : +44 (0)1865 289480
‑‑ Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
Hi More info is not really possible. At least I do not know how. 1. it is a systemd service. systemd try really everything to not let some script print anything on the console. 2. There is really only 1 query running inside of the DB. This query takes so long and AFAIK postgresql has no progress when executing a query. So our only chance was to write in the release notes that it might take longer. We had reports about 9 hours on big enterprise hardware. So 5 hours is still in inside a normal range. Am Donnerstag, 4. März 2021, 22:04:16 CET schrieb Tim Shaw:
Thanks to several people for the advice.
It is now 5 hours with no visible change although postgres is certainly busy...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14080 postgres 20 0 3232908 2.918g 2.856g R 99.34 24.89 350:24.35 postgres
Files in /var/lib/pgsql/data/pg_stat_tmp/ are constantly changing
I will leave it running overnight. I think it would be helpful for the scripts involved in this process to make some sort of report back to the user on progress from time to time!
T
*Please note I am not normally in the office on Mondays or Fridays* ___________________________________________________________ TIM SHAW - Deputy Director - Network Services Medical Sciences Division - University of Oxford email : tim.shaw@medsci.ox.ac.uk tel : +44 (0)1865 289480
Julio González Gil <jgonzalez@suse.com> 04/03/2021 17:28 >>>
Most likely it's not stuck. At the release notes there's a note for the
2021.01 entry about the PostgreSQL upgrade taking up to several hours depending on the environment.
On jueves, 4 de marzo de 2021 17:24:08 (CET) Tim Shaw wrote:
Hello
Just upgrading today from 2020.03. Yes ‑ from last March. All seems to be
going well but...
The database migration from 10 to 12 has been sitting without any obvious progress for over an hour ‑ is it stuck?
The processes are still running:
13756 ? Ss 0:00 /bin/bash
/usr/sbin/spacewalk‑startup‑helper
check‑database 13768 ? S 0:08 /usr/bin/perl
/usr/bin/spacewalk‑schema‑upgrade ‑y 14078 ? S 0:00 psql ‑U
uyuni ‑d uyuni ‑h localhost ‑p 5432 ‑v ON_ERROR_STOP=ON ‑f ‑
And the screen running the upgrade says:
15:03:44 Successfully upgraded database to postgresql 12. 15:03:44 Tune new postgresql configuration... INFO: Database configuration has been changed. INFO: Wrote new general configuration. Backup as /var/lib/pgsql/data/postgresql.2021‑03‑04‑15‑03‑46.conf INFO: Wrote
new
client auth configuration. Backup as /var/lib/pgsql/data/pg_hba.2021‑03‑04‑15‑03‑46.conf INFO: Configuration has
been changed, but your database is right now offline. Database is offline System check finished 15:03:46 Successfully tuned new postgresql configuration. 15:03:46 Starting spacewalk services... 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
But this hasn't changed for over an hour:
spacewalk:~ # journalctl ‑f ‑u uyuni‑check‑database.service
‑‑ Logs begin at Thu 2021‑03‑04 13:50:15 GMT. ‑‑
Mar 04 15:03:58 spacewalk spacewalk‑startup‑helper[13756]: Schema upgrade:
[susemanager‑schema‑4.1.7‑1.1.uyuni] ‑>
[susemanager‑schema‑4.2.8‑1.3.uyuni] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for upgrade path to:
[susemanager‑schema‑4.2.8‑1] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for upgrade path to:
[susemanager‑schema‑4.2.8] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for start path:
[susemanager‑schema‑4.1.7‑1] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for start path:
[susemanager‑schema‑4.1.7] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: The path: [susemanager‑schema‑4.1.7] ‑>
[susemanager‑schema‑4.1.8] ‑> [susemanager‑schema‑4.1.9] ‑>
[susemanager‑schema‑4.1.10] ‑> [susemanager‑schema‑4.1.11] ‑>
[susemanager‑schema‑4.2.0] ‑> [susemanager‑schema‑4.2.1] ‑>
[susemanager‑schema‑4.2.2] ‑> [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] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Planning to run schema upgrade with dir
'/var/log/spacewalk/schema‑upgrade/schema‑from‑20210304‑150358' Mar 04
15:03:58 spacewalk spacewalk‑startup‑helper[13756]: Executing
spacewalk‑sql, the log is in
[/var/log/spacewalk/schema‑upgrade/schema‑from‑20210304‑150358‑to‑susemanag
er‑schema‑4.2.8.log]. Mar 04 15:04:01 spacewalk
spacewalk‑startup‑helper[13756]: [2.0K blob data] Mar 04 15:04:03 spacewalk
spacewalk‑startup‑helper[13756]: [2.0K blob data]
Should I be more patient? Advice welcome!
T
*Please note I am not normally in the office on Mondays or Fridays* ___________________________________________________________ TIM SHAW ‑ Deputy Director ‑ Network Services
Medical Sciences Division ‑ University of Oxford
email : tim.shaw@medsci.ox.ac.uk
tel : +44 (0)1865 289480
‑‑
Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com
-- Regards Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com -------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg)
So it completed after 13 hours ! All looks good - I just needed to be patient However I was puzzled by this message at the end... "It seems database backups via smdba had been configured for postgresql 10. Please re-configure backup for new database version!" I was not aware there was any postgres version specific config in the smdba backup. Does anyone know what this means or what action needs to be taken? T _________________________________________ TIM SHAW - Deputy Director - Network Services Medical Sciences Division - University of Oxford email : tim.shaw@medsci.ox.ac.uk tel : +44 (0)1865 289480 ________________________________ From: Tim Shaw <Tim.Shaw@medsci.ox.ac.uk> Sent: 04 March 2021 21:04 To: users@lists.uyuni-project.org <users@lists.uyuni-project.org> Subject: Re: Upgrade stuck or not... Thanks to several people for the advice. It is now 5 hours with no visible change although postgres is certainly busy... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14080 postgres 20 0 3232908 2.918g 2.856g R 99.34 24.89 350:24.35 postgres Files in /var/lib/pgsql/data/pg_stat_tmp/ are constantly changing I will leave it running overnight. I think it would be helpful for the scripts involved in this process to make some sort of report back to the user on progress from time to time! T *Please note I am not normally in the office on Mondays or Fridays* ___________________________________________________________ TIM SHAW - Deputy Director - Network Services Medical Sciences Division - University of Oxford email : tim.shaw@medsci.ox.ac.uk tel : +44 (0)1865 289480
Julio González Gil <jgonzalez@suse.com<mailto:jgonzalez@suse.com>> 04/03/2021 17:28 >>>
Most likely it's not stuck. At the release notes there's a note for the 2021.01 entry about the PostgreSQL upgrade taking up to several hours depending on the environment. On jueves, 4 de marzo de 2021 17:24:08 (CET) Tim Shaw wrote:
Hello
Just upgrading today from 2020.03. Yes ‑ from last March. All seems to be
going well but...
The database migration from 10 to 12 has been sitting without any obvious progress for over an hour ‑ is it stuck?
The processes are still running:
13756 ? Ss 0:00 /bin/bash /usr/sbin/spacewalk‑startup‑helper
check‑database 13768 ? S 0:08 /usr/bin/perl
/usr/bin/spacewalk‑schema‑upgrade ‑y 14078 ? S 0:00 psql ‑U
uyuni ‑d uyuni ‑h localhost ‑p 5432 ‑v ON_ERROR_STOP=ON ‑f ‑
And the screen running the upgrade says:
15:03:44 Successfully upgraded database to postgresql 12. 15:03:44 Tune new postgresql configuration... INFO: Database configuration has been changed. INFO: Wrote new general configuration. Backup as /var/lib/pgsql/data/postgresql.2021‑03‑04‑15‑03‑46.conf INFO: Wrote new
client auth configuration. Backup as /var/lib/pgsql/data/pg_hba.2021‑03‑04‑15‑03‑46.conf INFO: Configuration has
been changed, but your database is right now offline. Database is offline System check finished 15:03:46 Successfully tuned new postgresql configuration. 15:03:46 Starting spacewalk services... 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
But this hasn't changed for over an hour:
spacewalk:~ # journalctl ‑f ‑u uyuni‑check‑database.service
‑‑ Logs begin at Thu 2021‑03‑04 13:50:15 GMT. ‑‑
Mar 04 15:03:58 spacewalk spacewalk‑startup‑helper[13756]: Schema upgrade:
[susemanager‑schema‑4.1.7‑1.1.uyuni] ‑>
[susemanager‑schema‑4.2.8‑1.3.uyuni] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for upgrade path to:
[susemanager‑schema‑4.2.8‑1] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for upgrade path to:
[susemanager‑schema‑4.2.8] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for start path:
[susemanager‑schema‑4.1.7‑1] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for start path:
[susemanager‑schema‑4.1.7] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: The path: [susemanager‑schema‑4.1.7] ‑>
[susemanager‑schema‑4.1.8] ‑> [susemanager‑schema‑4.1.9] ‑>
[susemanager‑schema‑4.1.10] ‑> [susemanager‑schema‑4.1.11] ‑>
[susemanager‑schema‑4.2.0] ‑> [susemanager‑schema‑4.2.1] ‑>
[susemanager‑schema‑4.2.2] ‑> [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] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Planning to run schema upgrade with dir
'/var/log/spacewalk/schema‑upgrade/schema‑from‑20210304‑150358' Mar 04
15:03:58 spacewalk spacewalk‑startup‑helper[13756]: Executing
spacewalk‑sql, the log is in
[/var/log/spacewalk/schema‑upgrade/schema‑from‑20210304‑150358‑to‑susemanag
er‑schema‑4.2.8.log]. Mar 04 15:04:01 spacewalk
spacewalk‑startup‑helper[13756]: [2.0K blob data] Mar 04 15:04:03 spacewalk
spacewalk‑startup‑helper[13756]: [2.0K blob data]
Should I be more patient? Advice welcome!
T
*Please note I am not normally in the office on Mondays or Fridays* ___________________________________________________________ TIM SHAW ‑ Deputy Director ‑ Network Services
Medical Sciences Division ‑ University of Oxford
email : tim.shaw@medsci.ox.ac.uk<mailto:tim.shaw@medsci.ox.ac.uk>
tel : +44 (0)1865 289480
‑‑ Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com<mailto:jgonzalez@suse.com>
Hi postgresql sometimes change config parameters from version to version. I remember that DB backup had changed, or better the restore. In version lower than 12 you had to create a recovery.conf file while in current version a restore command is required in the postgresql.conf. But this message is always printed when you run pg-migrate-10-to-12.sh and backup is configured. While checking the code it seems you can ignore this as this change will be made when you call "restore". I think this message was just copy&paste from older DB migrations where you really had to do something for the "backup" part. Am Freitag, 5. März 2021, 09:12:13 CET schrieb Tim Shaw:
So it completed after 13 hours !
All looks good - I just needed to be patient
However I was puzzled by this message at the end...
"It seems database backups via smdba had been configured for postgresql 10. Please re-configure backup for new database version!"
I was not aware there was any postgres version specific config in the smdba backup.
Does anyone know what this means or what action needs to be taken?
T
_________________________________________ TIM SHAW - Deputy Director - Network Services Medical Sciences Division - University of Oxford email : tim.shaw@medsci.ox.ac.uk tel : +44 (0)1865 289480
________________________________ From: Tim Shaw <Tim.Shaw@medsci.ox.ac.uk> Sent: 04 March 2021 21:04 To: users@lists.uyuni-project.org <users@lists.uyuni-project.org> Subject: Re: Upgrade stuck or not...
Thanks to several people for the advice.
It is now 5 hours with no visible change although postgres is certainly busy...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14080 postgres 20 0 3232908 2.918g 2.856g R 99.34 24.89 350:24.35 postgres
Files in /var/lib/pgsql/data/pg_stat_tmp/ are constantly changing
I will leave it running overnight. I think it would be helpful for the scripts involved in this process to make some sort of report back to the user on progress from time to time!
T
*Please note I am not normally in the office on Mondays or Fridays* ___________________________________________________________ TIM SHAW - Deputy Director - Network Services Medical Sciences Division - University of Oxford email : tim.shaw@medsci.ox.ac.uk tel : +44 (0)1865 289480
Julio González Gil <jgonzalez@suse.com<mailto:jgonzalez@suse.com>> 04/03/2021 17:28 >>>
Most likely it's not stuck. At the release notes there's a note for the 2021.01 entry about the PostgreSQL upgrade taking up to several hours depending on the environment.
On jueves, 4 de marzo de 2021 17:24:08 (CET) Tim Shaw wrote:
Hello
Just upgrading today from 2020.03. Yes ‑ from last March. All seems to be
going well but...
The database migration from 10 to 12 has been sitting without any obvious progress for over an hour ‑ is it stuck?
The processes are still running:
13756 ? Ss 0:00 /bin/bash /usr/sbin/spacewalk‑startup‑helper
check‑database 13768 ? S 0:08 /usr/bin/perl
/usr/bin/spacewalk‑schema‑upgrade ‑y 14078 ? S 0:00 psql ‑U
uyuni ‑d uyuni ‑h localhost ‑p 5432 ‑v ON_ERROR_STOP=ON ‑f ‑
And the screen running the upgrade says:
15:03:44 Successfully upgraded database to postgresql 12. 15:03:44 Tune new postgresql configuration... INFO: Database configuration has been changed. INFO: Wrote new general configuration. Backup as /var/lib/pgsql/data/postgresql.2021‑03‑04‑15‑03‑46.conf INFO: Wrote new
client auth configuration. Backup as /var/lib/pgsql/data/pg_hba.2021‑03‑04‑15‑03‑46.conf INFO: Configuration has
been changed, but your database is right now offline. Database is offline System check finished 15:03:46 Successfully tuned new postgresql configuration. 15:03:46 Starting spacewalk services... 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
But this hasn't changed for over an hour:
spacewalk:~ # journalctl ‑f ‑u uyuni‑check‑database.service
‑‑ Logs begin at Thu 2021‑03‑04 13:50:15 GMT. ‑‑
Mar 04 15:03:58 spacewalk spacewalk‑startup‑helper[13756]: Schema upgrade:
[susemanager‑schema‑4.1.7‑1.1.uyuni] ‑>
[susemanager‑schema‑4.2.8‑1.3.uyuni] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for upgrade path to:
[susemanager‑schema‑4.2.8‑1] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for upgrade path to:
[susemanager‑schema‑4.2.8] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for start path:
[susemanager‑schema‑4.1.7‑1] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Searching for start path:
[susemanager‑schema‑4.1.7] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: The path: [susemanager‑schema‑4.1.7] ‑>
[susemanager‑schema‑4.1.8] ‑> [susemanager‑schema‑4.1.9] ‑>
[susemanager‑schema‑4.1.10] ‑> [susemanager‑schema‑4.1.11] ‑>
[susemanager‑schema‑4.2.0] ‑> [susemanager‑schema‑4.2.1] ‑>
[susemanager‑schema‑4.2.2] ‑> [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] Mar 04 15:03:58 spacewalk
spacewalk‑startup‑helper[13756]: Planning to run schema upgrade with dir
'/var/log/spacewalk/schema‑upgrade/schema‑from‑20210304‑150358' Mar 04
15:03:58 spacewalk spacewalk‑startup‑helper[13756]: Executing
spacewalk‑sql, the log is in
[/var/log/spacewalk/schema‑upgrade/schema‑from‑20210304‑150358‑to‑susemanag
er‑schema‑4.2.8.log]. Mar 04 15:04:01 spacewalk
spacewalk‑startup‑helper[13756]: [2.0K blob data] Mar 04 15:04:03 spacewalk
spacewalk‑startup‑helper[13756]: [2.0K blob data]
Should I be more patient? Advice welcome!
T
*Please note I am not normally in the office on Mondays or Fridays* ___________________________________________________________ TIM SHAW ‑ Deputy Director ‑ Network Services
Medical Sciences Division ‑ University of Oxford
email : tim.shaw@medsci.ox.ac.uk<mailto:tim.shaw@medsci.ox.ac.uk>
tel : +44 (0)1865 289480
‑‑
Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez@suse.com<mailto:jgonzalez@suse.com>
-- Regards Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com -------------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg)
participants (3)
-
Michael Calmer -
Tim Shaw -
Tim Shaw