September 2016 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 996088] After updates today (29/08/16) efibootmgr: Could not set BootOrder: No space left on device
by bugzilla_noreply＠novell.com 01 Sep '16

01 Sep '16

http://bugzilla.suse.com/show_bug.cgi?id=996088 http://bugzilla.suse.com/show_bug.cgi?id=996088#c6 Raymund Will <rw(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(stuart@stella-mar | |is.org.uk) --- Comment #6 from Raymund Will <rw(a)suse.com> --- Please refrain from UEFI/NVRAM experiments on self-paid hardware, it may well break... (does anybody remember Samsung laptops or intel motherboards?) Looking at the comments above, brings me to the following "remarks": 1. your system apparently has trouble with garbage collection in the NVRAM management. That "no space left on device" in fact refers to NVRAM, which "suffered" one addition of a variable (the refreshed boot entry #0000), followed by one replacement (BootOrder +1), plus one removal (the now obsolete old boot entry #0003) and then another replacement (BootOrder -1) during that grub2-update. Obviously the last step failed. 2. This state persists until after a reset/reboot. UEFI garbage-collection is performed and write operations can succeed again -- unless a buggy firmware and careless OS/apps conspire and leave less free NVRAM available than necessary, in which case all NVRAM write operations fail (even vital ones by UEFI itself). Usually an external programmer and firmware+ documentation unavailable to mere mortals) is needed to revive such a motherboard. (IIRC linux has patches to not touch the last 5% (or was it 10%) of NVRAM for exactly that reason.) 3. I'm convinced that "booting from file" (or via EFI shell) and running that 'efibootmgr -o 0000,0001,0002' from the initial comment would have restored the system, without ever touching TW rescue. 4. Can you tell how much NVRAM is in your system, and how much of that is occupied? Is there anything eating up precious space? I've seen issues like yours only on systems used for heavy testing with lots and lots of boot entries, or back then when that UEFI pstore-backend was active, or on buggy firmware (even from "big players")... 5. If you encounter the same issue again, e.g. after another grub2-update, could you please try remark 3 -- if that would fail, while efibootmgr from TW rescue succeeds... but you actually did not *run* efibootmgr from TW rescue, did you? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 996753] Qt development package is missing
by bugzilla_noreply＠novell.com 01 Sep '16

01 Sep '16

http://bugzilla.suse.com/show_bug.cgi?id=996753 http://bugzilla.suse.com/show_bug.cgi?id=996753#c3 --- Comment #3 from Stefan Brüns <stefan.bruens(a)rwth-aachen.de> --- Note: Since kernel version 4.4, both Qt4 and Qt5 will work: http://lkml.iu.edu/hypermail/linux/kernel/1511.1/01884.html -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 995769] UEFI + MBR = Dataloss
by bugzilla_noreply＠novell.com 01 Sep '16

01 Sep '16

http://bugzilla.suse.com/show_bug.cgi?id=995769 http://bugzilla.suse.com/show_bug.cgi?id=995769#c7 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|yast2-maintainers(a)suse.de |yast-community(a)opensuse.org --- Comment #7 from Stefan Hundhammer <shundhammer(a)suse.com> --- That said, maybe some community members might want to pick up this idea. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 995769] UEFI + MBR = Dataloss
by bugzilla_noreply＠novell.com 01 Sep '16

01 Sep '16

http://bugzilla.suse.com/show_bug.cgi?id=995769 http://bugzilla.suse.com/show_bug.cgi?id=995769#c6 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(shundhammer@suse. | |com) | --- Comment #6 from Stefan Hundhammer <shundhammer(a)suse.com> --- We do not require a GPT disk label. You can still install with a legacy MS-DOS style partition table. The YaST expert partitioner also supports creating a new disk label (GPT or MS-DOS style), but only with deleting all previous disk content. It is not trivial (much less guaranteed to work in every case) to do such a conversion in a lossless way. We also use GNU parted as our primary partitioning tool because of better availability on and compatibility with all target platforms (which includes IBM S/390 mainframes as well as embedded ARM systems etc.). If you need to do such a conversion, I suggest to boot a live medium and do that conversion from there. This is not such a common task that it warrants inclusion in a generic tool like the YaST partitioner IMHO. Also, there is a huge potential for damage and data loss that we would be held responsible for if we offered such a feature. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 996520] apparmor: please convert /etc/rc.d/boot.apparmor into a systemd native unit file
by bugzilla_noreply＠novell.com 01 Sep '16

