Red Hat Bugzilla – Full Text Bug Listing
|Summary:||openfirmware .fth file not updated when new kernel installed.|
|Product:||[Fedora] Fedora||Reporter:||Mikus Grinbergs <mikus>|
|Component:||dracut-modules-olpc||Assignee:||Daniel Drake <dsd>|
|Status:||CLOSED EOL||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||19||CC:||bruno, chris, dan, dsd, ffesti, harald, hdegoede, itamar, james.antill, jonathan, kernel-maint, martin, pbrobinson, pjones, pmatilai, sascha-web-bugzilla.redhat.com, tla, wtogami|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-02-18 06:58:57 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Mikus Grinbergs 2009-04-23 14:35:19 EDT
Description of problem: Was running recent fedora-xo image on an XO-1 system. Did 'yum update kernel'. The new kernel was downloaded to my XO and installed -- but when I rebooted that XO, what was being run was still the original kernel from the fedora-xo image. Version-Release number of selected component (if applicable): yum-3.2.22-4.fc11.noarch How reproducible: Always. Steps to Reproduce: 1. Install recent fedora-xo image onto XO-1 system (using 'copy-nand'). 2. Wait until a newer version of 'kernel' is available in the rawhide repositories 3. Do 'uname -r' and note the (multidigit) kernel release number 4. Do 'yum upgrade kernel' and note the new kernel release number 5. Reboot, and do 'uname -r'. See which kernel release is running Actual results: The kernel release from the original install is running. Expected results: The newly installed kernel would be running. Additional info: The problem arises because on the XO, neither 'grub' nor the files (nor symbolic links) in /boot determine which kernel version is booted. [The XO does not use a conventional BIOS.] Instead, it is the content of the file /boot/olpc.fth that specifies which kernel version is booted. When I do 'yum update kernel', that file's content does not get updated.
Comment 1 James Antill 2009-04-23 14:49:54 EDT
Why is this yum's fault?
Comment 2 seth vidal 2009-04-23 14:56:43 EDT
it's probably mkinitrd, actually.
Comment 3 Mikus Grinbergs 2009-04-24 01:11:35 EDT
(In reply to comment #1) > Why is this yum's fault? Bugzilla requires the user to choose a component. I did not know which component was "at fault" - but since I entered ' yum ' at the command line, and since I did not see the results I had expected from my running of ' yum ' - I thought entering the name of the command I ran would be adequate. By the way - I forgot in my problem description to mention that an output line from running ' yum update kernel ' on my XO was: "WARNING: /dev/root is a not a block device, skipping" ---- I don't know if 'mkinitrd' is the correct component, either - as far as I could tell, 'mkinitrd' did everything it was supposed to do. I suspect that code needs to be added to the XO kernel update process for modifying file /boot/olpc.fth. If this were the case, I don't know which "component" would be the one to which such XO-specific code should be added.
Comment 4 Hans de Goede 2009-04-24 03:00:08 EDT
(In reply to comment #3) > from running ' yum update kernel ' on my XO was: "WARNING: /dev/root is a not > a block device, skipping" > mkinitrd is at fault, this is a message from mkinitrd: WARNING: /dev/root is a not a block device, skipping And its bad news, can you attach /etc/fstab please and the output of the following commands: ls -l /dev/root ls -lR /sys/block Please? Thank you!
Comment 5 Mikus Grinbergs 2009-04-24 11:08:47 EDT
> > mkinitrd is at fault, this is a message from mkinitrd: > WARNING: /dev/root is a not a block device, skipping > > And its bad news, can you attach /etc/fstab please and the output > of the following commands: > ls -l /dev/root > ls -lR /sys/block > This is /etc/fstab : /dev/root / ext3 defaults,noatime 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 /dev/mmcblk0p1 /media/fcd86b35-246a-4cfc-8765-bc156179e9be ext2 defaults,noatime 0 0 Note: the last line was added manually to cause the XO to "pre-mount" an SD card. ---- [root@localhost liveuser]# ls -l /dev/root ls: cannot access /dev/root: No such file or directory [root@localhost liveuser]# ---- [root@localhost liveuser]# ls -lR /sys/block /sys/block: total 0 lrwxrwxrwx 1 root root 0 Apr 24 01:09 loop0 -> ../devices/virtual/block/loop0 < mikus: seven similar lines for loop1 - loop7 > lrwxrwxrwx 1 root root 0 Apr 24 01:09 mmcblk0 -> ../devices/pci0000:00/0000:00:0c.1/mmc_host/mmc0/mmc0:0007/block/mmcblk0 lrwxrwxrwx 1 root root 0 Apr 24 01:09 ram0 -> ../devices/virtual/block/ram0 < mikus: fifteen similar lines for ram1 - ram15 > [root@localhost liveuser]#
Comment 6 Hans de Goede 2009-04-24 11:20:22 EDT
(In reply to comment #5) > > > > mkinitrd is at fault, this is a message from mkinitrd: > > WARNING: /dev/root is a not a block device, skipping > > > > And its bad news, can you attach /etc/fstab please and the output > > of the following commands: > > ls -l /dev/root > > ls -lR /sys/block > > > > > This is /etc/fstab : > > /dev/root / ext3 defaults,noatime 0 0 <snip> > [root@localhost liveuser]# ls -l /dev/root Well that explains it all then, someone or something has specified a non existing device for / in fstab, no wonder mkinitrd cannot find it, not mkinitrd's fault. How did you end up with that in fstab ?
Comment 7 Peter Robinson 2009-04-24 14:22:46 EDT
> > [root@localhost liveuser]# ls -l /dev/root > > > Well that explains it all then, someone or something has specified a > non existing device for / in fstab, no wonder mkinitrd cannot find it, > not mkinitrd's fault. How did you end up with that in fstab ? I think the livecd image has /dev/root in the fstab even though / is actually mounted as something else. That aside it seems that mkinitrd doesn't update the openfirmware ofw file if it exists (or possibly create it if it doesn't). I know jkatz has added this functionality to the livecd tools so it shouldn't be too hard to add the functionality to mkinitrd.
Comment 8 Jeremy Katz 2009-05-06 12:57:22 EDT
If you're just using a live image and booting that (even off of NAND), then kernel updates aren't handled in terms of updating because we instead set up the live image to be easily installable. But the jffs2 nand of olpc isn't supported to install to by anaconda. *** This bug has been marked as a duplicate of bug 446935 ***
Comment 9 Mikus Grinbergs 2009-05-06 15:08:18 EDT
I'm unfamiliar with the conventions used on bugzilla.redhat (I'm just an user, not a developer). How do I __re-open__ bug #497398 ? ---- Bug 446935 describes 'syslinux' not finding the correct thing after a yum update of a liveusb image. To the best of my knowledge, the system I booted does not need to have 'syslinux' on the device being booted from. [The NAND on an XO serves the same function as a hard disk partition does on a desktop system. The difference is that a desktop system would normally have a BIOS (I believe that BIOS would eventually invoke syslinux), whereas the XO uses OFW in place of a BIOS (plus XO does not use grub) - and in the case I wrote #497398 about, the XO OFW looks in /boot/olpc.fth for instructions of what (kernel) to load.] The problem I attempted to document was that having run yum update on an XO, mkinitrd (or whatever) did not adequately communicate to the XO OFW that there was a new kernel to be loaded. To emphasize: I am not booting a "liveusb image". [Once the thing called a rawhide-xo "image" has been copied onto NAND (the XO equivalent of hard disk), NAND contains the same kind of files (e.g., in /boot, in /usr, and so forth) as are on hard disk after a regular Linux install. To my mind, this is an installed "Linux system" that I am booting.] [And the 'yum update' that I did was of that installed "rawhide system", not of a "liveusb image".] I am concerned that if the bug I wrote is closed as a duplicate of a bug that concerns the booting of "liveusb images", what I've written in bug #497398 will be forgotten.
Comment 10 Mikus Grinbergs 2009-05-06 15:13:48 EDT
(In reply to comment #6) > > [root@localhost liveuser]# ls -l /dev/root > > ls: cannot access /dev/root: No such file or directory > > Well that explains it all then, someone or something has specified a > non existing device for / in fstab, no wonder mkinitrd cannot find it, > not mkinitrd's fault. How did you end up with that in fstab ? My understanding of the way development for what is called the fedora-xo project is done is that someone working with the XO (e.g., Chris Ball <firstname.lastname@example.org>) prepares an "installed" image (e.g., build) from the Rawhide (plus XO-specific) repositories, for people to test with. I just booted that "installed" image - whatever was there, that is what I have on my system. Peter Robinson (see comment #7) is someone involved in the upstreaming into Rawhide of software to support the XO hardware.
Comment 11 Peter Robinson 2009-05-06 19:50:16 EDT
jkatz: From my testing I think the major part of this is that mkinitrd doesn't create/update the /boot/olpc.fth file when a new kernel is installed like it does the grub.conf but also with my testing mkinitrd doesn't support mmc_block as a block devices which is possibly also covered by bug 461884. I think you added the support for livecd-creator for the .fth file creation so I'm not sure how hard it is to add that to mkinitrd as well. The support for mmc_block is probably a separate bug.
Comment 12 Jeremy Katz 2009-05-06 21:43:51 EDT
Whoops, the impression I had was that the copy-nand image was still a "live" image, just being copied to the jffs2 and run off of there. In which case, the bug is mostly the same. Adding support for updating the fth file is ... not necessarily hard, but not trivial. It's mostly a matter of adding a whole new type of bootloader to grubby (it supports a lot already). The hardest thing is going to be that the olpc.fth as it stands only supports booting one kernel afaik and no fallback or menu'ing. Which means it doesn't really match the standard way the rest of Fedora works.
Comment 13 Peter Robinson 2009-05-10 08:27:05 EDT
> The hardest thing is going to be that the > olpc.fth as it stands only supports booting one kernel afaik and no fallback or > menu'ing. Which means it doesn't really match the standard way the rest of > Fedora works. Would it be possible to build a .fth file per kernel (olpc-220.127.116.11-126.fc11.x86_64.fth or even ofw-18.104.22.168-126.fc11.x86_64.fth) and then symlink (hard or soft) to the latest one. If it fails to boot you can then from the ofw ok prompt do a "dir sd:\boot" to at least see what other kernels are available to boot. Not sure the .fth file should necessarily be olpc.fth as its conceivable that openfirmware can be used by other systems, with the XO 1.5 using a more mainline via platform with OFW this will be possibly more likely.
Comment 14 Mikus Grinbergs 2009-05-13 18:30:39 EDT
While running kernel 22.214.171.124-126 on my XO, I did 'yum upgrade'. That caused an additional kernel (126.96.36.199-140) to be placed on my system. [The bug #497398 problem is still there.] Looking afterward at /boot, I noticed that the original initrd file (created when the "installation image" for ~cjb/rawhide-so 20090512 was built) for the -126 kernel had a size of 4.7 MB, whereas the newly placed initrd file (created by mkinitrd? when called by yum) for the -140 kernel had a size of 2.7 MB.
Comment 15 Bug Zapper 2009-06-09 10:28:41 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Hans de Goede 2010-01-12 10:31:11 EST
This is a mass edit of all mkinitrd bugs. Thanks for taking the time to file this bug report (and/or commenting on it). As you may have heard in Fedora 12 mkinitrd has been replaced by dracut. In Fedora 12 the mkinitrd package is still around as some programs depend on certain libraries it provides, but mkinitrd itself is no longer used. In Fedora 13 mkinitrd will be removed completely. This means that all work on initrd has stopped. Rather then keeping mkinitrd bugs open and giving false hope they might get fixed we are mass closing them, so as to clearly communicate that no more work will be done on mkinitrd. We apologize for any inconvenience this may cause. If you are using Fedora 11 and are experiencing a mkinitrd bug you cannot work around, please upgrade to Fedora 12. If you experience problems with the initrd in Fedora 12, please file a bug against dracut.
Comment 17 Peter Robinson 2010-01-13 05:11:18 EST
Reopening as this bug is still valid with dracut (not sure if that's the best component). Also updating the description to better describe the issue.
Comment 18 Daniel Drake 2010-01-13 20:33:36 EST
It's always been like this with OLPC OS, see http://wiki.laptop.org/go/Kernel
Comment 19 Martin Dengler 2010-01-13 22:17:40 EST
I thought OLPC's kernel rpm updated the /boot/vmlinuz, etc. symlinks that /boot/olpc.fth expected? http://dev.laptop.org/git/olpc-2.6/tree/olpc/SPECS/olpc-2.6.spec?h=olpc-2.6.30&id=7815f5ffa0754069aa92bb87968b5be3615658dd#n857 http://dev.laptop.org/git/olpc-2.6/tree/olpc/SPECS/kernel-xo1.spec?h=olpc-2.6.30#n861 Perhaps it's a FedoraXO problem - either /boot/olpc.fth isn't in sync with OLPC's kernels setup of /boot/vmlinuz, etc. symlinks , or /boot/olpc.fth could be modified to boot the latest kernel/initramfs in /boot (as mikus suggested). I'm not sure why this is closed/notbug. Kernel updates should work from yum/rpm, right?
Comment 20 Martin Dengler 2010-01-13 22:20:34 EST
I had a real cheesy way to update olpc.fth that I thought might work, but I never tested it...might get someone annoyed enough to do it right though: http://git.sugarlabs.org/projects/soas/repos/mainline/blobs/blueberry/soas-base.ks#line217
Comment 21 Daniel Drake 2010-01-13 22:45:41 EST
Not without following the instructions on that page. Judging from the description this bug is not about olpc.fth, it's about the new kernel not being booted. But anyway, olpc.fth is static and does not need to be updated for OLPC OS. Not that OLPC OS bugs should be filed here, nor should bugs for OLPCs kernel, so it's all a bit confusing.
Comment 22 Martin Dengler 2010-01-13 23:19:22 EST
(In reply to comment #21) > Not without following the instructions on that page. That web page is more out of date than I am. It says "The 'kernel-' RPMs contains all you need to boot into that new kernel; simply install it, reboot, and you're set" and doesn't say "you can't just use yum as normal". I guess I should fix it but I'm not sure what the right fix is, sorry. > Judging from the description this bug is not about olpc.fth, it's about the new > kernel not being booted. I was mistaken to assume that olpc.fth was responsible for telling OFW what kernel to boot, I guess. What's responsible for booting the new kernel? > Not that OLPC OS bugs should be filed here, nor should > bugs for OLPCs kernel, so it's all a bit confusing. Should mikus be asked to move the bug to dev.laptop.org?
Comment 23 Peter Robinson 2010-01-14 03:18:20 EST
> Judging from the description this bug is not about olpc.fth, it's about the new > kernel not being booted. But anyway, olpc.fth is static and does not need to be > updated for OLPC OS. Not that OLPC OS bugs should be filed here, nor should > bugs for OLPCs kernel, so it's all a bit confusing. Its got nothing to do with OLPC-OS. Its about running native Fedora on the XO hardware. So this bug is still relevant because when the fedora kernel upgraded it still doesn't update the olpc.fth and hence the new kernel is not booted by default as expected in Fedora.
Comment 24 Daniel Drake 2010-01-14 07:45:07 EST
OK, but perhaps this bug should really be "olpc.fth should be supported by Fedora" - I don't think anything in Fedora provides or generates it in the first place.
Comment 25 Bug Zapper 2010-03-15 08:33:28 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Fedora End Of Life 2013-04-03 16:02:37 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 27 Fedora End Of Life 2015-01-09 16:39:21 EST
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Comment 28 Fedora End Of Life 2015-02-18 06:58:57 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.