December 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 906900] PostgreSQL improper shutdown
by bugzilla_noreply＠novell.com 04 Dec '14

04 Dec '14

http://bugzilla.suse.com/show_bug.cgi?id=906900 --- Comment #46 from Dr. Werner Fink <werner(a)suse.com> --- (In reply to Dr. Werner Fink from comment #45) Also with some more effort it would be possible to use an service unit with an @ symbol before then suffix .service to be able to use several stages of postgresql data base sevsers, simply by linking the postgresql@.service to e.g. postgresql(a)first.service Within the postgresql@.service then %i can be used to export the string between the "@" character and the suffix. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 908328] New: modules/Progress.rb:754 Progress bar has only 100 steps, not 101.
by bugzilla_noreply＠novell.com 04 Dec '14

04 Dec '14

http://bugzilla.opensuse.org/show_bug.cgi?id=908328 Bug ID: 908328 Summary: modules/Progress.rb:754 Progress bar has only 100 steps, not 101. Classification: openSUSE Product: openSUSE Factory Version: 201412* Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: mpluskal(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 615851 --> http://bugzilla.opensuse.org/attachment.cgi?id=615851&action=edit y2logs I have noticed following in yast logs: 2014-11-21 16:35:19 <1> antikristyna(13558) [Ruby] modules/PackageCallbacks.rb:2819 Process: Finished 2014-11-21 16:35:19 <1> antikristyna(13558) [Ruby] modules/PackageCallbacks.rb:2827 Close Wizard window: true, new stack: [] 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 Progress bar has only 100 steps, not 101. 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 ------------- Backtrace begin ------------- 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/Progress.rb:754:in `UpdateProgressBar' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/Progress.rb:811:in `NextStep' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/Progress.rb:820:in `NextStage' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/Progress.rb:953:in `Finish' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/PackageCallbacks.rb:2834:in `ProcessDone' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/fun_ref.rb:33:in `call' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/fun_ref.rb:33:in `call' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 (eval):3:in `call_yast_function' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 (eval):3:in `SourceStartManager' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/AutoinstSoftware.rb:989:in `ReadHelper' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/AutoinstSoftware.rb:1083:in `Read' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/clients/software_auto.rb:55:in `main' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/clients/software_auto.rb:274:in `<top (required)>' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/wfm.rb:184:in `eval' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/wfm.rb:184:in `run_client' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/wfm.rb:176:in `call_builtin' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/wfm.rb:176:in `call_builtin_wrapper' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/wfm.rb:169:in `CallFunction' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/Call.rb:45:in `Function' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/AutoinstClone.rb:109:in `CommonClone' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/AutoinstClone.rb:199:in `block in Process' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:97:in `call' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:97:in `block in foreach' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:96:in `each' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:96:in `foreach' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/AutoinstClone.rb:187:in `Process' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/include/autoinstall/dialogs.rb:250:in `cloneSystem' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/include/autoinstall/wizards.rb:25:in `block in AutoSequence' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:541:in `call' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/builtins.rb:541:in `eval' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/Sequencer.rb:268:in `WS_run' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/Sequencer.rb:340:in `Run' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/include/autoinstall/wizards.rb:66:in `AutoSequence' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/fun_ref.rb:33:in `call' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/fun_ref.rb:33:in `call' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/modules/CommandLine.rb:1591:in `Run' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/clients/autoyast.rb:103:in `main' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/share/YaST2/clients/autoyast.rb:149:in `<top (required)>' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/wfm.rb:184:in `eval' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 /usr/lib64/ruby/vendor_ruby/2.1.0/yast/wfm.rb:184:in `run_client' 2014-11-21 16:35:19 <3> antikristyna(13558) [Ruby] modules/Progress.rb:754 ------------- Backtrace end --------------- -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 811042] quota-nfs reports wrong limitations for very large filesystems ( 4TB )
by bugzilla_noreply＠novell.com 04 Dec '14

04 Dec '14

http://bugzilla.suse.com/show_bug.cgi?id=811042 Jan Kara <jack(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jack(a)suse.com --- Comment #2 from Jan Kara <jack(a)suse.com> --- This was a real bug in quota tools (or actually a limitation of RPC protocol if I remember right) but it was worked around upstream in June 2012 so recent distros should be fine. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 906900] PostgreSQL improper shutdown
by bugzilla_noreply＠novell.com 04 Dec '14

