http://bugzilla.opensuse.org/show_bug.cgi?id=1094430 http://bugzilla.opensuse.org/show_bug.cgi?id=1094430#c7 Tony Mechelynck changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(antoine.mechelync | |k@gmail.com) | --- Comment #7 from Tony Mechelynck --- I'll add at the bottom of this comment the output of a little bash script I wrote some years ago, showing how disk, swap and RAM memory is used. Of course, memory use (as opposed to installed memory) is volatile and will vary with time. I run yast (or anything else, except zypper dup about once a year) concurrently with SeaMonkey, whose memory use slowly but surely goes upwards with time: GNOME System Monitor reports memory use as 20% right after boot before SeaMonkey is started, 40% immediately after loading it, and up to 80% or more until SeaMonkey itself becomes noticeably sluggish and has to be restarted, so "out of memory" is definitely a possibility. I didn't expect setting the boot default kernel to be a really memory extensive operation, and I didn't take any special precautions to protect YaST from any memory-hungry processes. (I have more than 600 tabs open in SeaMonkey, but most of them aren't loaded since I have set browser.sessionstore.max_concurrent_tabs to zero in about:config, which means that on restart, tabs will not load until or unless I access them.) Yesterday I ran zypper --releasever 15.0 ref zypper --releasever 15.0 dup at runlevel 3 (i.e. without X11) then immediately after reboot (by mistake I rebooted into kernel 4.12.14-lp150.12.4-debug instead of the corresponding default kernel) and after starting X11 I used the YaST GUI to set the new kernel 4.12.14-lp150.12.4-default as the new boot default, without running again into this problem (which, in the light of comment #6, is understandable since there were gobs of memory available at that point in time). Mon 28 May 13:06:36 CEST 2018 Filesystem Size Used Avail Use% Mounted on sysfs 0 0 0 - /sys proc 0 0 0 - /proc devtmpfs 3.9G 0 3.9G 0% /dev securityfs 0 0 0 - /sys/kernel/security tmpfs 3.9G 184K 3.9G 1% /dev/shm devpts 0 0 0 - /dev/pts tmpfs 3.9G 1.6M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup cgroup 0 0 0 - /sys/fs/cgroup/unified cgroup 0 0 0 - /sys/fs/cgroup/systemd pstore 0 0 0 - /sys/fs/pstore cgroup 0 0 0 - /sys/fs/cgroup/pids cgroup 0 0 0 - /sys/fs/cgroup/rdma cgroup 0 0 0 - /sys/fs/cgroup/cpu,cpuacct cgroup 0 0 0 - /sys/fs/cgroup/net_cls,net_prio cgroup 0 0 0 - /sys/fs/cgroup/perf_event cgroup 0 0 0 - /sys/fs/cgroup/hugetlb cgroup 0 0 0 - /sys/fs/cgroup/devices cgroup 0 0 0 - /sys/fs/cgroup/memory cgroup 0 0 0 - /sys/fs/cgroup/cpuset cgroup 0 0 0 - /sys/fs/cgroup/freezer cgroup 0 0 0 - /sys/fs/cgroup/blkio /dev/sda7 92G 76G 16G 84% / systemd-1 0 0 0 - /proc/sys/fs/binfmt_misc hugetlbfs 0 0 0 - /dev/hugepages mqueue 0 0 0 - /dev/mqueue debugfs 0 0 0 - /sys/kernel/debug /dev/sda5 20G 8.2G 11G 45% /boot /dev/sdb2 3.7G 96M 3.4G 3% /mnt/sdb1 tmpfs 785M 24K 785M 1% /run/user/0 gvfsd-fuse 0 0 0 - /run/user/0/gvfs fusectl 0 0 0 - /sys/fs/fuse/connections tracefs 0 0 0 - /sys/kernel/debug/tracing NAME TYPE SIZE USED PRIO /swapfile file 12G 0B 7 /dev/sdb1 partition 3.7G 0B 5 /dev/sda6 partition 16G 0B 10 total used free shared buff/cache available Mem: 7.7G 3.5G 286M 191M 3.8G 3.6G Swap: 31G 0B 31G -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1094430 http://bugzilla.opensuse.org/show_bug.cgi?id=1094430#c9 Tony Mechelynck changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED --- Comment #9 from Tony Mechelynck --- (In reply to Josef Reidinger from comment #8)

OK, so I worry there is not much we can do in advance. Especially when it fails not in yast2 itself but in grub2 mkconfig script, probably together with os-prober that probing windows partition. So sorry, we cannot do much to avoid this situation (and quessing how much free memory we will need in advance is hard job due to many other dependencies). Closing as won't fix.

OK. Next time I'll make sure memory isn't "almost full" when I change the default kernel (and probably at other times too). I think WONTFIX is the only thing to do, considering what you found out. -- You are receiving this mail because: You are on the CC list for the bug.