On Fri, May 16, 2014 at 4:46 AM, Stefan G. Weichinger <li...@xunil.at> wrote:
> Am 15.05.2014 20:33, schrieb Canek Peláez Valdés:
>> On Thu, May 15, 2014 at 1:27 PM, Stefan G. Weichinger <li...@xunil.at> wrote:
>>> Am 15.05.2014 20:05, schrieb Canek Peláez Valdés:
>>>
>>>> With -H, you don't get the kernel cmdline, and therefore your kernel
>>>> cannot load your LVM volumes since it doesn't know their... names? I
>>>> don't knot the terminology.
>>>>
>>>> In any case, you need to set --hostonly-cmdline (or
>>>> hostonly_cmdline="yes" in the config file), *besides* -H.
>>>
>>> ok ... I pulled your changes (kerninst) from github ... on the web I see
>>> it, but it doesn't get into my copy here ... strange.
>>>
>>> As I don't need it right now, I will (a) wait or (b) edit manually.
>>>
>>> No problem.
>>
>> I actually *removed* -H from kerninst. That should be configured in
>> the user's dracut.conf; now I have:
>>
>> hostonly="yes"
>> hostonly_cmdline="yes"
>>
>> in my dracut.conf.
>
> Yes, I understood ... thanks.
>
> Aside from that a more general question:
>
> Does it it any way help to have a *small* (= as small as possible)
> initramfs?
>
> Maybe on embedded systems but on the big multi-GB-ram-machines we use it
> doesn't make much difference, right?

AFAIU, no, it doesn't. As long as the (uncompressed) initramfs fits
into the RAM, its size doesn't matter.

> I ask because in all my reorganizing furor I also thought that now with
> btrfs only I could get rid of "lvm mdraid" as dracut-modules. I can try
> ... ;-) (don't call me "ricer")

Whatever gets rid of LVM is good on my book. I've never understood why
people uses it, and in my experience it only brings headaches.
Besides, I've heard from many people that btrfs is the way to go in
the future. I'm not ready to make the change yet, but I will at some
point.

> Additional in this context: does it make a noticeable difference which
> "Kernel compression mode" you choose? I assume it is again an issue for
> systems with (a) small boot-partitions and/or (b) slower CPUs to select
> something special here.

Given the size of the kernel, I don't thin the difference can be
humanly measured.

> I checked and see that I use LZ4 anyway already ... seems to be the
> fastest to unpack as far as I understand the help text.

It will be a difference of microseconds, if not nanoseconds. I
honestly don't think it matters at all.

> And then, who writes the howto condensed out of this thread? ;-)
> Much to learn and understand as always, I appreciate it a lot.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Reply via email to