04 Dec '14

http://bugzilla.suse.com/show_bug.cgi?id=906900 --- Comment #45 from Dr. Werner Fink <werner(a)suse.com> --- (In reply to Bernhard Wiedemann from comment #43) The env tool does not switch the user, this would require a dirty hack binary without any pam support, don't know if this would be valid. Beside this: su has been changed to use pam and systemd will clean sessions at shutdown. A solution would be to remove any su or sudo from the postgresql boot script and move it to e.g. /usr/lib/postgresql/manager Then create a service unit with something like this [Service] Type=forking User=postgres PermissionsStartOnly=true EnvironmentFile=-/etc/sysconfig/postgresql ExecStartPre=/usr/bin/install -d -o postgres -g postgres -m 700 $POSTGRES_DATADIR ExecStart=/usr/lib/postgresql/manager start ExecStop=/usr/lib/postgresql/manager stop ExecReload=/usr/lib/postgresql/manager reload -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 908163] Start job for kernel modules stays forever on packaged 3.17.2, 3.17.4 (git is fine)
by bugzilla_noreply＠novell.com 04 Dec '14

04 Dec '14

http://bugzilla.suse.com/show_bug.cgi?id=908163 Thomas Blume <thomas.blume(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thomas.blume(a)suse.com --- Comment #8 from Thomas Blume <thomas.blume(a)suse.com> --- Seems that a crypt module triggers a kernel oops: -->-- [ 20.118036] systemd[442]: Executing: /usr/lib/systemd/systemd-modules-load [ 20.120079] BUG: unable to handle kernel paging request at ffffffffa001b000 [ 20.120084] IP: [<ffffffff812a3188>] register_key_type+0x48/0xb0 [ 20.120086] PGD 1e17067 PUD 1e18063 PMD bd6f3067 PTE 0 [ 20.120088] Oops: 0000 [#1] PREEMPT SMP [ 20.120096] Modules linked in: encrypted_keys(+) btrfs xor raid6_pq crc32c_intel sdhci_acpi sdhci xhci_hcd mmc_core video button sg trusted tpm [ 20.120099] CPU: 1 PID: 442 Comm: systemd-modules Not tainted 3.17.4-2.g2d23787-desktop #1 [ 20.120100] Hardware name: Dell Inc. XPS13 9333/0GFTRT, BIOS A02 12/11/2013 [ 20.120102] task: ffff8800377c6090 ti: ffff8802135ec000 task.ti: ffff8802135ec000 [ 20.120106] RIP: 0010:[<ffffffff812a3188>] [<ffffffff812a3188>] register_key_type+0x48/0xb0 [ 20.120107] RSP: 0018:ffff8802135efd10 EFLAGS: 00010202 [ 20.120108] RAX: ffff8800377c6090 RBX: ffffffffa001b000 RCX: 0000000000000000 [ 20.120109] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81e91a00 [ 20.120110] RBP: ffffffffa006115a R08: 000000000000ffff R09: ffff880037650ec0 [ 20.120111] R10: 0000000000000029 R11: 00000000000022cc R12: ffffffffa001b070 [ 20.120113] R13: ffffffffa0062000 R14: ffffffffa00620d0 R15: 0000000000000001 [ 20.120115] FS: 00007f7897799740(0000) GS:ffff88021f240000(0000) knlGS:0000000000000000 [ 20.120116] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 20.120117] CR2: ffffffffa001b000 CR3: 0000000213a8b000 CR4: 00000000001407e0 [ 20.120118] Stack: [ 20.120121] ffffffff81e1b020 ffff8802120d4340 0000000000000000 ffffffffa000b000 [ 20.120123] ffffffffa000b06f ffff8802920d4340 ffffffff81e1b020 ffffffff8100030c [ 20.120126] ffff88021f4ea000 ffffffffa00620d0 0000000000000001 0000000000000282 [ 20.120126] Call Trace: [ 20.120135] [<ffffffffa000b06f>] init_encrypted+0x6f/0x1000 [encrypted_keys] [ 20.120145] [<ffffffff8100030c>] do_one_initcall+0xcc/0x200 [ 20.120153] [<ffffffff810db4d2>] load_module+0x2372/0x2700 [ 20.120160] [<ffffffff810db9b5>] SYSC_finit_module+0x75/0xa0 [ 20.120165] [<ffffffff816354ad>] system_call_fastpath+0x1a/0x1f [ 20.120169] [<00007f7896eb8829>] 0x7f7896eb8829 [ 20.120183] Code: cf e8 be 00 49 81 fc 30 1a e9 81 49 8d 5c 24 90 74 42 49 8b 6d 00 eb 13 0f 1f 00 48 8b 43 70 48 3d 30 1a e9 81 48 8d 58 90 74 29 <48> 8b 3b 48 89 ee e8 2d 5b 08 00 85 c0 75 e1 bb ef ff ff ff 48 [ 20.120185] RIP [<ffffffff812a3188>] register_key_type+0x48/0xb0 [ 20.120186] RSP <ffff8802135efd10> [ 20.120186] CR2: ffffffffa001b000 [ 20.120188] ---[ end trace 35b66b44b468cfb4 ]--- --<-- -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 906990] Add "Boot Linux" to installation media
by bugzilla_noreply＠novell.com 04 Dec '14

