Bug 865037 - Fedora 17 kernel doesn't boot after DVD upgrade from F16
Fedora 17 kernel doesn't boot after DVD upgrade from F16
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
17
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-10 12:46 EDT by sven.kieske
Modified: 2012-10-11 08:40 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-11 08:40:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description sven.kieske 2012-10-10 12:46:25 EDT
Description of problem:
I cannot boot into any f17 kernel after upgrading via DVD.
After upgrade I had lot's of old fc16 packages still installed, which
didn't get upgraded, so I did upgrade them manually through yum upgrade.
I still got kernel 3.4.11-1.fc16.x86_64 installed which boots fine.
I also did an upgrade from grub to grub2, when the official dvd asked me if I want this.

when I boot any f17-kernel systemd shows the following:
everything "ok" until "mounted boot" and then:
Job nfs-idmap.service/start failed with result 'dependency'.

After this one I get:
"Timed out waiting for device[..]" and all lvm-volumes don't get mounted.
At first I suspected a problem related to an cifs-mount in my /etc/fstab
(when I had this mountpoint in fstab the anaconda-installer failed through dvd-upgrade, because it couldn't mount it).
but when I uncommented this one it didn't help, but I got a slightly different
error at boottime:
instead of nfs-idmap nfs-mountd.service failed, with the same result and the same reason (dependency).

How reproducible:
always
  
Actual results:
system fails to boot

Expected results:
system boots into fc17

Additional info:

Dependency configuration from systemd(not changed manually) from the fc16 kernel-based boot:

Servicedescription:
ID:nfs-idmap.service(running)
Description: NFSv4 ID-name mapping daemon
Dependencies: requires: basic.target(active),systemd-journal.socket(running)
conflicts:shutdown.target(dead)
required by:nfs-server.service(exited)
wanted by:multi-user.target(active)
after:basic.target(active),nfs-server.service(exited),systemd-journal.socket(running)

before:multi-user.target(active),shutdown.target(dead)
Fragmnet Path: /usr/lib/systemd/system/nfs-idmap.service
Control Group: name=systemd:/system/nfs-idmap.service

Is this correct(I couldn't find defaults or something on the web)?


Content of /usr/lib/systemd/system/nfs-idmap.service:

[Unit]
Description=NFSv4 ID-name mapping daemon
BindTo=nfs-server.service
After=nfs-server.service

[Service]
Type=forking
StandardError=syslog+console
EnvironmentFile=-/etc/sysconfig/nfs
ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS

[Install]
WantedBy=nfs.target



I'm not quite sure if this is a systemd bug at all.

If you need additional information, please let me know!
please also let me know how to get this information.
I'll provide it.

Thanks in advance

Sven Kieske
Comment 1 Michal Schmidt 2012-10-10 13:21:30 EDT
I suspect a problem with the initramfs for the F17 kernel. Verify that the installed 'dracut' package is a version from F17. Then regenerate the initramfs for the F17 kernel:
dracut -f /boot/initramfs-$VERSION.img $VERSION

If it still does not work, here are some tips on systemd debugging:
http://freedesktop.org/wiki/Software/systemd/Debugging
Comment 2 sven.kieske 2012-10-11 05:31:25 EDT
(In reply to comment #1)
> I suspect a problem with the initramfs for the F17 kernel. Verify that the
> installed 'dracut' package is a version from F17. Then regenerate the
> initramfs for the F17 kernel:
> dracut -f /boot/initramfs-$VERSION.img $VERSION
> 
> If it still does not work, here are some tips on systemd debugging:
> http://freedesktop.org/wiki/Software/systemd/Debugging

Thanks for your reply, here is what I have:

yum list installed | grep dracut
dracut.noarch                          018-98.git20120813.fc17   @updates

so dracut is clearly an F17 version.

but when I call:
dracut -f /boot/initramfs-3.5.6-1.fc17.x86_64.img 3.5.6-1.fc17.x68_64
(as root) I get:

find: `/lib/modules/3.5.6-1.fc17.x68_64/': No such file or directory
find: `/lib/modules/3.5.6-1.fc17.x68_64/': No such file or directory
find: `/lib/modules/3.5.6-1.fc17.x68_64/': No such file or directory
find: `/lib/modules/3.5.6-1.fc17.x68_64/': No such file or directory
find: `/lib/modules/3.5.6-1.fc17.x68_64/': No such file or directory
find: `/lib/modules/3.5.6-1.fc17.x68_64/': No such file or directory
find: `/lib/modules/3.5.6-1.fc17.x68_64/': No such file or directory

but when I do:
ll /lib/modules/
I get:
drwxr-xr-x. 3 root root 4096  7. Apr 2012  2.6.42.12-1.fc15.x86_64
drwxr-xr-x. 3 root root 4096  7. Apr 2012  2.6.42.9-2.fc15.x86_64
drwxr-xr-x. 6 root root 4096 25. Sep 18:47 3.4.11-1.fc16.x86_64
drwxr-xr-x. 3 root root 4096  8. Okt 12:07 3.5.4-1.fc17.x86_64
drwxr-xr-x. 3 root root 4096 10. Okt 11:25 3.5.4-2.fc17.x86_64
drwxr-xr-x. 6 root root 4096  8. Okt 12:07 3.5.5-2.fc17.x86_64
drwxr-xr-x. 6 root root 4096 10. Okt 11:25 3.5.6-1.fc17.x86_64

and for the directory 3.5.6-1.fc17.x86_64:
ll /lib/modules/3.5.6-1.fc17.x86_64/
insgesamt 2476
lrwxrwxrwx.  1 root root     36 10. Okt 11:25 build -> /usr/src/kernels/3.5.6-1.fc17.x86_64
drwxr-xr-x.  6 root root   4096 10. Okt 11:25 extra
drwxr-xr-x. 12 root root   4096 10. Okt 11:25 kernel
-rw-r--r--.  1 root root 642932 10. Okt 11:25 modules.alias
-rw-r--r--.  1 root root 630086 10. Okt 11:25 modules.alias.bin
-rw-r--r--.  1 root root   1659  7. Okt 21:49 modules.block
-rw-r--r--.  1 root root   6523  7. Okt 21:48 modules.builtin
-rw-r--r--.  1 root root   8682 10. Okt 11:25 modules.builtin.bin
-rw-r--r--.  1 root root 233277 10. Okt 11:25 modules.dep
-rw-r--r--.  1 root root 338901 10. Okt 11:25 modules.dep.bin
-rw-r--r--.  1 root root    274 10. Okt 11:25 modules.devname
-rw-r--r--.  1 root root     68  7. Okt 21:49 modules.drm
-rw-r--r--.  1 root root     53  7. Okt 21:49 modules.modesetting
-rw-r--r--.  1 root root   2301  7. Okt 21:49 modules.networking
-rw-r--r--.  1 root root  91035  7. Okt 21:48 modules.order
-rw-r--r--.  1 root root    131 10. Okt 11:25 modules.softdep
-rw-r--r--.  1 root root 232941 10. Okt 11:25 modules.symbols
-rw-r--r--.  1 root root 295150 10. Okt 11:25 modules.symbols.bin
lrwxrwxrwx.  1 root root      5 10. Okt 11:25 source -> build
drwxr-xr-x.  2 root root   4096  7. Okt 21:49 updates
drwxr-xr-x.  2 root root   4096 10. Okt 11:25 vdso


so the directory is there but dracut doesn't find it?
I will investigate further. Any help would be appreciated!
Comment 3 sven.kieske 2012-10-11 06:14:46 EDT
after the following the dracut -f ... worked and I could
start the fc17 kernel:

grub2-mkconfig -o /boot/grub2/grub.cfg
dracut -f /boot/initramfs-3.5.6-1.fc17.x86_64.img 3.5.6-1.fc17.x86_64
[root@CARZ141 ~]# uname -a
Linux CARZ141 3.5.6-1.fc17.x86_64 #1 SMP Sun Oct 7 19:31:14 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


Thanks for your help, again!
But I still don't know why this did happen, I followed the description in
the installation guide and upgraded with the dvd.

What I did forge to mention: it's the xfce-spin installed.

If you are interested in determining why this failed initially, please
contact me.
Comment 4 Michal Schmidt 2012-10-11 08:40:51 EDT
(In reply to comment #2)
> find: `/lib/modules/3.5.6-1.fc17.x68_64/': No such file or directory

It was a typo. x68 should be x86.

(In reply to comment #3)
> But I still don't know why this did happen, I followed the description in
> the installation guide and upgraded with the dvd.

I don't know either. I myself avoid the DVD upgrade method. The fact that the method does not consider the updates repository makes it particularly untrustworthy. Furthermore, I am distrustful of Anaconda. I upgrade my systems using yum. Some other Fedora developers will disagree with my opinions.

I am closing this bug, because it was not caused by systemd and I am not willing to investigate DVD upgrade breakage.

Note You need to log in before you can comment on or make changes to this bug.