From urs.frey at post.ch Mon Sep 8 02:37:35 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Mon, 8 Sep 2014 08:37:35 +0000 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <5409B3190200006D0016FBEB@prv-mh.provo.novell.com> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <20140826153700.506936f1@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> <20140826155728.76851414@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2DFB@HXMB12.pnet.ch> <5409B3190200006D0016FBEB@prv-mh.provo.novell.com> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D59F8@HXMB12.pnet.ch> Hello Mark >There is a class of service files that are called "static." They cannot be enabled or disabled, per se. It would be nice if systemctl disable would tell you that. :( Thank you very much for your answer, brining me a bit closer to systemD Question: Is there a way to list this system class of static services I googled a bit, but nil found. Manned also (man -k systemD | systemctl), but nil found Also in the sles_admin_book_en.pdf there is nothing to find I would like to learn more about those "static classes" in systemD Thank you very much Best regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Mark Post Gesendet: Friday, September 05, 2014 6:57 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing >>> On 8/27/2014 at 04:38 AM, wrote: > Aug 27 08:13:59 h05cnh systemd[1]: Started Login Service. > Aug 27 08:13:59 h05cnh systemd-logind[10059]: New seat seat0. > Aug 27 08:13:59 h05cnh systemd-logind[10059]: Watching system buttons on > /dev/input/event2 (Power Button) > + systemctl disable systemd-logind > + systemctl stop systemd-logind > +sleep 300 > + systemctl enable systemd-logind > The unit files have no [Install] section. They are not meant to be enabled > using systemctl. > Possible reasons for having this kind of units are: > 1) A unit may be statically enabled by being symlinked from another unit's > .wants/ or .requires/ directory. > 2) A unit's purpose may be to act as a helper for some other unit which has > a requirement dependency on it. > 3) A unit may be started when needed via activation (socket, path, timer, > D-Bus, udev, scripted systemctl call, ...). There is a class of service files that are called "static." They cannot be enabled or disabled, per se. It would be nice if systemctl disable would tell you that. :( You _can_ mask/unmask them, however. So, try this: systemctl mask systemd-logind.service systemctl stop systemd-logind.service systemctl unmask systemd-logind.service systemctl start systemd-logind.service Mark Post _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From gahorvath at npsh.hu Mon Sep 8 03:49:45 2014 From: gahorvath at npsh.hu (=?UTF-8?B?R8OhYm9yIEhvcnbDoXRo?=) Date: Mon, 08 Sep 2014 11:49:45 +0200 Subject: [sles-beta] YaST2 + Ldap + Mirrormode In-Reply-To: <5347779.7gbrKqiqjK@gjn.priv.at> References: <5347779.7gbrKqiqjK@gjn.priv.at> Message-ID: <540D97D9020000D70001BAB3@groupwise.npsh.hu> Hello Gunther, I do have a working setup on SLES12, although I have not used YaST2 to create it. And I am using MDB db format. So I really don't know how relevant this is to your plight :-| g. >>> "G?nther J.Niederwimmer" 09/06/14 5:59 PM >>> Hello, have any tested, set up a ldap MirrorMode server and have afterward a running system ? I gamble now three Days but I don't have a running system :-( I make the ground configuration with YaST2 and afterward with slapcat / slapadd the rest , ldapmodify is not working for the DB hdb Please test it ,and say afterward it is my mistake ;) Thanks for a answer. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: From urs.frey at post.ch Mon Sep 8 06:19:37 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Mon, 8 Sep 2014 12:19:37 +0000 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <5409B3190200006D0016FBEB@prv-mh.provo.novell.com> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <20140826153700.506936f1@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> <20140826155728.76851414@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2DFB@HXMB12.pnet.ch> <5409B3190200006D0016FBEB@prv-mh.provo.novell.com> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D5A7C@HXMB12.pnet.ch> Hello Mark Ok I had a closer look at # man systemctl When issuing # systemctl list-unit-files all system unit-files are listed with their capability v03er9:~ # systemctl list-unit-files | grep systemd systemd-ask-password-console.path static systemd-ask-password-plymouth.path static systemd-ask-password-wall.path static systemd-ask-password-console.service static systemd-ask-password-plymouth.service static systemd-ask-password-wall.service static systemd-backlight at .service static systemd-binfmt.service static systemd-fsck-root.service static systemd-fsck at .service static systemd-halt.service static systemd-hibernate.service static systemd-hostnamed.service static systemd-hybrid-sleep.service static systemd-initctl.service static systemd-journal-flush.service static systemd-journald.service static systemd-kexec.service static systemd-localed.service static systemd-logind.service static systemd-machined.service static systemd-modules-load.service static systemd-nspawn at .service disabled systemd-poweroff.service static systemd-quotacheck.service static systemd-random-seed.service static systemd-readahead-collect.service enabled systemd-readahead-done.service static systemd-readahead-drop.service enabled systemd-readahead-replay.service enabled systemd-reboot.service static systemd-remount-fs.service static systemd-rfkill at .service static systemd-shutdownd.service static systemd-suspend.service static systemd-sysctl.service static systemd-timedated.service static systemd-tmpfiles-clean.service static systemd-tmpfiles-setup-dev.service static systemd-tmpfiles-setup.service static systemd-udev-root-symlink.service static systemd-udev-settle.service static systemd-udev-trigger.service static systemd-udevd.service static systemd-update-utmp-runlevel.service static systemd-update-utmp.service static systemd-user-sessions.service static systemd-vconsole-setup.service static systemd-initctl.socket static systemd-journald.socket static systemd-shutdownd.socket static systemd-udevd-control.socket static systemd-udevd-kernel.socket static systemd-readahead-done.timer static systemd-tmpfiles-clean.timer static v03er9:~ # And from # man systemctl I found this is-enabled NAME... Checks whether any of the specified unit files are enabled (as with enable). Returns an exit code of 0 if at least one is enabled, non-zero otherwise. Prints the current enable status (see table). To suppress this output, use --quiet. Table 1. is-enabled output +------------------------------------------------------------------+ ?Printed string ? Meaning ? Return value ? +------------------------------------------------------------------+ ?"enabled" ? Enabled through a symlink in ? ? +------------------+ .wants directory (permanently ? 0 ? ?"enabled-runtime" ? or just in /run) ? ? +------------------------------------------------------------------+ ?"linked" ? Made available through a ? ? +------------------+ symlink to the unit file ? 1 ? ?"linked-runtime" ? (permanently or just in /run) ? ? +------------------------------------------------------------------+ ?"masked" ? Disabled entirely (permanently ? ? +------------------+ or just in /run) ? 1 ? ?"masked-runtime" ? ? ? +------------------------------------------------------------------+ ?"static" ? Unit is not enabled, but has ? 0 ? ? ? no provisions for enabling in ? ? ? ? [Install] section ? ? +------------------------------------------------------------------+ ?"disabled" ? Unit is not enabled ? 1 ? +------------------------------------------------------------------+ So your statement > There is a class of service files that are called "static." They cannot be enabled or disabled, per se. It would be nice if systemctl disable would tell you that. :( can be put into context when using ?# systemctl list-unit-files | grep static And all these ?static? service files belong to the very base of the systemD environment. This is the context I was looking for Thanks Best regards Urs Frey Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX : ++41 (0)58 667 30 07 E-Mail: urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Mark Post Gesendet: Friday, September 05, 2014 6:57 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing >>> On 8/27/2014 at 04:38 AM, > wrote: > Aug 27 08:13:59 h05cnh systemd[1]: Started Login Service. > Aug 27 08:13:59 h05cnh systemd-logind[10059]: New seat seat0. > Aug 27 08:13:59 h05cnh systemd-logind[10059]: Watching system buttons on > /dev/input/event2 (Power Button) > + systemctl disable systemd-logind > + systemctl stop systemd-logind > +sleep 300 > + systemctl enable systemd-logind > The unit files have no [Install] section. They are not meant to be enabled > using systemctl. > Possible reasons for having this kind of units are: > 1) A unit may be statically enabled by being symlinked from another unit's > .wants/ or .requires/ directory. > 2) A unit's purpose may be to act as a helper for some other unit which has > a requirement dependency on it. > 3) A unit may be started when needed via activation (socket, path, timer, > D-Bus, udev, scripted systemctl call, ...). There is a class of service files that are called "static." They cannot be enabled or disabled, per se. It would be nice if systemctl disable would tell you that. :( You _can_ mask/unmask them, however. So, try this: systemctl mask systemd-logind.service systemctl stop systemd-logind.service systemctl unmask systemd-logind.service systemctl start systemd-logind.service Mark Post _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbrown at suse.de Tue Sep 9 09:25:30 2014 From: rbrown at suse.de (Richard Brown) Date: Tue, 09 Sep 2014 17:25:30 +0200 Subject: [sles-beta] EXTERNAL: SLES12 RC2 x86_64 - iSCSI boot and UEFI together In-Reply-To: <540E3CB1.5050108@cbnco.com> References: <540E1802.4080903@cbnco.com> <540E3CB1.5050108@cbnco.com> Message-ID: <1410276330.6686.20.camel@ibrokeit.suse.de> I've tried iSCSI boot in the following scenarios with RC2 and earlier BIOS with an iBFT iSCSI HBA/Offload BIOS with /boot on removable/local media and /root on iSCSI UEFI with /boot on removable/local media and /root on iSCSI I don't have a UEFI machine that's compatible with my iSCSI HBA, but on the surface I cant see how they'd be different, assuming the HBA correctly identifies itself as boot device to UEFI, but to me that seems more the realm of hardware compatibility, and not something SLE 12 can do anything about in software Regards, Richard On Mon, 2014-09-08 at 19:33 -0400, Tom Parker wrote: > No. I don't have any machines with UEFI enabled. Sorry > > Tom > > > On 08/09/14 05:05 PM, Johnathan Wong (johnawon) wrote: > > > Hi Tom, > > > > > > > > Have you tried iSCSI boot with UEFI? Thanks! > > > > > > > > > > > > -john > > > > > > > > From: Tom Parker [mailto:tparker at cbnco.com] > > Sent: Monday, September 08, 2014 1:57 PM > > To: Rivera, Miguel E; Johnathan Wong (johnawon); > > sles-beta at lists.suse.com > > Subject: Re: [sles-beta] EXTERNAL: SLES12 RC2 x86_64 - iSCSI boot > > and UEFI together > > > > > > > > > > I have done successful iSCSI boots in two scenarios. > > > > 1. iSCSI Offload on an HP BL420c with HP VirtualConnect and an > > FLB554 flex lom (iSCSI HBA and Offload) > > > > and > > > > 2. Installing /boot to a USB key (or microSD card) with / on iSCSI > > and a software initiator running from the initrd. (This one only > > works as of RC2. There have been several bugs in dracut that needed > > to be fixed.) > > > > As of RC2 everything seems to work as expected. > > > > Tom > > > > > > > > On 08/09/14 02:21 PM, Rivera, Miguel E wrote: > > > > > > Has anyone been successful getting iscsi boot to work? > > > > > > > > Mike > > > > > > > > From: sles-beta-bounces at lists.suse.com > > [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of > > Johnathan Wong (johnawon) > > Sent: Monday, September 08, 2014 11:44 AM > > To: sles-beta at lists.suse.com > > Subject: EXTERNAL: [sles-beta] SLES12 RC2 x86_64 - iSCSI > > boot and UEFI together > > > > > > > > > > All, > > > > > > > > Has anyone tried iSCSI boot and UEFI together? > > > > > > > > -john > > > > > > > > > > _______________________________________________ > > sles-beta mailing list > > sles-beta at lists.suse.com > > http://lists.suse.com/mailman/listinfo/sles-beta > > > > > > > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta -- Richard Brown QA Engineer openSUSE Chairman Phone +4991174053-361 SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) From rbrown at suse.de Tue Sep 9 09:28:45 2014 From: rbrown at suse.de (Richard Brown) Date: Tue, 09 Sep 2014 17:28:45 +0200 Subject: [sles-beta] SLES12 RC2 No base product found error In-Reply-To: <93D02C4EC25DFA4880936D810521282440E7DBBD@AMEXMB01.ds.jdsu.net> References: <93D02C4EC25DFA4880936D810521282440E7DBBD@AMEXMB01.ds.jdsu.net> Message-ID: <1410276525.6686.22.camel@ibrokeit.suse.de> That certainly isn't happening on my test machines with RC2 As the error message states, can you provide the logs? they might provide some insight. Instead of the just the specific y2log, you can always run save_y2logs to generate a nice useful tarball full of all the logs YaST has generated upto that point in the installation Regards, Richard On Tue, 2014-09-09 at 15:22 +0000, Bob Schleiger wrote: > I am getting an error on install from PXE ? ?No base product found?. > If I retry, the install seems to work fine from that point on. > Attached screen shots. Wondering if this is a mount error on the > repo. > > > > Just wondering if this has already been discussed or resolved. I > could find nothing about this except a bug filed against opensuse > which seems to be in the resolved state. > > > > My PXE entry and directory 12RC2_64 is a copy of the RC2 downloaded > ISO for SLES12. > > > > label SLES12 S12RC2 OS > > kernel sles12RC2_64.krnl > > append initrd=sles12RC2_64.ird > install=ftp://10.1.1.25/pub/linux/SLES/repo/12RC2_64 > autoyast=ftp://10.1.1.25/pub/linux/SLES/S12RC2/profiles/ insecure=1 > splash=silent showopts biosdevname=0 > > > > > > Bob Schleiger > > CommTest Solutions Division/Development Support Group > > JDSU > > 9950 Federal Drive, Suite 150 > > Colorado Springs, CO 80921 > > > > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta -- Richard Brown QA Engineer openSUSE Chairman Phone +4991174053-361 SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) From schubi at suse.de Tue Sep 9 09:31:59 2014 From: schubi at suse.de (Stefan Schubert) Date: Tue, 09 Sep 2014 17:31:59 +0200 Subject: [sles-beta] SLES12 RC2 No base product found error In-Reply-To: <93D02C4EC25DFA4880936D810521282440E7DBBD@AMEXMB01.ds.jdsu.net> References: <93D02C4EC25DFA4880936D810521282440E7DBBD@AMEXMB01.ds.jdsu.net> Message-ID: <540F1D6F.80302@suse.de> Sounds like https://bugzilla.novell.com/show_bug.cgi?id=895418 which has been fixed today :-) Greetings Stefan Schubert Am 09.09.2014 17:22, schrieb Bob Schleiger: > > I am getting an error on install from PXE ? ?No base product found?. > If I retry, the install seems to work fine from that point on. > Attached screen shots. Wondering if this is a mount error on the repo. > > Just wondering if this has already been discussed or resolved. I could > find nothing about this except a bug filed against opensuse which > seems to be in the resolved state. > > My PXE entry and directory 12RC2_64 is a copy of the RC2 downloaded > ISO for SLES12. > > label SLES12 S12RC2 OS > > kernel sles12RC2_64.krnl > > append initrd=sles12RC2_64.ird > install=ftp://10.1.1.25/pub/linux/SLES/repo/12RC2_64 > autoyast=ftp://10.1.1.25/pub/linux/SLES/S12RC2/profiles/ insecure=1 > splash=silent showopts biosdevname=0 > > *Bob Schleiger * > > CommTest Solutions Division/Development Support Group > > JDSU > > 9950 Federal Drive, Suite 150 > > Colorado Springs, CO 80921 > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta -- ******************************************************************************* Stefan Schubert e-mail: schubi at suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) Maxfeldstra?e 5 90409 N?rnberg Germany From rbrown at suse.de Tue Sep 9 09:37:28 2014 From: rbrown at suse.de (Richard Brown) Date: Tue, 09 Sep 2014 17:37:28 +0200 Subject: [sles-beta] SLES12 Rc2 x86_64 root disk lvm2 setup btrfs In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D6002@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D6002@HXMB12.pnet.ch> Message-ID: <1410277048.6686.28.camel@ibrokeit.suse.de> On Tue, 2014-09-09 at 15:09 +0000, urs.frey at post.ch wrote: > > Btrfs on LVM2 would be a good solution for me, because of the > resizing/extending feature possible. > Installation worked well and GRUB2 found my Btrfs including /boot on > LVM2. > I'm going to allow wiser minds to comment on the supportability of your propose configuration, but I had to comment on the above extract from your email BTRFS includes its own resize/extending features https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-device btrfs device add to add devices to the filesystem btrfs device delete to remove them btrfs replace start to replace a device with another and move all its blocks to the target device and btrfs filesystem has the 'resize' subcommand to grow, or shrink the size of a filesystem https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-filesystem There's certainly one use case I can think of where using LVM and btrfs has benefits (full / root and /boot filesystem encryption), but resizing/extending isn't one of them :) Hope this helps Richard -- Richard Brown QA Engineer openSUSE Chairman Phone +4991174053-361 SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) From urs.frey at post.ch Tue Sep 9 10:27:40 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Tue, 9 Sep 2014 16:27:40 +0000 Subject: [sles-beta] SLES12 Rc2 x86_64 root disk lvm2 setup btrfs In-Reply-To: <1410277048.6686.28.camel@ibrokeit.suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9D6002@HXMB12.pnet.ch> <1410277048.6686.28.camel@ibrokeit.suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D6053@HXMB12.pnet.ch> Hi Richard Thank you very much! I got the error message below, when trying to extend my root fs. v03er9:~ # btrfs filesystem resize +1.5G /dev/mapper/vg_sys-lv_root ERROR: can't access '/dev/mapper/vg_sys-lv_root' v03er9:~ # > root resizing/extending isn't one of them :) Your reconfirmation of what I found is very welcome. In fact resizing the filesystem under a running Linux system would be somewhat acrobatic in terms of keeping consistency of the installed system, configured kernel and bootloader etc. Thanks a lot Best regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Richard Brown Gesendet: Tuesday, September 09, 2014 5:37 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 Rc2 x86_64 root disk lvm2 setup btrfs On Tue, 2014-09-09 at 15:09 +0000, urs.frey at post.ch wrote: > > Btrfs on LVM2 would be a good solution for me, because of the > resizing/extending feature possible. > Installation worked well and GRUB2 found my Btrfs including /boot on > LVM2. > I'm going to allow wiser minds to comment on the supportability of your propose configuration, but I had to comment on the above extract from your email BTRFS includes its own resize/extending features https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-device btrfs device add to add devices to the filesystem btrfs device delete to remove them btrfs replace start to replace a device with another and move all its blocks to the target device and btrfs filesystem has the 'resize' subcommand to grow, or shrink the size of a filesystem https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-filesystem There's certainly one use case I can think of where using LVM and btrfs has benefits (full / root and /boot filesystem encryption), but resizing/extending isn't one of them :) Hope this helps Richard -- Richard Brown QA Engineer openSUSE Chairman Phone +4991174053-361 SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From Bob.Schleiger at jdsu.com Tue Sep 9 14:13:32 2014 From: Bob.Schleiger at jdsu.com (Bob Schleiger) Date: Tue, 9 Sep 2014 20:13:32 +0000 Subject: [sles-beta] SLES12 RC2 No base product found error In-Reply-To: <1410276525.6686.22.camel@ibrokeit.suse.de> References: <93D02C4EC25DFA4880936D810521282440E7DBBD@AMEXMB01.ds.jdsu.net> <1410276525.6686.22.camel@ibrokeit.suse.de> Message-ID: <93D02C4EC25DFA4880936D810521282440E7DD38@AMEXMB01.ds.jdsu.net> Richard, Sent you the log file you mentioned. Just another bit of info. We have 2 xml files. One is the general stuff and one is the site specific info like networking, dns, ntp setup, etc. These 2 files are merged with rules.xml under the profiles directory. We have done this for years with SLES10/11. I have found that if I merge our 2 xml files together and point to it instead of the profiles directory, all works fine. No error. The rules.xml file that merges is the same one used for SLES11 SP3. So looks like it might be related to this but not sure why. Y2log shows a yast/wfm.rb internal error. Bob -----Original Message----- From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of Richard Brown Sent: Tuesday, September 09, 2014 9:29 AM To: sles-beta at lists.suse.com Subject: Re: [sles-beta] SLES12 RC2 No base product found error That certainly isn't happening on my test machines with RC2 As the error message states, can you provide the logs? they might provide some insight. Instead of the just the specific y2log, you can always run save_y2logs to generate a nice useful tarball full of all the logs YaST has generated upto that point in the installation Regards, Richard On Tue, 2014-09-09 at 15:22 +0000, Bob Schleiger wrote: > I am getting an error on install from PXE ? ?No base product found?. > If I retry, the install seems to work fine from that point on. > Attached screen shots. Wondering if this is a mount error on the > repo. > > > > Just wondering if this has already been discussed or resolved. I > could find nothing about this except a bug filed against opensuse > which seems to be in the resolved state. > > > > My PXE entry and directory 12RC2_64 is a copy of the RC2 downloaded > ISO for SLES12. > > > > label SLES12 S12RC2 OS > > kernel sles12RC2_64.krnl > > append initrd=sles12RC2_64.ird > install=ftp://10.1.1.25/pub/linux/SLES/repo/12RC2_64 > autoyast=ftp://10.1.1.25/pub/linux/SLES/S12RC2/profiles/ insecure=1 > splash=silent showopts biosdevname=0 > > > > > > Bob Schleiger > > CommTest Solutions Division/Development Support Group > > JDSU > > 9950 Federal Drive, Suite 150 > > Colorado Springs, CO 80921 > > > > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta -- Richard Brown QA Engineer openSUSE Chairman Phone +4991174053-361 SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From darrent at akurit.com.au Tue Sep 9 15:19:47 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Wed, 10 Sep 2014 07:19:47 +1000 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D5A7C@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <20140826153700.506936f1@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> <20140826155728.76851414@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2DFB@HXMB12.pnet.ch> <5409B3190200006D0016FBEB@prv-mh.provo.novell.com> <40637DBB36AF3941B243A286A432CA0B0F9D5A7C@HXMB12.pnet.ch> Message-ID: systemctl list-unit-files | grep static ??? Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au On 8 September 2014 22:19, wrote: > Hello Mark > > > > Ok I had a closer look at # man systemctl > > > > When issuing # systemctl list-unit-files all system unit-files are listed > with their capability > > v03er9:~ # systemctl list-unit-files | grep systemd > > systemd-ask-password-console.path static > > systemd-ask-password-plymouth.path static > > systemd-ask-password-wall.path static > > systemd-ask-password-console.service static > > systemd-ask-password-plymouth.service static > > systemd-ask-password-wall.service static > > systemd-backlight at .service static > > systemd-binfmt.service static > > systemd-fsck-root.service static > > systemd-fsck at .service static > > systemd-halt.service static > > systemd-hibernate.service static > > systemd-hostnamed.service static > > systemd-hybrid-sleep.service static > > systemd-initctl.service static > > systemd-journal-flush.service static > > systemd-journald.service static > > systemd-kexec.service static > > systemd-localed.service static > > systemd-logind.service static > > systemd-machined.service static > > systemd-modules-load.service static > > systemd-nspawn at .service disabled > > systemd-poweroff.service static > > systemd-quotacheck.service static > > systemd-random-seed.service static > > systemd-readahead-collect.service enabled > > systemd-readahead-done.service static > > systemd-readahead-drop.service enabled > > systemd-readahead-replay.service enabled > > systemd-reboot.service static > > systemd-remount-fs.service static > > systemd-rfkill at .service static > > systemd-shutdownd.service static > > systemd-suspend.service static > > systemd-sysctl.service static > > systemd-timedated.service static > > systemd-tmpfiles-clean.service static > > systemd-tmpfiles-setup-dev.service static > > systemd-tmpfiles-setup.service static > > systemd-udev-root-symlink.service static > > systemd-udev-settle.service static > > systemd-udev-trigger.service static > > systemd-udevd.service static > > systemd-update-utmp-runlevel.service static > > systemd-update-utmp.service static > > systemd-user-sessions.service static > > systemd-vconsole-setup.service static > > systemd-initctl.socket static > > systemd-journald.socket static > > systemd-shutdownd.socket static > > systemd-udevd-control.socket static > > systemd-udevd-kernel.socket static > > systemd-readahead-done.timer static > > systemd-tmpfiles-clean.timer static > > v03er9:~ # > > > > And from # man systemctl I found this > > is-enabled NAME... > > Checks whether any of the specified unit files are enabled (as > with enable). Returns an exit code of 0 if at > > least one is enabled, non-zero otherwise. Prints the current > enable status (see table). To suppress this > > output, use --quiet. > > > > Table 1. is-enabled output > > > +------------------------------------------------------------------+ > > ?Printed string ? Meaning ? Return > value ? > > > +------------------------------------------------------------------+ > > ?"enabled" ? Enabled through a symlink in > ? ? > > +------------------+ .wants directory (permanently ? > 0 ? > > ?"enabled-runtime" ? or just in /run) > ? ? > > > +------------------------------------------------------------------+ > > ?"linked" ? Made available through a > ? ? > > +------------------+ symlink to the unit file ? > 1 ? > > ?"linked-runtime" ? (permanently or just in /run) > ? ? > > > +------------------------------------------------------------------+ > > ?"masked" ? Disabled entirely (permanently > ? ? > > +------------------+ or just in /run) ? > 1 ? > > ?"masked-runtime" ? > ? ? > > > +------------------------------------------------------------------+ > > ?"static" ? Unit is not enabled, but has ? > 0 ? > > ? ? no provisions for enabling in > ? ? > > ? ? [Install] section > ? ? > > > +------------------------------------------------------------------+ > > ?"disabled" ? Unit is not enabled ? > 1 ? > > > +------------------------------------------------------------------+ > > > > So your statement > > > There is a class of service files that are called "static." They cannot > be enabled or disabled, per se. It would be nice if systemctl disable would > tell you that. :( > > can be put into context when using ?# systemctl list-unit-files | grep > static > > > > And all these ?static? service files belong to the very base of the > systemD environment. > > > > This is the context I was looking for > > > > Thanks > > > > Best regards > > > > Urs Frey > > Post CH AG > > Informationstechnologie > > IT Betrieb > > Webergutstrasse 12 > > 3030 Bern (Zollikofen) > > Telefon : ++41 (0)58 338 58 70 > > FAX : ++41 (0)58 667 30 07 > > E-Mail: urs.frey at post.ch > > > > > > -----Urspr?ngliche Nachricht----- > Von: sles-beta-bounces at lists.suse.com [mailto: > sles-beta-bounces at lists.suse.com] Im Auftrag von Mark Post > Gesendet: Friday, September 05, 2014 6:57 PM > An: sles-beta at lists.suse.com > Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though > autoyast init-script is still runing > > > > >>> On 8/27/2014 at 04:38 AM, wrote: > > > Aug 27 08:13:59 h05cnh systemd[1]: Started Login Service. > > > Aug 27 08:13:59 h05cnh systemd-logind[10059]: New seat seat0. > > > Aug 27 08:13:59 h05cnh systemd-logind[10059]: Watching system buttons on > > > /dev/input/event2 (Power Button) > > > + systemctl disable systemd-logind > > > + systemctl stop systemd-logind > > > +sleep 300 > > > + systemctl enable systemd-logind > > > The unit files have no [Install] section. They are not meant to be > enabled > > > using systemctl. > > > Possible reasons for having this kind of units are: > > > 1) A unit may be statically enabled by being symlinked from another > unit's > > > .wants/ or .requires/ directory. > > > 2) A unit's purpose may be to act as a helper for some other unit which > has > > > a requirement dependency on it. > > > 3) A unit may be started when needed via activation (socket, path, timer, > > > D-Bus, udev, scripted systemctl call, ...). > > > > There is a class of service files that are called "static." They cannot > be enabled or disabled, per se. It would be nice if systemctl disable would > tell you that. :( > > > > You _can_ mask/unmask them, however. So, try this: > > systemctl mask systemd-logind.service > > systemctl stop systemd-logind.service > > systemctl unmask systemd-logind.service > > systemctl start systemd-logind.service > > > > > > Mark Post > > > > _______________________________________________ > > sles-beta mailing list > > sles-beta at lists.suse.com > > http://lists.suse.com/mailman/listinfo/sles-beta > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From urs.frey at post.ch Wed Sep 10 01:28:10 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Wed, 10 Sep 2014 07:28:10 +0000 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <20140826153700.506936f1@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> <20140826155728.76851414@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2DFB@HXMB12.pnet.ch> <5409B3190200006D0016FBEB@prv-mh.provo.novell.com> <40637DBB36AF3941B243A286A432CA0B0F9D5A7C@HXMB12.pnet.ch> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D624C@HXMB12.pnet.ch> Hi Darren YES But sometimes one needs to know a little bit of ?background? information. Why ?static?, what does this mean? => man sysemctl => is-enabled Best regards Urs Frey Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX : ++41 (0)58 667 30 07 E-Mail: urs.frey at post.ch Von: Darren Thompson [mailto:darrent at akurit.com.au] Gesendet: Tuesday, September 09, 2014 11:20 PM An: Frey Urs, IT222 Cc: Mark Post; sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing systemctl list-unit-files | grep static ??? Darren Thompson Professional Services Engineer / Consultant [cid:image001.jpg at 01CB7C0C.6C6A2AE0] Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au On 8 September 2014 22:19, > wrote: Hello Mark Ok I had a closer look at # man systemctl When issuing # systemctl list-unit-files all system unit-files are listed with their capability v03er9:~ # systemctl list-unit-files | grep systemd systemd-ask-password-console.path static systemd-ask-password-plymouth.path static systemd-ask-password-wall.path static systemd-ask-password-console.service static systemd-ask-password-plymouth.service static systemd-ask-password-wall.service static systemd-backlight at .service static systemd-binfmt.service static systemd-fsck-root.service static systemd-fsck at .service static systemd-halt.service static systemd-hibernate.service static systemd-hostnamed.service static systemd-hybrid-sleep.service static systemd-initctl.service static systemd-journal-flush.service static systemd-journald.service static systemd-kexec.service static systemd-localed.service static systemd-logind.service static systemd-machined.service static systemd-modules-load.service static systemd-nspawn at .service disabled systemd-poweroff.service static systemd-quotacheck.service static systemd-random-seed.service static systemd-readahead-collect.service enabled systemd-readahead-done.service static systemd-readahead-drop.service enabled systemd-readahead-replay.service enabled systemd-reboot.service static systemd-remount-fs.service static systemd-rfkill at .service static systemd-shutdownd.service static systemd-suspend.service static systemd-sysctl.service static systemd-timedated.service static systemd-tmpfiles-clean.service static systemd-tmpfiles-setup-dev.service static systemd-tmpfiles-setup.service static systemd-udev-root-symlink.service static systemd-udev-settle.service static systemd-udev-trigger.service static systemd-udevd.service static systemd-update-utmp-runlevel.service static systemd-update-utmp.service static systemd-user-sessions.service static systemd-vconsole-setup.service static systemd-initctl.socket static systemd-journald.socket static systemd-shutdownd.socket static systemd-udevd-control.socket static systemd-udevd-kernel.socket static systemd-readahead-done.timer static systemd-tmpfiles-clean.timer static v03er9:~ # And from # man systemctl I found this is-enabled NAME... Checks whether any of the specified unit files are enabled (as with enable). Returns an exit code of 0 if at least one is enabled, non-zero otherwise. Prints the current enable status (see table). To suppress this output, use --quiet. Table 1. is-enabled output +------------------------------------------------------------------+ ?Printed string ? Meaning ? Return value ? +------------------------------------------------------------------+ ?"enabled" ? Enabled through a symlink in ? ? +------------------+ .wants directory (permanently ? 0 ? ?"enabled-runtime" ? or just in /run) ? ? +------------------------------------------------------------------+ ?"linked" ? Made available through a ? ? +------------------+ symlink to the unit file ? 1 ? ?"linked-runtime" ? (permanently or just in /run) ? ? +------------------------------------------------------------------+ ?"masked" ? Disabled entirely (permanently ? ? +------------------+ or just in /run) ? 1 ? ?"masked-runtime" ? ? ? +------------------------------------------------------------------+ ?"static" ? Unit is not enabled, but has ? 0 ? ? ? no provisions for enabling in ? ? ? ? [Install] section ? ? +------------------------------------------------------------------+ ?"disabled" ? Unit is not enabled ? 1 ? +------------------------------------------------------------------+ So your statement > There is a class of service files that are called "static." They cannot be enabled or disabled, per se. It would be nice if systemctl disable would tell you that. :( can be put into context when using ?# systemctl list-unit-files | grep static And all these ?static? service files belong to the very base of the systemD environment. This is the context I was looking for Thanks Best regards Urs Frey Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX : ++41 (0)58 667 30 07 E-Mail: urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Mark Post Gesendet: Friday, September 05, 2014 6:57 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing >>> On 8/27/2014 at 04:38 AM, > wrote: > Aug 27 08:13:59 h05cnh systemd[1]: Started Login Service. > Aug 27 08:13:59 h05cnh systemd-logind[10059]: New seat seat0. > Aug 27 08:13:59 h05cnh systemd-logind[10059]: Watching system buttons on > /dev/input/event2 (Power Button) > + systemctl disable systemd-logind > + systemctl stop systemd-logind > +sleep 300 > + systemctl enable systemd-logind > The unit files have no [Install] section. They are not meant to be enabled > using systemctl. > Possible reasons for having this kind of units are: > 1) A unit may be statically enabled by being symlinked from another unit's > .wants/ or .requires/ directory. > 2) A unit's purpose may be to act as a helper for some other unit which has > a requirement dependency on it. > 3) A unit may be started when needed via activation (socket, path, timer, > D-Bus, udev, scripted systemctl call, ...). There is a class of service files that are called "static." They cannot be enabled or disabled, per se. It would be nice if systemctl disable would tell you that. :( You _can_ mask/unmask them, however. So, try this: systemctl mask systemd-logind.service systemctl stop systemd-logind.service systemctl unmask systemd-logind.service systemctl start systemd-logind.service Mark Post _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3692 bytes Desc: image001.jpg URL: From snwint at suse.de Wed Sep 10 02:59:17 2014 From: snwint at suse.de (Steffen Winterfeldt) Date: Wed, 10 Sep 2014 10:59:17 +0200 (CEST) Subject: [sles-beta] custom ISO with autoinst.xml In-Reply-To: References: Message-ID: On Tue, 9 Sep 2014, Harold Longley wrote: > Opened SR#10909527911 > > Does anyone else put their own autoinst.xml file inside the SLES12 ISO as /autoinst.xml to boot > from an ISO in a virtual machine or DVD for a real machine? You can place a file /autoyast.xml inside the ISO and create the ISO with volume label 'OEMDRV' (mkisofs -V). Then it will be used. Steffen From uwedr at suse.com Wed Sep 10 03:32:47 2014 From: uwedr at suse.com (Uwe Drechsel) Date: Wed, 10 Sep 2014 11:32:47 +0200 Subject: [sles-beta] Customer quotes on SLE? Message-ID: <20140910093247.GD5019@suse.com> Dear testers, our marketing team asked me for quotes they could use to advertize the SLE products once they are shipped. If you would like to help us making SLE more interesting to many more people out there, e.g. for the upcoming SUSECon in Orlando, please drop me a private mail and I get you in touch with the team. Thanks!! Uwe -- Uwe Drechsel Project Manager SUSE Linux Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From snwint at suse.de Wed Sep 10 07:48:04 2014 From: snwint at suse.de (Steffen Winterfeldt) Date: Wed, 10 Sep 2014 15:48:04 +0200 (CEST) Subject: [sles-beta] custom ISO with autoinst.xml In-Reply-To: References: Message-ID: On Wed, 10 Sep 2014, Steffen Winterfeldt wrote: > On Tue, 9 Sep 2014, Harold Longley wrote: > >> Opened SR#10909527911 >> >> Does anyone else put their own autoinst.xml file inside the SLES12 ISO as >> /autoinst.xml to boot >> from an ISO in a virtual machine or DVD for a real machine? > > You can place a file /autoyast.xml inside the ISO and create the ISO with > volume label 'OEMDRV' (mkisofs -V). Then it will be used. /autoinst.xml after rc3. Steffen From mpost at suse.com Thu Sep 11 01:00:14 2014 From: mpost at suse.com (Mark Post) Date: Thu, 11 Sep 2014 01:00:14 -0600 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D624C@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <20140826153700.506936f1@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> <20140826155728.76851414@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2DFB@HXMB12.pnet.ch> <5409B3190200006D0016FBEB@prv-mh.provo.novell.com> <40637DBB36AF3941B243A286A432CA0B0F9D5A7C@HXMB12.pnet.ch> <40637DBB36AF3941B243A286A432CA0B0F9D624C@HXMB12.pnet.ch> Message-ID: <5411103E0200006D00170775@prv-mh.provo.novell.com> >>> On 9/10/2014 at 03:28 AM, wrote: > Why *static*, what does this mean? "Static" means that the unit file does not have an [Install] section, so it won't be activated automatically. Another unit file depends on the static service, so it is listed as enabled, but "static." If all the services that depend on it are disabled, the static service will no longer show up as enabled. At least, that's my understanding of how it works. Mark Post From snwint at suse.de Thu Sep 11 03:21:20 2014 From: snwint at suse.de (Steffen Winterfeldt) Date: Thu, 11 Sep 2014 11:21:20 +0200 (CEST) Subject: [sles-beta] custom ISO with autoinst.xml In-Reply-To: References: Message-ID: On Wed, 10 Sep 2014, Steffen Winterfeldt wrote: > On Wed, 10 Sep 2014, Steffen Winterfeldt wrote: > >> On Tue, 9 Sep 2014, Harold Longley wrote: >> >>> Opened SR#10909527911 >>> >>> Does anyone else put their own autoinst.xml file inside the SLES12 ISO as >>> /autoinst.xml to boot >>> from an ISO in a virtual machine or DVD for a real machine? >> >> You can place a file /autoyast.xml inside the ISO and create the ISO with >> volume label 'OEMDRV' (mkisofs -V). Then it will be used. > > /autoinst.xml after rc3. After some discussion, we've settled for this: http://en.opensuse.org/SDB:Linuxrc#AutoYaST_Profile_Handling Basically, autoinst.xml will be automatically used when it's on the DVD. Is that ok? Objections? Steffen From kukuk at suse.de Thu Sep 11 03:22:33 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Thu, 11 Sep 2014 11:22:33 +0200 Subject: [sles-beta] SLES12 x86_64 RC2 mkfs.btrfs: WARNING! - Btrfs v3.14.2+20140704 IS EXPERIMENTAL In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D699F@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D699F@HXMB12.pnet.ch> Message-ID: <20140911092233.GA3775@suse.de> Hi, On Thu, Sep 11, urs.frey at post.ch wrote: > Hi SUSE Team > > Something not really correct at this stage of SLES 12 RC2 x86_64 > When invoking mkfs.btrfs I get a warning: Correct, you shouldn't use mkfs.btrfs yourself directly but do this via YaST2 storage module. The reason is, that YaST2 enables/disables the features in a way that a by us supported btrfs filesystem will be created. This is not always given if you call mkfs.btrfs directly. In this regard nothing has changed compared to SLES11 SP3. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From urs.frey at post.ch Thu Sep 11 03:40:22 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Thu, 11 Sep 2014 09:40:22 +0000 Subject: [sles-beta] SLES12 x86_64 RC2 mkfs.btrfs: WARNING! - Btrfs v3.14.2+20140704 IS EXPERIMENTAL In-Reply-To: <20140911092233.GA3775@suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9D699F@HXMB12.pnet.ch> <20140911092233.GA3775@suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D69BE@HXMB12.pnet.ch> Hi >Correct, you shouldn't use mkfs.btrfs yourself directly but >do this via YaST2 storage module. The reason is, that YaST2 >enables/disables the features in a way that a by us supported >btrfs filesystem will be created. This is not always given if >you call mkfs.btrfs directly. Working with yast? Sound weird, when I just want to create a FS on some SAN LUNs for specific use. So in this case BtrFS with all its features seems is not to be yet mature enough, sorry Background: I would like to compare the use of BtrFS and XFS on LVM2 logical volumes in context resizing, defrag, balance. So using yast for BtrFS just because of some for me not transparent automatisms this is not really user friendly. But good to know Thanks a lot Best regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Thorsten Kukuk Gesendet: Thursday, September 11, 2014 11:23 AM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 RC2 mkfs.btrfs: WARNING! - Btrfs v3.14.2+20140704 IS EXPERIMENTAL Hi, On Thu, Sep 11, urs.frey at post.ch wrote: > Hi SUSE Team > > Something not really correct at this stage of SLES 12 RC2 x86_64 > When invoking mkfs.btrfs I get a warning: Correct, you shouldn't use mkfs.btrfs yourself directly but do this via YaST2 storage module. The reason is, that YaST2 enables/disables the features in a way that a by us supported btrfs filesystem will be created. This is not always given if you call mkfs.btrfs directly. In this regard nothing has changed compared to SLES11 SP3. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From mge at suse.com Thu Sep 11 05:09:26 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Thu, 11 Sep 2014 13:09:26 +0200 Subject: [sles-beta] SLES12 x86_64 RC2 mkfs.btrfs: WARNING! - Btrfs v3.14.2+20140704 IS EXPERIMENTAL In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D69BE@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D699F@HXMB12.pnet.ch> <20140911092233.GA3775@suse.de> <40637DBB36AF3941B243A286A432CA0B0F9D69BE@HXMB12.pnet.ch> Message-ID: <20140911110926.GA21455@suse.com> Hello Urs and all, On 2014-09-11 T 09:40 +0000 urs.frey at post.ch wrote: > >Correct, you shouldn't use mkfs.btrfs yourself > >directly but do this via YaST2 storage module. The > >reason is, that YaST2 enables/disables the features > >in a way that a by us supported btrfs filesystem > >will be created. This is not always given if you > >call mkfs.btrfs directly. > > Working with yast? Sound weird, when I just want to > create a FS on some SAN LUNs for specific use. So in > this case BtrFS with all its features seems is not to > be yet mature enough, sorry Thorsten is correct. We usually and for a long time say and write that we only support creating disks/ partitions via YaST. However, once a disk has been created, it certainly is hard to distinguish, ... ;-) > Background: I would like to compare the use of BtrFS > and XFS on LVM2 logical volumes in context resizing, > defrag, balance. So using yast for BtrFS just > because of some for me not transparent automatisms > this is not really user friendly. Agreed. The experienced user (and I rate everybody on this list in that category; that's why you are here!) certainly can create partitions manually, as long as he follows the advice in the SUSE manuals regarding defaults and options. With respect to the bug report: you are right: the "EXPERIMENTAL" message was supposed to have been removed by SLES 12 Beta1. I wonder, why it came back:-( Let me dig into that. so long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE? Linux Enterprise Phone: +49 30 44315731 Mobile: +49 179 2949448 E-Mail: mge at suse.com SUSE LINUX Products GmbH Maxfeldstra?e 5 90409 N?rnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From mge at suse.com Thu Sep 11 05:39:46 2014 From: mge at suse.com (Matthias G. Eckermann) Date: Thu, 11 Sep 2014 13:39:46 +0200 Subject: [sles-beta] SLES12 x86_64 RC2 mkfs.btrfs: WARNING! - Btrfs v3.14.2+20140704 IS EXPERIMENTAL In-Reply-To: <20140911110926.GA21455@suse.com> References: <40637DBB36AF3941B243A286A432CA0B0F9D699F@HXMB12.pnet.ch> <20140911092233.GA3775@suse.de> <40637DBB36AF3941B243A286A432CA0B0F9D69BE@HXMB12.pnet.ch> <20140911110926.GA21455@suse.com> Message-ID: <20140911113946.GC21776@suse.com> Hello Urs and all, On 2014-09-11 T 13:09 +0200 Matthias G. Eckermann wrote: > With respect to the bug report: you are right: the > "EXPERIMENTAL" message was supposed to have been > removed by SLES 12 Beta1. I wonder, why it came back:-( > > Let me dig into that. this already has been fixed in the most recent builds (SLE 12 RC3 candidates). I just checked myself: ---------------------------< snip >--------------------------- 2014-09-11 13:27 (1) ~ kos root (0) # mkfs.btrfs -f -L btrfs_lzo_test /dev/sdb4 Btrfs v3.16+20140829 See http://btrfs.wiki.kernel.org for more information. Turning ON incompat feature 'extref': increased hardlink limit per file to 65536 Turning ON incompat feature 'skinny-metadata': reduced-size metadata extent refs fs created label btrfs_lzo_test on /dev/sdb4 nodesize 16384 leafsize 16384 sectorsize 4096 size 64.00GiB ---------------------------< snap >--------------------------- So long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE? Linux Enterprise Phone: +49 30 44315731 Mobile: +49 179 2949448 E-Mail: mge at suse.com SUSE LINUX Products GmbH Maxfeldstra?e 5 90409 N?rnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From urs.frey at post.ch Thu Sep 11 05:45:24 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Thu, 11 Sep 2014 11:45:24 +0000 Subject: [sles-beta] SLES12 x86_64 RC2 mkfs.btrfs: WARNING! - Btrfs v3.14.2+20140704 IS EXPERIMENTAL In-Reply-To: <20140911113946.GC21776@suse.com> References: <40637DBB36AF3941B243A286A432CA0B0F9D699F@HXMB12.pnet.ch> <20140911092233.GA3775@suse.de> <40637DBB36AF3941B243A286A432CA0B0F9D69BE@HXMB12.pnet.ch> <20140911110926.GA21455@suse.com> <20140911113946.GC21776@suse.com> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D6A51@HXMB12.pnet.ch> Thank you very much Matthias Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: Matthias G. Eckermann [mailto:mge at suse.com] Gesendet: Thursday, September 11, 2014 1:40 PM An: Frey Urs, IT222; kukuk at suse.de Cc: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 RC2 mkfs.btrfs: WARNING! - Btrfs v3.14.2+20140704 IS EXPERIMENTAL Hello Urs and all, On 2014-09-11 T 13:09 +0200 Matthias G. Eckermann wrote: > With respect to the bug report: you are right: the > "EXPERIMENTAL" message was supposed to have been > removed by SLES 12 Beta1. I wonder, why it came back:-( > > Let me dig into that. this already has been fixed in the most recent builds (SLE 12 RC3 candidates). I just checked myself: ---------------------------< snip >--------------------------- 2014-09-11 13:27 (1) ~ kos root (0) # mkfs.btrfs -f -L btrfs_lzo_test /dev/sdb4 Btrfs v3.16+20140829 See http://btrfs.wiki.kernel.org for more information. Turning ON incompat feature 'extref': increased hardlink limit per file to 65536 Turning ON incompat feature 'skinny-metadata': reduced-size metadata extent refs fs created label btrfs_lzo_test on /dev/sdb4 nodesize 16384 leafsize 16384 sectorsize 4096 size 64.00GiB ---------------------------< snap >--------------------------- So long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE? Linux Enterprise Phone: +49 30 44315731 Mobile: +49 179 2949448 E-Mail: mge at suse.com SUSE LINUX Products GmbH Maxfeldstra?e 5 90409 N?rnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From behlert at suse.com Thu Sep 11 09:23:19 2014 From: behlert at suse.com (Stefan Behlert) Date: Thu, 11 Sep 2014 17:23:19 +0200 Subject: [sles-beta] [ANNOUNCE] SLES 12 RC3 is available Message-ID: <20140911152319.GR6782@suse.de> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! SUSE CONFIDENTIAL !! SUSE CONFIDENTIAL !! SUSE CONFIDENTIAL !! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Dear Beta participants, we are happy to announce the third RC of SUSE Linux Enterprise Server 12. ISO images are now available for download now. Please go to http://www.novell.com/beta and select "View my beta page". Here you should see all Beta's you are part of. Note that the directory contains the images for the SDK as well as for the SLED Extension. We offer 3 DVD ISOs: DVD1 contains the binaries, the second DVD the sources and the third DVD the debuginfo packages. The final product will not contain the debuginfo packages on the media. For installation purposes you just need Media 1 for your architecture. Please verify the md5sum of the ISO using the MD5SUMS file, which can be found in the same directory on the download servers. Known issues (selection): Important change in the pattern naming of SLES: gnome is now named as 'gnome-basic'; If you have patterns mentioned explicitely in your autoyast.xml you need to change 'gnome' to 'gnome-basic'. Note that if you register the system, you will receive updates. With this snapshot we have reached several milestones: o Milestone: All blocker bugs resolved. o Milestone: Last documentation and translation fixes integrated. o Milestone: Last security and showstopper bugfixes integrated. o Milestone: All blocker bugs resolved. o Official ISV/IHV (re-)certification/validation continues. o Official partner acceptance continues. o Only showstopper and security bugfixes get integrated. o Apply final release notes entries o Further security updates will be handled as separate packages. For the next Release we are targeting these actions and milestones: o Milestone: All blocker bugs resolved. o Milestone: Last documentation and translation fixes integrated. o Milestone: Last security and showstopper bugfixes integrated. o Milestone: All blocker bugs resolved. o Official ISV/IHV (re-)certification/validation continues. o Official partner acceptance continues. o Only showstopper and security bugfixes get integrated. o Apply final release notes entries o Further security updates will be handled as separate packages. Be aware that we have provided snapshots of three 'modules' at the download page with this milestone: Module "Legacy": The Legacy Module supports your migration from SUSE Linux Enterprise 10 and 11 and other systems to SUSE Linux Enterprise 12, by providing packages which are discontinued on SUSE Linux Enterprise Server, but which you may rely on, such as: CyrusIMAP, BSD like ftp client, sendmail, IBM Java6. Access to the Legacy Module is included in your SUSE Linux Enterprise Server subscription. The module has a different lifecycle than SUSE Linux Enterprise Server itself; please check the Release Notes for further details. Module "Web & Scripting": The SUSE Linux Enterprise Web and Scripting Module delivers a comprehensive suite of scripting languages, frameworks, and related tools helping developers and systems administrators accelerate the creation of stable, modern web applications. Access to the Web and Scripting Module is included in your SUSE Linux Enterprise Server subscription. The module has a different lifecycle than SUSE Linux Enterprise Server itself; please check the Release Notes for further details. Module "Advanced System Management": This Module gives you a sneak-peak into our upcoming systems management toolbox which allows you to inspect systems remotely, store their system description and create new systems to deploy them in datacenters and clouds. The toolbox is still in active development and will get regular updates. Note that these are provided "as is" and not all packages that will go into them are already contained in them. We recommend to use them through the repositories available online after registration. Thanks in advance for all your testing Your SUSE Linux Enterprise Team -- Stefan Behlert, SUSE LINUX Project Manager Enterprise Server Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-173 SUSE LINUX Products GmbH, Nuernberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) From fcrozat at suse.com Thu Sep 11 09:49:09 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Thu, 11 Sep 2014 17:49:09 +0200 Subject: [sles-beta] sles12-rc3 404 not found In-Reply-To: References: Message-ID: <1410450549.5791.17.camel@par-r81vxc7.par.novell.com> Le jeudi 11 septembre 2014 ? 11:42 -0400, Gary Ernst a ?crit : > As the subject indicates, I am unable to download DVD1 for s390x It works for me, which means CDN is still propagating the ISO image. Wait a bit and try again. I wish we could propage ISOs at light speed with infinite bandwith ;) -- Frederic Crozat Project Manager Enterprise Desktop SUSE From fcrozat at suse.com Fri Sep 12 07:36:05 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Fri, 12 Sep 2014 15:36:05 +0200 Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch> Message-ID: <1410528965.1791.12.camel@par-r81vxc7.par.novell.com> Le vendredi 12 septembre 2014 ? 13:12 +0000, urs.frey at post.ch a ?crit : > Hi > > When installing SLES12 x86_64 RC3 and on top of it some specific > Rubygem packages I get now this error message I did not have with RC2 > > Problem: pst-rubygem-stomp-1.3.2-1.x86_64 requires ruby(abi) = 2.1.0, > but this requirement cannot be provided > Problem: pst-rubygem-stomp-1.3.2-1.x86_64 requires ruby(abi) = 2.1.0, > but this requirement cannot be provided > Problem: pst-rubygem-sshkeyauth-0.0.11-5.x86_64 requires ruby(abi) = > 2.1.0, but this requirement cannot be provided > Problem: pst-rubygem-sshkeyauth-0.0.11-5.x86_64 requires ruby(abi) = > 2.1.0, but this requirement cannot be provided > Problem: pst-rubygem-net-ssh-2.6.6-1.x86_64 requires ruby(abi) = > 2.1.0, but this requirement cannot be provided > > I googled a bit about this ruby(abi) notation > > In the changelog ChangeLog-RC2-RC3.txt.gz I found this > > ----------------------------------------------------------------------------- > > o Updated ruby-common (security/bugfix/feature) > > - we actually need the splitted version in any case. uncomment it > again > - pass the ruby abi as hash containing :interpreter, :version, > :abi as keys. that way we have the full new string but also the > version for the 1.8 support > - rubygemsdeps.rb: > - make the provides/requires also include the ruby interpreter > - no longer emit the old package name style provides > - rubygems.attr: > - make the path a bit more relaxed so we can match other ruby > interpreter too > > So from my point of view there is now a real problem, as I can not > install packages showing ruby(abi) requirements > freyu at h05cni:~/rpmbuild/RPMS/x86_64> rpm -qp --requires > pst-rubygem-net-ssh-2.6.6-1.x86_64.rpm > /usr/bin/ruby > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > ruby >= 1.8.7 > ruby(abi) = ruby:2.1.0 > rpmlib(PayloadIsLzma) <= 4.4.6-1 > freyu at h05cni:~/rpmbuild/RPMS/x86_64> > > h05cni:~ # zypper in pst-rubygem-net-ssh > Loading repository data... > Reading installed packages... > Resolving package dependencies... > > Problem: nothing provides ruby(abi) = 2.1.0 needed by > pst-rubygem-net-ssh-2.6.6-1.x86_64 > Solution 1: do not install pst-rubygem-net-ssh-2.6.6-1.x86_64 > Solution 2: break pst-rubygem-net-ssh-2.6.6-1.x86_64 by ignoring some > of its dependencies > > Choose from above solutions by number or cancel [1/2/c] (c): > > > Somebody an idea to work around this? > This worked with SLES12 RC2, now I got stuck > From my point of view zypper can not handle, what has got modified > with ruby and :abi key > > It is not even possible to get this requirement out of the rpm package > when building with rpmbuild Thanks Urs for your email. We had to slightly change ruby packaging to allow parallel installation of ruby version for the future. Due to that, you need to rebuild your pst* packages on SLE12 RC3 (no change should be needed on the specfile) and they will install fine on RC3. Sorry for this inconvenience but this is to ensure we are future proof ruby-wise. -- Frederic Crozat Project Manager Enterprise Desktop SUSE From urs.frey at post.ch Fri Sep 12 07:47:16 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Fri, 12 Sep 2014 13:47:16 +0000 Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided In-Reply-To: <1410528965.1791.12.camel@par-r81vxc7.par.novell.com> References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch> <1410528965.1791.12.camel@par-r81vxc7.par.novell.com> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch> Hello Frederic Thank you very much for your answer See the problem is, that I am really rebuilding on RC3 and still encountering problems freyu at h05cni:~/rpmbuild/SPECS> uname -a Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) x86_64 x86_64 x86_64 GNU/Linux freyu at h05cni:~/rpmbuild/SPECS> rpmbuild -ba --clean rubygem-stomp.spec . . . freyu at h05cni:~/rpmbuild/SPECS> rpm -qp --requires ../RPMS/x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby /usr/bin/ruby.ruby2.1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 ruby(abi) = ruby:2.1.0 rpmlib(PayloadIsLzma) <= 4.4.6-1 freyu at h05cni:~/rpmbuild/SPECS> h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) x86_64 x86_64 x86_64 GNU/Linux h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -ivh pst-rubygem-stomp-1.3.2-1.x86_64.rpm Preparing... ################################# [100%] Updating / installing... 1:pst-rubygem-stomp-1.3.2-1 ################################# [100%] h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -e pst-rubygem-stomp h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) x86_64 x86_64 x86_64 GNU/Linux h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # On my network install server, the package uploaded, made ready for use with zypper =========================================== v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # rpm -qp --requires pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby /usr/bin/ruby.ruby2.1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 ruby(abi) = ruby:2.1.0 rpmlib(PayloadIsLzma) <= 4.4.6-1 v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # md5sum pst-rubygem-stomp-1.3.2-1.x86_64.rpm 16d8783d67730675ea7d80264d6c72db pst-rubygem-stomp-1.3.2-1.x86_64.rpm v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # freyu at h05cni:~/rpmbuild/SPECS> md5sum ../RPMS/x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm 16d8783d67730675ea7d80264d6c72db ../RPMS/x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm freyu at h05cni:~/rpmbuild/SPECS> On SLES12 RC3 again ================= h05cni:~ # zypper in pst-rubygem-stomp Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides ruby(abi) = 2.1.0 needed by pst-rubygem-stomp-1.3.2-1.x86_64 Solution 1: do not install pst-rubygem-stomp-1.3.2-1.x86_64 Solution 2: break pst-rubygem-stomp-1.3.2-1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): c h05cni:~ # h05cni:~ # uname -a Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) x86_64 x86_64 x86_64 GNU/Linux h05cni:~ # cat /etc/issue Welcome to SUSE Linux Enterprise Server 12 RC3 (x86_64) - Kernel \r (\l). h05cni:~ # ========================== So even with my best will, RC3 is unusable for me. There is a real problem with the ruby packages now regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Frederic Crozat Gesendet: Friday, September 12, 2014 3:36 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided Le vendredi 12 septembre 2014 ? 13:12 +0000, urs.frey at post.ch a ?crit : > Hi > > When installing SLES12 x86_64 RC3 and on top of it some specific > Rubygem packages I get now this error message I did not have with RC2 > > Problem: pst-rubygem-stomp-1.3.2-1.x86_64 requires ruby(abi) = 2.1.0, > but this requirement cannot be provided > Problem: pst-rubygem-stomp-1.3.2-1.x86_64 requires ruby(abi) = 2.1.0, > but this requirement cannot be provided > Problem: pst-rubygem-sshkeyauth-0.0.11-5.x86_64 requires ruby(abi) = > 2.1.0, but this requirement cannot be provided > Problem: pst-rubygem-sshkeyauth-0.0.11-5.x86_64 requires ruby(abi) = > 2.1.0, but this requirement cannot be provided > Problem: pst-rubygem-net-ssh-2.6.6-1.x86_64 requires ruby(abi) = > 2.1.0, but this requirement cannot be provided > > I googled a bit about this ruby(abi) notation > > In the changelog ChangeLog-RC2-RC3.txt.gz I found this > > ----------------------------------------------------------------------------- > > o Updated ruby-common (security/bugfix/feature) > > - we actually need the splitted version in any case. uncomment it > again > - pass the ruby abi as hash containing :interpreter, :version, > :abi as keys. that way we have the full new string but also the > version for the 1.8 support > - rubygemsdeps.rb: > - make the provides/requires also include the ruby interpreter > - no longer emit the old package name style provides > - rubygems.attr: > - make the path a bit more relaxed so we can match other ruby > interpreter too > > So from my point of view there is now a real problem, as I can not > install packages showing ruby(abi) requirements > freyu at h05cni:~/rpmbuild/RPMS/x86_64> rpm -qp --requires > pst-rubygem-net-ssh-2.6.6-1.x86_64.rpm > /usr/bin/ruby > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > ruby >= 1.8.7 > ruby(abi) = ruby:2.1.0 > rpmlib(PayloadIsLzma) <= 4.4.6-1 > freyu at h05cni:~/rpmbuild/RPMS/x86_64> > > h05cni:~ # zypper in pst-rubygem-net-ssh > Loading repository data... > Reading installed packages... > Resolving package dependencies... > > Problem: nothing provides ruby(abi) = 2.1.0 needed by > pst-rubygem-net-ssh-2.6.6-1.x86_64 > Solution 1: do not install pst-rubygem-net-ssh-2.6.6-1.x86_64 > Solution 2: break pst-rubygem-net-ssh-2.6.6-1.x86_64 by ignoring some > of its dependencies > > Choose from above solutions by number or cancel [1/2/c] (c): > > > Somebody an idea to work around this? > This worked with SLES12 RC2, now I got stuck > From my point of view zypper can not handle, what has got modified > with ruby and :abi key > > It is not even possible to get this requirement out of the rpm package > when building with rpmbuild Thanks Urs for your email. We had to slightly change ruby packaging to allow parallel installation of ruby version for the future. Due to that, you need to rebuild your pst* packages on SLE12 RC3 (no change should be needed on the specfile) and they will install fine on RC3. Sorry for this inconvenience but this is to ensure we are future proof ruby-wise. -- Frederic Crozat Project Manager Enterprise Desktop SUSE _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From fcrozat at suse.com Fri Sep 12 07:57:41 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Fri, 12 Sep 2014 15:57:41 +0200 Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch> <1410528965.1791.12.camel@par-r81vxc7.par.novell.com> <40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch> Message-ID: <1410530261.1791.13.camel@par-r81vxc7.par.novell.com> Le vendredi 12 septembre 2014 ? 13:47 +0000, urs.frey at post.ch a ?crit : > Hello Frederic > > Thank you very much for your answer > > See the problem is, that I am really rebuilding on RC3 and still encountering problems Let me forward those information to our ruby specialist. > > freyu at h05cni:~/rpmbuild/SPECS> uname -a > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) x86_64 x86_64 x86_64 GNU/Linux > freyu at h05cni:~/rpmbuild/SPECS> rpmbuild -ba --clean rubygem-stomp.spec > . . . > freyu at h05cni:~/rpmbuild/SPECS> rpm -qp --requires ../RPMS/x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm > /usr/bin/ruby > /usr/bin/ruby.ruby2.1 > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > ruby(abi) = ruby:2.1.0 > rpmlib(PayloadIsLzma) <= 4.4.6-1 > freyu at h05cni:~/rpmbuild/SPECS> > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) x86_64 x86_64 x86_64 GNU/Linux > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -ivh pst-rubygem-stomp-1.3.2-1.x86_64.rpm > Preparing... ################################# [100%] > Updating / installing... > 1:pst-rubygem-stomp-1.3.2-1 ################################# [100%] > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -e pst-rubygem-stomp > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) x86_64 x86_64 x86_64 GNU/Linux > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # > > > On my network install server, the package uploaded, made ready for use with zypper > =========================================== > v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # rpm -qp --requires pst-rubygem-stomp-1.3.2-1.x86_64.rpm > /usr/bin/ruby > /usr/bin/ruby.ruby2.1 > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > ruby(abi) = ruby:2.1.0 > rpmlib(PayloadIsLzma) <= 4.4.6-1 > v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # > v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # md5sum pst-rubygem-stomp-1.3.2-1.x86_64.rpm > 16d8783d67730675ea7d80264d6c72db pst-rubygem-stomp-1.3.2-1.x86_64.rpm > v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # > freyu at h05cni:~/rpmbuild/SPECS> md5sum ../RPMS/x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm > 16d8783d67730675ea7d80264d6c72db ../RPMS/x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm > freyu at h05cni:~/rpmbuild/SPECS> > > On SLES12 RC3 again > ================= > h05cni:~ # zypper in pst-rubygem-stomp > Loading repository data... > Reading installed packages... > Resolving package dependencies... > > Problem: nothing provides ruby(abi) = 2.1.0 needed by pst-rubygem-stomp-1.3.2-1.x86_64 > Solution 1: do not install pst-rubygem-stomp-1.3.2-1.x86_64 > Solution 2: break pst-rubygem-stomp-1.3.2-1.x86_64 by ignoring some of its dependencies > > Choose from above solutions by number or cancel [1/2/c] (c): c > h05cni:~ # > h05cni:~ # uname -a > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) x86_64 x86_64 x86_64 GNU/Linux > h05cni:~ # cat /etc/issue > > Welcome to SUSE Linux Enterprise Server 12 RC3 (x86_64) - Kernel \r (\l). > > h05cni:~ # > > ========================== > So even with my best will, RC3 is unusable for me. > There is a real problem with the ruby packages now > > regards > > > Urs Frey > Post CH AG > Informationstechnologie > IT Betrieb > Webergutstrasse 12 > 3030 Bern (Zollikofen) > Telefon : ++41 (0)58 338 58 70 > FAX : ++41 (0)58 667 30 07 > E-Mail: urs.frey at post.ch > > > -----Urspr?ngliche Nachricht----- > Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Frederic Crozat > Gesendet: Friday, September 12, 2014 3:36 PM > An: sles-beta at lists.suse.com > Betreff: Re: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided > > Le vendredi 12 septembre 2014 ? 13:12 +0000, urs.frey at post.ch a ?crit : > > Hi > > > > When installing SLES12 x86_64 RC3 and on top of it some specific > > Rubygem packages I get now this error message I did not have with RC2 > > > > Problem: pst-rubygem-stomp-1.3.2-1.x86_64 requires ruby(abi) = 2.1.0, > > but this requirement cannot be provided > > Problem: pst-rubygem-stomp-1.3.2-1.x86_64 requires ruby(abi) = 2.1.0, > > but this requirement cannot be provided > > Problem: pst-rubygem-sshkeyauth-0.0.11-5.x86_64 requires ruby(abi) = > > 2.1.0, but this requirement cannot be provided > > Problem: pst-rubygem-sshkeyauth-0.0.11-5.x86_64 requires ruby(abi) = > > 2.1.0, but this requirement cannot be provided > > Problem: pst-rubygem-net-ssh-2.6.6-1.x86_64 requires ruby(abi) = > > 2.1.0, but this requirement cannot be provided > > > > I googled a bit about this ruby(abi) notation > > > > In the changelog ChangeLog-RC2-RC3.txt.gz I found this > > > > ----------------------------------------------------------------------------- > > > > o Updated ruby-common (security/bugfix/feature) > > > > - we actually need the splitted version in any case. uncomment it > > again > > - pass the ruby abi as hash containing :interpreter, :version, > > :abi as keys. that way we have the full new string but also the > > version for the 1.8 support > > - rubygemsdeps.rb: > > - make the provides/requires also include the ruby interpreter > > - no longer emit the old package name style provides > > - rubygems.attr: > > - make the path a bit more relaxed so we can match other ruby > > interpreter too > > > > So from my point of view there is now a real problem, as I can not > > install packages showing ruby(abi) requirements > > freyu at h05cni:~/rpmbuild/RPMS/x86_64> rpm -qp --requires > > pst-rubygem-net-ssh-2.6.6-1.x86_64.rpm > > /usr/bin/ruby > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > ruby >= 1.8.7 > > ruby(abi) = ruby:2.1.0 > > rpmlib(PayloadIsLzma) <= 4.4.6-1 > > freyu at h05cni:~/rpmbuild/RPMS/x86_64> > > > > h05cni:~ # zypper in pst-rubygem-net-ssh > > Loading repository data... > > Reading installed packages... > > Resolving package dependencies... > > > > Problem: nothing provides ruby(abi) = 2.1.0 needed by > > pst-rubygem-net-ssh-2.6.6-1.x86_64 > > Solution 1: do not install pst-rubygem-net-ssh-2.6.6-1.x86_64 > > Solution 2: break pst-rubygem-net-ssh-2.6.6-1.x86_64 by ignoring some > > of its dependencies > > > > Choose from above solutions by number or cancel [1/2/c] (c): > > > > > > Somebody an idea to work around this? > > This worked with SLES12 RC2, now I got stuck > > From my point of view zypper can not handle, what has got modified > > with ruby and :abi key > > > > It is not even possible to get this requirement out of the rpm package > > when building with rpmbuild > > Thanks Urs for your email. > > We had to slightly change ruby packaging to allow parallel installation > of ruby version for the future. Due to that, you need to rebuild your > pst* packages on SLE12 RC3 (no change should be needed on the specfile) > and they will install fine on RC3. > > Sorry for this inconvenience but this is to ensure we are future proof > ruby-wise. > > > -- Frederic Crozat Project Manager Enterprise Desktop SUSE From urs.frey at post.ch Fri Sep 12 08:49:34 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Fri, 12 Sep 2014 14:49:34 +0000 Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided In-Reply-To: <20140912163613.32576d01@tengu.suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch> <1410528965.1791.12.camel@par-r81vxc7.par.novell.com> <40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch> <1410530261.1791.13.camel@par-r81vxc7.par.novell.com> <20140912163613.32576d01@tengu.suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D6DDA@HXMB12.pnet.ch> Hello Marcus Thank you for this hint! h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # zypper in pst-rubygem-stomp-1.3.2-1.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: pst-rubygem-stomp 1 new package to install. Overall download size: 138.4 KiB. Already cached: 0 B After the operation, additional 399.2 KiB will be used. Continue? [y/n/? shows all options] (y): Retrieving package pst-rubygem-stomp-1.3.2-1.x86_64 (1/1), 138.4 KiB (399.2 KiB unpacked) Checking for file conflicts: .........................................................................................................[done] (1/1) Installing: pst-rubygem-stomp-1.3.2-1 ..........................................................................................[done] h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # So I have to debug my repository refresh job then Thank you very much Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: Marcus R?ckert [mailto:mrueckert at suse.de] Gesendet: Friday, September 12, 2014 4:36 PM An: Frederic Crozat Cc: Frey Urs, IT222; sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided On Fri, 12 Sep 2014 15:57:41 +0200 Frederic Crozat wrote: > Le vendredi 12 septembre 2014 ? 13:47 +0000, urs.frey at post.ch a > ?crit : > > Hello Frederic > > > > Thank you very much for your answer > > > > See the problem is, that I am really rebuilding on RC3 and still > > encountering problems > > Let me forward those information to our ruby specialist. > > > > > > freyu at h05cni:~/rpmbuild/SPECS> uname -a > > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 > > (aff039d) x86_64 x86_64 x86_64 GNU/Linux > > freyu at h05cni:~/rpmbuild/SPECS> rpmbuild -ba --clean > > rubygem-stomp.spec . . . freyu at h05cni:~/rpmbuild/SPECS> rpm -qp > > --requires ../RPMS/x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby > > /usr/bin/ruby.ruby2.1 > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > ruby(abi) = ruby:2.1.0 > > rpmlib(PayloadIsLzma) <= 4.4.6-1 > > freyu at h05cni:~/rpmbuild/SPECS> > > > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a > > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 > > (aff039d) x86_64 x86_64 x86_64 GNU/Linux > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -ivh > > pst-rubygem-stomp-1.3.2-1.x86_64.rpm > > Preparing... > > ################################# [100%] Updating / installing... > > 1:pst-rubygem-stomp-1.3.2-1 > > ################################# [100%] > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -e pst-rubygem-stomp > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a Linux h05cni > > 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) > > x86_64 x86_64 x86_64 GNU/Linux > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # > > > > > > On my network install server, the package uploaded, made ready for > > use with zypper =========================================== > > v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # rpm -qp > > --requires pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby > > /usr/bin/ruby.ruby2.1 > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > ruby(abi) = ruby:2.1.0 as you see here it generated the correct ruby(abi) requires. > > h05cni:~ # zypper in pst-rubygem-stomp could you copy over the file you just built above and try zypper in pst-rubygem-stomp-1.3.2-1.x86_64.rpm It looks like the package it tries to install from the repository has not been rebuilt yet. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From urs.frey at post.ch Fri Sep 12 09:25:32 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Fri, 12 Sep 2014 15:25:32 +0000 Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided In-Reply-To: <20140912163613.32576d01@tengu.suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch> <1410528965.1791.12.camel@par-r81vxc7.par.novell.com> <40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch> <1410530261.1791.13.camel@par-r81vxc7.par.novell.com> <20140912163613.32576d01@tengu.suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D6DF7@HXMB12.pnet.ch> Hello Marcus OK after you hint, installing with zypper locally after having rebuilt the ruby package this worked h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # zypper in pst-rubygem-stomp-1.3.2-1.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: pst-rubygem-stomp 1 new package to install. Overall download size: 138.4 KiB. Already cached: 0 B After the operation, additional 399.2 KiB will be used. Continue? [y/n/? shows all options] (y): y Retrieving package pst-rubygem-stomp-1.3.2-1.x86_64 (1/1), 138.4 KiB (399.2 KiB unpacked) Checking for file conflicts: .........................................................................................................[done] (1/1) Installing: pst-rubygem-stomp-1.3.2-1 ..........................................................................................[done] h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # Now on my network install repo, observe the md5sum of the package =================================================== h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # md5sum pst-rubygem-stomp-1.3.2-1.x86_64.rpm 445b9d07e9283d6cad1fa8e3d13cc71d pst-rubygem-stomp-1.3.2-1.x86_64.rpm h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # md5sum pst-rubygem-stomp-1.3.2-1.x86_64.rpm 445b9d07e9283d6cad1fa8e3d13cc71d pst-rubygem-stomp-1.3.2-1.x86_64.rpm v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # The same file Here I do nothing else than createrepo . on a SLES11-SP3 Repo-Server And obviously this does not work anymore, v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # su - pkgadm pkgadm at v03g27:~> cd /appl/pstkits/pstaddon/SLES12_64/post/ pkgadm at v03g27:/appl/pstkits/pstaddon/SLES12_64/post> createrepo . Spawning worker 0 with 23 pkgs Workers Finished Gathering worker results Saving Primary metadata Saving file lists metadata Saving other metadata pkgadm at v03g27:/appl/pstkits/pstaddon/SLES12_64/post> Because when trying to install http with zypper I run always into this problem h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # zypper in pst-rubygem-stomp Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides ruby(abi) = 2.1.0 needed by pst-rubygem-stomp-1.3.2-1.x86_64 Solution 1: do not install pst-rubygem-stomp-1.3.2-1.x86_64 Solution 2: break pst-rubygem-stomp-1.3.2-1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # QUESTION: can it be, that with the new implementation of ruby(api) createrepo on SLES11-SP3 has some difficulty?? From the file repodate/primary.xml.gz I can see this for pst-rubygem-stomp pst-rubygem-stomp x86_64 52dd2e42986e176bfc9b63005f44e5e024fd4826 Ruby client for the Stomp messaging protocol A ruby gem for sending and receiving messages from a Stomp protocol compliant message queue. Includes: fail over logic, ssl support. https://github.com/stompgem/stomp So the change in SLES12 RC3 with ruby makes my entire environment and SLES12 unusable Installation local with rpm and zypper works, but zypper from a rpm-md repository does not work anymore http-172.27.40.68-44fc3b8b | Post-Specific-Kits 12 | Yes | Yes | 99 | rpm-md | http://172.27.40.68/pstkits/pstaddon/SLES12_64 ----------------------------------------------------------------------------- o Updated ruby-common (security/bugfix/feature) - we actually need the splitted version in any case. uncomment it again - pass the ruby abi as hash containing :interpreter, :version, :abi as keys. that way we have the full new string but also the version for the 1.8 support - rubygemsdeps.rb: - make the provides/requires also include the ruby interpreter - no longer emit the old package name style provides - rubygems.attr: - make the path a bit more relaxed so we can match other ruby interpreter too ----------------------------------------------------------------------------- Unless I can safely install my own built RPM packages from a http network repo server SLES11-SP3, repo updated with createrepo under SLES11-SP3 , SLES12 is unusable for me. regardds Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: Marcus R?ckert [mailto:mrueckert at suse.de] Gesendet: Friday, September 12, 2014 4:36 PM An: Frederic Crozat Cc: Frey Urs, IT222; sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided On Fri, 12 Sep 2014 15:57:41 +0200 Frederic Crozat wrote: > Le vendredi 12 septembre 2014 ? 13:47 +0000, urs.frey at post.ch a > ?crit : > > Hello Frederic > > > > Thank you very much for your answer > > > > See the problem is, that I am really rebuilding on RC3 and still > > encountering problems > > Let me forward those information to our ruby specialist. > > > > > > freyu at h05cni:~/rpmbuild/SPECS> uname -a > > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 > > (aff039d) x86_64 x86_64 x86_64 GNU/Linux > > freyu at h05cni:~/rpmbuild/SPECS> rpmbuild -ba --clean > > rubygem-stomp.spec . . . freyu at h05cni:~/rpmbuild/SPECS> rpm -qp > > --requires ../RPMS/x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby > > /usr/bin/ruby.ruby2.1 > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > ruby(abi) = ruby:2.1.0 > > rpmlib(PayloadIsLzma) <= 4.4.6-1 > > freyu at h05cni:~/rpmbuild/SPECS> > > > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a > > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 > > (aff039d) x86_64 x86_64 x86_64 GNU/Linux > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -ivh > > pst-rubygem-stomp-1.3.2-1.x86_64.rpm > > Preparing... > > ################################# [100%] Updating / installing... > > 1:pst-rubygem-stomp-1.3.2-1 > > ################################# [100%] > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -e pst-rubygem-stomp > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a Linux h05cni > > 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) > > x86_64 x86_64 x86_64 GNU/Linux > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # > > > > > > On my network install server, the package uploaded, made ready for > > use with zypper =========================================== > > v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # rpm -qp > > --requires pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby > > /usr/bin/ruby.ruby2.1 > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > ruby(abi) = ruby:2.1.0 as you see here it generated the correct ruby(abi) requires. > > h05cni:~ # zypper in pst-rubygem-stomp could you copy over the file you just built above and try zypper in pst-rubygem-stomp-1.3.2-1.x86_64.rpm It looks like the package it tries to install from the repository has not been rebuilt yet. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From urs.frey at post.ch Fri Sep 12 10:42:59 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Fri, 12 Sep 2014 16:42:59 +0000 Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided In-Reply-To: <20140912163613.32576d01@tengu.suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch> <1410528965.1791.12.camel@par-r81vxc7.par.novell.com> <40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch> <1410530261.1791.13.camel@par-r81vxc7.par.novell.com> <20140912163613.32576d01@tengu.suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D6E47@HXMB12.pnet.ch> Hi all Tried to dig deeper into the stuff I installed an apache webserver directly on the host I am building the packages, SLES12. Then I built ma repository directly in this build server using createrepo Then I attached the directory as rpm-md with zypper Conclusion: Installation locally using rpm or zypper does work But as soon as I try to create a repo with createrepo and install http the ruby(abi) stuff does not work. All can be easily reproduced directly on SLES12 RC3 In the attachment you will find source and spec to reproduce for rubygem-stomp h05cni:/appl/pstkits/pstaddon/SLES12_64/post # uname -a Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) x86_64 x86_64 x86_64 GNU/Linux h05cni:/appl/pstkits/pstaddon/SLES12_64/post # cat /etc/issue Welcome to SUSE Linux Enterprise Server 12 RC3 (x86_64) - Kernel \r (\l). h05cni:/appl/pstkits/pstaddon/SLES12_64/post # h05cni:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # zypper in pst-rubygem-stomp-1.3.2-1.x86_64.rpm Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: pst-rubygem-stomp 1 new package to install. Overall download size: 138.4 KiB. Already cached: 0 B After the operation, additional 399.2 KiB will be used. Continue? [y/n/? shows all options] (y): y Retrieving package pst-rubygem-stomp-1.3.2-1.x86_64 (1/1), 138.4 KiB (399.2 KiB unpacked) Checking for file conflicts: .....................................................................................................[done] (1/1) Installing: pst-rubygem-stomp-1.3.2-1 ......................................................................................[done] h05cni:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # h05cni:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # zypper repos -ud | grep -i post 2 | http-172.27.40.68-44fc3b8b | Post-Specific-Kits 12 | Yes | Yes | 99 | rpm-md | http://10.226.169.29/pstkits/pstaddon/SLES12_64 | h05cni:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # grep h05cni /etc/hosts 10.226.169.29 h05cni.pnet.ch h05cni h05cni:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # h05cni:/appl/pstkits/pstaddon/SLES12_64/post # createrepo . Spawning worker 0 with 1 pkgs Spawning worker 1 with 1 pkgs Spawning worker 2 with 1 pkgs Spawning worker 3 with 1 pkgs Spawning worker 4 with 1 pkgs Spawning worker 5 with 1 pkgs Spawning worker 6 with 1 pkgs Spawning worker 7 with 1 pkgs Spawning worker 8 with 1 pkgs Spawning worker 9 with 1 pkgs Spawning worker 10 with 1 pkgs Spawning worker 11 with 1 pkgs Spawning worker 12 with 1 pkgs Spawning worker 13 with 1 pkgs Spawning worker 14 with 1 pkgs Spawning worker 15 with 1 pkgs Spawning worker 16 with 1 pkgs Spawning worker 17 with 1 pkgs Spawning worker 18 with 1 pkgs Spawning worker 19 with 1 pkgs Spawning worker 20 with 1 pkgs Spawning worker 21 with 1 pkgs Spawning worker 22 with 1 pkgs Workers Finished Saving Primary metadata Saving file lists metadata Saving other metadata h05cni:/appl/pstkits/pstaddon/SLES12_64/post # h05cni:/appl/pstkits/pstaddon/SLES12_64/post # grep pstkits /etc/apache2/default-server.conf Alias /pstkits "/appl/pstkits/" h05cni:/appl/pstkits/pstaddon/SLES12_64/post # systemctl restart apache2.service h05cni:/appl/pstkits/pstaddon/SLES12_64/post # systemctl status apache2.service apache2.service - The Apache Webserver Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled) Active: active (running) since Fri 2014-09-12 18:29:23 CEST; 9s ago Process: 11041 ExecStop=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND -k graceful-stop (code=exited, status=0/SUCCESS) Main PID: 11062 (httpd2-prefork) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/apache2.service ??11062 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -DFOREGROUND -k start ??11079 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -DFOREGROUND -k start ??11080 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -DFOREGROUND -k start ??11081 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -DFOREGROUND -k start ??11082 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -DFOREGROUND -k start ??11083 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -DFOREGROUND -k start Sep 12 18:29:23 h05cni systemd[1]: Started The Apache Webserver. h05cni:/appl/pstkits/pstaddon/SLES12_64/post # h05cni:/appl/pstkits/pstaddon/SLES12_64/post # zypper refresh Repository 'SLES12-12-0' is up to date. Repository 'Post-Specific-Kits 12' is up to date. Repository 'SDK12 12-0' is up to date. Repository 'Adv-Sys-Mgmt-module 12-0' is up to date. All repositories have been refreshed. h05cni:/appl/pstkits/pstaddon/SLES12_64/post # zypper in pst-rubygem-stomp Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides ruby(abi) = 2.1.0 needed by pst-rubygem-stomp-1.3.2-1.x86_64 Solution 1: do not install pst-rubygem-stomp-1.3.2-1.x86_64 Solution 2: break pst-rubygem-stomp-1.3.2-1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): h05cni:/appl/pstkits/pstaddon/SLES12_64/post # So I state that this rubygem change with SLES12 RC3 is incompatible with createrepo It is even incompatible with createrepo on SLES12 RC3 h05cni:/appl/pstkits/pstaddon/SLES12_64/post # uname -a Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) x86_64 x86_64 x86_64 GNU/Linux h05cni:/appl/pstkits/pstaddon/SLES12_64/post # cat /etc/issue Welcome to SUSE Linux Enterprise Server 12 RC3 (x86_64) - Kernel \r (\l). h05cni:/appl/pstkits/pstaddon/SLES12_64/post # So there is a real problem now which has to be fixed please Best regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: Marcus R?ckert [mailto:mrueckert at suse.de] Gesendet: Friday, September 12, 2014 4:36 PM An: Frederic Crozat Cc: Frey Urs, IT222; sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided On Fri, 12 Sep 2014 15:57:41 +0200 Frederic Crozat wrote: > Le vendredi 12 septembre 2014 ? 13:47 +0000, urs.frey at post.ch a > ?crit : > > Hello Frederic > > > > Thank you very much for your answer > > > > See the problem is, that I am really rebuilding on RC3 and still > > encountering problems > > Let me forward those information to our ruby specialist. > > > > > > freyu at h05cni:~/rpmbuild/SPECS> uname -a > > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 > > (aff039d) x86_64 x86_64 x86_64 GNU/Linux > > freyu at h05cni:~/rpmbuild/SPECS> rpmbuild -ba --clean > > rubygem-stomp.spec . . . freyu at h05cni:~/rpmbuild/SPECS> rpm -qp > > --requires ../RPMS/x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby > > /usr/bin/ruby.ruby2.1 > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > ruby(abi) = ruby:2.1.0 > > rpmlib(PayloadIsLzma) <= 4.4.6-1 > > freyu at h05cni:~/rpmbuild/SPECS> > > > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a > > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 > > (aff039d) x86_64 x86_64 x86_64 GNU/Linux > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -ivh > > pst-rubygem-stomp-1.3.2-1.x86_64.rpm > > Preparing... > > ################################# [100%] Updating / installing... > > 1:pst-rubygem-stomp-1.3.2-1 > > ################################# [100%] > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -e pst-rubygem-stomp > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a Linux h05cni > > 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) > > x86_64 x86_64 x86_64 GNU/Linux > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # > > > > > > On my network install server, the package uploaded, made ready for > > use with zypper =========================================== > > v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # rpm -qp > > --requires pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby > > /usr/bin/ruby.ruby2.1 > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > ruby(abi) = ruby:2.1.0 as you see here it generated the correct ruby(abi) requires. > > h05cni:~ # zypper in pst-rubygem-stomp could you copy over the file you just built above and try zypper in pst-rubygem-stomp-1.3.2-1.x86_64.rpm It looks like the package it tries to install from the repository has not been rebuilt yet. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -------------- next part -------------- A non-text attachment was scrubbed... Name: rubygem_stomp.tgz Type: application/x-compressed Size: 74050 bytes Desc: rubygem_stomp.tgz URL: From gjn at gjn.priv.at Sat Sep 13 04:23:06 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Sat, 13 Sep 2014 12:23:06 +0200 Subject: [sles-beta] Documentation pdf Files Message-ID: <1522810.6lHP2jRvDl@gjn.priv.at> Hello, is this known in the Doc (book...pdf) RC3 are YaST module described this don't exist anymore in YaST2, like kerberos client or kerberos server but nothing for the sssd config or the new auth-server client. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From gjn at gjn.priv.at Sun Sep 14 01:28:14 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Sun, 14 Sep 2014 09:28:14 +0200 Subject: [sles-beta] What is wrong with my #SR Message-ID: <1692194.zSqY0tH0o8@gjn.priv.at> Hello, I mean all reported Bug Reports are here in RC3 again ? Example: Kerberos /etc/host xxx.xxx.xxx.xxx xxxx.example.prv xxx.xxx.xxx.xxx xxxx.wrong.com hostname -f xxxx.example.prv create with YaST a ldap & kerberos installation Principals kadmin/xxxx.wrong.com at EXAMPLE.PRV -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From gjn at gjn.priv.at Sun Sep 14 01:49:49 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Sun, 14 Sep 2014 09:49:49 +0200 Subject: [sles-beta] Certificate Deleted Message-ID: <1611665.XhP1MaMyAv@gjn.priv.at> Hello, when I make a zypper up from RC2 to RC3 my Certificate are deleted in /usr/lib/ca-certificates/pem ? -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From gjn at gjn.priv.at Sun Sep 14 02:20:29 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Sun, 14 Sep 2014 10:20:29 +0200 Subject: [sles-beta] Kerberos packet with Error Message-ID: <6477817.OFS5e0gLqf@gjn.priv.at> Hello, I mean the kerberos packet have a "spec" Problem. After installing I have no "Path" to the Files -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From mrueckert at suse.de Fri Sep 12 08:36:13 2014 From: mrueckert at suse.de (Marcus =?UTF-8?B?UsO8Y2tlcnQ=?=) Date: Fri, 12 Sep 2014 16:36:13 +0200 Subject: [sles-beta] SLES12 x86_64 RC3 zypper problem: requires ruby(abi) = 2.1.0, but this requirement cannot be provided In-Reply-To: <1410530261.1791.13.camel@par-r81vxc7.par.novell.com> References: <40637DBB36AF3941B243A286A432CA0B0F9D6CC8@HXMB12.pnet.ch> <1410528965.1791.12.camel@par-r81vxc7.par.novell.com> <40637DBB36AF3941B243A286A432CA0B0F9D6D2D@HXMB12.pnet.ch> <1410530261.1791.13.camel@par-r81vxc7.par.novell.com> Message-ID: <20140912163613.32576d01@tengu.suse.de> On Fri, 12 Sep 2014 15:57:41 +0200 Frederic Crozat wrote: > Le vendredi 12 septembre 2014 ? 13:47 +0000, urs.frey at post.ch a > ?crit : > > Hello Frederic > > > > Thank you very much for your answer > > > > See the problem is, that I am really rebuilding on RC3 and still > > encountering problems > > Let me forward those information to our ruby specialist. > > > > > > freyu at h05cni:~/rpmbuild/SPECS> uname -a > > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 > > (aff039d) x86_64 x86_64 x86_64 GNU/Linux > > freyu at h05cni:~/rpmbuild/SPECS> rpmbuild -ba --clean > > rubygem-stomp.spec . . . freyu at h05cni:~/rpmbuild/SPECS> rpm -qp > > --requires ../RPMS/x86_64/pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby > > /usr/bin/ruby.ruby2.1 > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > ruby(abi) = ruby:2.1.0 > > rpmlib(PayloadIsLzma) <= 4.4.6-1 > > freyu at h05cni:~/rpmbuild/SPECS> > > > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a > > Linux h05cni 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 > > (aff039d) x86_64 x86_64 x86_64 GNU/Linux > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -ivh > > pst-rubygem-stomp-1.3.2-1.x86_64.rpm > > Preparing... > > ################################# [100%] Updating / installing... > > 1:pst-rubygem-stomp-1.3.2-1 > > ################################# [100%] > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # rpm -e pst-rubygem-stomp > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # uname -a Linux h05cni > > 3.12.28-2-default #1 SMP Mon Sep 8 11:15:37 UTC 2014 (aff039d) > > x86_64 x86_64 x86_64 GNU/Linux > > h05cni:/home/freyu/rpmbuild/RPMS/x86_64 # > > > > > > On my network install server, the package uploaded, made ready for > > use with zypper =========================================== > > v03g27:/appl/pstkits/pstaddon/SLES12_64/post/x86_64 # rpm -qp > > --requires pst-rubygem-stomp-1.3.2-1.x86_64.rpm /usr/bin/ruby > > /usr/bin/ruby.ruby2.1 > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > ruby(abi) = ruby:2.1.0 as you see here it generated the correct ruby(abi) requires. > > h05cni:~ # zypper in pst-rubygem-stomp could you copy over the file you just built above and try zypper in pst-rubygem-stomp-1.3.2-1.x86_64.rpm It looks like the package it tries to install from the repository has not been rebuilt yet. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org