Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.hardware > #2761

Re: Any Kernel Hackers in the house

Show all headers | View raw

On 03/21/15 14:04, Aragorn wrote:
> On Saturday 21 March 2015 09:24, ruben safir conveyed the following to
> comp.os.linux.hardware...
>
>> I'm really struggling with compiling the kerne.  Actually installing
>> it is the trouble.  Istead of rewriting everything I'm Copying this
>> previous message here.
>>
>> I am not understanding grub and initramfs at all at this point
>>
>> [...] The installation has initramfs files for each of its stock
>> kernels with long tedious an incomprehendable configuration lines for
>> each kernel.  There is no longer a mkinitrd. Instead I have
>> documentation that goes on for 20 paragraphs and never tells you how
>> to actually make these initram files, nor does it say when they are
>> need.
>>
>> They shouldn't BE needed, actually.  Somewhere in the compiled code,
>> evidently, there is a initram file that needs to be extracted out with
>> a versio of cpio.  Then after reading all of that, he recommends you
>> go to busy box to make a ram disk?
>
> There is a distinction between a traditional initrd (which is a cpio
> archive) and an initramfs (which is a RAM-based root filesystem).  A
> traditional initd is created using mkinitrd, but in order to create an
> initramfs, you need something like dracut.
>
> Mind you that an initramfs (or initrd) isn't really necessary under all
> conditions.  An initramfs /might be necessary/ if you're using a
> distribution which uses systemd rather than sysvinit or a sysvinit-based
> init system *and* you have /usr on an separate filesystem, or you have
> the root filesystem on an LVM volume ─ in which case, you would need a
> separate /boot as GRUB doesn't understand LVM.  The initramfs created
> with dracut will then contain the necessary tools to mount /usr and/or
> support LVM.
>
> Likewise, the kernel does not support LABELs or UUIDs, so if you want to
> use those in GRUB, you'll need to create an initramfs, which has the
> tools necessary to handle LABELs and UUIDs.  On the other hand, if you
> have a GPT partition table, then the kernel command line does support
> PARTUID, i.e. the *GPT partition UUID,* which is a different thing from
> the *filesystem UUID.*
>
> It has been a long time ─ maybe ten years ─ since I've built a custom
> kernel, but I have always managed to get it to booted and run without an
> initd, and I've also never built a kernel that wouldn't boot.  I did
> have one unstable kernel at one point, but that was because I was using
> the upstream sources from kernel.org and that kernel had a very serious
> bug in it, which was fixed with a patch the next day.  That particular
> kernel was 2.6.8, and the fix ─ 2.6.8.1 ─ is what got the "four
> numerals" versioning started, which lasted up until Linus decided to
> bump the kernel version to 3.0.
>
> The first kernel I ever built was 2.6.5, and I was on a system that
> still had been built with a 2.4.x kernel.  My custom kernel booted
> straight up without a glitch and ran perfectly, and all without needing
> an initrd.
>

Or skip all of that non sense and just use FreeBSD.
Will boot even if /usr is on a separate filesystem, they keep everything 
needed to boot where it is and suppose to be. /bin /boot /etc nad /sbin.
Hell they even have a /rescue so if you botch things up you can fix it.
Building a custom kernel = piece of cake.

--
Linux: just too much non sense

Back to comp.os.linux.hardware | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Any Kernel Hackers in the house ruben safir <dont@email.me> - 2015-03-21 08:24 +0000
  Re: Any Kernel Hackers in the house ruben safir <dont@email.me> - 2015-03-21 16:21 +0000
  Re: Any Kernel Hackers in the house Aragorn <thorongil@telenet.be.invalid> - 2015-03-21 19:04 +0100
    Re: Any Kernel Hackers in the house Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2015-03-21 22:48 +0100
      Re: Any Kernel Hackers in the house ruben <ceo@iran.gov> - 2015-04-20 09:11 +0000
        Re: Any Kernel Hackers in the house Aragorn <thorongil@telenet.be.invalid> - 2015-04-20 14:49 +0200
          Re: Any Kernel Hackers in the house Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2015-04-22 00:40 +0200
            Re: Any Kernel Hackers in the house ruben safir <ruben@mrbrklyn.com> - 2015-04-22 05:38 -0400
              Re: Any Kernel Hackers in the house ruben safir <ruben@mrbrklyn.com> - 2015-04-22 05:39 -0400
    Re: Any Kernel Hackers in the house Baho Utot <baho-utot@columbus.rr.com> - 2015-03-21 17:52 -0400
      Re: Any Kernel Hackers in the house Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 00:03 +0100
  Re: Any Kernel Hackers in the house Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2015-03-21 22:50 +0100
    Re: Any Kernel Hackers in the house ruben safir <ruben@mrbrklyn.com> - 2015-03-21 18:25 -0400
      Re: Any Kernel Hackers in the house Marc Haber <mh+usenetspam1118@zugschl.us> - 2015-03-22 10:51 +0100
    Re: Any Kernel Hackers in the house ruben <ceo@iran.gov> - 2015-04-20 09:18 +0000
  Re: Any Kernel Hackers in the house Richard Kettlewell <rjk@greenend.org.uk> - 2015-03-22 10:28 +0000
    Re: Any Kernel Hackers in the house ruben <ceo@iran.gov> - 2015-04-20 09:35 +0000
      Re: Any Kernel Hackers in the house Richard Kettlewell <rjk@greenend.org.uk> - 2015-04-20 10:37 +0100
        Re: Any Kernel Hackers in the house ruben safir <ruben@mrbrklyn.com> - 2015-04-20 09:36 -0400
          Re: Any Kernel Hackers in the house Richard Kettlewell <rjk@greenend.org.uk> - 2015-04-20 16:23 +0100
            Re: Any Kernel Hackers in the house ruben safir <ruben@mrbrklyn.com> - 2015-05-01 01:55 -0400
  Re: Any Kernel Hackers in the house Thomas Richter <thor@math.tu-berlin.de> - 2015-03-24 13:00 +0100
    Re: Any Kernel Hackers in the house ruben safir <dont@email.me> - 2015-03-25 02:54 +0000

csiph-web