From vmoutoussamy at suse.com Thu Jan 4 09:49:17 2018 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Thu, 4 Jan 2018 17:49:17 +0100 Subject: [sle-beta] Kernel patch (4.12.14-8.3.12) in our online channels Message-ID: Happy new year everyone! For those who didn?t notice it we have released a kernel patch (4.12.14-8.3.12) on 27th December, the detailed changelog of this patch can be found in attachment or you can use "sudo zypper info -t patch SUSE-SLE-Module-Basesystem-15-2017-2151? if you have registered your SLE 15 Beta. /!\IMPORTANT/!\ This patch was prior to Meltdown and Spectre: https://www.suse.com/c/suse-addresses-meltdown-spectre-vulnerabilities/ But for sure the Meltdown and Spectre CVE will also be addressed in future updates for SLE15. Happy testing, Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SUSE-SLE-Module-Basesystem-15-2017-2151.txt 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 Dick.Waite at softwareag.com Wed Jan 17 11:00:57 2018 From: Dick.Waite at softwareag.com (Waite, Dick (External)) Date: Wed, 17 Jan 2018 18:00:57 +0000 Subject: [sle-beta] Beta5 - UPDATE / migrate ? Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D0120729301@daeexmbx1.eur.ad.sag> Grand Beta5 Vincent, It's Thursday in some parts our world, so will we be celebrate 2018 with a Beta that supports UPDATE / migrate so that many of us can really start to use SLES15 and check it's performance against SLES12. I do understand you want your new features tested and I have done work on that but the real test of SLES15 is it's ability to perform, with these new features, better than sLES12, and for that one needs to be able to migrate working systems to SLES15 to see what we have in "wall clock" for those night batch runs which each year seem to need to do more work in less time et al. Wishing all an exciting and healthy 2018. __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 From beta-programs at lists.suse.com Fri Jan 19 08:32:36 2018 From: beta-programs at lists.suse.com (SUSE Beta Program) Date: Fri, 19 Jan 2018 16:32:36 +0100 Subject: [sle-beta] SLE 15 Beta 5 release delayed to the week of January 22nd, 2018 Message-ID: <5a620f942f579_738993931016489@boucane.mail> Dear Beta user, As you know, the release of the SUSE Linux Enterprise (SLE) 15 Beta 5 was scheduled for January 18th, 2018. While we have incorporated all the feedback received so far as part of the SLE 15 Beta 5 release, we are also working to incorporate the fixes to the recent hardware security vulnerabilities ? Meltdown and Spectre. The SUSE Linux Enterprise production releases have all been updated with the fixes to these vulnerabilities. Unfortunately, due to the timing of these hardware security vulnerabilities and the work required to incorporate, fully test and validate the fixes in to the beta release, the availability of the Beta 5 release has been impacted. Our updated plan is to delay Beta 5 release originally scheduled for January 18th, 2018 to the week of January 22nd, 2018. This allows us to deliver the next Beta release with the fixes for the recent vulnerabilities included. While we realize this is a delay in getting you the latest Beta release, our top priority is ensuring these vulnerabilities are addressed so that we are not prolonging these exposures for our beta customers. The SLE Release Team will keep you informed on the exact release date of Beta 5 via sle-beta at lists.suse.com. We thank you for your continued support of the SUSE Linux Enterprise 15 Beta program and look forward to your feedback on the upcoming SLE15 Beta 5 release. With Kind Regards, SUSE Product Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From vmoutoussamy at suse.com Mon Jan 22 07:30:43 2018 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Mon, 22 Jan 2018 15:30:43 +0100 Subject: [sle-beta] Desktop Applications Module and rpmbuild In-Reply-To: <499e7aa4580a46e69f59f5899d55d1a1@EXUSDAGORL02.INTERNAL.ROOT.TES> References: <499e7aa4580a46e69f59f5899d55d1a1@EXUSDAGORL02.INTERNAL.ROOT.TES> Message-ID: <169EAB1E-B017-4E36-BD38-0F8A2477D462@suse.com> Hi, > On 19 Jan 2018, at 23:41, Bong Koo wrote: > > Hi, > > I have installed a VM with SLES15-Beta4 and registered it. > During installation, I can?t add ?Development Tools Module?. Please be more specific with ?can?t add Development Tools Module?: - Did you register during the installation? - apart from "Development Tools Module?, were the rest of the modules fine to be added? - What was the error message? > Can I get help on installing it ? Could you please copy/paste the output of the following command: $ sudo zypper lr > > Anyway, after installation, I tried to install ?gcc? with ?zypper?. > But, ?rpmbuild? can not be installed again. > What is the best way to install it ? gcc is in the "SLE-Module-Basesystem15-Pool?, so you don?t need the Development Tools for this package. But rpm-build is in the Development Tools Module. So we need to find the root cause of your online channels registration but you can also manually add the ?Packages? DVD as a repository via yast/zypper. > Regards, > Bong Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager -------------- 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 beta-programs at lists.suse.com Tue Jan 23 07:32:04 2018 From: beta-programs at lists.suse.com (SUSE Beta Program) Date: Tue, 23 Jan 2018 15:32:04 +0100 Subject: [sle-beta] [ANNOUNCE] SUSE Linux Enterprise 15 is now Beta 5! Message-ID: <5a674764932dc_43c0f1331c764b4@boucane.mail> We are apologizing for the delay, at last here comes Beta 5 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), and SUSE Linux Enterprise Workstation Extension (SLE-WE) Download[1] == Important =Migration from SLE 12 to SLE 15: With Beta 5, we are still not in an ideal state for the support of the different Migration scenarios from SLE 12 to SLE 15. You can try it but it is not expected to be smooth! Nevertheless do not hesitate to share your findings if you face any issues, but keep in mind that the state of the migration will be improved for the Release Candidate phase. - Offline migration: With Beta 5, it is possible by using the "Installer" and "Packages" isos. - Online migration: Not possible with Beta 5, the SCC setup of the online channels still needs adaptation. We hope to get this done for future beta releases. =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 - SLE 15 Beta 5 integrates Meltdown and Spectre mitigations for the Linux kernel, - Starting with Beta5, SLES 15 JeOS images are now available for download and testing! However the OpenStack JeOS image will only be available in future beta, - Virtualization: We are moving our virtual machine management tooling from python2 to python3 for SLE 15, in that matter, Beta5 contains a lot of changes, - openSSL 1.1.0 is now the default and used in the distribution. The old openSSL 1.0.0 will be provided in the final product in the Legacy module, Some packages may still encounter issues. - Planned Releases dates have been updated[5]. =Fixed bugs in beta 5 (selection): - Modules are not preselected after registration, make sure to select Basesystem module at minimum (bsc#1056413) == More information SLE Beta Page[2] Release Notes[3] Known Issues[4] 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://www.suse.com/betaprogram/sle-beta [3] https://www.suse.com/betaprogram/sle-beta/#releasenotes [4] https://www.suse.com/betaprogram/sle-beta/#knownissues [5] https://www.suse.com/betaprogram/sle-beta/#releases -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrd at netlab1.net Wed Jan 24 02:22:19 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Wed, 24 Jan 2018 09:22:19 +0000 Subject: [sle-beta] Beta 5, initial impressions Message-ID: ??? SLES 15 beta 5. My overall impression thus far is good, and the system works as an ESXi guest in my case. ??? A few comments about it. ??? A fresh installation of beta 5 would not boot: no O/S found. Some use of Recovery and Update menus to view and refresh disk partitioning and initrd brought this under control. I must have made a silly error somewhere in this familiar process. A guess is I defined a /boot partition, type EXT2 so there is no journal to be replayed, and not using the offered EFI choice. Root is XFS. Unless others encounter a similar problem this will remain as a local fluke. ??? Retention of various standard network utilities (say netstat, telnet etc) is much appreciated. Yet there remain problems such as xinetd not installing completely and thus not being usable. What would significantly help is a document describing the changes/shifts of direction/replacements so that sysadmins could smoothly cope with the changes. Presently we are left stranded.? Such a doc could extrapolate from say SLES11 level to that now in SLES15. ??? I appreciate the gradual reordering of material; that is good. However, in the process some common installation bits are becoming buried in the overall structure. Examples are setting the screen resolution and some menus now have their captions truncated and thus be nearly unusable, ntp being disabled after its usual initial setup, PackageKit refusing to get out of the way, nearly buried Cert Authority config in YaST, non-tracking of GUI keyboard language, and so forth. Thus, for the future I think a good idea would be to identify such common practice settings and make them be more visible rather than being relegated levels deep as now. ??? It is a bit concerning to see the Apache web server identified as basically unsupported, and its YaST section gone. There must be a good reasons for this, yet it would be beneficial for us to have Apache return as a first class item rather than a DIY item. ??? I am pleased to see the system brought to the Openssl v1.1 level across the board, and having the FIPS option. ??? Lastly, I am impressed with how well SUSE is handling the current CPU chip security issues. That measured approach is valued. ??? Thanks, ??? Joe D. From jsrain at suse.cz Wed Jan 24 03:10:20 2018 From: jsrain at suse.cz (Jiri Srain) Date: Wed, 24 Jan 2018 11:10:20 +0100 Subject: [sle-beta] Beta 5, initial impressions In-Reply-To: References: Message-ID: <9bba24a5-584a-7891-5f6b-c14bab18e79a@suse.cz> Hello Joe, On 24.1.2018 10:22, Joe Doupnik wrote: > ??? SLES 15 beta 5. My overall impression thus far is good, and the > system works as an ESXi guest in my case. > ??? A few comments about it. > ??? A fresh installation of beta 5 would not boot: no O/S found. Some > use of Recovery and Update menus to view and refresh disk partitioning > and initrd brought this under control. I must have made a silly error > somewhere in this familiar process. A guess is I defined a /boot > partition, type EXT2 so there is no journal to be replayed, and not > using the offered EFI choice. Root is XFS. Unless others encounter a > similar problem this will remain as a local fluke. Hard to guess from this information, anyway: As you mentioned EFI, you need to have a /boot/efi partition formatted as MS-DOS, otherwise the EFI firmware will not boot. Having (additional) /boot with ext2 should not hurt, although I don't see a use for it. With Beta6, you should get a warning when you do a mistake in partitioning that should prevent booting. Jiri > ??? Retention of various standard network utilities (say netstat, telnet > etc) is much appreciated. Yet there remain problems such as xinetd not > installing completely and thus not being usable. What would > significantly help is a document describing the changes/shifts of > direction/replacements so that sysadmins could smoothly cope with the > changes. Presently we are left stranded.? Such a doc could extrapolate > from say SLES11 level to that now in SLES15. > ??? I appreciate the gradual reordering of material; that is good. > However, in the process some common installation bits are becoming > buried in the overall structure. Examples are setting the screen > resolution and some menus now have their captions truncated and thus be > nearly unusable, ntp being disabled after its usual initial setup, > PackageKit refusing to get out of the way, nearly buried Cert Authority > config in YaST, non-tracking of GUI keyboard language, and so forth. > Thus, for the future I think a good idea would be to identify such > common practice settings and make them be more visible rather than being > relegated levels deep as now. > ??? It is a bit concerning to see the Apache web server identified as > basically unsupported, and its YaST section gone. There must be a good > reasons for this, yet it would be beneficial for us to have Apache > return as a first class item rather than a DIY item. > ??? I am pleased to see the system brought to the Openssl v1.1 level > across the board, and having the FIPS option. > ??? Lastly, I am impressed with how well SUSE is handling the current > CPU chip security issues. That measured approach is valued. > ??? Thanks, > ??? Joe D. > _______________________________________________ > sle-beta mailing list > sle-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sle-beta -- 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 jrd at netlab1.net Wed Jan 24 03:28:58 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Wed, 24 Jan 2018 10:28:58 +0000 Subject: [sle-beta] Beta 5, initial impressions In-Reply-To: <9bba24a5-584a-7891-5f6b-c14bab18e79a@suse.cz> References: <9bba24a5-584a-7891-5f6b-c14bab18e79a@suse.cz> Message-ID: <8b25093d-d58d-2931-bc39-5f98eba740bd@netlab1.net> ??? Comment placed in-line below. On 24/01/2018 10:10, Jiri Srain wrote: > Hello Joe, > > On 24.1.2018 10:22, Joe Doupnik wrote: >> ??? SLES 15 beta 5. My overall impression thus far is good, and the >> system works as an ESXi guest in my case. >> ??? A few comments about it. >> ??? A fresh installation of beta 5 would not boot: no O/S found. Some >> use of Recovery and Update menus to view and refresh disk partitioning >> and initrd brought this under control. I must have made a silly error >> somewhere in this familiar process. A guess is I defined a /boot >> partition, type EXT2 so there is no journal to be replayed, and not >> using the offered EFI choice. Root is XFS. Unless others encounter a >> similar problem this will remain as a local fluke. > Hard to guess from this information, anyway: As you mentioned EFI, you > need to have a /boot/efi partition formatted as MS-DOS, otherwise the > EFI firmware will not boot. > > Having (additional) /boot with ext2 should not hurt, although I don't > see a use for it. > > With Beta6, you should get a warning when you do a mistake in > partitioning that should prevent booting. > > Jiri --------- Jiri, ??? Thanks for that quick clarification. ??? I do not use, nor need, the EFI scheme. I use /boot (EXT2) to avoid historical problems merging everything into /. I do not use BTRFS, thanks. Historically that /boot partition was/is needed to accommodate updating the kernel, where the initrd would not be properly reconstructed (root set as XFS). It uses EXT2 to avoid possibly needing to update root from a journal during boot while root is still read-only (yes, I know about file systems). To avoid all that hassle I use an EXT2 /boot partition, which works. Just what went wrong in my initial installation process is uncertain, but a guess points to /boot and initrd composition during the initial installation process because a following review of that area resulted in a working version. Could be a bug, or just a human error on my part, but I thought the problem worth noting while matters are still fluid. Returning "/boot" to the partition choice menu would be a wise move. ??? That future "silly me" check about partitioning errors would be most welcomed. ??? Thanks, ??? Joe D. >> ??? Retention of various standard network utilities (say netstat, telnet >> etc) is much appreciated. Yet there remain problems such as xinetd not >> installing completely and thus not being usable. What would >> significantly help is a document describing the changes/shifts of >> direction/replacements so that sysadmins could smoothly cope with the >> changes. Presently we are left stranded.? Such a doc could extrapolate >> from say SLES11 level to that now in SLES15. >> ??? I appreciate the gradual reordering of material; that is good. >> However, in the process some common installation bits are becoming >> buried in the overall structure. Examples are setting the screen >> resolution and some menus now have their captions truncated and thus be >> nearly unusable, ntp being disabled after its usual initial setup, >> PackageKit refusing to get out of the way, nearly buried Cert Authority >> config in YaST, non-tracking of GUI keyboard language, and so forth. >> Thus, for the future I think a good idea would be to identify such >> common practice settings and make them be more visible rather than being >> relegated levels deep as now. >> ??? It is a bit concerning to see the Apache web server identified as >> basically unsupported, and its YaST section gone. There must be a good >> reasons for this, yet it would be beneficial for us to have Apache >> return as a first class item rather than a DIY item. >> ??? I am pleased to see the system brought to the Openssl v1.1 level >> across the board, and having the FIPS option. >> ??? Lastly, I am impressed with how well SUSE is handling the current >> CPU chip security issues. That measured approach is valued. >> ??? Thanks, >> ??? Joe D. >> _______________________________________________ >> sle-beta mailing list >> sle-beta at lists.suse.com >> http://lists.suse.com/mailman/listinfo/sle-beta From jsrain at suse.cz Wed Jan 24 05:21:40 2018 From: jsrain at suse.cz (Jiri Srain) Date: Wed, 24 Jan 2018 13:21:40 +0100 Subject: [sle-beta] Beta 5, initial impressions In-Reply-To: <8b25093d-d58d-2931-bc39-5f98eba740bd@netlab1.net> References: <9bba24a5-584a-7891-5f6b-c14bab18e79a@suse.cz> <8b25093d-d58d-2931-bc39-5f98eba740bd@netlab1.net> Message-ID: Hello Joe, On 24.1.2018 11:28, Joe Doupnik wrote: > ??? Comment placed in-line below. > > On 24/01/2018 10:10, Jiri Srain wrote: >> Hello Joe, >> >> On 24.1.2018 10:22, Joe Doupnik wrote: >>> ???? SLES 15 beta 5. My overall impression thus far is good, and the >>> system works as an ESXi guest in my case. >>> ???? A few comments about it. >>> ???? A fresh installation of beta 5 would not boot: no O/S found. Some >>> use of Recovery and Update menus to view and refresh disk partitioning >>> and initrd brought this under control. I must have made a silly error >>> somewhere in this familiar process. A guess is I defined a /boot >>> partition, type EXT2 so there is no journal to be replayed, and not >>> using the offered EFI choice. Root is XFS. Unless others encounter a >>> similar problem this will remain as a local fluke. >> Hard to guess from this information, anyway: As you mentioned EFI, you >> need to have a /boot/efi partition formatted as MS-DOS, otherwise the >> EFI firmware will not boot. >> >> Having (additional) /boot with ext2 should not hurt, although I don't >> see a use for it. >> >> With Beta6, you should get a warning when you do a mistake in >> partitioning that should prevent booting. >> >> Jiri > --------- > Jiri, > ??? Thanks for that quick clarification. > ??? I do not use, nor need, the EFI scheme. I use /boot (EXT2) to avoid > historical problems merging everything into /. I do not use BTRFS, > thanks. Historically that /boot partition was/is needed to accommodate > updating the kernel, where the initrd would not be properly > reconstructed (root set as XFS). It uses EXT2 to avoid possibly needing > to update root from a journal during boot while root is still read-only > (yes, I know about file systems). To avoid all that hassle I use an EXT2 > /boot partition, which works. Just what went wrong in my initial > installation process is uncertain, but a guess points to /boot and > initrd composition during the initial installation process because a > following review of that area resulted in a working version. Could be a > bug, or just a human error on my part, but I thought the problem worth > noting while matters are still fluid. Returning "/boot" to the partition > choice menu would be a wise move. If you could tar-up the /var/log/YaST2 directory of your system after installation and send it to me via email (perhaps exclude the mailing list), I could quickly check it and possibly find what went wrong. Separate /boot should not hurt; after your last description, it looks more like improper location of GRUB chosen. Anyway, the logs should say that. > ??? That future "silly me" check about partitioning errors would be most > welcomed. As I wrote above, expect it for next Beta, you should get warned if partitioning does not match the product's or bootloader's requirement. Jiri > ??? Thanks, > ??? Joe D. > >>> ???? Retention of various standard network utilities (say netstat, >>> telnet >>> etc) is much appreciated. Yet there remain problems such as xinetd not >>> installing completely and thus not being usable. What would >>> significantly help is a document describing the changes/shifts of >>> direction/replacements so that sysadmins could smoothly cope with the >>> changes. Presently we are left stranded.? Such a doc could extrapolate >>> from say SLES11 level to that now in SLES15. >>> ???? I appreciate the gradual reordering of material; that is good. >>> However, in the process some common installation bits are becoming >>> buried in the overall structure. Examples are setting the screen >>> resolution and some menus now have their captions truncated and thus be >>> nearly unusable, ntp being disabled after its usual initial setup, >>> PackageKit refusing to get out of the way, nearly buried Cert Authority >>> config in YaST, non-tracking of GUI keyboard language, and so forth. >>> Thus, for the future I think a good idea would be to identify such >>> common practice settings and make them be more visible rather than being >>> relegated levels deep as now. >>> ???? It is a bit concerning to see the Apache web server identified as >>> basically unsupported, and its YaST section gone. There must be a good >>> reasons for this, yet it would be beneficial for us to have Apache >>> return as a first class item rather than a DIY item. >>> ???? I am pleased to see the system brought to the Openssl v1.1 level >>> across the board, and having the FIPS option. >>> ???? Lastly, I am impressed with how well SUSE is handling the current >>> CPU chip security issues. That measured approach is valued. >>> ???? Thanks, >>> ???? Joe D. >>> _______________________________________________ >>> 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 -- 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 ecki at zusammenkunft.net Sat Jan 27 16:00:42 2018 From: ecki at zusammenkunft.net (Bernd) Date: Sun, 28 Jan 2018 00:00:42 +0100 Subject: [sle-beta] packages of minimal vs. base Message-ID: Hello, what would be a command to compare the packages installed with minimal (no package DVD) vs. base-module and text-mode pattern in SLES15? It looks to me like the minimal system would be enough to run applications, is that actually supported/intended or should the base module always be present (for SLES). BTW: in minimal I missed "sudo" and "less", both packages seem to be on the installer media and can manually be installed. Is there a policy on what will be on installer CD but not in minimal? Greetings Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sat Jan 27 16:23:11 2018 From: ecki at zusammenkunft.net (Bernd) Date: Sun, 28 Jan 2018 00:23:11 +0100 Subject: [sle-beta] Packages DVD is Add-On Message-ID: Hello, it is described in the manual, that you have to provide the packages DVD as a "add-on" product if you want to install SLES15 (beta5 in my case) without registration. However neither the "do not register" warning message nor the "add on product" screen mention this relationship. Maybe the screen should be titled "I would like to install an additional Add-On product or package media" to make this more clear? (or at least mention it in the warning message) ... A full system can be installed using the SLE-15-Packages media from.... Please provide the location of the media files in the following Add-On Product screen. Without these media only a minimum system is available in this installation. (or something). Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sat Jan 27 17:31:02 2018 From: ecki at zusammenkunft.net (Bernd) Date: Sun, 28 Jan 2018 01:31:02 +0100 Subject: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP was enabled in installer Message-ID: Hello, If I install beta5 with no registration/packages and select under settings to get the time from the NTP pool the screen with the timezone map shows me the right (updated) time. But if I proceed with the installation the "Performing Installation" screen (Step: "Save Installation Settings" -> "Writing NTP Configuration...") shows a popup "Cannot adjust 'NTP' service.". This popup does not happen when I do not enable NTP. When clicking OK the installation proceeds. Gruss Bernd PS: in the timezone selection the "hardware clock in UTC" does not adjust the currently displayed time. It is a bit frustrating when you select a timezone and the displayed current time is off by an hour. Because you have to switch on the UTC mode and then go to manual settings and correct the time (or turn on NTP as I did). I think former versions of SLES has that "feature" as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kukuk at suse.de Sat Jan 27 23:15:07 2018 From: kukuk at suse.de (Thorsten Kukuk) Date: Sun, 28 Jan 2018 07:15:07 +0100 Subject: [sle-beta] packages of minimal vs. base In-Reply-To: References: Message-ID: <20180128061507.GA11802@suse.de> On Sun, Jan 28, Bernd wrote: > Hello, > > what would be a command to compare the packages installed with minimal (no > package DVD) vs. base-module and text-mode pattern in SLES15? Install it, run rpm -qa|sort and compare the result. > It looks to me like the minimal system would be enough to run applications, is > that actually supported/intended or should the base module always be present > (for SLES). Depends on the requirements of the application. > BTW: in minimal I missed "sudo" and "less", both packages seem to be on the > installer media and can manually be installed. Is there a policy on what will > be on installer CD but not in minimal? You have 4 products on the installer DVD, not only one. So of course you have packages on the DVD which will not be installed with every product. 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 Sun Jan 28 04:16:51 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Sun, 28 Jan 2018 11:16:51 +0000 Subject: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP was enabled in installer In-Reply-To: References: Message-ID: ??? There is also the step of going into systemd services and enabling service NTP, at least in my experiments. ??? In the overall time keeping mix are two client-style competitors. It seems to me, as some say, the wise choice would be use regular NTP itself which can be both client and server, under our control. This also avoids the mistake of force jumping clocks which are out of synchronization, an act which can clobber cron jobs and other time sensitive things. The initial setting of the local machine's time is properly done by adding tag "iburst" to a server line within /etc/ntp.conf. such as? server uk.pool.ntp.org iburst.? That causes rapid slewing, rather than the normal more gradual one and has no jumps. ??? Nuances about choosing a time source amongst competitors is another soft spot best left to the seasoned solutions of NTP proper. That puzzle has been worked out over many years through much experience with the protocol. Another thing to do in most cases is turn off using the local clock as a time source competitor (meaning comment out the lines in /etc/ntp.conf saying ? server 127.127.1.0 ? and ? fudge 127.127.1.0 stratum 10). ??? Thanks, ??? Joe D. On 28/01/2018 00:31, Bernd wrote: > Hello, > > If I install beta5 with no registration/packages and select under > settings to get the time from the NTP pool the screen with the > timezone map shows me the right (updated) time. > > But if I proceed with the installation the "Performing Installation" > screen (Step: "Save Installation Settings" -> "Writing NTP > Configuration...") shows a popup "Cannot adjust 'NTP' service.". This > popup does not happen when I do not enable NTP. When clicking OK the > installation proceeds. > > Gruss > Bernd > > PS: in the timezone selection the "hardware clock in UTC" does not > adjust the currently displayed time. It is a bit frustrating when you > select a timezone and the displayed current time is off by an hour. > Because you have to switch on the UTC mode and then go to manual > settings and correct the time (or turn on NTP as I did). I think > former versions of SLES has that "feature" as well. > > > _______________________________________________ > 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 ecki at zusammenkunft.net Sun Jan 28 04:37:02 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 28 Jan 2018 12:37:02 +0100 Subject: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP was enabled in installer In-Reply-To: References: Message-ID: <5a6db5de.47a5500a.af295.64ac@mx.google.com> Hello, I think the Problem here is that chrony is not part of the minimal System, at least it is not installed after the Installation and I dont see the package on the Installer-DVD1. The NTP Option in the installer is not only a one shot Option (which seems to work) but it also offers a checkbox to start the daemon. I had selected that one. The chrony config file is written with the pool entry. (I pretty much prefer chrony over ntpd, it producs less Problems with time warping on customer systems, so it would be good to make it a essential package. Glad that SuSE catched up here) Gruss Bernd -- http://bernd.eckenfels.net Von: Joe Doupnik Gesendet: Sonntag, 28. Januar 2018 12:16 An: sle-beta at lists.suse.com Betreff: Re: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP wasenabled in installer ??? There is also the step of going into systemd services and enabling service NTP, at least in my experiments. ??? In the overall time keeping mix are two client-style competitors. It seems to me, as some say, the wise choice would be use regular NTP itself which can be both client and server, under our control. This also avoids the mistake of force jumping clocks which are out of synchronization, an act which can clobber cron jobs and other time sensitive things. The initial setting of the local machine's time is properly done by adding tag "iburst" to a server line within /etc/ntp.conf. such as? server uk.pool.ntp.org iburst.? That causes rapid slewing, rather than the normal more gradual one and has no jumps. ??? Nuances about choosing a time source amongst competitors is another soft spot best left to the seasoned solutions of NTP proper. That puzzle has been worked out over many years through much experience with the protocol. Another thing to do in most cases is turn off using the local clock as a time source competitor (meaning comment out the lines in /etc/ntp.conf saying ? server 127.127.1.0 ? and ? fudge 127.127.1.0 stratum 10). ??? Thanks, ??? Joe D. On 28/01/2018 00:31, Bernd wrote: Hello, If I install beta5 with no registration/packages and select under settings to get the time from the NTP pool the screen with the timezone map shows me the right (updated) time. But if I proceed with the installation the "Performing Installation" screen (Step: "Save Installation Settings" -> "Writing NTP Configuration...") shows a popup "Cannot adjust 'NTP' service.". This popup does not happen when I do not enable NTP. When clicking OK the installation proceeds. Gruss Bernd PS: in the timezone selection the "hardware clock in UTC" does not adjust the currently displayed time. It is a bit frustrating when you select a timezone and the displayed current time is off by an hour. Because you have to switch on the UTC mode and then go to manual settings and correct the time (or turn on NTP as I did). I think former versions of SLES has that "feature" as well. _______________________________________________ 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 Sun Jan 28 05:34:26 2018 From: jrd at netlab1.net (Joe Doupnik) Date: Sun, 28 Jan 2018 12:34:26 +0000 Subject: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP was enabled in installer In-Reply-To: <5a6db5de.47a5500a.af295.64ac@mx.google.com> References: <5a6db5de.47a5500a.af295.64ac@mx.google.com> Message-ID: <01f118cb-a797-bed1-68af-c55fb1210994@netlab1.net> ??? For general amusement and perhaps education, the NTP problem of choosing amongst competing time givers is known as the Byzantine Generals Problem. The situation is a group of Generals/time givers offer their views, but some may not be truthful (are traitors) and ought to be excluded from the group. The first step in a solution is to form a majority group (a quorum, a concensus), and for that there needs to be 2N+1 participants to caste out N possible non-truthful members. Then stratum number and optionally other measurements come into play. Thus for us we ought to have an odd number of time givers, a minimum of three and a few more than that can be better. ??? Including the PC local clock amongst them biases matters if the local clock is far off the mark. It's presence is in case there are no other time givers for this machine (network problems) and yet this machine may offer time to other machines. Oh dear, that's an awkward situation if the local clock may be well off, which in turn can upset a site. To minimize the problem of possibly insane local machine clock sources have each machine reference a set of likely external sources located both on-site and remotely (forms overlapping meshes). Friends helping friends based on widely spread expertise. ??? The Byzantine Generals problem arises in many kinds of fault-tolerant systems. ??? Thanks, ??? Joe D. On 28/01/2018 11:37, Bernd Eckenfels wrote: > > Hello, > > I think the Problem here is that chrony is not part of the minimal > System, at least it is not installed after the Installation and I dont > see the package on the Installer-DVD1. > > The NTP Option in the installer is not only a one shot Option (which > seems to work) but it also offers a checkbox to start the daemon. I > had selected that one. The chrony config file is written with the pool > entry. > > (I pretty much prefer chrony over ntpd, it producs less Problems with > time warping on customer systems, so it would be good to make it a > essential package. Glad that SuSE catched up here) > > Gruss > > Bernd > > -- > http://bernd.eckenfels.net > > *Von: *Joe Doupnik > *Gesendet: *Sonntag, 28. Januar 2018 12:16 > *An: *sle-beta at lists.suse.com > *Betreff: *Re: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP > wasenabled in installer > > ??? There is also the step of going into systemd services and enabling > service NTP, at least in my experiments. > ??? In the overall time keeping mix are two client-style competitors. > It seems to me, as some say, the wise choice would be use regular NTP > itself which can be both client and server, under our control. This > also avoids the mistake of force jumping clocks which are out of > synchronization, an act which can clobber cron jobs and other time > sensitive things. The initial setting of the local machine's time is > properly done by adding tag "iburst" to a server line within > /etc/ntp.conf. such as? server uk.pool.ntp.org iburst.? That causes > rapid slewing, rather than the normal more gradual one and has no jumps. > ??? Nuances about choosing a time source amongst competitors is > another soft spot best left to the seasoned solutions of NTP proper. > That puzzle has been worked out over many years through much > experience with the protocol. Another thing to do in most cases is > turn off using the local clock as a time source competitor (meaning > comment out the lines in /etc/ntp.conf saying ? server 127.127.1.0 ? > and ? fudge 127.127.1.0 stratum 10). > ??? Thanks, > ??? Joe D. > > On 28/01/2018 00:31, Bernd wrote: > > Hello, > > If I install beta5 with no registration/packages and select under > settings to get the time from the NTP pool the screen with the > timezone map shows me the right (updated) time. > > But if I proceed with the installation the "Performing > Installation" screen (Step: "Save Installation Settings" -> > "Writing NTP Configuration...") shows a popup "Cannot adjust 'NTP' > service.". This popup does not happen when I do not enable NTP. > When clicking OK the installation proceeds. > > Gruss > > Bernd > > PS: in the timezone selection the "hardware clock in UTC" does not > adjust the currently displayed time. It is a bit frustrating when > you select a timezone and the displayed current time is off by an > hour. Because you have to switch on the UTC mode and then go to > manual settings and correct the time (or turn on NTP as I did). I > think former versions of SLES has that "feature" as well. > > > > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From okurz at suse.de Sun Jan 28 09:12:28 2018 From: okurz at suse.de (Oliver Kurz) Date: Sun, 28 Jan 2018 17:12:28 +0100 Subject: [sle-beta] Packages DVD is Add-On In-Reply-To: References: Message-ID: <1665585.v5TZZrM4ht@linux-28d6.suse> Hello, On Sunday, 28 January 2018 00:23:11 CET Bernd wrote: > it is described in the manual, that you have to provide the packages DVD as > a "add-on" product if you want to install SLES15 (beta5 in my case) without > registration. However neither the "do not register" warning message nor the > "add on product" screen mention this relationship. > > Maybe the screen should be titled "I would like to install an additional > Add-On product or package media" to make this more clear? (or at least > mention it in the warning message) > > ... > A full system can be installed using the SLE-15-Packages media from.... > Please provide the location of the media files in the following Add-On > Product screen. Without these media only a minimum system is available in > this installation. > > (or something). Yes, I think extending the string in the warning message could be possible. From fcrozat at suse.com Mon Jan 29 04:40:40 2018 From: fcrozat at suse.com (Frederic Crozat) Date: Mon, 29 Jan 2018 12:40:40 +0100 Subject: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP was enabled in installer In-Reply-To: References: Message-ID: <1517226040.9477.0.camel@suse.com> Le dimanche 28 janvier 2018 ? 01:31 +0100, Bernd a ?crit?: > Hello, > > If I install beta5 with no registration/packages and select under > settings to get the time from the NTP pool the screen with the > timezone map shows me the right (updated) time. > > But if I proceed with the installation the "Performing Installation" > screen (Step: "Save Installation Settings" -> "Writing NTP > Configuration...") shows a popup "Cannot adjust 'NTP' service.". This > popup does not happen when I do not enable NTP. When clicking OK the > installation proceeds. This is a known issue, the installer is still not 100% migrated to chrony but it will be soon. > PS: in the timezone selection the "hardware clock in UTC" does not > adjust the currently displayed time. It is a bit frustrating when you > select a timezone and the displayed current time is off by an hour. > Because you have to switch on the UTC mode and then go to manual > settings and correct the time (or turn on NTP as I did). I think > former versions of SLES has that "feature" as well. Please open a bug report for this. -- Frederic Crozat Enterprise Desktop Release Manager SUSE From vmoutoussamy at suse.com Tue Jan 30 01:46:37 2018 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Tue, 30 Jan 2018 09:46:37 +0100 Subject: [sle-beta] packages of minimal vs. base In-Reply-To: References: Message-ID: <89F2188A-2AEC-4455-A099-D309E59307CC@suse.com> Hi, > On 28 Jan 2018, at 00:00, Bernd wrote: > > Hello, > > what would be a command to compare the packages installed with minimal (no package DVD) vs. base-module and text-mode pattern in SLES15? This is not exactly right, minimal here in your sentence mean the Installer. However "The scope of an installation, only containing the base system, is comparable to the installation pattern minimal system of previous SUSE Linux Enterprise Server versions.? (cf https://www.suse.com/betaprogram/wp-content/uploads/2017/12/sles_installquick_20171221.pdf). So Installer + Basesystem Module = minimal system. The installer alone for us is not intend to be used as a ?minimal system"! > > It looks to me like the minimal system would be enough to run applications, is that actually supported/intended or should the base module always be present (for SLES). Well for ?minimal system? we already provide and support JeOS. Did you take a look at it? > BTW: in minimal I missed "sudo" and "less", both packages seem to be on the installer media and can manually be installed. Is there a policy on what will be on installer CD but not in minimal? > Greetings > Bernd Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager -------------- 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 ecki at zusammenkunft.net Tue Jan 30 07:57:57 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 30 Jan 2018 15:57:57 +0100 Subject: [sle-beta] packages of minimal vs. base In-Reply-To: <89F2188A-2AEC-4455-A099-D309E59307CC@suse.com> References: <89F2188A-2AEC-4455-A099-D309E59307CC@suse.com> Message-ID: <5a7087f9.668c500a.11874.143c@mx.google.com> Yes you have different wordings in manual, meta data and installer gui. it woukd be good to unify minimal/base/text-only. However I was refering to the variant called ?minimal? by the installer when no package media is registered (and sles product is selected). I am.mostly researching to give a minimal package base for installation prerequisites Gruss Bernd Von: Vincent Moutoussamy Gesendet: Dienstag, 30. Januar 2018 09:47 An: Bernd Cc: sle-beta at lists.suse.com Betreff: Re: [sle-beta] packages of minimal vs. base Hi, > On 28 Jan 2018, at 00:00, Bernd wrote: > > Hello, > > what would be a command to compare the packages installed with minimal (no package DVD) vs. base-module and text-mode pattern in SLES15? This is not exactly right, minimal here in your sentence mean the Installer. However "The scope of an installation, only containing the base system, is comparable to the installation pattern minimal system of previous SUSE Linux Enterprise Server versions.? (cf https://www.suse.com/betaprogram/wp-content/uploads/2017/12/sles_installquick_20171221.pdf). So Installer + Basesystem Module = minimal system. The installer alone for us is not intend to be used as a ?minimal system"! > > It looks to me like the minimal system would be enough to run applications, is that actually supported/intended or should the base module always be present (for SLES). Well for ?minimal system? we already provide and support JeOS. Did you take a look at it? > BTW: in minimal I missed "sudo" and "less", both packages seem to be on the installer media and can manually be installed. Is there a policy on what will be on installer CD but not in minimal? > Greetings > Bernd Regards, -- Vincent Moutoussamy SUSE Beta Program and SDK Project Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronald.j.bynoe at intel.com Tue Jan 30 09:01:03 2018 From: ronald.j.bynoe at intel.com (Bynoe, Ronald J) Date: Tue, 30 Jan 2018 16:01:03 +0000 Subject: [sle-beta] targetcli Message-ID: <1517328059.2533.3.camel@intel.com> Looks like the beta5 ISO is missing the targetcli-fb package, but it was present in the previous betas. Was this an oversight or is it being removed? If targetcli is being removed, what iSCSI target software is replacing it? Pleasantly, Ronald Bynoe ND SW: IP Development QoS and Drivers Linux Validation Lead -------------- next part -------------- An HTML attachment was scrubbed... URL: From lduncan at suse.com Tue Jan 30 12:34:38 2018 From: lduncan at suse.com (Lee Duncan) Date: Tue, 30 Jan 2018 11:34:38 -0800 Subject: [sle-beta] targetcli In-Reply-To: <1517328059.2533.3.camel@intel.com> References: <1517328059.2533.3.camel@intel.com> Message-ID: On 01/30/2018 08:01 AM, Bynoe, Ronald J wrote: > Looks like the beta5 ISO is missing the targetcli-fb package, but it was > present in the previous betas. Was this an oversight or is it being > removed? If targetcli is being removed, what iSCSI target software is > replacing it? > > > Pleasantly, > Ronald Bynoe > ND SW: IP Development > QoS and Drivers Linux Validation Lead > Have you checked for python3-targetcli-fb? This is the new name of the package I believe, since python2 support is removed for SLE 15. I am downloading the ISOs now the test them. If it is indeed missing please file a bug, and please cc me? -- Lee Duncan SUSE Labs From scottx.register at intel.com Tue Jan 30 13:57:08 2018 From: scottx.register at intel.com (Register, ScottX) Date: Tue, 30 Jan 2018 20:57:08 +0000 Subject: [sle-beta] targetcli In-Reply-To: References: <1517328059.2533.3.camel@intel.com> Message-ID: <1DD97F252888F94BB0FC25E64E6807792EE871AF@ORSMSX112.amr.corp.intel.com> It does indeed look like it targetcli/python3-targetcli-fb is missing. lin-vm-6274e:~ # zypper refresh Repository 'SLES-15-Basesystem' is up to date. Repository 'SLES-15-Desktop-Applications' is up to date. Repository 'SLES-15-Desktop-Productivity' is up to date. Repository 'SLES-15-Development-Tools' is up to date. Repository 'SLES-15-HA' is up to date. Repository 'SLES-15-HPC' is up to date. Repository 'SLES-15-Legacy' is up to date. Repository 'SLES-15-Public-Cloud' is up to date. Repository 'SLES-15-SAP-Applications' is up to date. Repository 'SLES-15-Server-Applications' is up to date. Repository 'SLES-15-x86_64' is up to date. lin-vm-6274e:~ # zypper search targetcli Loading repository data... Reading installed packages... No matching items found. -----Original Message----- From: sle-beta-bounces at lists.suse.com [mailto:sle-beta-bounces at lists.suse.com] On Behalf Of Lee Duncan Sent: Tuesday, January 30, 2018 11:35 AM To: sle-beta at lists.suse.com Subject: Re: [sle-beta] targetcli On 01/30/2018 08:01 AM, Bynoe, Ronald J wrote: > Looks like the beta5 ISO is missing the targetcli-fb package, but it > was present in the previous betas. Was this an oversight or is it > being removed? If targetcli is being removed, what iSCSI target > software is replacing it? > > > Pleasantly, > Ronald Bynoe > ND SW: IP Development > QoS and Drivers Linux Validation Lead > Have you checked for python3-targetcli-fb? This is the new name of the package I believe, since python2 support is removed for SLE 15. I am downloading the ISOs now the test them. If it is indeed missing please file a bug, and please cc me? -- Lee Duncan SUSE Labs _______________________________________________ sle-beta mailing list sle-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sle-beta From fcrozat at suse.com Wed Jan 31 01:56:41 2018 From: fcrozat at suse.com (Frederic Crozat) Date: Wed, 31 Jan 2018 09:56:41 +0100 Subject: [sle-beta] targetcli In-Reply-To: <1DD97F252888F94BB0FC25E64E6807792EE871AF@ORSMSX112.amr.corp.intel.com> References: <1517328059.2533.3.camel@intel.com> <1DD97F252888F94BB0FC25E64E6807792EE871AF@ORSMSX112.amr.corp.intel.com> Message-ID: <1517389001.7503.5.camel@suse.com> Le mardi 30 janvier 2018 ? 20:57 +0000, Register, ScottX a ?crit?: > It does indeed look like it targetcli/python3-targetcli-fb is > missing. This will be fixed for upcoming Beta6. Thanks for your report. -- Frederic Crozat Enterprise Desktop Release Manager SUSE