Bug 497398

 Why is this yum's fault?

it's probably mkinitrd, actually.

(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.

(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!

> 
> 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]#

(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 ?

> >  [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.

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 ***

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.

(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 <cjb>) 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.

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.

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.

>  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-2.6.29.2-126.fc11.x86_64.fth or even ofw-2.6.29.2-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.

While running kernel 2.6.29.2-126 on my XO, I did 'yum upgrade'.  That caused an additional kernel (2.6.29.2-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.

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

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.

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.

It's always been like this with OLPC OS, see http://wiki.laptop.org/go/Kernel

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?

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

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.

(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?

> 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.

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.

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

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

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.

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.