From Dick.Waite at softwareag.com Sun Apr 1 02:23:57 2018 From: Dick.Waite at softwareag.com (Waite, Dick (External)) Date: Sun, 1 Apr 2018 08:23:57 +0000 Subject: [sle-beta] Gnome and a good Script Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D0120778CF4@daeexmbx1.eur.ad.sag> Grand Morning Malcolm et al An example is worth 10,000 of my words.... Your in a Gnome session...sad but true... sag at mcrjw02-15-0-2:/opt/softwareag$ script fred"$(date +"%Y_%m_%d_%I_%M_%p").log" # so you enter the script command and give it an output file fred and you try ( I'm trying) ) to give it date/time. It comes back, when you have got it right, with the start string.... Script started, file is fred2018_04_01_10_04_am.log [Setting environment for Adabas Client] [done] This is Adabas getting in on the act, but it does show your getting all the stuff... sag at mcrjw02-15-0-2:/opt/softwareag$ # some input ### this is me giving some input sag at mcrjw02-15-0-2:/opt/softwareag$ exit ## and then I say enough is enough exit Script done, file is fred2018_04_01_10_04_am.log sag at mcrjw02-15-0-2:/opt/softwareag$ cat fred2018_04_01_10_04_am.log ### I now cat the output file to see what we have... Script started on Sun 01 Apr 2018 10:04:28 CEST [Setting environment for Adabas Client] [done] [Setting environment for Adabas 6.3 SP4] [done] sag at mcrjw02-15-0-2:/opt/softwareag$ # some input sag at mcrjw02-15-0-2:/opt/softwareag$ exit exit Script done on Sun 01 Apr 2018 10:04:45 CEST sag at mcrjw02-15-0-2:/opt/softwareag$ ################################################### == ############################################### That is where I'm at, but I have seen some example on the web that do more exciting things and as I expect many on this forum needs some mind games over Easter I thought I'd ask.... The best will get my thanks ;o) and of course those of our new young people. Happy Easter All __R Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolmlewis at cableone.net Sun Apr 1 10:35:35 2018 From: malcolmlewis at cableone.net (Malcolm) Date: Sun, 1 Apr 2018 11:35:35 -0500 Subject: [sle-beta] Gnome and a good Script In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D0120778CF4@daeexmbx1.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D0120778CF4@daeexmbx1.eur.ad.sag> Message-ID: <20180401113535.2c504ca9@grover.homelinux.org> On Sun, 1 Apr 2018 08:23:57 +0000 "Waite, Dick (External)" wrote: > Grand Morning Malcolm et al > > An example is worth 10,000 of my words.... > > Your in a Gnome session...sad but true... > Something like; http://paste.opensuse.org/view/raw/128ec1d6 Or your after the screen output as well? -- Cheers Malcolm ??? SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.3 | GNOME 3.20.2 | 4.4.120-45-default HP 255 G4 Notebook | A6-6310 X4 @ 1.80 GHz | AMD Radeon R4 up 6 days 11:43, 1 user, load average: 3.91, 3.29, 2.71 From Dick.Waite at softwareag.com Mon Apr 2 22:19:37 2018 From: Dick.Waite at softwareag.com (Waite, Dick (External)) Date: Tue, 3 Apr 2018 04:19:37 +0000 Subject: [sle-beta] LEAP 15 et al Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> Grand Morning, It was a wet Easter here, so I had a look at LEAP 15 ( was known as LEAP 42.3 ). It's available at http://download.opensuse.org/distribution/leap/15.0/iso/ and they are looking for Beta people. So if you haven't had enough with SLES 15 be a hobby Beta with LEAP 15. For those missing your favorite DM the KDE on LEAP 15 is good , I'm sure Gnome is there too... I have been running with Windows 10 Beta's for the past couple of years and with RS4 coming out very soon, it good to see KDE can compete with what is good crisp pictures on Win 10 RS4. openSUSE LEAP 15 has no SCC or Register stuff , just zppper DUP for updates and then zypper UP when it's GA, about end of May start of June. So if you have the time, enjoy SLES 15 with KDE, go LEAP 15 and enjoy. Now back to the day job... __R Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbrown at suse.de Tue Apr 3 01:27:39 2018 From: rbrown at suse.de (Richard Brown) Date: Tue, 3 Apr 2018 09:27:39 +0200 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> Message-ID: <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> > On 3. Apr 2018, at 06:19, Waite, Dick (External) wrote: > > Grand Morning, > > It was a wet Easter here, so I had a look at LEAP 15 ( was known as LEAP 42.3 ). It's available at http://download.opensuse.org/distribution/leap/15.0/iso/ and they are looking for Beta people. So if you haven't had enough with SLES 15 be a hobby Beta with LEAP 15. For those missing your favorite DM the KDE on LEAP 15 is good , I'm sure Gnome is there too... I have been running with Windows 10 Beta's for the past couple of years and with RS4 coming out very soon, it good to see KDE can compete with what is good crisp pictures on Win 10 RS4. > > openSUSE LEAP 15 has no SCC or Register stuff , just zppper DUP for updates and then zypper UP when it's GA, about end of May start of June. So if you have the time, enjoy SLES 15 with KDE, go LEAP 15 and enjoy. > > Now back to the day job... > > __R Thanks for the kind words & attention Dick. There is one thing I would like to add. We aim for Leap 15 to be the first openSUSE release with a supported migration path to SLE 15 I believe the process is documented in the SLE 15 Beta documentation I would personally appreciate it if any of the beta testers on this list could find the time to try it out. We?re testing it heavily internally, but as this is one feature we can?t expect the openSUSE community to test much (due to the absence of SLE 15 codes), the participants of this beta programme could be a great help Regards Richard openSUSE Chairman > > Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com > > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrd at netlab1.net Tue Apr 3 01:30:43 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Tue, 3 Apr 2018 08:30:43 +0100 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> Message-ID: <66926d64-4554-35b5-8862-bb20a2b2231e@netlab1.net> ??? Seconding Dick's comments. LEAP is an interesting platform upon which to experiment and test forward looking applications and situations while maintaining the solid SLES basis. I use it here for just that purpose: test and build with more recent components than regular SLES. As the name says, it is a look ahead. ??? Thanks, ??? Joe D. On 03/04/2018 05:19, Waite, Dick (External) wrote: > Grand Morning, > > It was a wet Easter here, so I had a look at LEAP 15 ( was known as > LEAP 42.3 ). It's available at > http://download.opensuse.org/distribution/leap/15.0/iso/ > and they > are looking for Beta people. So if you haven't had enough with SLES 15 > be a hobby Beta with LEAP 15. For those missing your favorite DM the > KDE on LEAP 15 is good , I'm sure Gnome is there too... I have been > running with Windows 10 Beta's for the past couple of years and with > RS4 coming out very soon, it good to see KDE can compete with what is > good crisp pictures on Win 10 RS4. > > openSUSE LEAP 15 has no SCC or Register stuff , just zppper DUP for > updates and then zypper UP when it's GA, about end of May start of > June.? So if you have the time, enjoy SLES 15 with KDE, go LEAP 15 and > enjoy. > > Now back to the day job... > > __R > > Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 > Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt > HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich > (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd > Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of > the Supervisory Board: Dr. Andreas Bereczky - *http://www.softwareag.com* > > > > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dick.Waite at softwareag.com Tue Apr 3 01:57:33 2018 From: Dick.Waite at softwareag.com (Waite, Dick (External)) Date: Tue, 3 Apr 2018 07:57:33 +0000 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D0120779BB8@daeexmbx1.eur.ad.sag> Grand Morning Richard, One can see the holiday is over, the sun is shining? I?d be very happy to give the migration path a run when it?s available. I spent most of my time on SLES15 Beta trying to get migration to work ;o) I added a couple of LEAP 15?s onto my SAG environment this morning, but I expect most of that work will be done from the grand home_Office. It?s good to see KDE looking good on openSUSE. I?m on holiday for two weeks in April, getting some sun, I?ll be back in the saddle for May / June. __R From: Richard Brown [mailto:rbrown at suse.de] Sent: Dienstag, 3. April 2018 09:28 To: Waite, Dick (External) Cc: sle-beta at lists.suse.com Subject: Re: [sle-beta] LEAP 15 et al On 3. Apr 2018, at 06:19, Waite, Dick (External) > wrote: Grand Morning, It was a wet Easter here, so I had a look at LEAP 15 ( was known as LEAP 42.3 ). It's available at http://download.opensuse.org/distribution/leap/15.0/iso/ and they are looking for Beta people. So if you haven't had enough with SLES 15 be a hobby Beta with LEAP 15. For those missing your favorite DM the KDE on LEAP 15 is good , I'm sure Gnome is there too... I have been running with Windows 10 Beta's for the past couple of years and with RS4 coming out very soon, it good to see KDE can compete with what is good crisp pictures on Win 10 RS4. openSUSE LEAP 15 has no SCC or Register stuff , just zppper DUP for updates and then zypper UP when it's GA, about end of May start of June. So if you have the time, enjoy SLES 15 with KDE, go LEAP 15 and enjoy. Now back to the day job... __R Thanks for the kind words & attention Dick. There is one thing I would like to add. We aim for Leap 15 to be the first openSUSE release with a supported migration path to SLE 15 I believe the process is documented in the SLE 15 Beta documentation I would personally appreciate it if any of the beta testers on this list could find the time to try it out. We?re testing it heavily internally, but as this is one feature we can?t expect the openSUSE community to test much (due to the absence of SLE 15 codes), the participants of this beta programme could be a great help Regards Richard openSUSE Chairman Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com _______________________________________________ sle-beta mailing list sle-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbrown at suse.de Tue Apr 3 02:10:06 2018 From: rbrown at suse.de (Richard Brown) Date: Tue, 03 Apr 2018 10:10:06 +0200 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> Message-ID: <4d8f6bde5ca22405559ebb94a71eee310255e302.camel@suse.de> On Tue, 2018-04-03 at 09:27 +0200, Richard Brown wrote: > > > On 3. Apr 2018, at 06:19, Waite, Dick (External) wrote: > > > Grand Morning, > > > > It was a wet Easter here, so I had a look at LEAP 15 ( was known as LEAP 42.3 ). It's available at http://download.opensuse.org/distribution/leap/15.0/iso/ and they are looking for Beta people. So if you haven't had enough with SLES 15 be a hobby Beta with LEAP 15. For those missing your favorite DM the KDE on LEAP 15 is good , I'm sure Gnome is there too... I have been running with Windows 10 Beta's for the past couple of years and with RS4 coming out very soon, it good to see KDE can compete with what is good crisp pictures on Win 10 RS4. > > > > openSUSE LEAP 15 has no SCC or Register stuff , just zppper DUP for updates and then zypper UP when it's GA, about end of May start of June. So if you have the time, enjoy SLES 15 with KDE, go LEAP 15 and enjoy. > > > > Now back to the day job... > > > > __R > > Thanks for the kind words & attention Dick. > > There is one thing I would like to add. We aim for Leap 15 to be the first openSUSE release with a supported migration path to SLE 15 > > I believe the process is documented in the SLE 15 Beta documentation > > I would personally appreciate it if any of the beta testers on this list could find the time to try it out. > > We?re testing it heavily internally, but as this is one feature we can?t expect the openSUSE community to test much (due to the absence of SLE 15 codes), the participants of this beta programme could be a great help > > Regards > > Richard > openSUSE Chairman For reference, here's the current documentation for migrating Leap to SLE 15 https://susedoc.github.io/doc-sle/develop/SLES-upgrade/html/cha.upgrade-online.html#sec.upgrade-online.opensuse_to_sle -- Richard Brown Linux Distribution Engineer - Future Technology Team Chairman - openSUSE Phone +4991174053-361 SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From Dick.Waite at softwareag.com Tue Apr 3 02:53:54 2018 From: Dick.Waite at softwareag.com (Waite, Dick (External)) Date: Tue, 3 Apr 2018 08:53:54 +0000 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <4d8f6bde5ca22405559ebb94a71eee310255e302.camel@suse.de> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> <4d8f6bde5ca22405559ebb94a71eee310255e302.camel@suse.de> Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D0120779C7D@daeexmbx1.eur.ad.sag> Many Thanks Richard, << Warning: Not All openSUSE Packages can be Migrated >> There was I thinking this might be a back door to get KDE onto SLES ;o) ;o) ;o) __R -----Original Message----- From: sle-beta-bounces at lists.suse.com [mailto:sle-beta-bounces at lists.suse.com] On Behalf Of Richard Brown Sent: Dienstag, 3. April 2018 10:10 To: sle-beta at lists.suse.com Subject: Re: [sle-beta] LEAP 15 et al On Tue, 2018-04-03 at 09:27 +0200, Richard Brown wrote: > > > On 3. Apr 2018, at 06:19, Waite, Dick (External) wrote: > > > Grand Morning, > > > > It was a wet Easter here, so I had a look at LEAP 15 ( was known as LEAP 42.3 ). It's available at http://download.opensuse.org/distribution/leap/15.0/iso/ and they are looking for Beta people. So if you haven't had enough with SLES 15 be a hobby Beta with LEAP 15. For those missing your favorite DM the KDE on LEAP 15 is good , I'm sure Gnome is there too... I have been running with Windows 10 Beta's for the past couple of years and with RS4 coming out very soon, it good to see KDE can compete with what is good crisp pictures on Win 10 RS4. > > > > openSUSE LEAP 15 has no SCC or Register stuff , just zppper DUP for updates and then zypper UP when it's GA, about end of May start of June. So if you have the time, enjoy SLES 15 with KDE, go LEAP 15 and enjoy. > > > > Now back to the day job... > > > > __R > > Thanks for the kind words & attention Dick. > > There is one thing I would like to add. We aim for Leap 15 to be the > first openSUSE release with a supported migration path to SLE 15 > > I believe the process is documented in the SLE 15 Beta documentation > > I would personally appreciate it if any of the beta testers on this list could find the time to try it out. > > We?re testing it heavily internally, but as this is one feature we > can?t expect the openSUSE community to test much (due to the absence > of SLE 15 codes), the participants of this beta programme could be a > great help > > Regards > > Richard > openSUSE Chairman For reference, here's the current documentation for migrating Leap to SLE 15 https://susedoc.github.io/doc-sle/develop/SLES-upgrade/html/cha.upgrade-online.html#sec.upgrade-online.opensuse_to_sle -- Richard Brown Linux Distribution Engineer - Future Technology Team Chairman - openSUSE Phone +4991174053-361 SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) _______________________________________________ sle-beta mailing list sle-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sle-beta Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com From rbrown at suse.de Tue Apr 3 03:02:22 2018 From: rbrown at suse.de (Richard Brown) Date: Tue, 03 Apr 2018 11:02:22 +0200 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D0120779C7D@daeexmbx1.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> <4d8f6bde5ca22405559ebb94a71eee310255e302.camel@suse.de> <46AC8C81C10B8C48820201DF2AE1D76D0120779C7D@daeexmbx1.eur.ad.sag> Message-ID: <412c0846f3370e0c3a0e58120b0b6bb735f092f1.camel@suse.de> On Tue, 2018-04-03 at 08:53 +0000, Waite, Dick (External) wrote: > Many Thanks Richard, > > << Warning: Not All openSUSE Packages can be Migrated >> > > There was I thinking this might be a back door to get KDE onto SLES ;o) ;o) ;o) that back door is called PackageHub ;) https://packagehub.suse.com/ KDE is there for SLE 12 and I would be _very_ surprised if the collaboration between the openSUSE community & SUSE behind packagehub doesn't result in KDE for SLE 15 also such packages are unsupported, of course, but do not compromise your support of the rest of your SLE system. HTH > > __R > > > -----Original Message----- > From: sle-beta-bounces at lists.suse.com [mailto:sle-beta-bounces at lists.suse.com] On Behalf Of Richard Brown > Sent: Dienstag, 3. April 2018 10:10 > To: sle-beta at lists.suse.com > Subject: Re: [sle-beta] LEAP 15 et al > > On Tue, 2018-04-03 at 09:27 +0200, Richard Brown wrote: > > > > > > On 3. Apr 2018, at 06:19, Waite, Dick (External) wrote: > > > > > Grand Morning, > > > > > > It was a wet Easter here, so I had a look at LEAP 15 ( was known as LEAP 42.3 ). It's available at http://download.opensuse.org/distribution/leap/15.0/iso/ and they are looking for Beta people. So if you haven't had enough with SLES 15 be a hobby Beta with LEAP 15. For those missing your favorite DM the KDE on LEAP 15 is good , I'm sure Gnome is there too... I have been running with Windows 10 Beta's for the past couple of years and with RS4 coming out very soon, it good to see KDE can compete with what is good crisp pictures on Win 10 RS4. > > > > > > openSUSE LEAP 15 has no SCC or Register stuff , just zppper DUP for updates and then zypper UP when it's GA, about end of May start of June. So if you have the time, enjoy SLES 15 with KDE, go LEAP 15 and enjoy. > > > > > > Now back to the day job... > > > > > > __R > > > > Thanks for the kind words & attention Dick. > > > > There is one thing I would like to add. We aim for Leap 15 to be the > > first openSUSE release with a supported migration path to SLE 15 > > > > I believe the process is documented in the SLE 15 Beta documentation > > > > I would personally appreciate it if any of the beta testers on this list could find the time to try it out. > > > > We?re testing it heavily internally, but as this is one feature we > > can?t expect the openSUSE community to test much (due to the absence > > of SLE 15 codes), the participants of this beta programme could be a > > great help > > > > Regards > > > > Richard > > openSUSE Chairman > > For reference, here's the current documentation for migrating Leap to SLE 15 > > https://susedoc.github.io/doc-sle/develop/SLES-upgrade/html/cha.upgrade-online.html#sec.upgrade-online.opensuse_to_sle > > -- > Richard Brown > Linux Distribution Engineer - Future Technology Team Chairman - openSUSE > > Phone +4991174053-361 > SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg > GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) > > > > > > > > > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta > > Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com > -- Richard Brown Linux Distribution Engineer - Future Technology Team Chairman - openSUSE Phone +4991174053-361 SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From tomaz.borstnar at softergee.si Tue Apr 3 03:20:42 2018 From: tomaz.borstnar at softergee.si (=?UTF-8?B?VG9tYcW+IEJvcsWhdG5hciwgU29mdGVyZ2Vl?=) Date: Tue, 3 Apr 2018 11:20:42 +0200 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> Message-ID: When I install the Leap beta and try zypper ref/up I always get notice about stale repositories. Is this to be expected? I wanted to perform updates via zypper and not via offline update. Toma? From tomaz.borstnar at softergee.si Tue Apr 3 03:22:57 2018 From: tomaz.borstnar at softergee.si (=?UTF-8?B?VG9tYcW+IEJvcsWhdG5hciwgU29mdGVyZ2Vl?=) Date: Tue, 3 Apr 2018 11:22:57 +0200 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <412c0846f3370e0c3a0e58120b0b6bb735f092f1.camel@suse.de> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> <4d8f6bde5ca22405559ebb94a71eee310255e302.camel@suse.de> <46AC8C81C10B8C48820201DF2AE1D76D0120779C7D@daeexmbx1.eur.ad.sag> <412c0846f3370e0c3a0e58120b0b6bb735f092f1.camel@suse.de> Message-ID: <12d99808-20a9-9154-eaea-6c463510550d@softergee.si> Nice backdoor. I always wanted MATE on SLES :-) Richard Brown je 03. 04. 2018 ob 11:02?napisal: > On Tue, 2018-04-03 at 08:53 +0000, Waite, Dick (External) wrote: >> Many Thanks Richard, >> >> << Warning: Not All openSUSE Packages can be Migrated >> >> >> There was I thinking this might be a back door to get KDE onto SLES ;o) ;o) ;o) > that back door is called PackageHub ;) https://packagehub.suse.com/ > > KDE is there for SLE 12 and I would be _very_ surprised if the collaboration between the openSUSE community & > SUSE behind packagehub doesn't result in KDE for SLE 15 also > > such packages are unsupported, of course, but do not compromise your support of the rest of your SLE system. > > HTH > > > > >> >> __R >> >> >> -----Original Message----- >> From: sle-beta-bounces at lists.suse.com [mailto:sle-beta-bounces at lists.suse.com] On Behalf Of Richard Brown >> Sent: Dienstag, 3. April 2018 10:10 >> To: sle-beta at lists.suse.com >> Subject: Re: [sle-beta] LEAP 15 et al >> >> On Tue, 2018-04-03 at 09:27 +0200, Richard Brown wrote: >>> >>> On 3. Apr 2018, at 06:19, Waite, Dick (External) wrote: >>> >>>> Grand Morning, >>>> >>>> It was a wet Easter here, so I had a look at LEAP 15 ( was known as LEAP 42.3 ). It's available at http://download.opensuse.org/distribution/leap/15.0/iso/ and they are looking for Beta people. So if you haven't had enough with SLES 15 be a hobby Beta with LEAP 15. For those missing your favorite DM the KDE on LEAP 15 is good , I'm sure Gnome is there too... I have been running with Windows 10 Beta's for the past couple of years and with RS4 coming out very soon, it good to see KDE can compete with what is good crisp pictures on Win 10 RS4. >>>> >>>> openSUSE LEAP 15 has no SCC or Register stuff , just zppper DUP for updates and then zypper UP when it's GA, about end of May start of June. So if you have the time, enjoy SLES 15 with KDE, go LEAP 15 and enjoy. >>>> >>>> Now back to the day job... >>>> >>>> __R >>> Thanks for the kind words & attention Dick. >>> >>> There is one thing I would like to add. We aim for Leap 15 to be the >>> first openSUSE release with a supported migration path to SLE 15 >>> >>> I believe the process is documented in the SLE 15 Beta documentation >>> >>> I would personally appreciate it if any of the beta testers on this list could find the time to try it out. >>> >>> We?re testing it heavily internally, but as this is one feature we >>> can?t expect the openSUSE community to test much (due to the absence >>> of SLE 15 codes), the participants of this beta programme could be a >>> great help >>> >>> Regards >>> >>> Richard >>> openSUSE Chairman >> For reference, here's the current documentation for migrating Leap to SLE 15 >> >> https://susedoc.github.io/doc-sle/develop/SLES-upgrade/html/cha.upgrade-online.html#sec.upgrade-online.opensuse_to_sle >> >> -- >> Richard Brown >> Linux Distribution Engineer - Future Technology Team Chairman - openSUSE >> >> Phone +4991174053-361 >> SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg >> GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) >> >> >> >> >> >> >> >> >> _______________________________________________ >> sle-beta mailing list >> sle-beta at lists.suse.com >> http://lists.suse.com/mailman/listinfo/sle-beta >> >> Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com >> From okurz at suse.de Tue Apr 3 03:31:38 2018 From: okurz at suse.de (Oliver Kurz) Date: Tue, 03 Apr 2018 11:31:38 +0200 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> Message-ID: <2302925.4Vdli2SH81@linux-28d6.suse> On Tuesday, 3 April 2018 06:19:37 CEST Waite, Dick (External) wrote: > It was a wet Easter here, so I had a look at LEAP 15 ( was known as LEAP > 42.3 ). It's available at > http://download.opensuse.org/distribution/leap/15.0/iso/ and they are > looking for Beta people. So if you haven't had enough with SLES 15 be a > hobby Beta with LEAP 15. For those missing your favorite DM the KDE on LEAP > 15 is good , I'm sure Gnome is there too... I have been running with > Windows 10 Beta's for the past couple of years and with RS4 coming out very > soon, it good to see KDE can compete with what is good crisp pictures on > Win 10 RS4. > openSUSE LEAP 15 has no SCC or Register stuff , just zppper DUP for updates > and then zypper UP when it's GA, about end of May start of June. So if you > have the time, enjoy SLES 15 with KDE, go LEAP 15 and enjoy. Thank you for your nice report and also for trying out openSUSE Leap 15.0 Also very soon there will be the packagehub module for SLE15 - also see https://packagehub.suse.com/ - which can help bridge the gap between SLE and Leap even further by providing - for example - KDE on top of SLE, not with SLE support but at least the SLE base will be still supported :) Regards, Oliver From rbrown at suse.de Tue Apr 3 03:34:21 2018 From: rbrown at suse.de (Richard Brown) Date: Tue, 03 Apr 2018 11:34:21 +0200 Subject: [sle-beta] LEAP 15 et al In-Reply-To: References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> Message-ID: <77e58151637b9a71fae26666873fb24cae1a0404.camel@suse.de> On Tue, 2018-04-03 at 11:20 +0200, Toma? Bor?tnar, Softergee wrote: > When I install the Leap beta and try zypper ref/up I always get notice > about stale repositories. Is this to be expected? I wanted to perform > updates via zypper and not via offline update. > > Toma? Fair question, I'm not sure on the answer It's probably best to direct Leap-only related questions to the opensuse-factory at opensuse.org mailinglist where you can expect people to know :) Regards, > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -- Richard Brown Linux Distribution Engineer - Future Technology Team Chairman - openSUSE Phone +4991174053-361 SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From vmoutoussamy at suse.com Tue Apr 3 07:55:38 2018 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Tue, 3 Apr 2018 15:55:38 +0200 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> Message-ID: <9AE11621-70E1-48C7-B688-8B548A1ED456@suse.com> Bonjour, It?s definitely nice to see your interest to openSUSE LEAP ; ). We are preparing a communication about LEAP 15, so we can share all important information and links. Anyway, FYI you can check [1] to see if a openSUSE LEAP 15 package comes from SLE15 or from openSUSE:Factory. Regards, [1] https://build.opensuse.org/package/view_file/openSUSE:Leap:15.0/00Meta/lookup.yml?expand=1 -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager > On 3 Apr 2018, at 06:19, Waite, Dick (External) > wrote: > > Grand Morning, > > It was a wet Easter here, so I had a look at LEAP 15 ( was known as LEAP 42.3 ). It's available at http://download.opensuse.org/distribution/leap/15.0/iso/ and they are looking for Beta people. So if you haven't had enough with SLES 15 be a hobby Beta with LEAP 15. For those missing your favorite DM the KDE on LEAP 15 is good , I'm sure Gnome is there too... I have been running with Windows 10 Beta's for the past couple of years and with RS4 coming out very soon, it good to see KDE can compete with what is good crisp pictures on Win 10 RS4. > > openSUSE LEAP 15 has no SCC or Register stuff , just zppper DUP for updates and then zypper UP when it's GA, about end of May start of June. So if you have the time, enjoy SLES 15 with KDE, go LEAP 15 and enjoy. > > Now back to the day job... > > __R > > Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From kdupke at suse.com Tue Apr 3 08:51:42 2018 From: kdupke at suse.com (Kai Dupke) Date: Tue, 3 Apr 2018 16:51:42 +0200 Subject: [sle-beta] LEAP 15 et al In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D0120779C7D@daeexmbx1.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> <4d8f6bde5ca22405559ebb94a71eee310255e302.camel@suse.de> <46AC8C81C10B8C48820201DF2AE1D76D0120779C7D@daeexmbx1.eur.ad.sag> Message-ID: <46299c45-0ecd-817b-f693-ea443e2b7b62@suse.com> On 03.04.2018 10:53, Waite, Dick (External) wrote: > << Warning: Not All openSUSE Packages can be Migrated >> > > There was I thinking this might be a back door to get KDE onto SLES Of course this isn't he idea behind a supported migration from LEAP to SLES. The goal if this is to enable users running a community Linux to move to an enterprise Linux. Think about a small shop, not having interest in enterprise. Or even big shops believing not needing support or committed maintenance. The small shop might grow, any downtime isn't an option anymore. The big shop might find that having a support partner is a benefit (yes, the recent security challenges helped to make customers rethink some). It also is an interesting part for some development, when it is integrated into a corporate structure depending on enterprise needs (and of course, DevOps does not make these needs go away, the opposite is true by my view). This is the first time this is done, so some way will be still to go. Best regards, Kai Dupke Senior Product Manager SUSE Linux Enterprise 15 -- Sell not virtue to purchase wealth, nor liberty to purchase power. Phone: +49-(0)5102-9310828 Mail: kdupke at suse.com Mobile: +49-(0)173-5876766 WWW: www.suse.com SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany) GF:Felix Imend?rffer,Jane Smithard,Graham Norton,HRB 21284 (AG N?rnberg) From bkoo at THALESESEC.NET Tue Apr 3 13:51:58 2018 From: bkoo at THALESESEC.NET (Bong Koo) Date: Tue, 3 Apr 2018 19:51:58 +0000 Subject: [sle-beta] Need kernel-default-debuginfo package for 4.12.14-16.4-default Message-ID: <6792a26c83694d188fee101e6779b3de@EXUSDAGORL02.INTERNAL.ROOT.TES> Hi, With RC2, kernel version is 4.12.14-16.4-default while kernel-default-debuginfo package is for 4.12.14-15.5. Where / how can I get the matching kernel-default-debuginfo package ? Regards, Bong ________________________________ [cid:imageb733d3.PNG at 18ccc1a4.41ba5013] Bong Koo Sr. Software Engineer Tel: +1 669 770 6870 [cid:image3d0472.PNG at 932d2ec8.45846fbb]@thalesesecurity Thales eSecurity 2860 Junction Ave San Jose CA 95134 United States [cid:image52ef56.PNG at a676257e.4f91207e] www.thalesesecurity.com [cid:image4b812f.PNG at 144acdd6.4f83773c] [cid:image602e35.PNG at 09fcb675.43a402e3] [cid:imagebcbea3.PNG at a3bb5b89.449a3db6] [cid:imageee01ef.PNG at 9851b857.4bb5e879] [cid:image690879.PNG at 8db12b9b.48879713] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imageb733d3.PNG Type: image/png Size: 1385 bytes Desc: imageb733d3.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image3d0472.PNG Type: image/png Size: 498 bytes Desc: image3d0472.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image52ef56.PNG Type: image/png Size: 244635 bytes Desc: image52ef56.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image4b812f.PNG Type: image/png Size: 367 bytes Desc: image4b812f.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image602e35.PNG Type: image/png Size: 457 bytes Desc: image602e35.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagebcbea3.PNG Type: image/png Size: 345 bytes Desc: imagebcbea3.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imageee01ef.PNG Type: image/png Size: 340 bytes Desc: imageee01ef.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image690879.PNG Type: image/png Size: 546 bytes Desc: image690879.PNG URL: From rbrown at suse.de Thu Apr 5 01:40:32 2018 From: rbrown at suse.de (Richard Brown) Date: Thu, 05 Apr 2018 09:40:32 +0200 Subject: [sle-beta] Transactional Updates in Leap 15 Message-ID: Hi SLE Beta Testers, I know you're all busy with the SLE 15 beta and I don't want to distract you (too much) from that excellent work. But if you have any cycles left to spare, I have a request on behalf of the openSUSE project for some time testing a feature which may also be finding its way into future versions of SLE in some form. Leap 15 will be openSUSE's first stable version offering a System Role with Transactional Updates & Read-Only Root Filesystems. Already used in SUSE CaaSP & Kubic, this approach gives an even more robust method for ensuring that patches are applied correctly, completely, or not at all. If anything goes wrong, systems can be restored to their previous working state in seconds. A detailed introduction and quick start guide can be found here: https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ Any thoughts, feedback, and bug reports will be greatly appreciated. Many Thanks, -- Richard Brown Linux Distribution Engineer - Future Technology Team Chairman - openSUSE Phone +4991174053-361 SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From jrd at netlab1.net Thu Apr 5 06:25:43 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Thu, 5 Apr 2018 13:25:43 +0100 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: References: Message-ID: On 05/04/2018 08:40, Richard Brown wrote: > Hi SLE Beta Testers, > > I know you're all busy with the SLE 15 beta and I don't want to distract you (too much) from that excellent > work. > > But if you have any cycles left to spare, I have a request on behalf of the openSUSE project for some time > testing a feature which may also be finding its way into future versions of SLE in some form. > > Leap 15 will be openSUSE's first stable version offering a System Role with Transactional Updates & Read-Only > Root Filesystems. Already used in SUSE CaaSP & Kubic, this approach gives an even more robust method for > ensuring that patches are applied correctly, completely, or not at all. If anything goes wrong, systems can be > restored to their previous working state in seconds. > > A detailed introduction and quick start guide can be found here: > https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ > > Any thoughts, feedback, and bug reports will be greatly appreciated. > > Many Thanks, > --------- ??? The referenced doc is interesting to read and think about. Alas, patching nirvana is still on back-order. ??? My thinking (yours will likely vary) is as follows. The snapshot-like temp area can be as large as the main o/s file system (root) because we put more into that area than just the o/s and we try to avoid over partitioning etc. Of particular concern is the arrow of time, which means changes occur on the running system after snapping and where also patches will eventually appear. Thus the snapshot becomes out of date after the first such change to the running system. Think about databases, linked systems, memory cached data and the like. Thus a snapshot may not be a safe item to restore in many cases. ??? What makes more sense to me is patch a quiescent system. That would mean accumulate the new change sets and then bring up the system in memory based rescue mode where the regular file systems is/are otherwise not enabled. The scheme then tries applying patches one by one (with a log to revert), and if a failure occurs then consider undoing them all, with optional variations about accepting some regardless and so forth. This eliminates concerns about open files, memory caches, partial transactions, interaction amongst machines, huge extra disk space, not being restricted to BTRFS, and likely a few more nuances. It also avoids yet another installation-time-only option and thus can be used well after a machine has been built in an ordinary manner. ??? A bit of clever thinking suggests create an alternative, a "patch-medic" virtual machine whose purpose is to collect new patches and apply them to a sedated real machine and thus avoid having fancy patch mechanism(s) and whatnot built into each regular machine. Rescue mode is an existing step in that direction. ??? Thanks, ??? Joe D. From rbrown at suse.de Thu Apr 5 06:37:08 2018 From: rbrown at suse.de (Richard Brown) Date: Thu, 05 Apr 2018 14:37:08 +0200 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: References: Message-ID: <1989aee46b694a35fcb477e278369d2620fafa12.camel@suse.de> On Thu, 2018-04-05 at 13:25 +0100, Joe Doupnik wrote: > > --------- > The referenced doc is interesting to read and think about. Alas, > patching nirvana is still on back-order. > My thinking (yours will likely vary) is as follows. The > snapshot-like temp area can be as large as the main o/s file system > (root) because we put more into that area than just the o/s and we try > to avoid over partitioning etc. Of particular concern is the arrow of > time, which means changes occur on the running system after snapping and > where also patches will eventually appear. Thus the snapshot becomes out > of date after the first such change to the running system. Think about > databases, linked systems, memory cached data and the like. Thus a > snapshot may not be a safe item to restore in many cases. And that problem is addressed by the fact that the root filesystem is read-only in the system role in question. "The arrow of time" can't change anything, in the root filesystem. Note, by "root filesystem", we mean the contents of the "root subvolume" on the btrfs partition. Any other subvolume is not snapshotted, not considered part of the transactional update, and not read-only. This includes (but is not limited to) gems such as /var, /root and /home, where we expect users and services to continue their merry tasks of writing nonsense and worthwhile data to those locations. This division between "the OS root filesystem" and "everything else" is working quite well, hence the promotion of this feature from it's previous incarnation only in CaaSP & Kubic, and now suitable for a broader audience in Leap and Tumbleweed. > What makes more sense to me is patch a quiescent system. That would > mean accumulate the new change sets and then bring up the system in > memory based rescue mode where the regular file systems is/are otherwise > not enabled. The scheme then tries applying patches one by one (with a > log to revert), and if a failure occurs then consider undoing them all, > with optional variations about accepting some regardless and so forth. > This eliminates concerns about open files, memory caches, partial > transactions, interaction amongst machines, huge extra disk space, not > being restricted to BTRFS, and likely a few more nuances. It also avoids > yet another installation-time-only option and thus can be used well > after a machine has been built in an ordinary manner. This approach would be incredibly long winded. Would users really be willing to have their systems offline for so long while they patch so slowly and serially? One of the benefits of our approach is we can patch in a threaded manner - every package applies its changeset as fast and as in parallel as the system allows, but none of those changes are written to the running snapshot so impacts are avoided until the next reboot. Doesn't this strike the best balance of using the systems hardware efficiently, minimising downtime, while still ensuring updates happen atomicly? -- Richard Brown Linux Distribution Engineer - Future Technology Team Chairman - openSUSE Phone +4991174053-361 SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From kukuk at suse.de Thu Apr 5 06:38:51 2018 From: kukuk at suse.de (Thorsten Kukuk) Date: Thu, 5 Apr 2018 14:38:51 +0200 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: References: Message-ID: <20180405123851.GA18789@suse.de> On Thu, Apr 05, Joe Doupnik wrote: > ??? The referenced doc is interesting to read and think about. Alas, > patching nirvana is still on back-order. > ??? My thinking (yours will likely vary) is as follows. The snapshot-like > temp area can be as large as the main o/s file system (root) because we put > more into that area than just the o/s and we try to avoid over partitioning > etc. Of particular concern is the arrow of time, which means changes occur > on the running system after snapping and where also patches will eventually > appear. Thus the snapshot becomes out of date after the first such change to > the running system. Think about databases, linked systems, memory cached > data and the like. Thus a snapshot may not be a safe item to restore in many > cases. Please show me a database, which can write to a read-only filesystem ;) Since we work with a read-only root filesystem, you have to strictly seperate data from applicatons, and only the applications are part of the snapshot. So you will never loose data. > ??? What makes more sense to me is patch a quiescent system. That would mean > accumulate the new change sets and then bring up the system in memory based > rescue mode where the regular file systems is/are otherwise not enabled. The > scheme then tries applying patches one by one (with a log to revert), and if > a failure occurs then consider undoing them all, with optional variations > about accepting some regardless and so forth. This eliminates concerns about > open files, memory caches, partial transactions, interaction amongst > machines, huge extra disk space, not being restricted to BTRFS, and likely a > few more nuances. It also avoids yet another installation-time-only option > and thus can be used well after a machine has been built in an ordinary > manner. Your approach is what we offer today, but this does not solve any of the problems we solve with transactinal-updates. Especially not the problem of a very long downtime of the machine and services for big updates. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) From jrd at netlab1.net Thu Apr 5 07:00:27 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Thu, 5 Apr 2018 14:00:27 +0100 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: <20180405123851.GA18789@suse.de> References: <20180405123851.GA18789@suse.de> Message-ID: <6b39b935-a818-77f7-7fae-e3200151e416@netlab1.net> On 05/04/2018 13:38, Thorsten Kukuk wrote: > On Thu, Apr 05, Joe Doupnik wrote: > >> ??? The referenced doc is interesting to read and think about. Alas, >> patching nirvana is still on back-order. >> ??? My thinking (yours will likely vary) is as follows. The snapshot-like >> temp area can be as large as the main o/s file system (root) because we put >> more into that area than just the o/s and we try to avoid over partitioning >> etc. Of particular concern is the arrow of time, which means changes occur >> on the running system after snapping and where also patches will eventually >> appear. Thus the snapshot becomes out of date after the first such change to >> the running system. Think about databases, linked systems, memory cached >> data and the like. Thus a snapshot may not be a safe item to restore in many >> cases. > Please show me a database, which can write to a read-only filesystem ;) > Since we work with a read-only root filesystem, you have to strictly seperate > data from applicatons, and only the applications are part of the snapshot. > So you will never loose data. > >> ??? What makes more sense to me is patch a quiescent system. That would mean >> accumulate the new change sets and then bring up the system in memory based >> rescue mode where the regular file systems is/are otherwise not enabled. The >> scheme then tries applying patches one by one (with a log to revert), and if >> a failure occurs then consider undoing them all, with optional variations >> about accepting some regardless and so forth. This eliminates concerns about >> open files, memory caches, partial transactions, interaction amongst >> machines, huge extra disk space, not being restricted to BTRFS, and likely a >> few more nuances. It also avoids yet another installation-time-only option >> and thus can be used well after a machine has been built in an ordinary >> manner. > Your approach is what we offer today, but this does not solve any of the > problems we solve with transactinal-updates. Especially not the problem > of a very long downtime of the machine and services for big updates. > > Thorsten > ----------- ??? My suggestion appears, in essence, in Windows. Some patches are done on the fly. Others are stashed, the machine is rebooted, and the boot steps are interrupted to make changes to sensitive things before proceeding. ??? The matter of long down time, or the possibility of it occurring, is always with us. Where we can we provide fall back systems to provide continued service and be insurance against possible irreversible changes. ??? My suggestion side steps the issue of BTRFS or not, large disk space, running with r/o file systems, complicated partitioning finesse designed in at system creation time, etc. It safely deal with apps which are not built to do freeze/thaw, and it allows for regression without further complications. Of course it does not provide the running fallback. ??? The notion is worth thinking about. My own feeling is on the fly patching of important systems is asking for trouble over the long term, and I would rather not have that be in a life support system. ??? A humorous mental picture is a doctor operating upon him/herself and discovering the need for three hands or careful visual control or the need for specialized knowledge not yet accumulated, etc. Another case of not knowing in advance what we don't know. ??? Thanks, ??? Joe D. From jrd at netlab1.net Thu Apr 5 07:14:46 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Thu, 5 Apr 2018 14:14:46 +0100 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: <1989aee46b694a35fcb477e278369d2620fafa12.camel@suse.de> References: <1989aee46b694a35fcb477e278369d2620fafa12.camel@suse.de> Message-ID: On 05/04/2018 13:37, Richard Brown wrote: > On Thu, 2018-04-05 at 13:25 +0100, Joe Doupnik wrote: >> --------- >> The referenced doc is interesting to read and think about. Alas, >> patching nirvana is still on back-order. >> My thinking (yours will likely vary) is as follows. The >> snapshot-like temp area can be as large as the main o/s file system >> (root) because we put more into that area than just the o/s and we try >> to avoid over partitioning etc. Of particular concern is the arrow of >> time, which means changes occur on the running system after snapping and >> where also patches will eventually appear. Thus the snapshot becomes out >> of date after the first such change to the running system. Think about >> databases, linked systems, memory cached data and the like. Thus a >> snapshot may not be a safe item to restore in many cases. > And that problem is addressed by the fact that the root filesystem is read-only in the system role in > question. > "The arrow of time" can't change anything, in the root filesystem. > > Note, by "root filesystem", we mean the contents of the "root subvolume" on the btrfs partition. > Any other subvolume is not snapshotted, not considered part of the transactional update, and not read-only. > This includes (but is not limited to) gems such as /var, /root and /home, where we expect users and services > to continue their merry tasks of writing nonsense and worthwhile data to those locations. > > This division between "the OS root filesystem" and "everything else" is working quite well, hence the > promotion of this feature from it's previous incarnation only in CaaSP & Kubic, and now suitable for a broader > audience in Leap and Tumbleweed. > >> What makes more sense to me is patch a quiescent system. That would >> mean accumulate the new change sets and then bring up the system in >> memory based rescue mode where the regular file systems is/are otherwise >> not enabled. The scheme then tries applying patches one by one (with a >> log to revert), and if a failure occurs then consider undoing them all, >> with optional variations about accepting some regardless and so forth. >> This eliminates concerns about open files, memory caches, partial >> transactions, interaction amongst machines, huge extra disk space, not >> being restricted to BTRFS, and likely a few more nuances. It also avoids >> yet another installation-time-only option and thus can be used well >> after a machine has been built in an ordinary manner. > This approach would be incredibly long winded. Would users really be willing to have their systems offline for > so long while they patch so slowly and serially? One of the benefits of our approach is we can patch in a > threaded manner - every package applies its changeset as fast and as in parallel as the system allows, but > none of those changes are written to the running snapshot so impacts are avoided until the next reboot. > > Doesn't this strike the best balance of using the systems hardware efficiently, minimising downtime, while > still ensuring updates happen atomicly? > ??? The offline duration part was addressed in my previous message (to Thorsten's). It is inherent with changes, and for sensitive situations an operational fallback is necessary to cover time and be a safety net. ??? Applying changes is still serial process, not parallel (else possible disaster and much buggy complexity, see any modern cooperative effort for examples). Atomicity/ACID is part of that design, at least as much as is reasonable. ??? As for efficiency and the like, the least complexity and detailed forward planning the better in the field, particularly if such configuration needs to be done when first installing a system. ??? Thanks, ??? Joe D. From kukuk at suse.de Thu Apr 5 07:31:31 2018 From: kukuk at suse.de (Thorsten Kukuk) Date: Thu, 5 Apr 2018 15:31:31 +0200 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: <6b39b935-a818-77f7-7fae-e3200151e416@netlab1.net> References: <20180405123851.GA18789@suse.de> <6b39b935-a818-77f7-7fae-e3200151e416@netlab1.net> Message-ID: <20180405133131.GA24366@suse.de> On Thu, Apr 05, Joe Doupnik wrote: > ??? My suggestion appears, in essence, in Windows. Some patches are done on > the fly. Others are stashed, the machine is rebooted, and the boot steps are > interrupted to make changes to sensitive things before proceeding. Correct, and you know how much damage this "I have to do urgent things with my machine, but Windows does not let me do this, it wants to update itself" already made? Only as example, as it was widely in the press in germany: "Baseketball team being relegated to lower division due to Windows Update". It maybe ok for Microsoft to live with such bad press, but I don't want to read Linux there. Only because Microsoft wasn't able to find a good solution, it does not mean there is no better solution ;) > ??? The matter of long down time, or the possibility of it occurring, is > always with us. Where we can we provide fall back systems to provide > continued service and be insurance against possible irreversible changes. The feature request number one we get is still: long down times are inacceptable. Most often mentioned example is the Windows Updater ... > ??? My suggestion side steps the issue of BTRFS or not, large disk space, > running with r/o file systems, complicated partitioning finesse designed in > at system creation time, etc. It safely deal with apps which are not built > to do freeze/thaw, and it allows for regression without further > complications. Of course it does not provide the running fallback. Don't know why you think you need complicated partitioning finesse. If you want to have reliable backups, you need to seperate your data from your applications. But this does not require complicated partitioning finesse. It only requires that your applications conform to the Linux FHS. > ??? The notion is worth thinking about. My own feeling is on the fly > patching of important systems is asking for trouble over the long term, and > I would rather not have that be in a life support system. > ??? A humorous mental picture is a doctor operating upon > him/herself and discovering the need for three hands or careful visual > control or the need for specialized knowledge not yet accumulated, etc. > Another case of not knowing in advance what we don't know. Looks like you should really watch a presentation from me about transactional updates. What you describe is what everybody is doing today, but not what transactional update is doing. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) From kukuk at suse.de Thu Apr 5 07:32:50 2018 From: kukuk at suse.de (Thorsten Kukuk) Date: Thu, 5 Apr 2018 15:32:50 +0200 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: References: <1989aee46b694a35fcb477e278369d2620fafa12.camel@suse.de> Message-ID: <20180405133250.GB24366@suse.de> On Thu, Apr 05, Joe Doupnik wrote: > ??? The offline duration part was addressed in my previous message (to > Thorsten's). It is inherent with changes, and for sensitive situations an > operational fallback is necessary to cover time and be a safety net. > ??? Applying changes is still serial process, not parallel (else possible > disaster and much buggy complexity, see any modern cooperative effort for > examples). Atomicity/ACID is part of that design, at least as much as is > reasonable. > ??? As for efficiency and the like, the least complexity and detailed > forward planning the better in the field, particularly if such configuration > needs to be done when first installing a system. Ok, now you perfectly described what transactional updates are doing :) Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) From jrd at netlab1.net Thu Apr 5 07:50:54 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Thu, 5 Apr 2018 14:50:54 +0100 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: <20180405133250.GB24366@suse.de> References: <1989aee46b694a35fcb477e278369d2620fafa12.camel@suse.de> <20180405133250.GB24366@suse.de> Message-ID: On 05/04/2018 14:32, Thorsten Kukuk wrote: > On Thu, Apr 05, Joe Doupnik wrote: > >> ??? The offline duration part was addressed in my previous message (to >> Thorsten's). It is inherent with changes, and for sensitive situations an >> operational fallback is necessary to cover time and be a safety net. >> ??? Applying changes is still serial process, not parallel (else possible >> disaster and much buggy complexity, see any modern cooperative effort for >> examples). Atomicity/ACID is part of that design, at least as much as is >> reasonable. >> ??? As for efficiency and the like, the least complexity and detailed >> forward planning the better in the field, particularly if such configuration >> needs to be done when first installing a system. > Ok, now you perfectly described what transactional updates are doing :) > > Thorsten > ---------- ??? I think we are mixing buzz words and tinkering which may not be well understood by average system managers, with consequent loss of confidence and/or interest. To deal with that we (myself included) need to describe matters in plain candid language which the average sysadmin can understand and make careful judgements about. We aren't there yet, again myself included. ??? The cited doc (worth rereading) does say "transactional" means a classical ACID approach (retreat from problems). What's missing is all the other things going on in a fully running system, where backing away from a change is often not an isolated process (particularly with coupled systems which involve timestamps etc). ??? In your previous messages the matter of file system layout comes to the foreground and is what I have termed advanced detailed planning which, alas, does not fit well with evolving conditions in the field. The o/s does not live in splendid isolation from all the rest of the applications (which are the reason for the o/s to exist). My suggestion tries to remove such preconditions. ??? Thus, it is good that we do some preliminary sorting of issues and come up with understandable and appealing plans. ??? Thanks, ??? Joe D. From jsmeix at suse.de Thu Apr 5 08:27:47 2018 From: jsmeix at suse.de (Johannes Meixner) Date: Thu, 5 Apr 2018 16:27:47 +0200 (CEST) Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: <1989aee46b694a35fcb477e278369d2620fafa12.camel@suse.de> References: <1989aee46b694a35fcb477e278369d2620fafa12.camel@suse.de> Message-ID: Hello, On Apr 5 14:37 Richard Brown wrote (excerpt): > On Thu, 2018-04-05 at 13:25 +0100, Joe Doupnik wrote: >> ... Of particular concern is the arrow of >> time, which means changes occur on the running system after snapping ... > And that problem is addressed by the fact that the root filesystem > is read-only in the system role in question. > "The arrow of time" can't change anything, in the root filesystem. What about changes in /etc in the running system after snapping? https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ reads (excerpt): ---------------------------------------------------------------------- User configuration in /etc is writable by virtue of an automatically configured overlayfs ---------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) From kukuk at suse.de Thu Apr 5 08:38:20 2018 From: kukuk at suse.de (Thorsten Kukuk) Date: Thu, 5 Apr 2018 16:38:20 +0200 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: References: <1989aee46b694a35fcb477e278369d2620fafa12.camel@suse.de> Message-ID: <20180405143820.GA32255@suse.de> On Thu, Apr 05, Johannes Meixner wrote: > > Hello, > > On Apr 5 14:37 Richard Brown wrote (excerpt): > > On Thu, 2018-04-05 at 13:25 +0100, Joe Doupnik wrote: > > > ... Of particular concern is the arrow of time, which means changes > > > occur on the running system after snapping > ... > > And that problem is addressed by the fact that the root filesystem > > is read-only in the system role in question. > > "The arrow of time" can't change anything, in the root filesystem. > > What about changes in /etc in the running system after snapping? > > https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ > reads (excerpt): > ---------------------------------------------------------------------- > User configuration in /etc is writable by virtue of an automatically > configured overlayfs ^^^^^^^^^ It's not part of the snapshot. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) From jrd at netlab1.net Thu Apr 5 09:09:00 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Thu, 5 Apr 2018 16:09:00 +0100 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: <20180405133131.GA24366@suse.de> References: <20180405123851.GA18789@suse.de> <6b39b935-a818-77f7-7fae-e3200151e416@netlab1.net> <20180405133131.GA24366@suse.de> Message-ID: <9ccc259f-a1b9-0665-67d4-f620ef526871@netlab1.net> On 05/04/2018 14:31, Thorsten Kukuk wrote: > On Thu, Apr 05, Joe Doupnik wrote: > >> ??? My suggestion appears, in essence, in Windows. Some patches are done on >> the fly. Others are stashed, the machine is rebooted, and the boot steps are >> interrupted to make changes to sensitive things before proceeding. > Correct, and you know how much damage this "I have to do urgent things > with my machine, but Windows does not let me do this, it wants to update > itself" already made? > > Only as example, as it was widely in the press in germany: > "Baseketball team being relegated to lower division due to > Windows Update". > > It maybe ok for Microsoft to live with such bad press, but I don't > want to read Linux there. > > Only because Microsoft wasn't able to find a good solution, it does > not mean there is no better solution ;) > >> ??? The matter of long down time, or the possibility of it occurring, is >> always with us. Where we can we provide fall back systems to provide >> continued service and be insurance against possible irreversible changes. > The feature request number one we get is still: long down times are > inacceptable. Most often mentioned example is the Windows Updater ... > >> ??? My suggestion side steps the issue of BTRFS or not, large disk space, >> running with r/o file systems, complicated partitioning finesse designed in >> at system creation time, etc. It safely deal with apps which are not built >> to do freeze/thaw, and it allows for regression without further >> complications. Of course it does not provide the running fallback. > Don't know why you think you need complicated partitioning finesse. > If you want to have reliable backups, you need to seperate your data from your > applications. But this does not require complicated partitioning finesse. > It only requires that your applications conform to the Linux FHS. > >> ??? The notion is worth thinking about. My own feeling is on the fly >> patching of important systems is asking for trouble over the long term, and >> I would rather not have that be in a life support system. >> ??? A humorous mental picture is a doctor operating upon >> him/herself and discovering the need for three hands or careful visual >> control or the need for specialized knowledge not yet accumulated, etc. >> Another case of not knowing in advance what we don't know. > Looks like you should really watch a presentation from me about transactional > updates. What you describe is what everybody is doing today, but not what > transactional update is doing. > > Thorsten > -------- ??? On the down time aspect, again. ??? Yes, Windows Update can be a pain, no question about that. Worse is when it won't come up sensibly after patching due to one thing or another (for which we go into Safe mode, seek restore points/os-only-snapshots, uninstall things, and other annoying emergency steps). The other side of that coin is Windows tries the dormant system (in boot code steps) approach for many patches, and for good reason. ??? The commercial solution to serious changes is CYA: employ a proper replacement system while the first is being operated upon. Clustering to the fore, particularly when time == money or customers become most upset, or worse. Which in turn means do such changes off line, pretty please. More important systems have more than one fall back system to avoid having only one good system at any time. Patching live running servers can't be relied upon that way, no matter how clever the authors because real server matters can be much more complicated than they know and involve considerably more than a r/o root file system. ??? Thus the downtime problem is somewhat distinct from how one patches systems or one tries to recover from related problems. Just how a site chooses to go about this will be up to them, of course, but at least understanding the risks and alternatives is necessary to make intelligent choices. Meanwhile we try to explain the nuances to folks in terms which they can assimilate. ??? Thanks, ??? Joe D. From jrd at netlab1.net Thu Apr 5 11:24:15 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Thu, 5 Apr 2018 18:24:15 +0100 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: <9ccc259f-a1b9-0665-67d4-f620ef526871@netlab1.net> References: <20180405123851.GA18789@suse.de> <6b39b935-a818-77f7-7fae-e3200151e416@netlab1.net> <20180405133131.GA24366@suse.de> <9ccc259f-a1b9-0665-67d4-f620ef526871@netlab1.net> Message-ID: <65331f18-71e7-0c09-7588-1c561029191d@netlab1.net> ??? Reviewing today's discussion, it seems to me that a useful step forward is documentation of merit and advice, listing each patch technique together with its benefits and caveats. That would allow each method to exhibit its good points, and inform sysadmins about aspects which to be cautious. No method is pushed forward as such, and certainly none is perfectly safe and sound. Taken as a whole the patch matter would be given a good professional description. In addition, supplementary docs would be valuable as they could go into detail about each method so that matters are well understood. In short, good solid engineering information. ??? Thanks, ??? Joe D. From mge at suse.com Thu Apr 5 12:33:17 2018 From: mge at suse.com (Matthias G. Eckermann) Date: Thu, 5 Apr 2018 20:33:17 +0200 Subject: [sle-beta] Transactional Updates in Leap 15 In-Reply-To: <65331f18-71e7-0c09-7588-1c561029191d@netlab1.net> References: <20180405123851.GA18789@suse.de> <6b39b935-a818-77f7-7fae-e3200151e416@netlab1.net> <20180405133131.GA24366@suse.de> <9ccc259f-a1b9-0665-67d4-f620ef526871@netlab1.net> <65331f18-71e7-0c09-7588-1c561029191d@netlab1.net> Message-ID: <20180405183317.nmhxpkehq6qup675@suse.com> Hello Joe, On 2018-04-05 T 18:24 +0100 Joe Doupnik wrote: > Reviewing today's discussion, it seems to me that a useful step > forward is documentation of merit and advice, listing each patch > technique together with its benefits and caveats. That would allow > each method to exhibit its good points, and inform sysadmins about > aspects which to be cautious. No method is pushed forward as such, > and certainly none is perfectly safe and sound. Taken as a whole the > patch matter would be given a good professional description. In > addition, supplementary docs would be valuable as they could go into > detail about each method so that matters are well understood. In > short, good solid engineering information. you have an excellent point here, and actually, just recently I had the opportunity to work with well known journalist Swapnil Bhartiya on the topic of different update mechanisms and the future of Linux OSes. His article just went online yesterday, and I think, he has created a very nice summary of the challenges and opportunities of the different ways of working with a Linux OS from an update perspective (traditional, image based, transactional). "Containerization, Atomic Distributions, and the Future of Linux" https://www.linux.com/blog/2018/4/containerization-atomic-distributions-and-future-linux Let me add one paragraph, which did not make it into the published article, which I hope is useful for our discussion here: --------------------------------< snip >---------------------------- There will be a convergence of traditional distributions, traditional operating systems and image-based models. I see the transactional update model that SUSE uses as a way for these two directions to find a common ground. Updating a traditional OS and the transactional way is not only in line with a traditional way, but it also supports the main goals of a traditional deployment method. These goals are [...] reliability, uninterrupted operating and long-term maintenance. --------------------------------< snap >---------------------------- Kind regards - So long - MgE -- Matthias G. Eckermann, Director Product Management SUSE Linux Enterprise Phone: +49 331 58 17 63 79 Mobile/DE: +49 17 92 94 94 48 SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From beta-programs at lists.suse.com Fri Apr 6 08:08:16 2018 From: beta-programs at lists.suse.com (SUSE Beta Program) Date: Fri, 06 Apr 2018 16:08:16 +0200 Subject: [sle-beta] [ANNOUNCE] SUSE Package Hub for SLES 15 now available! Message-ID: <5ac77f50b4987_6ebb128731883771@boucane.mail> SUSE Package Hub for SLES 15 now available via SUSE Customer Center! This means that you can now add the SUSE Package Hub online repositories to your SUSE Linux Enterprise Server 15 Beta. And start installing and testing your favourite community packages on SLES 15 Beta! To do so, on a registered SLES 15 Beta Server*, open YaST -> ?Software" -> "Add Systems Extensions or Modules" -> deselect ?Hide Beta Versions? -> then select ?SUSE Package Hub 15 x86_64? and proceed by following the wizard. # General Information SUSE Package Hub is a free of charge extension providing access to community maintained packages built to run on SUSE Linux Enterprise Server. Built from the same sources used in the openSUSE distributions, these quality packages provide additional software to what is found in the SUSE Linux Enterprise Server product. Packages from the Package Hub are delivered without L3 support from SUSE. General updates and fixes to the packages in SUSE Package Hub are provided by the openSUSE community based on their discretion though SUSE will monitor and ensure that any known critical security issues will be addressed. Packages in the Package Hub are approved by SUSE for use with SUSE Linux Enterprise Server 15 and to not interfere with the supportability of SUSE Linux Enterprise Server it?s modules and extensions. For more information about SUSE Package Hub please visit https://packagehub.suse.com. *If you do not have a beta registration[1] for SLES 15 Beta, you need to request one to beta-programs at lists.suse.com # List all available packages After enabling the SUSE Package Hub 15 on your server, you can use the following zypper command to list all available packages in the SUSE-PackageHub-15 repository: # zypper packages --repo SUSE-PackageHub-15 Loading repository data... Reading installed packages... S | Repository | Name | Version | Arch --+--------------------+---------------------------------------------------+--------------------------+------- | SUSE-PackageHub-15 | R-KernSmooth | 2.23.15-1.10 | x86_64 | SUSE-PackageHub-15 | R-MASS | 7.3.47-1.10 | x86_64 | SUSE-PackageHub-15 | R-Matrix | 1.2.12-1.10 | x86_64 | SUSE-PackageHub-15 | R-Matrix-devel | 1.2.12-1.10 | x86_64 | SUSE-PackageHub-15 | R-base | 3.4.3-1.10 | x86_64 | SUSE-PackageHub-15 | R-base-devel | 3.4.3-1.10 | x86_64 | SUSE-PackageHub-15 | R-boot | 1.3.20-1.10 | x86_64 [...] [1] https://www.suse.com/betaprogram/sle-beta/#faq-reg Your SUSE Linux Enterprise Team Do not hesitate to contact us at beta-programs at lists.suse.com if you have any questions. You received this email because you're signed up to get updates from us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vmoutoussamy at suse.com Fri Apr 6 09:22:01 2018 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Fri, 6 Apr 2018 17:22:01 +0200 Subject: [sle-beta] UUDI not tested - Wrong Hostname updated --cleanup In-Reply-To: <20180313062808.GA3534@suse.de> References: <46AC8C81C10B8C48820201DF2AE1D76D012076E552@daeexmbx1.eur.ad.sag> <1520862787.4384.84.camel@suse.de> <46AC8C81C10B8C48820201DF2AE1D76D012076F2FA@daeexmbx1.eur.ad.sag> <20180313062808.GA3534@suse.de> Message-ID: <23BFF189-7147-45DC-8A1C-E64F19B6BBBB@suse.com> Hi, By the way, I recently discovered the tool ?clone-master-clean-up?: > # zypper info clone-master-clean-up > Loading repository data... > Reading installed packages... > > > Information for package clone-master-clean-up: > ---------------------------------------------- > Repository : SLE-Module-Server-Applications15-Pool > Name : clone-master-clean-up > Version : 1.2-2.6 > Arch : noarch > Vendor : SUSE LLC > Support Level : Level 3 > Installed Size : 12.4 KiB > Installed : No > Status : not installed > Source package : clone-master-clean-up-1.2-2.6.src > Summary : Clean up a system for cloning preparation > Description : > Clean up a system for cloning preparation by cleaning up usage history and log files, etc. And you can also find a bit of documentation at: https://susedoc.github.io/doc-sle/develop/SLES-deployment/single-html/#sec.deployment.clone_image.clean Please give this tool a try, Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager > On 13 Mar 2018, at 07:28, Thorsten Kukuk wrote: > > On Tue, Mar 13, Waite, Dick (External) wrote: > >> Last word and then I shut up... >> >> You can not update / write to a database / registry without any check that the caller is entitled to update / write that field. Even a Hostname check would be better that nothing. The --cleanup option will be forgotten at some time by someone and then that lowly clone is going to update the SCC of a valuable Mother or maybe even a queen. > > Again: the hostname is completly useless for this case in most environments. > Else: all other data used for registration got cloned by you and > is identical on both machines. So any check we can do would tell > us: this is the same machine as registered against SCC. > > If you clone a machine, you have to remove all host specific data. > And this is not only the SCC registration stuff, this are also > machine-id, dbus ID, ssh host key, maschine specific certificates, ... > If you don't do that, bad thinks can happen, not only with registration. > > Thorsten > > -- > Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From Joerg.Reisenweber at btc-it-services.com Fri Apr 6 09:35:30 2018 From: Joerg.Reisenweber at btc-it-services.com (Joerg.Reisenweber at btc-it-services.com) Date: Fri, 6 Apr 2018 15:35:30 +0000 Subject: [sle-beta] UUDI not tested - Wrong Hostname updated --cleanup In-Reply-To: <23BFF189-7147-45DC-8A1C-E64F19B6BBBB@suse.com> References: <46AC8C81C10B8C48820201DF2AE1D76D012076E552@daeexmbx1.eur.ad.sag> <1520862787.4384.84.camel@suse.de> <46AC8C81C10B8C48820201DF2AE1D76D012076F2FA@daeexmbx1.eur.ad.sag> <20180313062808.GA3534@suse.de> <23BFF189-7147-45DC-8A1C-E64F19B6BBBB@suse.com> Message-ID: <9dddde1eefe348a891bc68277cbc11ae@OLGA9758.btcnet.btc-ag.com> Thank you, Vincent! This sounds promising and might come in handy a few times. We will definitely give it a try. Have a great weekend Joerg Von: sle-beta-bounces at lists.suse.com [mailto:sle-beta-bounces at lists.suse.com] Im Auftrag von Vincent Moutoussamy Gesendet: Freitag, 6. April 2018 17:22 An: Waite, Dick (External) ; SUSE SLE Beta Betreff: Re: [sle-beta] UUDI not tested - Wrong Hostname updated --cleanup Hi, By the way, I recently discovered the tool ?clone-master-clean-up?: # zypper info clone-master-clean-up Loading repository data... Reading installed packages... Information for package clone-master-clean-up: ---------------------------------------------- Repository : SLE-Module-Server-Applications15-Pool Name : clone-master-clean-up Version : 1.2-2.6 Arch : noarch Vendor : SUSE LLC > Support Level : Level 3 Installed Size : 12.4 KiB Installed : No Status : not installed Source package : clone-master-clean-up-1.2-2.6.src Summary : Clean up a system for cloning preparation Description : Clean up a system for cloning preparation by cleaning up usage history and log files, etc. And you can also find a bit of documentation at: https://susedoc.github.io/doc-sle/develop/SLES-deployment/single-html/#sec.deployment.clone_image.clean Please give this tool a try, Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager On 13 Mar 2018, at 07:28, Thorsten Kukuk > wrote: On Tue, Mar 13, Waite, Dick (External) wrote: Last word and then I shut up... You can not update / write to a database / registry without any check that the caller is entitled to update / write that field. Even a Hostname check would be better that nothing. The --cleanup option will be forgotten at some time by someone and then that lowly clone is going to update the SCC of a valuable Mother or maybe even a queen. Again: the hostname is completly useless for this case in most environments. Else: all other data used for registration got cloned by you and is identical on both machines. So any check we can do would tell us: this is the same machine as registered against SCC. If you clone a machine, you have to remove all host specific data. And this is not only the SCC registration stuff, this are also machine-id, dbus ID, ssh host key, maschine specific certificates, ... If you don't do that, bad thinks can happen, not only with registration. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) _______________________________________________ sle-beta mailing list sle-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: From okurz at suse.de Sun Apr 8 03:42:21 2018 From: okurz at suse.de (Oliver Kurz) Date: Sun, 08 Apr 2018 11:42:21 +0200 Subject: [sle-beta] LEAP 15 et al In-Reply-To: References: <46AC8C81C10B8C48820201DF2AE1D76D01207797AA@daeexmbx1.eur.ad.sag> <8BC78110-7627-4A98-9742-53DC5FB04B46@suse.de> Message-ID: <3002804.f9FpFdue4B@linux-28d6.suse> On Tuesday, 3 April 2018 11:20:42 CEST Toma? Bor?tnar, Softergee wrote: > When I install the Leap beta and try zypper ref/up I always get notice > about stale repositories. Is this to be expected? I wanted to perform > updates via zypper and not via offline update. Keep in mind that the correct command to update/upgrade a Leap 15.0 installation until the official release ("GM" milestone for "gold master") is `zypper dup`. The reason is that updated packages should come due an updated build of the product, i.e. you *upgrade* from build say 0123 to 0127, a newer version of openSUSE Leap 15.0 itself. What will happen after the release of openSUSE Leap 15.0 is that the product itself does not change but instead "maintenance updates" will be released. These are also coming from different online repositories, the *update* repositories. For further investigation you can post the output of `zypper lr --uri` to be able to check the repo URLs. From vmoutoussamy at suse.com Mon Apr 9 07:43:01 2018 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Mon, 9 Apr 2018 15:43:01 +0200 Subject: [sle-beta] Persistent rules - udev In-Reply-To: References: <8676B27F01464747B047766FF17A1B5A789A86E8@prvxmb04.microfocus.com> Message-ID: Hi, Yes nothing has changed here. JFYI our documentation https://susedoc.github.io/doc-sle/develop/SLES-storage/single-html/#sec.uuid.udev , point to http://reactivated.net/writing_udev_rules.html for "how to define your own rules for udev?, Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager > On 27 Mar 2018, at 21:50, Arun Singh > wrote: > > Hello All: > > Please Ignore this as I was able to make it work. For some reason ?systemctl status systemd-udevd? displayed syntax error. > > It worked after adding spaces to keys. > > Thanks > -Arun > > > From: sle-beta-bounces at lists.suse.com [mailto:sle-beta-bounces at lists.suse.com ] On Behalf Of Arun Singh > Sent: Friday, March 23, 2018 8:03 PM > To: sle-beta at lists.suse.com > Subject: [sle-beta] Persistent rules - udev > > Hi SLE Team: > > Following steps were working in RC1 (not in RC2): > > Create & set permissions of disk (/dev/sdb3 persistent at boot) > 1. Create & locate Disk ID: # /lib/udev/ata_id /dev/sdb > ST1000NM0033-9ZM173_Z1W24H49 > 2. Create rules: /etc/udev/rules.d # cat 99-oracle-asm.rules > KERNEL=="sd?3",ENV{ID_SERIAL}=="ST1000NM0033-9ZM173_Z1W24H49",SYMLINK+="asm/disk3",OWNER="oracle",GROUP="dba",MODE="0600" > 3. #udevadm control ?reload > 4. # partprobe /dev/sdb > 5. ls ?al /dev/asm -> displays asm/disk3 with correct permissions > > Any hint as what changed or how to accomplish above in RC2? > > Thanks, > Arun > > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From vmoutoussamy at suse.com Mon Apr 9 07:51:49 2018 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Mon, 9 Apr 2018 15:51:49 +0200 Subject: [sle-beta] firewalld with subzones In-Reply-To: <70144992.5652287.1520290933220.JavaMail.zimbra@tre-sc.jus.br> References: <70144992.5652287.1520290933220.JavaMail.zimbra@tre-sc.jus.br> Message-ID: Hi, > On 6 Mar 2018, at 00:02, Luiz Angelo Daros de Luca wrote: > > Hello, > > While porting exising SuSEFirewall2 confs to firewalld, things started to get complicated. > > With SuSEFirewall2, admin can create a service file opens ports to specific source clients. > /etc/sysconfig/SuSEFirewall2 is kept simple, only defining interface zones and enabling services for each zone. > I had to repeat multiple times the same source addresses for different services but, at least, everything was contained inside > a single service file. I rarely depended on direct iptables calls inside custom script. > > Now arrives firewalld. > > Services in firewalld are much simpler definitions. There is no such thing as source address filtering. > Source is only filtered by "source zones", "rich rules" or "direct rules". First I though "source zones" was the way to go. > I could define multiple source_zones like "production", "remote sites", "local site". It would improve the "repeat multiple times > the same source addresses" that I faced with SuSEFirewall2. Now things gets complicated. > > "Zones" in firewalld cannot overlap (https://github.com/firewalld/firewalld/issues/295, https://github.com/firewalld/firewalld/issues/192, https://github.com/firewalld/firewalld/issues/149). > If a source zone matches source address, the connection passes through its rules. If nothing matches inside those zone rules, firewalld checks the zone "target", which > could accept, reject/drop or default. All of them are final but default which will send processing back to INPUT chain. The next thing it will test will be the interface zone or the default zone. > So, once a connection matches a source zone, no other source zone will be checked. > > I could order source zones in a special sequence. I would need to prefix zone name with number (https://github.com/firewalld/firewalld/issues/224, https://github.com/firewalld/firewalld/issues/166), something like 10_production, 20_servers, 30_localsite, 40_intranet. Anyway, as only the first source zone that matched is processed. If I add a service all my intranet but not to extranet, I would need to add it to all zones (10_production, 20_servers, 30_localsite, 40_intranet). If you add a new subzone, you need to add every single service open in "broader zones" to it. It gets exponentially complex with more services/zones. > > The second option is to avoid "source zones" and use rich rules in the default zone, while "source zones" addresses become ipsets. However, now I get just a bunch of rules, without a contained organization. Rich rules does not even have a name/id that would help with scripts. And rich rules uses always the sequence "deny, allow", there is no other rule sequence. I can still reference services but not much besides that. Direct rules gives me back sequence, but only between direct rules, and it removes the little abstraction that remained. They always goes before "rich rules" and "services". It seems that with firewalld I get a layer of complexity over iptables without abstractions that simplify configurations. > > Firewalld zones seems to be designed with desktop environment in mind. I can open a service when at work, at home, but leave it closed in public. For enterprise, zones did not really help. > It can do the job for simple "open ports/services for all", but it gets in the way when you need to filter "by source", specially when you have multiple layers. > > The multiple open issues at github related to "source filtering"/"rules/zone order" show that some features are still missing in firewalld and users are trying to (ab)use the existing features the wrong way. Sorry for the late response, do you still struggle to get things done with firewalld? I?m not a firewalld expert but please give me your latest feedback and I will try to help! Did you take a look at our firewalld documentation? https://susedoc.github.io/doc-sle/develop/SLES-security/single-html/#cha.security.firewall > > I know RHEL aready uses firewalld for some time. However, they kept a iptables-service for when firewalld gets in the way. What can I use with SLE15 besides firewalld? SuSEFirewall2? Can I still depend on SuSEFirewall2 during SLE15 suport (even on ServicePacks)? Well no SuSEFirewall2 should be removed completely from SLE15. > > Regards, Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager > -- > Luiz Angelo Daros de Luca > > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From luizluca at tre-sc.jus.br Mon Apr 9 11:55:27 2018 From: luizluca at tre-sc.jus.br (Luiz Angelo Daros de Luca) Date: Mon, 9 Apr 2018 14:55:27 -0300 (BRT) Subject: [sle-beta] firewalld with subzones In-Reply-To: References: <70144992.5652287.1520290933220.JavaMail.zimbra@tre-sc.jus.br> Message-ID: <1066985952.7528724.1523296526999.JavaMail.zimbra@tre-sc.jus.br> > Sorry for the late response, do you still struggle to get things done with > firewalld? I?m not a firewalld expert but please give me your latest feedback > and I will try to help! Thanks Vicent. I really had no choice but to use rich rules with ipsets. "source zones" will propably need to be rethink as a feature in the future. Even ipsets are not ideal as a tool to segment network as I need to readd the same network address on every ipset that includes it. Linux ipsets do supports a set of sets, but firewalld ipsets does not. What I really miss now is a organized way to group rules and identify them. As the number of rules increase, my rules started to look like Spaghetti code, with many rules sharing the same source filter. I know that the result rules in iptables do normally looks like " Spaghetti code", but I has hopping that at the abstraction layer, as firewalld is, it would be more organized. A way to group rules by source would also make rules much cleaner. In pure iptables, I would use something like this: -s 10.1.1.0/24 -j PRODNET -s 10.1.2.0/24 -j TESTNET -s 10.1.1.0/24 -j SRVNET -s 10.1.2.0/24 -j SRVNET -j ALLNET There is no equivalent for firewalld. Zones cannot be used for that as they, once matched the source, stop the rule processing. There is no easy way to have an id for rich rules. I have scripts that add, update, remove firewall rules. In order to manipulate a rule, I need to know exactly its arguments. If the script needs to update a rule, it need to keep track of every single variation that rule had in the past and that might still be in use, look for each variation and remove it before adding the new variation. My solution was to (ab)use logging feature to add an "id" to rules in log prefix. I normally would use iptables comment, but rich rules does not have support for them. So, since my last email, nothing really changed. I do have an open issue for adding ID to rich rules: https://github.com/firewalld/firewalld/issues/308 For ipset list:set support: https://github.com/firewalld/firewalld/issues/324 And for zone ordering/overlapping, there are already some open issues. > Did you take a look at our firewalld documentation? > https://susedoc.github.io/doc-sle/develop/SLES-security/single-html/#cha.security.firewall I took a look now (it wasn't avaiable at the time). >> I know RHEL aready uses firewalld for some time. However, they kept a >> iptables-service for when firewalld gets in the way. What can I use with SLE15 >> besides firewalld? SuSEFirewall2? Can I still depend on SuSEFirewall2 during >> SLE15 suport (even on ServicePacks)? > Well no SuSEFirewall2 should be removed completely from SLE15. I have to live with that. Regards, -- Luiz Angelo Daros de Luca Tribunal Regional Eleitoral de Santa Catarina STI/CSIT/Se??o de Comunica??o de Dados e-mail: luizluca at tre-sc.jus.br jabber: luizluca at tre-sc.gov.br -------------- next part -------------- An HTML attachment was scrubbed... URL: From beta-programs at lists.suse.com Tue Apr 10 09:46:09 2018 From: beta-programs at lists.suse.com (SUSE Beta Program) Date: Tue, 10 Apr 2018 17:46:09 +0200 Subject: [sle-beta] [ANNOUNCE] SUSE Linux Enterprise High Performance Computing officially part of the SLE 15 Beta Program! Message-ID: <5accdc411dc24_4453449300169a1@boucane.mail> SUSE Linux Enterprise High Performance Computing officially part of the SLE 15 Beta Program! As part of the (upcoming) major version of SUSE Linux Enterprise 15, SUSE Linux Enterprise High Performance Computing (HPC) is now a dedicated SLE product base on SLES 15. This product is available for the x86_64 and ARM aarch64 hardware platforms. So you can now request beta registration code for SLE-HPC 15 on x86_64 or aarch64*! With the new SLE 15 Installer, there is now a single unified way to install one of the SLE products: the SLE HPC 15 option will set up the installation including the HPC module and lets the user chose between system roles customized for HPC which will simplify the installation of development, control and compute nodes. # HPC components The HPC Module offers components to address several aspects in High Performance Computing. - A workload manager (slurm) - Cluster management software (mrsh, pdsh, conman, etc) - Cluster monitoring (ganglia) - An environment module system (Lmod) - Multiple MPI implementation selectable thru environement modules (OpenMPI v2, mvapich2, mpich) with support for Infiniband and OPA in close cooperation with major fabric manufacturers. - Computational libraries built for use with environment modules, the MPI versions of these exist for all supported MPI flavors. - Development and benchmarking tools. The release frequency if these computation libraries will be much higher than software for SLES in general. The environment modules does not only allow the cluster administrator install variants built for different MPI flavors on the same system but also to keep multiple versions of these libraries installed in parallel. It will also allow the user to select between libraries built with different compilers or different compiler optimizations. # More on SLE-HPC Today, SUSE Linux Enterprise already runs on half of the top 100 HPC systems, SUSE partners with major players in the HPC eco system: - AMD, Intel, NVIDA ... - Cray, HPE/SGI, Fujitsu, NEC, Mellanox, Qlogic, ... It provides technologies like - 'Tickless Kernel' which brings huge power savings, a 3 percent performance improvement on classic systems and which is essential on Many Core systems like Intel Xeon Phi. - Automatic NUMA Balancing - PREEMMPT_RT (Linux-based real-time) which allows for tighter synchronization on HPC clusters with significant efficiency gains. This together with 3rd party technologies - like Lustre, NVIDIA Cuda, AMD ROCm - makes SUSE Linux Enterprise HPC a first class choice for High Performance Computing. Your SUSE Linux Enterprise Team * https://www.suse.com/betaprogram/sle-beta/#faq-reg Do not hesitate to contact us at beta-programs at lists.suse.com if you have any questions. You received this email because you're signed up to get updates from us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dietmar.hahn at ts.fujitsu.com Wed Apr 11 07:03:46 2018 From: dietmar.hahn at ts.fujitsu.com (Dietmar Hahn) Date: Wed, 11 Apr 2018 15:03:46 +0200 Subject: [sle-beta] Can't find os-prober Message-ID: <1598501.bee4jWxWdm@amur> Hi, during the installation I selected the os-prober flag in the boot menu but my SLES12SP3 on another partition wasn't found. I checked the /etc/default/grub and found: GRUB_DISABLE_OS_PROBER="false". When looking in /etc/grub.d/30_os-prober I found the problem. if [ -z "`which os-prober 2> /dev/null`" ] || [ -z "`which linux-boot-prober 2> /dev/null`" ] ; then # missing os-prober and/or linux-boot-prober exit 0 fi # zypper search os-prober Refreshing service 'Basesystem_Module_15_x86_64'. Refreshing service 'Desktop_Applications_Module_15_x86_64'. Refreshing service 'Development_Tools_Module_15_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. Refreshing service 'SUSE_Package_Hub_15_x86_64'. Refreshing service 'Server_Applications_Module_15_x86_64'. Loading repository data... Reading installed packages... No matching items found. Thank you and have a nice day! Dietmar. From fcrozat at suse.com Wed Apr 11 07:10:09 2018 From: fcrozat at suse.com (Frederic Crozat) Date: Wed, 11 Apr 2018 15:10:09 +0200 Subject: [sle-beta] Can't find os-prober In-Reply-To: <1598501.bee4jWxWdm@amur> References: <1598501.bee4jWxWdm@amur> Message-ID: <1523452209.4415.6.camel@suse.com> Le mercredi 11 avril 2018 ? 15:03 +0200, Dietmar Hahn a ?crit : > Hi, > > during the installation I selected the os-prober flag in the boot > menu but > my SLES12SP3 on another partition wasn't found. I checked > the /etc/default/grub > and found: GRUB_DISABLE_OS_PROBER="false". > When looking in /etc/grub.d/30_os-prober I found the problem. > if [ -z "`which os-prober 2> /dev/null`" ] || [ -z "`which linux- > boot-prober 2> /dev/null`" ] ; then > # missing os-prober and/or linux-boot-prober > exit 0 > fi > > # zypper search os-prober > Refreshing service 'Basesystem_Module_15_x86_64'. > Refreshing service 'Desktop_Applications_Module_15_x86_64'. > Refreshing service 'Development_Tools_Module_15_x86_64'. > Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. > Refreshing service 'SUSE_Package_Hub_15_x86_64'. > Refreshing service 'Server_Applications_Module_15_x86_64'. > Loading repository data... > Reading installed packages... > No matching items found. > > Thank you and have a nice day! os-prober is only available in SLED or Workstation extension, since dual-boot is a feature for desktop systems, not server. -- Frederic Crozat Enterprise Desktop Release Manager SUSE From malcolmlewis at cableone.net Wed Apr 11 07:13:04 2018 From: malcolmlewis at cableone.net (Malcolm) Date: Wed, 11 Apr 2018 08:13:04 -0500 Subject: [sle-beta] Can't find os-prober In-Reply-To: <1598501.bee4jWxWdm@amur> References: <1598501.bee4jWxWdm@amur> Message-ID: <20180411081304.2a081c09@grover.homelinux.org> On Wed, 11 Apr 2018 15:03:46 +0200 Dietmar Hahn wrote: > Hi, > > during the installation I selected the os-prober flag in the boot > menu but my SLES12SP3 on another partition wasn't found. I checked > the /etc/default/grub and found: GRUB_DISABLE_OS_PROBER="false". > When looking in /etc/grub.d/30_os-prober I found the problem. > if [ -z "`which os-prober 2> /dev/null`" ] || [ -z "`which > linux-boot-prober 2> /dev/null`" ] ; then # missing os-prober and/or > linux-boot-prober exit 0 > fi > > # zypper search os-prober > Refreshing service 'Basesystem_Module_15_x86_64'. > Refreshing service 'Desktop_Applications_Module_15_x86_64'. > Refreshing service 'Development_Tools_Module_15_x86_64'. > Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. > Refreshing service 'SUSE_Package_Hub_15_x86_64'. > Refreshing service 'Server_Applications_Module_15_x86_64'. > Loading repository data... > Reading installed packages... > No matching items found. > Hi I see it's in the Work Station extension... Information for package os-prober: ---------------------------------- Repository : SLE-Product-WE15-Pool Name : os-prober -- Cheers Malcolm ??? SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.3 | GNOME 3.20.2 | 4.4.120-45-default HP 255 G4 Notebook | A6-6310 X4 @ 1.80 GHz | AMD Radeon R4 up 3 days 21:11, 1 user, load average: 2.22, 2.58, 1.81 From dietmar.hahn at ts.fujitsu.com Thu Apr 12 06:48:45 2018 From: dietmar.hahn at ts.fujitsu.com (Dietmar Hahn) Date: Thu, 12 Apr 2018 14:48:45 +0200 Subject: [sle-beta] Can't find os-prober In-Reply-To: <1523452209.4415.6.camel@suse.com> References: <1598501.bee4jWxWdm@amur> <1523452209.4415.6.camel@suse.com> Message-ID: <2365739.UfLTavGI37@amur> Am Mittwoch, 11. April 2018, 15:10:09 CEST schrieb Frederic Crozat: > Le mercredi 11 avril 2018 ? 15:03 +0200, Dietmar Hahn a ?crit : > > Hi, > > > > during the installation I selected the os-prober flag in the boot > > menu but > > my SLES12SP3 on another partition wasn't found. I checked > > the /etc/default/grub > > and found: GRUB_DISABLE_OS_PROBER="false". > > When looking in /etc/grub.d/30_os-prober I found the problem. > > if [ -z "`which os-prober 2> /dev/null`" ] || [ -z "`which linux- > > boot-prober 2> /dev/null`" ] ; then > > # missing os-prober and/or linux-boot-prober > > exit 0 > > fi > > > > # zypper search os-prober > > Refreshing service 'Basesystem_Module_15_x86_64'. > > Refreshing service 'Desktop_Applications_Module_15_x86_64'. > > Refreshing service 'Development_Tools_Module_15_x86_64'. > > Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. > > Refreshing service 'SUSE_Package_Hub_15_x86_64'. > > Refreshing service 'Server_Applications_Module_15_x86_64'. > > Loading repository data... > > Reading installed packages... > > No matching items found. > > > > Thank you and have a nice day! > > os-prober is only available in SLED or Workstation extension, since > dual-boot is a feature for desktop systems, not server. OK, I understand. Thanks. From dietmar.hahn at ts.fujitsu.com Fri Apr 13 02:05:33 2018 From: dietmar.hahn at ts.fujitsu.com (Dietmar Hahn) Date: Fri, 13 Apr 2018 10:05:33 +0200 Subject: [sle-beta] kdump doesn't work with Xen Message-ID: <1726741.L56QzCjM8A@amur> Hi, I installed a virtualisationhost with Xen as the hypervisor. With yast I configured kdump. After a reboot on the serial console I can see: (XEN) Kdump: 239MB (244736kB) at 0xac300000 # systemctl status kdump ? kdump.service - Load kdump kernel and initrd Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled) Active: active (exited) since Fri 2018-04-13 05:19:49 CEST; 1h 54min ago Process: 1480 ExecStart=/lib/kdump/load.sh --update (code=exited, status=0/SUCCESS) Main PID: 1480 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) CGroup: /system.slice/kdump.service Apr 13 05:19:46 bs2gfx systemd[1]: Starting Load kdump kernel and initrd... Apr 13 05:19:49 bs2gfx kdump[1622]: Loaded kdump kernel: /sbin/kexec -p /boot/vmlinuz-4.12.14-16.4-default --a Apr 13 05:19:49 bs2gfx systemd[1]: Started Load kdump kernel and initrd. All seem to be very well but when triggering the crash via # echo c > /proc/sysrq-trigger no dump is written, I only see the message (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. Later I tried to trigger the crash directly from within Xen: login: (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to DOM0) (XEN) 'C' pressed -> triggering crashdump (XEN) * no crash kernel loaded! Is there something I'm doing wrong? Thanks. Dietmar. From ross.brunson at suse.com Tue Apr 17 11:14:56 2018 From: ross.brunson at suse.com (Ross Brunson) Date: Tue, 17 Apr 2018 17:14:56 +0000 Subject: [sle-beta] Issue with online_update Message-ID: <040FF212-640F-4D23-95EE-E04CA8189B7B@suse.com> I sent this to Vincent, but wanted to see if anyone else has this issue too? Craig and I (SLE 15 Courseware development) are using the following key for our SCC registration: INTERNAL-USE-ONLY-54c291bc27f2cb87 When I get the product installed and run the online_update module to get the latest of everything, I get a message that states: ?No update repository configured yet. Run configuration workflow?? Doing so results in a message that the system is ?already registered? and the extensions I have selected are: SUSE Package Hub Basesystem Module Desktop Applications Module Server Applications Module Any help, direction or just good thoughts would be much appreciated. We are both getting the same errors/messages. Thanks! Ross -- Ross Brunson Senior Training Engineer SUSE Inc. ross.brunson at suse.com training.suse.com Ofc: 406-404-2005 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross.brunson at suse.com Tue Apr 17 11:28:05 2018 From: ross.brunson at suse.com (Ross Brunson) Date: Tue, 17 Apr 2018 17:28:05 +0000 Subject: [sle-beta] Issue with online_update Message-ID: <34101784-9068-4917-928A-999945B6202C@suse.com> Whoops, forgot to mention this is RC3. -- Ross Brunson Senior Training Engineer SUSE Inc. ross.brunson at suse.com training.suse.com Ofc: 406-404-2005 From: on behalf of Ross Brunson Date: Tuesday, April 17, 2018 at Apr 17, 2018 -11:16 AM To: "sle-beta at lists.suse.com" Subject: [sle-beta] Issue with online_update I sent this to Vincent, but wanted to see if anyone else has this issue too? Craig and I (SLE 15 Courseware development) are using the following key for our SCC registration: INTERNAL-USE-ONLY-54c291bc27f2cb87 When I get the product installed and run the online_update module to get the latest of everything, I get a message that states: ?No update repository configured yet. Run configuration workflow?? Doing so results in a message that the system is ?already registered? and the extensions I have selected are: SUSE Package Hub Basesystem Module Desktop Applications Module Server Applications Module Any help, direction or just good thoughts would be much appreciated. We are both getting the same errors/messages. Thanks! Ross -- Ross Brunson Senior Training Engineer SUSE Inc. ross.brunson at suse.com training.suse.com Ofc: 406-404-2005 -------------- next part -------------- An HTML attachment was scrubbed... URL: From beta-programs at lists.suse.com Tue Apr 17 12:04:58 2018 From: beta-programs at lists.suse.com (SUSE Beta Program) Date: Tue, 17 Apr 2018 20:04:58 +0200 Subject: [sle-beta] [ANNOUNCE] SUSE Linux Enterprise 15 Release Candidate 3 is out! Message-ID: <5ad6374ac0f8b_559d11e13146222e@boucane.mail> Here it comes! Release Candidate 3 of SUSE Linux Enterprise 15: SUSE Linux Enterprise Server (SLES), SUSE Linux Enterprise Just Enough Operating System(JeOS), SUSE Linux Enterprise Desktop (SLED), SUSE Linux Enterprise High Availability (SLE-HA), SUSE Linux Enterprise Workstation Extension (SLE-WE) and SUSE Linux Enterprise High Performance Computing (SLE-HPC) Download[1] == Important Notice =Packages DVD When using Packages DVD to install SLE modules, please make sure to also add the Product repository you are installing (SLES / SLED / HA / ...) from Packages DVD. Not doing so might result in missing system roles during installation. =Notable changes - Migration from SLE 12 to SLE 15: Please refer to our new "Upgrade Guide" available as a beta documentation[2] - SLE 15 HPC now fully part of the SLE15 Beta Program. You can now request Beta Registration Code for SLE 15 HPC on x86_64 and aarch64[3]. - OpenSSL 1.0 is no longer installed by default, all packages have been migrated to OpenSSL 1.1. OpenSSL 1.0 will be available in Legacy module. - zypper-package-search-plugin has been added, and allow you to search for packages across ALL SLE15 Online Channels. We are eager to get your feedback on this new searching capability. - Our Release Notes were updated[5] =Package changes - Added packages: dovecot23, enigmail, gegl, gtk2-branding-SLE, gtk-vnc2, java-10-openjdk, libgrss, libimagequant, libsmbios, mpitests-mvapich2-psm2, mpitests-mvapich2-psm, nss_ldap, openmpi_2_1_3-gnu-hpc, openmpi_2_1_3-gnu-hpc-testsuite, pam_ldap, petsc, pidentd, pngquant, python-cmdln, python-Cython, python-distro, smp_utils, unrar_wrapper, xcb-proto, zypper-package-search-plugin. - Removed packages: dovecot22, fprintd, gegl-unstable, iproute2-doc, java-9-openjdk, libfprint, libindicator, libsmbios2, openmpi_2_1_2-gnu-hpc, openmpi_2_1_2-gnu-hpc-testsuite - Updated packages (selection): apache2 2.4.33, cargo 0.25.0 / rust 1.24.1, crash 7.2.1, cups 2.2.7, curl 7.59.0 dhcp 4.3.6-P1, gdb 8.1, git 2.16.3, gstreamer-* 1.12.5, gtk-vnc 0.7.2, haveged 1.9.2 iptables 1.6.2, ipset 6.36, jasper 2.0.14, libreoffice 6.0.3.2, ncurses 6.1-20180317, nginx 1.13.11, nmap 7.70, nodejs 8.11.1, openldap 2.4.46, openmpi 2.1.3, openssl 1.1.0h, open-vm-tools 10.2.5, postfix 3.3.0, rmt-server 0.0.5, rsyslog 8.33.1, sqlite3 3.23.0, wireshark 2.4.6, xrdp 0.9.6 == More information SLE Beta Page[4] Release Notes[5] Known Issues[6] Your SUSE Linux Enterprise Team == Beta Program Please refer to our dedicated SLE Beta Program webpage[1] for any general information. However, do not hesitate to contact us at beta-programs at lists.suse.com if you have any questions. You received this email because you're signed up to get updates from us. Please send an email to beta-programs at lists.suse.com if you want to unsubscribe. [1] https://www.suse.com/betaprogram/sle-beta/#download [2] https://susedoc.github.io/doc-sle/develop/SLES-upgrade/single-html/ [3] https://www.suse.com/betaprogram/sle-beta/#faq-reg [4] https://www.suse.com/betaprogram/sle-beta [5] https://www.suse.com/betaprogram/sle-beta/#releasenotes [6] https://www.suse.com/betaprogram/sle-beta/#knownissues [7] https://www.suse.com/betaprogram/sle-beta/#releases [8] https://www.suse.com/betaprogram/sle-beta/#faq-update1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkoo at THALESESEC.NET Tue Apr 17 19:17:32 2018 From: bkoo at THALESESEC.NET (Bong Koo) Date: Wed, 18 Apr 2018 01:17:32 +0000 Subject: [sle-beta] Need kernel-default-debuginfo package for 4.12.14-16.4-default In-Reply-To: <23A104D0-E4F7-4577-89F7-A3680927BDCF@suse.com> References: <6792a26c83694d188fee101e6779b3de@EXUSDAGORL02.INTERNAL.ROOT.TES> <23A104D0-E4F7-4577-89F7-A3680927BDCF@suse.com> Message-ID: <652f356e8c634817a9f68ac2a3426126@EXUSDAGORL02.INTERNAL.ROOT.TES> Hi, I have installed SLES15 RC3 and found that kernel version, 4.12.14-16-default or 4.12.14-16.2, is older than one for RC2, 4.12.14-16.4-default. Did kernel version fall back to the old one ? Or, didn?t I choose to apply updates during installation ? Regards, Bong ________________________________ [cid:image6fcc04.PNG at 897ed5e7.47b14add] Bong Koo Sr. Software Engineer Tel: +1 669 770 6870 [cid:image1dce7e.PNG at 341e52e4.48878042]@thalesesecurity Thales eSecurity 2860 Junction Ave San Jose CA 95134 United States [cid:imagefba4ca.PNG at 2b57785a.44810aa3] www.thalesesecurity.com [cid:imagef56721.PNG at 514712cb.43962175] [cid:image5a6a5a.PNG at 6f4a12a0.49aa0708] [cid:image5bceaa.PNG at 30ba5098.46a820c3] [cid:image0bac2e.PNG at e09d3e5c.42bf6f94] [cid:imagef5e2a4.PNG at f1bcaa2f.4f8649a4] From: Vincent Moutoussamy Sent: Wednesday, April 04, 2018 5:13 AM To: Bong Koo Cc: sle-beta at lists.suse.com Subject: Re: [sle-beta] Need kernel-default-debuginfo package for 4.12.14-16.4-default Hi, kernel version 4.12.14-16.4-default comes from the patch: SUSE-SLE-Module-Basesystem-15-2018-519 If you did a fresh install, this means that you have chosen to apply updates during the installation. You can get the kernel debuginfo of this kernel by enabling the debuginfo online channel. I would suggest to use YaST: yast -> Software Repositories -> Enable SLE-Module-Basesystem15-Debuginfo-Updates then zypper info should show: zypper info kernel-default-debuginfo Refreshing service 'Basesystem_Module_15_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. Refreshing service 'Server_Applications_Module_15_x86_64'. Loading repository data... Reading installed packages... Information for package kernel-default-debuginfo: ------------------------------------------------- Repository : SLE-Module-Basesystem15-Debuginfo-Updates Name : kernel-default-debuginfo Version : 4.12.14-16.4.1 Arch : x86_64 Vendor : SUSE LLC Support Level : unknown Installed Size : 2.11 GiB Installed : No Status : not installed Source package : kernel-default-4.12.14-16.4.1.nosrc Summary : Debug information for package kernel-default Description : This package provides debug information for package kernel-default. Debug information is useful when developing applications that use this package or when debugging this package. Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager On 3 Apr 2018, at 21:51, Bong Koo > wrote: Hi, With RC2, kernel version is 4.12.14-16.4-default while kernel-default-debuginfo package is for 4.12.14-15.5. Where / how can I get the matching kernel-default-debuginfo package ? Regards, Bong ________________________________ Bong Koo Sr. Software Engineer Tel: +1 669 770 6870 @thalesesecurity Thales eSecurity 2860 Junction Ave San Jose CA 95134 United States www.thalesesecurity.com _______________________________________________ sle-beta mailing list sle-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image6fcc04.PNG Type: image/png Size: 1385 bytes Desc: image6fcc04.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image1dce7e.PNG Type: image/png Size: 498 bytes Desc: image1dce7e.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagefba4ca.PNG Type: image/png Size: 244635 bytes Desc: imagefba4ca.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagef56721.PNG Type: image/png Size: 367 bytes Desc: imagef56721.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image5a6a5a.PNG Type: image/png Size: 457 bytes Desc: image5a6a5a.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image5bceaa.PNG Type: image/png Size: 345 bytes Desc: image5bceaa.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image0bac2e.PNG Type: image/png Size: 340 bytes Desc: image0bac2e.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagef5e2a4.PNG Type: image/png Size: 546 bytes Desc: imagef5e2a4.PNG URL: From Georges.Martin at iba-group.com Wed Apr 18 06:06:51 2018 From: Georges.Martin at iba-group.com (Georges Martin) Date: Wed, 18 Apr 2018 12:06:51 +0000 Subject: [sle-beta] Samba AD DC in SLES 15 ? Message-ID: Hello, Kudos to the team for the nice work on openSUSE/SLES 15 :-) I have a question regarding Samba 4.8, though. In your release notes, you say: "The version of Samba shipped with SUSE Linux Enterprise Server 15 GA delivers integration with Windows 7 Active Directory domains. In addition, we provide the clustered version of Samba as part of SUSE Linux Enterprise High Availability Extension 15 GA." ...so, do you intend to deliver the ActiveDirectory Domain Controller functionalities in SLES 15? G. Ps: I am currently testing the Samba AD DC with Tumbleweed and keeping a close eye on the network:samba:STABLE repo From bkoo at THALESESEC.NET Wed Apr 18 12:10:17 2018 From: bkoo at THALESESEC.NET (Bong Koo) Date: Wed, 18 Apr 2018 18:10:17 +0000 Subject: [sle-beta] Need kernel-default-debuginfo package for 4.12.14-16.4-default In-Reply-To: <652f356e8c634817a9f68ac2a3426126@EXUSDAGORL02.INTERNAL.ROOT.TES> References: <6792a26c83694d188fee101e6779b3de@EXUSDAGORL02.INTERNAL.ROOT.TES> <23A104D0-E4F7-4577-89F7-A3680927BDCF@suse.com> <652f356e8c634817a9f68ac2a3426126@EXUSDAGORL02.INTERNAL.ROOT.TES> Message-ID: <1755cf06eb9349e6a6fe74bd1101aa96@EXUSDAGORL02.INTERNAL.ROOT.TES> Can I get a comment on this ? From: sle-beta-bounces at lists.suse.com On Behalf Of Bong Koo Sent: Tuesday, April 17, 2018 6:18 PM To: Vincent Moutoussamy Cc: sle-beta at lists.suse.com Subject: Re: [sle-beta] Need kernel-default-debuginfo package for 4.12.14-16.4-default Hi, I have installed SLES15 RC3 and found that kernel version, 4.12.14-16-default or 4.12.14-16.2, is older than one for RC2, 4.12.14-16.4-default. Did kernel version fall back to the old one ? Or, didn?t I choose to apply updates during installation ? Regards, Bong ________________________________ [cid:image001.png at 01D3D705.D330B7B0] Bong Koo Sr. Software Engineer Tel: +1 669 770 6870 [cid:image002.png at 01D3D705.D330B7B0]@thalesesecurity Thales eSecurity 2860 Junction Ave San Jose CA 95134 United States [cid:image003.png at 01D3D705.D330B7B0] www.thalesesecurity.com [cid:image004.png at 01D3D705.D330B7B0] [cid:image005.png at 01D3D705.D330B7B0] [cid:image006.png at 01D3D705.D330B7B0] [cid:image007.png at 01D3D705.D330B7B0] [cid:image008.png at 01D3D705.D330B7B0] From: Vincent Moutoussamy > Sent: Wednesday, April 04, 2018 5:13 AM To: Bong Koo > Cc: sle-beta at lists.suse.com Subject: Re: [sle-beta] Need kernel-default-debuginfo package for 4.12.14-16.4-default Hi, kernel version 4.12.14-16.4-default comes from the patch: SUSE-SLE-Module-Basesystem-15-2018-519 If you did a fresh install, this means that you have chosen to apply updates during the installation. You can get the kernel debuginfo of this kernel by enabling the debuginfo online channel. I would suggest to use YaST: yast -> Software Repositories -> Enable SLE-Module-Basesystem15-Debuginfo-Updates then zypper info should show: zypper info kernel-default-debuginfo Refreshing service 'Basesystem_Module_15_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. Refreshing service 'Server_Applications_Module_15_x86_64'. Loading repository data... Reading installed packages... Information for package kernel-default-debuginfo: ------------------------------------------------- Repository : SLE-Module-Basesystem15-Debuginfo-Updates Name : kernel-default-debuginfo Version : 4.12.14-16.4.1 Arch : x86_64 Vendor : SUSE LLC Support Level : unknown Installed Size : 2.11 GiB Installed : No Status : not installed Source package : kernel-default-4.12.14-16.4.1.nosrc Summary : Debug information for package kernel-default Description : This package provides debug information for package kernel-default. Debug information is useful when developing applications that use this package or when debugging this package. Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager On 3 Apr 2018, at 21:51, Bong Koo > wrote: Hi, With RC2, kernel version is 4.12.14-16.4-default while kernel-default-debuginfo package is for 4.12.14-15.5. Where / how can I get the matching kernel-default-debuginfo package ? Regards, Bong ________________________________ Bong Koo Sr. Software Engineer Tel: +1 669 770 6870 @thalesesecurity Thales eSecurity 2860 Junction Ave San Jose CA 95134 United States www.thalesesecurity.com _______________________________________________ sle-beta mailing list sle-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1385 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 498 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 82817 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 367 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 457 bytes Desc: image005.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 345 bytes Desc: image006.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 340 bytes Desc: image007.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.png Type: image/png Size: 546 bytes Desc: image008.png URL: From behlert at suse.com Thu Apr 19 23:43:13 2018 From: behlert at suse.com (Stefan Behlert) Date: Fri, 20 Apr 2018 07:43:13 +0200 Subject: [sle-beta] Need kernel-default-debuginfo package for 4.12.14-16.4-default In-Reply-To: <1755cf06eb9349e6a6fe74bd1101aa96@EXUSDAGORL02.INTERNAL.ROOT.TES> References: <6792a26c83694d188fee101e6779b3de@EXUSDAGORL02.INTERNAL.ROOT.TES> <23A104D0-E4F7-4577-89F7-A3680927BDCF@suse.com> <652f356e8c634817a9f68ac2a3426126@EXUSDAGORL02.INTERNAL.ROOT.TES> <1755cf06eb9349e6a6fe74bd1101aa96@EXUSDAGORL02.INTERNAL.ROOT.TES> Message-ID: <20180420054313.GA29939@suse.de> Moin, On Apr 18, 18 18:10:17 +0000, Bong Koo wrote: > Can I get a comment on this ? sure :) SLE-15-Installer-RC2/x86_64/DVD1/x86_64/kernel-default-4.12.14-15.5.x86_64.rpm SLE-15-Installer-RC3/x86_64/DVD1/x86_64/kernel-default-4.12.14-16.2.x86_64.rpm So RC3 had the newer kernel. My suspicion is that you installed the updates for RC2, and there the _buildcounter_ seemed to be lower than the one for RC3. You can safely ignore it and install the RC3 kernel, which is newer. Stefan > > From: sle-beta-bounces at lists.suse.com On Behalf Of Bong Koo > Sent: Tuesday, April 17, 2018 6:18 PM > To: Vincent Moutoussamy > Cc: sle-beta at lists.suse.com > Subject: Re: [sle-beta] Need kernel-default-debuginfo package for 4.12.14-16.4-default > > Hi, > > I have installed SLES15 RC3 and found that kernel version, 4.12.14-16-default or 4.12.14-16.2, is older than one for RC2, 4.12.14-16.4-default. > Did kernel version fall back to the old one ? > Or, didn?t I choose to apply updates during installation ? > > Regards, > Bong > > > ________________________________ > [cid:image001.png at 01D3D705.D330B7B0] > Bong Koo > Sr. Software Engineer > Tel: +1 669 770 6870 > > [cid:image002.png at 01D3D705.D330B7B0]@thalesesecurity > > Thales eSecurity > 2860 Junction Ave > San Jose CA 95134 > United States > [cid:image003.png at 01D3D705.D330B7B0] > www.thalesesecurity.com > > > [cid:image004.png at 01D3D705.D330B7B0] [cid:image005.png at 01D3D705.D330B7B0] [cid:image006.png at 01D3D705.D330B7B0] [cid:image007.png at 01D3D705.D330B7B0] [cid:image008.png at 01D3D705.D330B7B0] > > > From: Vincent Moutoussamy > > Sent: Wednesday, April 04, 2018 5:13 AM > To: Bong Koo > > Cc: sle-beta at lists.suse.com > Subject: Re: [sle-beta] Need kernel-default-debuginfo package for 4.12.14-16.4-default > > Hi, > > kernel version 4.12.14-16.4-default comes from the patch: SUSE-SLE-Module-Basesystem-15-2018-519 > If you did a fresh install, this means that you have chosen to apply updates > during the installation. > > You can get the kernel debuginfo of this kernel by enabling the debuginfo online > channel. I would suggest to use YaST: > yast -> Software Repositories -> Enable SLE-Module-Basesystem15-Debuginfo-Updates > then zypper info should show: > > zypper info kernel-default-debuginfo > Refreshing service 'Basesystem_Module_15_x86_64'. > Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. > Refreshing service 'Server_Applications_Module_15_x86_64'. > Loading repository data... > Reading installed packages... > > > Information for package kernel-default-debuginfo: > ------------------------------------------------- > Repository : SLE-Module-Basesystem15-Debuginfo-Updates > Name : kernel-default-debuginfo > Version : 4.12.14-16.4.1 > Arch : x86_64 > Vendor : SUSE LLC > Support Level : unknown > Installed Size : 2.11 GiB > Installed : No > Status : not installed > Source package : kernel-default-4.12.14-16.4.1.nosrc > Summary : Debug information for package kernel-default > Description : > This package provides debug information for package kernel-default. > Debug information is useful when developing applications that use this > package or when debugging this package. > > Regards, > -- > Vincent Moutoussamy > SUSE Beta Program and SDK Project Manager > > On 3 Apr 2018, at 21:51, Bong Koo > wrote: > > Hi, > > With RC2, kernel version is 4.12.14-16.4-default while kernel-default-debuginfo package is for 4.12.14-15.5. > Where / how can I get the matching kernel-default-debuginfo package ? > > Regards, > Bong > > ________________________________ > > Bong Koo > Sr. Software Engineer > Tel: +1 669 770 6870 > > @thalesesecurity > > Thales eSecurity > 2860 Junction Ave > San Jose CA 95134 > United States > > www.thalesesecurity.com > > > > > > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta > > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -- Stefan Behlert, SUSE LINUX Release Manager Enterprise Server Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-173 SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) From kukuk at suse.de Sun Apr 22 23:01:39 2018 From: kukuk at suse.de (Thorsten Kukuk) Date: Mon, 23 Apr 2018 07:01:39 +0200 Subject: [sle-beta] SLES 15 RC3 missing sys group In-Reply-To: References: Message-ID: <20180423050139.GA6603@suse.de> On Mon, Apr 23, Alex Hennekam wrote: > Hi, > > While I understand that the sys group is kinda obsolete and rarely used, > removing it will cause upgrade issues for some products and components. We don't delete groups during upgrade, so this cannot lead to an upgrade issue. > I'll > try to explain. If I have a single stand-alone component rpm install that sets > it's file permissions as root/sys then when I install it we get the warning > "warning: group sys does not exist - using root". While this is visually > distracting the install still works and the rpm command returns success (zero). > This most folks can likely live with. If you need the group sys, just install them: 'zypper insall "group(sys)"' Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) From Dick.Waite at softwareag.com Tue Apr 24 06:53:44 2018 From: Dick.Waite at softwareag.com (Waite, Dick (External)) Date: Tue, 24 Apr 2018 12:53:44 +0000 Subject: [sle-beta] UPDATE with RC3 Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D01207A792D@daeexmbx1.eur.ad.sag> Grand Day, I used VMware Virtual machines that did UPDATE with Beta-6 and 7 in the offline, no regisrtion key mode with SLES15 - RC3. I have not tested with RC1 or RC2. The UPDATE ran without any visible issue but on the re-ipl each machine fails to load. I'm using the RC3 installer and then via network update the environment. This looks Okay. I can see the console and via C+A+F10 the systemd output but I can not enter any commands. When trying to close down often the VMware "stop" does not close the systems. They use ext3, ext4 and XFS, no btrfs systems. I can capture an image view but I'm sure SUSE would like more, I don't know how to give you more. These machines do run with SLES12 SP-3 and they did UPDATE with Beta6 and 7 using both Installer and packages iso's Be happy to try again tomorrow with your good words of advice. __R Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolmlewis at cableone.net Tue Apr 24 07:44:29 2018 From: malcolmlewis at cableone.net (Malcolm) Date: Tue, 24 Apr 2018 08:44:29 -0500 Subject: [sle-beta] SLED 15 RC2 - Unable to install gnome-shell extensions integration In-Reply-To: <20180327182629.5b66b784@grover.homelinux.org> References: <20180327182629.5b66b784@grover.homelinux.org> Message-ID: <20180424084429.387b9dd1@grover.homelinux.org> On Tue, 27 Mar 2018 18:26:29 -0500 Malcolm wrote: > Hi > If I go to https://extensions.gnome.org and try to install the browser > extension it downloads, but is unable to install because it's not > compatible with Firefox 52.7.2. The installed version of > chrome-gnome-shell is 10-1.3 on Leap 42.3 which also uses the same > browser version is 9-1.1 and works fine. > > This was working in RC1... > Hi Bump.... failing in RC3 Firefox 52.7.3 I'm guessing it's the missing gnome-shell-browser-plugin (part of gnome-shell). Is this missing on purpose, or needs a bug report? -- Cheers Malcolm ??? SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.3 | GNOME 3.20.2 | 4.4.126-48-default HP 255 G4 Notebook | A6-6310 X4 @ 1.80 GHz | AMD Radeon R4 up 4 days 12:09, 1 user, load average: 2.71, 3.56, 3.12 From fcrozat at suse.com Tue Apr 24 08:21:28 2018 From: fcrozat at suse.com (Frederic Crozat) Date: Tue, 24 Apr 2018 16:21:28 +0200 Subject: [sle-beta] SLED 15 RC2 - Unable to install gnome-shell extensions integration In-Reply-To: <20180424084429.387b9dd1@grover.homelinux.org> References: <20180327182629.5b66b784@grover.homelinux.org> <20180424084429.387b9dd1@grover.homelinux.org> Message-ID: <1524579688.4317.16.camel@suse.com> Le mardi 24 avril 2018 ? 08:44 -0500, Malcolm a ?crit : > On Tue, 27 Mar 2018 18:26:29 -0500 > Malcolm wrote: > > > Hi > > If I go to https://extensions.gnome.org and try to install the > > browser > > extension it downloads, but is unable to install because it's not > > compatible with Firefox 52.7.2. The installed version of > > chrome-gnome-shell is 10-1.3 on Leap 42.3 which also uses the same > > browser version is 9-1.1 and works fine. > > > > This was working in RC1... > > > > Hi > Bump.... failing in RC3 Firefox 52.7.3 I'm guessing it's the missing > gnome-shell-browser-plugin (part of gnome-shell). Is this missing on > purpose, or needs a bug report? We do not provide gnome-shell-browser-plugin on SLE15 because NPAPI plugin are not available in the next ESR release of Firefox, which will be released next month. chrome-gnome-shell is used instead to do the same job. -- Frederic Crozat Enterprise Desktop Release Manager SUSE From malcolmlewis at cableone.net Tue Apr 24 08:32:22 2018 From: malcolmlewis at cableone.net (Malcolm) Date: Tue, 24 Apr 2018 09:32:22 -0500 Subject: [sle-beta] SLED 15 RC2 - Unable to install gnome-shell extensions integration In-Reply-To: <1524579688.4317.16.camel@suse.com> References: <20180327182629.5b66b784@grover.homelinux.org> <20180424084429.387b9dd1@grover.homelinux.org> <1524579688.4317.16.camel@suse.com> Message-ID: <20180424093222.6af0bfe2@grover.homelinux.org> On Tue, 24 Apr 2018 16:21:28 +0200 Frederic Crozat wrote: > Le mardi 24 avril 2018 ? 08:44 -0500, Malcolm a ?crit : > > On Tue, 27 Mar 2018 18:26:29 -0500 > > Malcolm wrote: > > > > > Hi > > > If I go to https://extensions.gnome.org and try to install the > > > browser > > > extension it downloads, but is unable to install because it's not > > > compatible with Firefox 52.7.2. The installed version of > > > chrome-gnome-shell is 10-1.3 on Leap 42.3 which also uses the same > > > browser version is 9-1.1 and works fine. > > > > > > This was working in RC1... > > > > > > > Hi > > Bump.... failing in RC3 Firefox 52.7.3 I'm guessing it's the missing > > gnome-shell-browser-plugin (part of gnome-shell). Is this missing on > > purpose, or needs a bug report? > > We do not provide gnome-shell-browser-plugin on SLE15 because NPAPI > plugin are not available in the next ESR release of Firefox, which > will be released next month. > > chrome-gnome-shell is used instead to do the same job. > Hi Frederic Hmm, so chrome-gnome-shell plugin is installed, yet still get the pop up at extensions.gnome.org after trying to install saying "GNOME shell integration could not be installed because it's not compatible with Firefox 52.7.3". So I'm guessing it's just a waiting game for the newer ESR release in SLE 15? -- Cheers Malcolm ??? SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.3 | GNOME 3.20.2 | 4.4.126-48-default HP 255 G4 Notebook | A6-6310 X4 @ 1.80 GHz | AMD Radeon R4 up 4 days 12:55, 1 user, load average: 2.10, 2.79, 3.02 From fcrozat at suse.com Tue Apr 24 09:20:12 2018 From: fcrozat at suse.com (Frederic Crozat) Date: Tue, 24 Apr 2018 17:20:12 +0200 Subject: [sle-beta] SLED 15 RC2 - Unable to install gnome-shell extensions integration In-Reply-To: <20180424093222.6af0bfe2@grover.homelinux.org> References: <20180327182629.5b66b784@grover.homelinux.org> <20180424084429.387b9dd1@grover.homelinux.org> <1524579688.4317.16.camel@suse.com> <20180424093222.6af0bfe2@grover.homelinux.org> Message-ID: <1524583212.4317.18.camel@suse.com> Le mardi 24 avril 2018 ? 09:32 -0500, Malcolm a ?crit : > On Tue, 24 Apr 2018 16:21:28 +0200 > Frederic Crozat wrote: > > > Le mardi 24 avril 2018 ? 08:44 -0500, Malcolm a ?crit : > > > On Tue, 27 Mar 2018 18:26:29 -0500 > > > Malcolm wrote: > > > > > > > Hi > > > > If I go to https://extensions.gnome.org and try to install the > > > > browser > > > > extension it downloads, but is unable to install because it's > > > > not > > > > compatible with Firefox 52.7.2. The installed version of > > > > chrome-gnome-shell is 10-1.3 on Leap 42.3 which also uses the > > > > same > > > > browser version is 9-1.1 and works fine. > > > > > > > > This was working in RC1... > > > > > > > > > > Hi > > > Bump.... failing in RC3 Firefox 52.7.3 I'm guessing it's the > > > missing > > > gnome-shell-browser-plugin (part of gnome-shell). Is this missing > > > on > > > purpose, or needs a bug report? > > > > We do not provide gnome-shell-browser-plugin on SLE15 because NPAPI > > plugin are not available in the next ESR release of Firefox, which > > will be released next month. > > > > chrome-gnome-shell is used instead to do the same job. > > > > Hi Frederic > Hmm, so chrome-gnome-shell plugin is installed, yet still get the pop > up at extensions.gnome.org after trying to install saying "GNOME > shell > integration could not be installed because it's not compatible with > Firefox 52.7.3". > > So I'm guessing it's just a waiting game for the newer ESR release in > SLE 15? Yes. We plan to ship a new Firefox release to beta testers as soon as we have one which works reliably on all SLE supported platforms ! -- Frederic Crozat Enterprise Desktop Release Manager SUSE From bkoo at THALESESEC.NET Wed Apr 25 17:44:05 2018 From: bkoo at THALESESEC.NET (Bong Koo) Date: Wed, 25 Apr 2018 23:44:05 +0000 Subject: [sle-beta] libcrypto is missing while installing condor on SLES15 RC3 Message-ID: <833d8ba6a0af42f49f8bd09b37a6db68@EXUSDAGORL02.INTERNAL.ROOT.TES> Hi, Installing ?condor? package has failed due to missing libcrypto. How do I get this ? # zypper in condor Refreshing service 'Basesystem_Module_15_x86_64'. Refreshing service 'Desktop_Applications_Module_15_x86_64'. Refreshing service 'Development_Tools_Module_15_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. Refreshing service 'Server_Applications_Module_15_x86_64'. Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides libcrypto.so.1.0.0()(64bit) needed by condor-8.6.6-3.1.x86_64 Solution 1: do not install condor-8.6.6-3.1.x86_64 Solution 2: break condor-8.6.6-3.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): Regards, Bong ________________________________ [cid:image41e54c.PNG at 84f8afb4.4786a125] Bong Koo Sr. Software Engineer Tel: +1 669 770 6870 [cid:imageb39f98.PNG at 631f4235.48acf601]@thalesesecurity Thales eSecurity 2860 Junction Ave San Jose CA 95134 United States [cid:image005b82.PNG at ed7c3500.4f91b35d] www.thalesesecurity.com [cid:imagee4b66b.PNG at 0e98484f.4ebd6cc1] [cid:image896314.PNG at 98b5bc29.43b2dfa6] [cid:imagec3f77a.PNG at dac631a4.41a2d785] [cid:image40768b.PNG at 9fe07abd.4cb78a79] [cid:imagef4e0a5.PNG at 418625d7.4da7c2ce] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image41e54c.PNG Type: image/png Size: 1385 bytes Desc: image41e54c.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imageb39f98.PNG Type: image/png Size: 498 bytes Desc: imageb39f98.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005b82.PNG Type: image/png Size: 60612 bytes Desc: image005b82.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagee4b66b.PNG Type: image/png Size: 367 bytes Desc: imagee4b66b.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image896314.PNG Type: image/png Size: 457 bytes Desc: image896314.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagec3f77a.PNG Type: image/png Size: 345 bytes Desc: imagec3f77a.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image40768b.PNG Type: image/png Size: 340 bytes Desc: image40768b.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagef4e0a5.PNG Type: image/png Size: 546 bytes Desc: imagef4e0a5.PNG URL: From meissner at suse.de Wed Apr 25 23:21:13 2018 From: meissner at suse.de (Marcus Meissner) Date: Thu, 26 Apr 2018 07:21:13 +0200 Subject: [sle-beta] libcrypto is missing while installing condor on SLES15 RC3 In-Reply-To: <833d8ba6a0af42f49f8bd09b37a6db68@EXUSDAGORL02.INTERNAL.ROOT.TES> References: <833d8ba6a0af42f49f8bd09b37a6db68@EXUSDAGORL02.INTERNAL.ROOT.TES> Message-ID: <20180426052113.digx74lixpm3v3nw@suse.de> Hi, This library is in the legacy module, as the core product now uses openssl 1.1 Ciao, Marcus On Wed, Apr 25, 2018 at 11:44:05PM +0000, Bong Koo wrote: > Hi, > > Installing ?condor? package has failed due to missing libcrypto. > How do I get this ? > > # zypper in condor > Refreshing service 'Basesystem_Module_15_x86_64'. > Refreshing service 'Desktop_Applications_Module_15_x86_64'. > Refreshing service 'Development_Tools_Module_15_x86_64'. > Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. > Refreshing service 'Server_Applications_Module_15_x86_64'. > Loading repository data... > Reading installed packages... > Resolving package dependencies... > > Problem: nothing provides libcrypto.so.1.0.0()(64bit) needed by condor-8.6.6-3.1.x86_64 > Solution 1: do not install condor-8.6.6-3.1.x86_64 > Solution 2: break condor-8.6.6-3.1.x86_64 by ignoring some of its dependencies > > Choose from above solutions by number or cancel [1/2/c] (c): > > Regards, > Bong > > ________________________________ > [cid:image41e54c.PNG at 84f8afb4.4786a125] > Bong Koo > Sr. Software Engineer > Tel: +1 669 770 6870 > > [cid:imageb39f98.PNG at 631f4235.48acf601]@thalesesecurity > > Thales eSecurity > 2860 Junction Ave > San Jose CA 95134 > United States > > [cid:image005b82.PNG at ed7c3500.4f91b35d] > > www.thalesesecurity.com > > [cid:imagee4b66b.PNG at 0e98484f.4ebd6cc1] [cid:image896314.PNG at 98b5bc29.43b2dfa6] [cid:imagec3f77a.PNG at dac631a4.41a2d785] [cid:image40768b.PNG at 9fe07abd.4cb78a79] [cid:imagef4e0a5.PNG at 418625d7.4da7c2ce] > > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real From jmoss at ecsmtp.pdx.intel.com Wed Apr 25 18:24:28 2018 From: jmoss at ecsmtp.pdx.intel.com (joseph.v.moss) Date: Wed, 25 Apr 2018 17:24:28 -0700 Subject: [sle-beta] libcrypto is missing while installing condor on SLES15 RC3 In-Reply-To: Your message of "Wed, 25 Apr 2018 23:44:05 -0000." <833d8ba6a0af42f49f8bd09b37a6db68@EXUSDAGORL02.INTERNAL.ROOT.TES> Message-ID: <59362.1524702268@ichips.intel.com> > Hi, > ?? > Installing ???condor??? package has failed due to missing libcrypto. > How do I get this ? > ?? > # zypper in condor > Refreshing service 'Basesystem_Module_15_x86_64'. > Refreshing service 'Desktop_Applications_Module_15_x86_64'. > Refreshing service 'Development_Tools_Module_15_x86_64'. > Refreshing service 'SUSE_Linux_Enterprise_Server_15_x86_64'. > Refreshing service 'Server_Applications_Module_15_x86_64'. > Loading repository data... > Reading installed packages... > Resolving package dependencies... > ?? > Problem: nothing provides libcrypto.so.1.0.0()(64bit) needed by > condor-8.6.6-3.1.x86_64 > Solution 1: do not install condor-8.6.6-3.1.x86_64 > Solution 2: break condor-8.6.6-3.1.x86_64 by ignoring some of its dependencies > ?? > Choose from above solutions by number or cancel [1/2/c] (c): ?? Short answer: add the Legacy module The release notes say: > OpenSSL libraries version 1.0.x were moved to the Legacy Module. The module has a different lifecycle from SUSE Linux Enterprise Server itself. This version is not expected to receive feature updates or security certifications. For new development, make sure to use the default OpenSSL version 1.1.x. So adding the Legacy Module should provide the needed dependencies, for now. The question is when will condor be updated to use the newer version of OpenSSL? From James.Taylor at eastcobbgroup.com Thu Apr 26 10:36:06 2018 From: James.Taylor at eastcobbgroup.com (James Taylor) Date: Thu, 26 Apr 2018 12:36:06 -0400 Subject: [sle-beta] Activation Key Message-ID: <5AE1C7B602000075000563B0@inet.eastcobbgroup.com> I need an activation for SLES, please. -jt James Taylor 678-697-9420 james.taylor at eastcobbgroup.com From vmoutoussamy at suse.com Fri Apr 27 09:01:50 2018 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Fri, 27 Apr 2018 17:01:50 +0200 Subject: [sle-beta] UPDATE with RC3 In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D01207A792D@daeexmbx1.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D01207A792D@daeexmbx1.eur.ad.sag> Message-ID: Hi, Hum well I guess if you can reproduce this with a fresh installation or when migrating SLES12SP3 to SLES15 RC3, this might be worth to investigate via a bugzilla report. Please be sure to provide supportconfig, screenshots and environment descriptions to ensure that we can investigate. Have a nice day, Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager > On 24 Apr 2018, at 14:53, Waite, Dick (External) wrote: > > Grand Day, > > I used VMware Virtual machines that did UPDATE with Beta-6 and 7 in the offline, no regisrtion key mode with SLES15 - RC3. I have not tested with RC1 or RC2. > > The UPDATE ran without any visible issue but on the re-ipl each machine fails to load. I'm using the RC3 installer and then via network update the environment. This looks Okay. > > I can see the console and via C+A+F10 the systemd output but I can not enter any commands. When trying to close down often the VMware "stop" does not close the systems. They use ext3, ext4 and XFS, no btrfs systems. > > I can capture an image view but I'm sure SUSE would like more, I don't know how to give you more. > > These machines do run with SLES12 SP-3 and they did UPDATE with Beta6 and 7 using both Installer and packages iso's > > Be happy to try again tomorrow with your good words of advice. > > __R > > > Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From vmoutoussamy at suse.com Fri Apr 27 09:18:27 2018 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Fri, 27 Apr 2018 17:18:27 +0200 Subject: [sle-beta] kdump doesn't work with Xen In-Reply-To: <1726741.L56QzCjM8A@amur> References: <1726741.L56QzCjM8A@amur> Message-ID: <7BE1AA08-F7B0-48F2-9A9A-DB364CB617F6@suse.com> Hi, Could you please create a bug report if you can still reproduce this on RC3? Thanks, Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager > On 13 Apr 2018, at 10:05, Dietmar Hahn wrote: > > Hi, > > I installed a virtualisationhost with Xen as the hypervisor. > With yast I configured kdump. > After a reboot on the serial console I can see: > (XEN) Kdump: 239MB (244736kB) at 0xac300000 > > # systemctl status kdump > ? kdump.service - Load kdump kernel and initrd > Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled) > Active: active (exited) since Fri 2018-04-13 05:19:49 CEST; 1h 54min ago > Process: 1480 ExecStart=/lib/kdump/load.sh --update (code=exited, status=0/SUCCESS) > Main PID: 1480 (code=exited, status=0/SUCCESS) > Tasks: 0 (limit: 4915) > CGroup: /system.slice/kdump.service > > Apr 13 05:19:46 bs2gfx systemd[1]: Starting Load kdump kernel and initrd... > Apr 13 05:19:49 bs2gfx kdump[1622]: Loaded kdump kernel: /sbin/kexec -p /boot/vmlinuz-4.12.14-16.4-default --a > Apr 13 05:19:49 bs2gfx systemd[1]: Started Load kdump kernel and initrd. > > All seem to be very well but when triggering the crash via > # echo c > /proc/sysrq-trigger > no dump is written, I only see the message > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. > > Later I tried to trigger the crash directly from within Xen: > login: (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to DOM0) > (XEN) 'C' pressed -> triggering crashdump > (XEN) * no crash kernel loaded! > > Is there something I'm doing wrong? > Thanks. > > Dietmar. > > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From jsrain at suse.cz Mon Apr 30 01:21:05 2018 From: jsrain at suse.cz (Jiri Srain) Date: Mon, 30 Apr 2018 09:21:05 +0200 Subject: [sle-beta] Adding extensions and modules after install In-Reply-To: <5AE371F4020000860001CDA0@prvgwdev-52.provo.novell.com> References: <5AE30F96020000860001CD8A@prvgwdev-52.provo.novell.com> <5AE371F4020000860001CDA0@prvgwdev-52.provo.novell.com> Message-ID: <4496e7cd-1e9c-b2ba-26f6-6222833ce905@suse.cz> Hello, On 27.4.2018 20:54, Glen Christensen wrote: > While it is possible to visit Yast2 > Software Management and install > additional packages, I am looking to add based on Module name that is > available, but not yet installed. > > During install the modules we select are installed, however,?after the > install?when we?launch YaST2 > Software >Add On Products we can see the > list of modules we added during the installation.? > > At this point?we want to add another?module that we missed during the > install.? So at this point I click Add > and I have to re-add the NFS > server which I don't understand since we added it during install, but I > add the NFS server and the exported directory and click OK and then I > see a list of Available Extensions and Modules, however, at this point > none of the modules display as having been installed. I would expect to > see the modules that I already have installed with a check in their > corresponding check box, but all the module check boxes are unchecked.? > Is this intentional? Well, you decided to add the modules (during installation as well as later) manually - as far as I understand - and not from the list coming from SCC. Which is a valid approach, but has some limits. The Packages DVD is only a list of repositories. When you see the list of repos, YaST does not know what is in each of them until you select them (scanning would take some time) and therefore it does not know which of them contain already installed modules. Until you select the repo from the media, it is just a generic repo which YaST knows nothing about. Even if it is the same module, it could be a newer snapshot (if we release it). The handling of custom repositories is generic to cover all cases. > Is there a reason we have to re-add the NFS repo? Adding the repo which is already added does not make any sense. As long as the contents is the same, there is no reason to do so. > Is there a reson the above module list does not have any modules checked? Yes, see above. If you select the modules provided by SCC (or RMT) and ghen select more via the registration module, you should see your installed modules checked in the list. However, in your screenshot, you only have a list of unknown repos. Hope that this explains the situation, Jiri -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain at suse.com Krizikova 148/34 tel: +420 284 084 659 186 00 Praha 8 fax: +420 284 084 001 Czech Republic http://www.suse.com From wstephenson at suse.de Mon Apr 30 05:48:41 2018 From: wstephenson at suse.de (Will Stephenson) Date: Mon, 30 Apr 2018 13:48:41 +0200 Subject: [sle-beta] YaST2 > Select Extentions In-Reply-To: <5AE37207020000860001CDA6@prvgwdev-52.provo.novell.com> References: <5AE37207020000860001CDA6@prvgwdev-52.provo.novell.com> Message-ID: <2652640.EMFieZJptO@f8> On Friday, 27 April 2018 20:55:03 CEST Glen Christensen wrote: > When we launch to YaST2 > Software > Add System Extensions or Modules > Skip > Registration > OK > Next the YaST2, Select Extensions dialog closes. > > 1. Is that W.A.D. since there are no reg servers for a beta product? SCC knows all about beta products, you can register with your beta keys. > 2. Is there a reason it doesn't pull up a list of available modules based on > the repository that is already in place for the Package 1 ISO? Can't help you with that one, I'm afraid. Will -- Will Stephenson SUSE Linux GmbH GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg) Maxfeldstra?e 5 90409 N?rnberg Germany From jsrain at suse.cz Mon Apr 30 06:03:41 2018 From: jsrain at suse.cz (Jiri Srain) Date: Mon, 30 Apr 2018 14:03:41 +0200 Subject: [sle-beta] YaST2 > Select Extentions In-Reply-To: <5AE37207020000860001CDA6@prvgwdev-52.provo.novell.com> References: <5AE37207020000860001CDA6@prvgwdev-52.provo.novell.com> Message-ID: <8be7e423-4083-4f4a-e5e0-08e4e989c99c@suse.cz> Hello Glen, On 27.4.2018 20:55, Glen Christensen wrote: > When we launch to YaST2 > Software > Add System Extensions or Modules > > Skip Registration?> OK > Next the YaST2, Select Extensions?dialog closes. > > 1. Is that?W.A.D. since there are no reg servers for a beta product? > > 2. Is there a reason it doesn't pull up a list of available?modules > based on the repository that is already in place for the Package 1 ISO? I'm not sure I understand your question, anyway, let me try: On the Packages DVD, there is one repository per module. The system knows what is inside the repository when you add it first. That means, there is no knowledge about modules available on the Packages media except the enabled repos. I would generally not mix repos coming from the packages media and from SCC; if you want to avoid multiple downloads, I suggest to use a local proxy like RMT to only mirror each repository from SCC once. There are two reasons not to mix them: - when registering, SCC will also provide repositories with updates; having one module with updates and another one without can lead to dependency conflicts when there are updates released requiring update for packages in other modules - you will make your life harder when migrating system to SP1; with SCC, all repo adjustments can be done automatically, with Packages DVD you are on your own; mixing these approaches are a good way to miss some repo adjustments You can build your custom Packages DVD (just add your own repos, remove existing, and update the index in the media.1 directory). Then the list of available repositories has nothing to do with the list which SCC provides. SCC only provides repos which it serves itself, but cannot provide repos from your (possibly custom?) DVD. Hope that this makes it a bit more clear for you, Jiri -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain at suse.com Krizikova 148/34 tel: +420 284 084 659 186 00 Praha 8 fax: +420 284 084 001 Czech Republic http://www.suse.com