4:56 p.m.
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 d. Noblet
5:08 p.m.
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
5:49 p.m.
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.
12:37 p.m.
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
10:49 a.m.
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...
11:44 a.m.
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
3:37 p.m.
New subject: Question on /var/run, tmpfs and initscripts
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
4:36 p.m.
New subject: Question on /var/run, tmpfs and initscripts
Paul Wouters (paul(a)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
4:41 a.m.
New subject: Question on /var/run, tmpfs and initscripts
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
9:44 a.m.
New subject: Question on /var/run, tmpfs and initscripts
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).
5546
days inactive
5679
days old
9 comments
6 participants
participants (6)
-
Bill Nottingham -
Chris Snook -
Harald Hoyer -
Nathanael D. Noblet -
Paul Wouters -
Ville Skyttä