Hello, I downloaded the live cd of F10 beta. Booted and added the live_ram option to the boot params. After copying the image to RAM I get the following error on two machines, (Apple Mac Book, and Acer 3680).
Done copying live image to RAM. eject: did not find a device /dev/root in /sys/block Bug in initramfs /init detected. Dropping to a shell. Good luck!
sbin/real-init: line 7: plymouth: command not found
I know I used that param for F9. Is it depreciated or is this a bug needing filling?
Nathanael Noblet wrote:
Hello, I downloaded the live cd of F10 beta. Booted and added the live_ram option to the boot params. After copying the image to RAM I get the following error on two machines, (Apple Mac Book, and Acer 3680).
Done copying live image to RAM. eject: did not find a device /dev/root in /sys/block Bug in initramfs /init detected. Dropping to a shell. Good luck!
sbin/real-init: line 7: plymouth: command not found
I know I used that param for F9. Is it depreciated or is this a bug needing filling?
Assuming it does something different when you omit the option, that's a bug. If we don't intend for it to work in F10, the option should be removed entirely, and ignored if passed by the user.
-- Chris
On Oct 1, 2008, at 4:08 PM, Chris Snook wrote:
Nathanael Noblet wrote:
Hello, I downloaded the live cd of F10 beta. Booted and added the live_ram option to the boot params. After copying the image to RAM I get the following error on two machines, (Apple Mac Book, and Acer 3680). Done copying live image to RAM. eject: did not find a device /dev/root in /sys/block Bug in initramfs /init detected. Dropping to a shell. Good luck! sbin/real-init: line 7: plymouth: command not found I know I used that param for F9. Is it depreciated or is this a bug needing filling?
Assuming it does something different when you omit the option, that's a bug. If we don't intend for it to work in F10, the option should be removed entirely, and ignored if passed by the user.
Yeah if you remove the live_ram from the boot options. It boots...
Is there a rationale for removing the option? It came in super useful for me a month or so back. I can't remember the exact issue but saved the day for me when I finally found it.
Nathanael Noblet wrote:
On Oct 1, 2008, at 4:08 PM, Chris Snook wrote:
Nathanael Noblet wrote:
Hello, I downloaded the live cd of F10 beta. Booted and added the live_ram option to the boot params. After copying the image to RAM I get the following error on two machines, (Apple Mac Book, and Acer 3680). Done copying live image to RAM. eject: did not find a device /dev/root in /sys/block Bug in initramfs /init detected. Dropping to a shell. Good luck! sbin/real-init: line 7: plymouth: command not found I know I used that param for F9. Is it depreciated or is this a bug needing filling?
Assuming it does something different when you omit the option, that's a bug. If we don't intend for it to work in F10, the option should be removed entirely, and ignored if passed by the user.
Yeah if you remove the live_ram from the boot options. It boots...
Is there a rationale for removing the option? It came in super useful for me a month or so back. I can't remember the exact issue but saved the day for me when I finally found it.
If it had been removed, it wouldn't do anything. The fact that it's doing something indicates that it's expected to still work, but broken. Please file a BZ.
-- Chris
On Oct 2, 2008, at 11:37 AM, Chris Snook wrote:
Nathanael Noblet wrote:
On Oct 1, 2008, at 4:08 PM, Chris Snook wrote:
Nathanael Noblet wrote:
Hello, I downloaded the live cd of F10 beta. Booted and added the live_ram option to the boot params. After copying the image to RAM I get the following error on two machines, (Apple Mac Book, and Acer 3680). Done copying live image to RAM. eject: did not find a device /dev/root in /sys/block Bug in initramfs /init detected. Dropping to a shell. Good luck! sbin/real-init: line 7: plymouth: command not found I know I used that param for F9. Is it depreciated or is this a bug needing filling?
Assuming it does something different when you omit the option, that's a bug. If we don't intend for it to work in F10, the option should be removed entirely, and ignored if passed by the user.
Yeah if you remove the live_ram from the boot options. It boots... Is there a rationale for removing the option? It came in super useful for me a month or so back. I can't remember the exact issue but saved the day for me when I finally found it.
If it had been removed, it wouldn't do anything. The fact that it's doing something indicates that it's expected to still work, but broken. Please file a BZ.
Against? mkinitrd? this is in the init in the initrd but I'm not sure if it is for installed systems or not...
Nathanael Noblet wrote:
On Oct 2, 2008, at 11:37 AM, Chris Snook wrote:
Nathanael Noblet wrote:
On Oct 1, 2008, at 4:08 PM, Chris Snook wrote:
Nathanael Noblet wrote:
Hello, I downloaded the live cd of F10 beta. Booted and added the live_ram option to the boot params. After copying the image to RAM I get the following error on two machines, (Apple Mac Book, and Acer 3680). Done copying live image to RAM. eject: did not find a device /dev/root in /sys/block Bug in initramfs /init detected. Dropping to a shell. Good luck! sbin/real-init: line 7: plymouth: command not found I know I used that param for F9. Is it depreciated or is this a bug needing filling?
Assuming it does something different when you omit the option, that's a bug. If we don't intend for it to work in F10, the option should be removed entirely, and ignored if passed by the user.
Yeah if you remove the live_ram from the boot options. It boots... Is there a rationale for removing the option? It came in super useful for me a month or so back. I can't remember the exact issue but saved the day for me when I finally found it.
If it had been removed, it wouldn't do anything. The fact that it's doing something indicates that it's expected to still work, but broken. Please file a BZ.
Against? mkinitrd? this is in the init in the initrd but I'm not sure if it is for installed systems or not...
Since it's livecd-specific, I would blame livecd-tools for setting it up incorrectly. When in doubt, file the bug and let the developers pass the blame if needed.
-- Chris
Hi,
I've been optimizing a system for flash, and wanted to have /var/run be a tmpfs mount, so that these writes to not wear down the flash/ssd.
I noticed only a few initscripts create their own directory in /var/run/ if they need it.
I've read http://fedoraproject.org/wiki/FCNewInit and http://fedoraproject.org/wiki/FCNewInit/Initscripts but neither one mentions anything about /var/run being tmpfs. Browsing the FSB does not yield anything either.
Should I consider it a bug if an initscript is using a subdirectory in /var/run/ but does not check/create it on being called with start?
And is there a convention for when to use files directly in /var/run/ and when to create a subdirectory?
Paul
Paul Wouters (paul@xelerance.com) said:
Should I consider it a bug if an initscript is using a subdirectory in /var/run/ but does not check/create it on being called with start?
No. It may not have permissions to, due to SELinux (among other reasons).
Bill
Paul Wouters wrote:
Hi,
I've been optimizing a system for flash, and wanted to have /var/run be a tmpfs mount, so that these writes to not wear down the flash/ssd.
I noticed only a few initscripts create their own directory in /var/run/ if they need it.
I've read http://fedoraproject.org/wiki/FCNewInit and http://fedoraproject.org/wiki/FCNewInit/Initscripts but neither one mentions anything about /var/run being tmpfs. Browsing the FSB does not yield anything either.
Should I consider it a bug if an initscript is using a subdirectory in /var/run/ but does not check/create it on being called with start?
And is there a convention for when to use files directly in /var/run/ and when to create a subdirectory?
Paul
You could use the readonlyroot feature and customize /etc/rwtab, /etc/sysconfig/readonly-root
On Wednesday 11 February 2009, Harald Hoyer wrote:
Paul Wouters wrote:
I've been optimizing a system for flash, and wanted to have /var/run be a tmpfs mount, so that these writes to not wear down the flash/ssd.
I've done something similar, but not for flash/ssd reasons, but rather to get a plain old HDD in my PVR spun down as much (and as easily) as possible, using the read only root feature. Or actually only the temporary state part of it.
You could use the readonlyroot feature and customize /etc/rwtab, /etc/sysconfig/readonly-root
What I find lacking in that feature for my scenario is that there's no out of the box way to persist the temporary state stuff on tmpfs back to disk on shutdown. So I did a rather crude hack to accomplish that at FC-6 time, and I think I'm still using the exactly same one with good success even though the box has been upgraded several times meanwhile, it's at F-10 currently. The hack and the RFE is at https://bugzilla.redhat.com/223722
There are not too many packages that drop /etc/rwtab.d snippets, so as Harald said, it's quite likely that customizing /etc/rwtab is needed in many scenarios. It'd be great if more packages took care of that out of the box (see for example the vdr and vdradmin-am packages if interested).
devel@lists.stg.fedoraproject.org
-
Bill Nottingham -
Chris Snook -
Harald Hoyer -
Nathanael D. Noblet -
Paul Wouters -
Ville Skyttä