Bugzilla – Bug 619283
no update of grub menu.lst
Last modified: 2016-04-15 11:58:02 UTC
I run "chroot /11.3 zypper dup" on an 11.2 partition mounted to /11.3 to update to 11.3-factory (/proc /sys /dev/ are bind-mounted into /11.3). at the end I checked /boot/grub/menu.lst and noticed that the update did not touchj the menu.lst at all, but the new kernel got installed: -rw------- 1 root root 2776 Nov 13 2009 /boot/grub/menu.lst # df / /boot/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/dm-6 30963708 25049864 4341044 86% / /dev/sda7 5170664 405776 4502228 9% /boot # rpm -qa kernel\* | grep 34| sort kernel-debug-base-2.6.34-12.1.x86_64 kernel-debug-devel-2.6.34-12.1.x86_64 kernel-default-2.6.34-12.1.x86_64 kernel-default-base-2.6.34-12.1.x86_64 kernel-default-devel-2.6.34-12.1.x86_64 kernel-desktop-2.6.34-12.1.x86_64 kernel-desktop-devel-2.6.34-12.1.x86_64 kernel-devel-2.6.34-12.1.noarch kernel-source-2.6.34-12.1.noarch kernel-syms-2.6.34-12.1.x86_64 kernel-xen-2.6.34-12.1.x86_64 kernel-xen-devel-2.6.34-12.1.x86_64 any idea why menu.lst did not get updated ?! the initrds have been created correctly (but I did not test if 11.3 really boots so far). any other information needed ?
Please, attach /var/log/YaST2/perl-BL-standalone-log, and, if possible, also original /boot/grub/menu.lst
Created attachment 373475 [details] perl-BL-standalone-log
Created attachment 373476 [details] menu.lst
kay - pbl reports me, that dm device doesn't ahve defined attribute DM_NAME ( no /dev/dm-* has such variable). I use this variable to convert dev/dm-* to /dev/mapper/*. Do you change it for factory?
These are properties managed by device-mapper rules. Plain udev has not changed regarding these.
there is another instance of such problem in RC2 - bug 619569
(In reply to comment #5) > These are properties managed by device-mapper rules. Plain udev has not changed > regarding these. device-mapper saves related info in /dev/.udev/db, while boot.udev does: # start without database from initramfs rm -rf /dev/.udev This breaks every device mapper device initialized in initrd. Is there any reason we have to do "rm -rf /dev/.udev" there ?
It was done this way to support new userspace packages with old initramfs images, or the other way around. If we don't delete the database of a possible different udev version, things can go wrong in weird ways. We can remove this, if we decide not to care about such scenarios.
(In reply to comment #8) > It was done this way to support new userspace packages with old initramfs > images, or the other way around. > > If we don't delete the database of a possible different udev version, things > can go wrong in weird ways. We can remove this, if we decide not to care about > such scenarios. Device mapper currently depends on the fact that "IMPORT{db}" can work continuously. "rm -rf" causes issues when root file-system and SWAP on device-mapper devices. Kay, Do you think this is a decision you can make. Or should I NEEDINFO from someone else ? Thanks.
(In reply to comment #9) > Do you think this is a decision you can make. Or should I NEEDINFO from > someone else ? I guess we should just remove the 'rm' line. I don't see how to get device-mapper working otherwise. The only thing that will be a requirement after this, is that the version of the tools in the initramfs image and the rootfs must match. And this is usually the case. In case you update the corresponding dm/LVM packages and udev is in your way, feel free to remove the line from the udev package at the same time. Otherwise let me know. Thanks.
*** Bug 619569 has been marked as a duplicate of this bug. ***
Forget to close this as fixed.
This is an autogenerated message for OBS integration: This bug (619283) was mentioned in https://build.opensuse.org/request/show/42477 Factory / udev https://build.opensuse.org/request/show/42621 11.3 / udev