04 Dec '14

http://bugzilla.suse.com/show_bug.cgi?id=906990 Jiri Srain <jsrain(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jsrain(a)suse.com) | --- Comment #5 from Jiri Srain <jsrain(a)suse.com> --- AFAIK Linuxrc does not load other boot loader - it just mounts the target system and chroots into it. This is something that I don't believe you can do from GRUB itself. Even adding such a section to boot menu may not be possible - if nothing else, the target root partition is different in every case and the other GRUB can be also installed in so many locations. Not to mention BIOS disk order, which could possibly prevent booting as well. If you have any more detailed idea how to implement such feature, I'm open to give it a try - but I'm rather pessimistic about it. The only thing that could possibly be done is a shortcut to Linuxrc's selection of root partition to boot. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 906900] PostgreSQL improper shutdown
by bugzilla_noreply＠novell.com 04 Dec '14

04 Dec '14

http://bugzilla.suse.com/show_bug.cgi?id=906900 Thomas Blume <thomas.blume(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(max(a)suse.com) --- Comment #44 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to Reinhard Max from comment #42) > All in all, if writing a unit file is the only way to get around the login > session problem of pam_unix, the way to go is probably to move just the user > switching from the init script to the unit file. IOW, the unit file would be > moved out of /etc/init.d and the su stuff would be removed from it, then the > unit file would take care of switching to the postgresql user and just call > the init script. Ok, this is also possible. (In reply to Bernhard Wiedemann from comment #43) > > is there a scriptable (I know it can be done in C) way to acchieve > > the side effects of "su -" without creating a new login session? > > If plain "su" and sudo do not do what you want, it can probably be done with > env (1) According to Werner, env wouldn't help. I will provide a service file that just runs the init script as postgres user. This, however, requires that all commands in the init script can run with the permissions of the postgres user. Reinhard, can you confirm this? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 903747] "Internal error" in kernel.rb during upgrade
by bugzilla_noreply＠novell.com 04 Dec '14

04 Dec '14

http://bugzilla.suse.com/show_bug.cgi?id=903747 Lukas Ocilka <locilka(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rrwidell(a)gmail.com --- Comment #21 from Lukas Ocilka <locilka(a)suse.com> --- *** Bug 908246 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 908246] 13.1 -> 13.2 upgrade, internal error during "Updating kernel module dependecies..."
by bugzilla_noreply＠novell.com 04 Dec '14

04 Dec '14

http://bugzilla.suse.com/show_bug.cgi?id=908246 Lukas Ocilka <locilka(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Lukas Ocilka <locilka(a)suse.com> --- Already reported, fix is in progress. Workaround is here: https://bugzilla.suse.com/show_bug.cgi?id=903747#c18 *** This bug has been marked as a duplicate of bug 903747 *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 905893] New: UMTS Broadband stick dosn't work on openSUSE 13.2
by bugzilla_noreply＠novell.com 04 Dec '14

04 Dec '14

http://bugzilla.opensuse.org/show_bug.cgi?id=905893 Bug ID: 905893 Summary: UMTS Broadband stick dosn't work on openSUSE 13.2 Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: 64bit OS: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: joachim(a)tantallon.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I use a UMTS stick (Huawei e160) to go online on the road. So far it worked flawlessly with openSUSE 12.3. After updating to openSUSE 13.2, it stopped working. It shows up in the Gnome network applet, but whatever I do, it can't be activated. -- You are receiving this mail because: You are on the CC list for the bug.

1 14