( 14/165) Installing: kernel-desktop-3.11.1-29.1.g2fa222d ..............................................................[done]Additional rpm output:
Scanning scripts ...
Resolve dependencies ...
Install symlinks in /lib/mkinitrd/setup ...
Install symlinks in /lib/mkinitrd/boot ...
Kernel image: /boot/vmlinuz-3.11.1-29.g2fa222d-desktop
Initrd image: /boot/initrd-3.11.1-29.g2fa222d-desktop
KMS drivers: radeon
cp: cannot stat '/usr/lib/udev/rules.d/80-btrfs.rules': No such file or directory
Script /lib/mkinitrd/setup/11-btrfs.sh failed!
There was an error generating the initrd (1)
Updating that way seems to always uninstall the current kernel & install new, leaving no safety net. This is usually OK, but this time, when I reboot I am left only Memtest entry. I am leaving laptop in suspend after reimaging in the hope Someone knows a fix.
zypper dup should allow you to keep older kernels. Since Tumbleweed only has one kernel at a time, using --from Tumbleweed basically means the older kernel is obsolete as zypper resolves dependencies. You should be prompted if this is the case, and you can tell zypper to keep the obsolete kernel.
Also, your error is the same one I got. The thread is here:
Yes, it depends on the repos of course if that’s necessary or not.
But with “zypper dup --from Tumbleweed” you won’t get any updates from the openSUSE-Current-Update repo, so you should also run “zypper patch” or “zypper up” from time to time (and run “zypper dup --from Tumbleweed” afterwards, or some of your Tumbleweed packages will be switched back to the versions from openSUSE-Current-Update which may result in a broken system)
Wrong. “zypper dup --from” makes vendor changes just like “zypper dup”. But it only takes the specified repos into account, so won’t change packages only available in other repos.
Regarding that kernel thing, I don’t see why “zypper dup --from Tumbleweed” should behave differently there than “zypper dup”.
But it really does:
I just ran “zypper dup --from openSUSE-12.3” on my 12.3 system (of course I didn’t really let it run through, but said no at the confirmation request ), I got asked if I wanted to uninstall the 2 installed kernels (from repo-update) and install the one from 12.3 instead, or keep those “obsolete” ones.
So maybe this is a bug?
Regarding your repos:
You are missing “openSUSE_Current_non-OSS-Updates”: [noparse]http://download.opensuse.org/update/openSUSE-non-oss-current/[/noparse]
That’s needed to update the stuff from openSUSE_Current_non-OSS, flash-player f.e. If you don’t have anything installed from there, it’s not really necessary of course, but in that case you could (should?) remove openSUSE_Current_non-OSS as well.
For the others I can’t really say much atm, because you didn’t post the URLs. Please show the output of:
Repo 6 and 14 conflict with each other, I would disable 6 as it is not a
tumbleweed repo. Also 3 and 13 conflict, disable 13 as it as well is not
a tumbleweed repo.
Another failed to build properly, execute script, kernel error. I tried above command as sudo, but should be su - to work (**** my Ubuntu upbringing!) I forgot this & unfortunately rebooted. Trying above command under 12.3 Live USB fails & has no effect. I am left with only memtest boot option. Do I need to mount file system to refresh GRUB2? If so how? Could someone kindly drop the needed command?
linux:~ # grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found theme: /boot/grub2/themes/openSUSE/theme.txt
/usr/sbin/grub2-probe: error: cannot find a GRUB drive for /read-only/fsdata.ext4. Check your device.map.
Found linux image: /boot/vmlinuz-3.7.10-1.1-desktop
/usr/sbin/grub2-probe: error: cannot find a GRUB drive for /read-only/fsdata.ext4. Check your device.map.
Found memtest image: /boot/memtest.bin
/dev/sdc: open failed: No medium found
No volume groups found
Found openSUSE 12.3 (x86_64) on /dev/sda2
So apparently btrfsprogs was updated, and over wrote the change I made to /lib/mkinitrd/setup/11-btrfs.sh, throwing up the same error as before. :\
The “old” fix was to edit the file above by pointing it to 64-btrfs.rules. But that is obviously unstable, as a re-install or update to btrfsprogs will over write that file–my bad.
This adds a link to 64-btrfs.rules, so any script which calls 80-btrfs.rules will instead be pointed to 64-btrfs.rules. This is “better” than replacing the 80-btrfs.rules file or editing /lib/mkinitrd/setup/11-btrfs.sh in my opinion, because as 64-brtfs.rules is updated, so will the link be updated. And if 80-btrfs.rules ever returns, it will be over written.
All that has to happen is that the maintainer of btrfsprogs should change 11-btrfs.sh. I don’t know why that hasn’t happened yet. Maybe he is on vacation. :shame:
But IMHO this would not be the right way to solve this. That’s just a mess if the mkinitrd script is in one package (btrfsprogs), whereas the referenced udev rule is in a completely different package (udev) which also has a different maintainer.
So maybe the mkinitrd script should be moved to udev as well…
This is actually an interesting “philosophical” issue regarding packages. I can see why they would want to remove what is basically a redundant udev rule. In fact, the root cause of this issue, in my opinion, is that the maintainer of btrfsprogs did an incomplete change to the package–he removed the udev rules file but failed to change the script in the btrfsprogs package accordingly.
The mkinitrd scripts are, in my opinion, supplied by various kernel addons, so it seems correct to me that mkinitrd would read a folder heirarchy to see what modueles and addons need to be included in the virtual file system. For instance, suppose I want nothing to do with btrfs–I can remove it and not worry too much about btrfsprogs.
I am not a Linux expert by any means, so I may be wrong–but there are a lot of mkinitrd scripts called when we run mkinitrd, correct?
And FWIW, I upgraded the kernel today via zypper with no issues. lol!
), I got asked if I wanted to uninstall the 2 installed kernels (from repo-update) and install the one from 12.3 instead, or keep those “obsolete” ones.