Bug 865037 - Fedora 17 kernel doesn't boot after DVD upgrade from F16
Summary: Fedora 17 kernel doesn't boot after DVD upgrade from F16
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 17
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-10 16:46 UTC by sven.kieske
Modified: 2012-10-11 12:40 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-11 12:40:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description sven.kieske 2012-10-10 16:46:25 UTC
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 17:21:30 UTC
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 09:31:25 UTC
(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 10:14:46 UTC
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 12:40:51 UTC
(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.