01 Sep '16

http://bugzilla.opensuse.org/show_bug.cgi?id=996520 http://bugzilla.opensuse.org/show_bug.cgi?id=996520#c4 --- Comment #4 from Franck Bui <fbui(a)suse.com> --- (In reply to Christian Boltz from comment #3) > The biggest problem is the "systemctl restart" behaviour as described in bug > 853019. The only serious fix for that would be to add support for > ExecRestart= in systemd. Maybe the rework of a proper AppArmor integration in systemd mentioned here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796589#51, will address your concern ? Meanwhile the debian folks came up with a wrapper unit that I was initially asking for. Couldn't we do the same ? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 995782] Editing "proposal settings" doesn't recalculate size of / partition
by bugzilla_noreply＠novell.com 01 Sep '16

01 Sep '16

http://bugzilla.suse.com/show_bug.cgi?id=995782 http://bugzilla.suse.com/show_bug.cgi?id=995782#c3 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID Flags|needinfo?(shundhammer@suse. | |com) | --- Comment #3 from Stefan Hundhammer <shundhammer(a)suse.com> --- This is intentional. There is a maximum size for the root partition that can be set in a product's control.xml file. For example, this is the relevant section of that file for SLES-12 SP2 (Leap 42.1 might be somewhat different, but certainly similar): <partitioning> <try_separate_home config:type="boolean">true</try_separate_home> <limit_try_home>5GB</limit_try_home> <root_space_percent>40</root_space_percent> <root_base_size>3GB</root_base_size> <root_max_size>10GB</root_max_size> <proposal_lvm config:type="boolean">false</proposal_lvm> <vm_desired_size>15GB</vm_desired_size> <vm_home_max_size>25GB</vm_home_max_size> <btrfs_increase_percentage config:type="integer">300</btrfs_increase_percentage>  <btrfs_default_subvolume>@</btrfs_default_subvolume> </partitioning> Those parameters interact with each other, and some are treated differently for example if the root file system is Btrfs (in this example there is a 300% increase in that case to make room for Btrfs snapshots). The general idea behind holding back free space in case of an LVM installation is to have some spare disk space for additional LVM physical volumes that can be used for additional LVM volume groups. I am not the one to decide if this is a good or a bad idea, but that was requested as a feature by product management a long time ago. And it's configurable per product via this control.xml file. Bottom line: This is the intended behaviour. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 996861] New: 42.2b1,kontact not staying in systray when closing it
by bugzilla_noreply＠novell.com 01 Sep '16

01 Sep '16

http://bugzilla.opensuse.org/show_bug.cgi?id=996861 Bug ID: 996861 Summary: 42.2b1,kontact not staying in systray when closing it Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: epistemepromeneur(a)free.fr QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- if you close kontact by clicking "x" then it quites instead of staying in systray for example akregator icon in systray disappears. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 986891] nvme-cli: "nvme list" returns error "nvme0 failed to map"
by bugzilla_noreply＠novell.com 01 Sep '16

01 Sep '16

http://bugzilla.suse.com/show_bug.cgi?id=986891 http://bugzilla.suse.com/show_bug.cgi?id=986891#c6 Johannes Thumshirn <jthumshirn(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #6 from Johannes Thumshirn <jthumshirn(a)suse.com> --- Submitted as SR#424189 Setting Bug to RESOLVED FIXED. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 995769] UEFI + MBR = Dataloss
by bugzilla_noreply＠novell.com 01 Sep '16

01 Sep '16

http://bugzilla.suse.com/show_bug.cgi?id=995769 http://bugzilla.suse.com/show_bug.cgi?id=995769#c5 --- Comment #5 from Stefan Hundhammer <shundhammer(a)suse.com> --- This is clearly not a critical bug. It is a feature request, thus an enhancement. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 995769] UEFI + MBR = Dataloss
by bugzilla_noreply＠novell.com 01 Sep '16

01 Sep '16

http://bugzilla.suse.com/show_bug.cgi?id=995769 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Critical |Enhancement -- You are receiving this mail because: You are on the CC list for the bug.

1 0