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

Groups > comp.os.linux.misc > #14079 > unrolled thread

Learning about the Kernal

Back to article view | Back to comp.os.linux.misc

Contents

  Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-03-14 19:59 -0400
    Re: Learning about the Kernal Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2015-03-15 11:11 +0100
      Re: Learning about the Kernal ruben <nowhere@nowhere.nor> - 2015-03-15 21:14 +0000
        Re: Learning about the Kernal Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-16 10:02 +0200
          Re: Learning about the Kernal Ruben Safir <mrbrklyn@panix.com> - 2015-03-17 00:18 +0000
            Re: Learning about the Kernal Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2015-03-16 20:53 -0700
              Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-17 05:14 +0000
              Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-17 05:23 +0000
        Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-16 21:58 -0400
          Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-17 05:21 +0000
            Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-17 10:51 +0000
            Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-17 09:10 -0400
              Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-03-17 14:12 -0400
                Re: Learning about the Kernal William Unruh <unruh@invalid.ca> - 2015-03-17 19:03 +0000
                  Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-17 19:08 +0000
                    Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-17 15:17 -0400
                      Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-20 01:06 +0000
                        Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-19 23:52 -0400
                        Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-20 10:52 +0000
                          Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-20 20:33 +0000
                            Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-04-20 09:48 -0400
                Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-17 15:08 -0400
                  Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-18 03:36 +0000
                    Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-18 10:09 -0400
                      Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-20 01:04 +0000
                      Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-20 10:58 +0000
                        Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-20 09:22 -0400
                          Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-20 18:39 +0000
                          Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-20 20:04 +0000
                            Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-20 21:10 -0400
                              Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 05:03 +0000
                        Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-20 18:42 +0000
                          Re: Learning about the Kernal Dan Espen <despen@verizon.net> - 2015-03-20 15:31 -0400
                            Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 05:13 +0000
                              Re: Learning about the Kernal The Natural Philosopher <tnp@invalid.invalid> - 2015-03-21 09:13 +0000
                                Re: Learning about the Kernal ruben <nowhere@nowhere.nor> - 2015-03-21 14:40 +0000
                                  Re: Learning about the Kernal Michael Black <et472@ncf.ca> - 2015-03-21 12:20 -0400
                                    Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 19:54 +0000
                                      Re: Learning about the Kernal Baho Utot <baho-utot@columbus.rr.com> - 2015-03-21 17:56 -0400
                                    Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 19:56 +0000
                                  Re: Learning about the Kernal Richard Kettlewell <rjk@greenend.org.uk> - 2015-03-21 16:18 +0000
            Re: Learning about the Kernal Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-17 16:10 +0200
              Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-03-17 14:06 -0400
                Re: Learning about the Kernal William Unruh <unruh@invalid.ca> - 2015-03-17 19:00 +0000
                  Re: Learning about the Kernal Tim Watts <tw_usenet@dionic.net> - 2015-03-17 19:05 +0000
                    Re: Learning about the Kernal Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2015-03-17 14:17 -0700
                    Re: Learning about the Kernal William Unruh <unruh@invalid.ca> - 2015-03-19 06:04 +0000
                      Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 08:45 +0000
                  Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 08:20 +0000
                    Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-21 16:09 +0000
                      Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 20:10 +0000
                Re: Learning about the Kernal Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-17 22:39 +0200
            Re: Learning about the Kernal Chick Tower <c.tower@deadspam.com> - 2015-03-18 03:35 +0000
              Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 08:47 +0000
                Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-21 20:19 +0000
                  Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-21 20:30 +0000
                    Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-22 20:05 +0000
                      Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-03-23 01:16 -0400
                        Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-23 20:27 +0000
                          Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-25 02:57 +0000
                          Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-25 02:59 +0000
                            Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-25 20:59 +0000
                              Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-04-20 09:44 -0400
                  Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 00:07 +0100
                    Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-22 00:07 +0000
                      Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 01:13 +0100
                        Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-22 03:11 +0000
                          Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 04:20 +0100
                            Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-22 13:19 +0000
                              Re: Learning about the Kernal Rich <rich@example.invalid> - 2015-03-22 15:13 +0000
                              Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 21:52 +0100
                            Re: Learning about the Kernal Jerry Peters <jerry@example.invalid> - 2015-03-22 20:13 +0000
                              Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-22 22:01 +0100
                Re: Learning about the Kernal Chick Tower <c.tower@deadspam.com> - 2015-03-23 04:02 +0000
                  Re: Learning about the Kernal Aragorn <thorongil@telenet.be.invalid> - 2015-03-23 05:13 +0100
                    Re: Learning about the Kernal ruben <ceo@iran.gov> - 2015-04-12 13:03 +0000
        Re: Learning about the Kernal ruben safir <dont@email.me> - 2015-03-17 05:18 +0000
        Re: Learning about the Kernal ruben safir <ruben@mrbrklyn.com> - 2015-03-17 01:52 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#14188

ruben <nowhere@nowhere.nor> writes:
> The Natural Philosopher wrote:
>> On 21/03/15 05:13, ruben safir wrote:
>>> Really, learning about Kernel compilation and coding is not a criminal
>>> matter and is a NORMAL endevour for GNU/Linux users.
>> 
>> No it isn't. Not for USERS. It might be for hobbyists administrators and
>> geeks, but most people just want a desktop that works.
>
> you don't speak for most people.  You don't even speak of some of the 
> people.  And what you wrote is disgusting, marketing dribble that didn't 
> address the point.  Keep reading this until you actually understand it.  
> This is not a Microsoft forum.  THIS is Free Software and we treat users 
> with respect.
>
> Learning about Kernel compilation and coding is not a criminal
> matter and is a NORMAL endevour for GNU/Linux users.

Who here is claiming it’s a “criminal matter”?  Dial back the hyperbole
a bit.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#14119

On 17.3.15 07:21, ruben safir wrote:
> On Mon, 16 Mar 2015 21:58:30 -0400, Dan Espen wrote:
>
>> Is that the "advice" you are looking for?
>
> I suppose the advise I was looking for was what is folks best experience
> to handling custom kernel builds and hacking, including the alerations
> that have to happen in grub  I want to set up a comfortable methodology
> to write, compile, install, boot, run, test
>
>
> and remix
>
> The make file is still trying to run lilo.
>
> Ruben


Please get a bit more specific what you're attempting to achieve.
We should be convinced that you're not looking for a quick way
to produce malware or break the kernel licensing conditions.

It seems to me that you're not yet up to the task. For starters,
you should get a good book about the Linux kernel, and read it.

The classic is:

  Daniel P. Bovet, Marco Cesati, Understanding the Linux Kernel,
  Third Edition, O'Reilly, ISBN-13: 978-0596005658.

-- 

Tauno Voipio

[toc] | [prev] | [next] | [standalone]

#14121

On 03/17/2015 10:10 AM, Tauno Voipio wrote:
> 
> Please get a bit more specific what you're attempting to achieve.
> We should be convinced that you're not looking for a quick way
> to produce malware or break the kernel licensing conditions.
> 
> It seems to me that you're not yet up to the task. For starters,
> you should get a good book about the Linux kernel, and read it.

There is no doubt about that, hence the question.  Reading that text
might not help much either.  I read it a  LONG time ago, and is sitting
open on my table right now.

If you want background, and you shouldn't need it, but if you want it,
I'll tell you that after using GNU systems since 1998 and taking many
advanced Programming classes in C, C++ Oracle etc, I decided to go back
for a masters degree in Comp Sci.  So here I am.  I have an assignment
to create an run an alternate Linux Scheduler but I found that compiling
Linux Kernels is not as easy as it had in the past.  The config file
that you get with make xconfig are enormous, and I forgot about grub.

So I need to develop a completely experimental and probably useless
linux scheduler and test it.   But there is not even Linux Source code
any longer in the distros I'm looking at, which happens to be
Manjaro/Arch.

And I'm left with a few questions that I never really thought of before.

make xconfig
make
make modules
make modules_install
make install


there used to be a make lilo

This is the procedure that I have generally used over the years.  It
never occurred to me ask how does a module get into make xconfig?

And how can I best handle multiple kernels with grub.


Is that a clearer question?

If you just want to answer with RTFM, no need.  You would have to be an
idiot to make this your sole source of information on this topic.

FWIW, the book that the course uses is Operating Systems Concepts 9th Ed
Silbershatz et al.

[toc] | [prev] | [next] | [standalone]

#14123

On 2015-03-17, ruben safir <ruben@mrbrklyn.com> wrote:
> On 03/17/2015 10:10 AM, Tauno Voipio wrote:
>> 
>> Please get a bit more specific what you're attempting to achieve.
>> We should be convinced that you're not looking for a quick way
>> to produce malware or break the kernel licensing conditions.
>> 
>> It seems to me that you're not yet up to the task. For starters,
>> you should get a good book about the Linux kernel, and read it.
>
> There is no doubt about that, hence the question.  Reading that text
> might not help much either.  I read it a  LONG time ago, and is sitting
> open on my table right now.
>
> If you want background, and you shouldn't need it, but if you want it,
> I'll tell you that after using GNU systems since 1998 and taking many
> advanced Programming classes in C, C++ Oracle etc, I decided to go back
> for a masters degree in Comp Sci.  So here I am.  I have an assignment
> to create an run an alternate Linux Scheduler but I found that compiling
> Linux Kernels is not as easy as it had in the past.  The config file
> that you get with make xconfig are enormous, and I forgot about grub.

Yes, grub is a change from lilo, and grub2 is at least a big a change
from grub as grub was from lilo. grub2 seems to be a full operating
system all on its own whose purpose is to load the operating system! :-)


>
> So I need to develop a completely experimental and probably useless
> linux scheduler and test it.   But there is not even Linux Source code
> any longer in the distros I'm looking at, which happens to be
> Manjaro/Arch.

Sure there is. You just have to install it. Usually distros will not
install the 1/2 GB of source code when all you need are the headers
to compile modules against. They have thus split the packages into the
headers and the src which includes the headers. 
I do not know Manjaro. I use Mageia. 
There they are differentiated by kernel-source and kernel-devel.


>
> And I'm left with a few questions that I never really thought of before.
>
> make xconfig
> make
> make modules
> make modules_install
> make install

Those are not questions. 

>
>
> there used to be a make lilo

It is grub that is now used. 

>
> This is the procedure that I have generally used over the years.  It
> never occurred to me ask how does a module get into make xconfig?

The various sources for the modules have a file called .Kconfig which
gives options  which to use whether module or built in etc. 
and the .config file which answers those options.

>
> And how can I best handle multiple kernels with grub.

By giving each kernel its own stanza. 
>
>
> Is that a clearer question?
No.

>
> If you just want to answer with RTFM, no need.  You would have to be an
> idiot to make this your sole source of information on this topic.
>
> FWIW, the book that the course uses is Operating Systems Concepts 9th Ed
> Silbershatz et al.

I would advise you to install a distribution. and see what they do while
you are installing it. Then make a prebuilt kernel. Then look into /boot
and /boot/grub{,2} to see what files are there and esp the menu.lst and
the grub.conf files. 

Then read man grub or man grub2



>
>
>
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#14125

On 17/03/15 19:00, William Unruh wrote:

> Yes, grub is a change from lilo, and grub2 is at least a big a change
> from grub as grub was from lilo. grub2 seems to be a full operating
> system all on its own whose purpose is to load the operating system! :-)

Lob it together with an EFI BIOS and it gets really insane**

** I actually have a system that did not want to boot in non EFI mode - 
first ever. Had to reinstall allowing for an EFI partition.

Still not sure if the extra complexity has actually solved any problems!!!

[toc] | [prev] | [next] | [standalone]

#14132

On 03/17/2015 12:05 PM, Tim Watts wrote:
> On 17/03/15 19:00, William Unruh wrote:
>
>> Yes, grub is a change from lilo, and grub2 is at least a big a change
>> from grub as grub was from lilo. grub2 seems to be a full operating
>> system all on its own whose purpose is to load the operating system! :-)

	If you want to get away from GRUB you might look and see what is
happening to e-lilo.
>
> Lob it together with an EFI BIOS and it gets really insane**
>
> ** I actually have a system that did not want to boot in non EFI mode -
> first ever. Had to reinstall allowing for an EFI partition.
>
> Still not sure if the extra complexity has actually solved any problems!!!

	Well it depends on the user I guess,  Those that are happily with the 
MS sort of partition with Logical and all the hacks that were
devised to get around the 4 partition limit for the old MBR won't
notice.
	Those who like myself find that limit cramping may find some use
for the EFI and GPT with 128 partition limit.

	Otherwise I agree with you about the problems of setting up
the GPT with out a set of printed out directions in front of you.
	But I had 9 active partitions on my 3.4 GB Amiga OS about
10 years back.  Too bad they did not adopt the RDB standard.

	selah!
	bliss
.

[toc] | [prev] | [next] | [standalone]

#14155

On 2015-03-17, Tim Watts <tw_usenet@dionic.net> wrote:
> On 17/03/15 19:00, William Unruh wrote:
>
>> Yes, grub is a change from lilo, and grub2 is at least a big a change
>> from grub as grub was from lilo. grub2 seems to be a full operating
>> system all on its own whose purpose is to load the operating system! :-)
>
> Lob it together with an EFI BIOS and it gets really insane**
>
> ** I actually have a system that did not want to boot in non EFI mode - 
> first ever. Had to reinstall allowing for an EFI partition.
>
> Still not sure if the extra complexity has actually solved any problems!!!

Well, EFI is supposed to allow for far greater flexibility in booting.
Both fedora and Mageia 5 seem to have gotten efi working. So, I think it
is not solving problems but "wouldn't it be nice if..."

[toc] | [prev] | [next] | [standalone]

#14182

On Thu, 19 Mar 2015 06:04:35 +0000, William Unruh wrote:

>> Still not sure if the extra complexity has actually solved any
>> problems!!!
> 
> Well, EFI is supposed to allow for far greater flexibility in booting.
> Both fedora and Mageia 5 seem to have gotten efi working. So, I think it
> is not solving problems but "wouldn't it be nice if..."

EFI is not one of the problems here.  It is a virtualbox of a Dual Core Intel.  
the Bios doesn't even have any EFi settings.




-- 
The Coin Hangout: http://www.coinhangout.com/home

[toc] | [prev] | [next] | [standalone]

#14181

On Tue, 17 Mar 2015 19:00:59 +0000, William Unruh wrote:

> I would advise you to install a distribution. and see what they do while
> you are installing it. Then make a prebuilt kernel. Then look into /boot
> and /boot/grub{,2} to see what files are there and esp the menu.lst and
> the grub.conf files.
> 
> Then read man grub or man grub2

I'm way past all this and very fustrated.  This has become another just broken part of what was a usable system.  I can compile the kernel and after that your on your own.  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?

I'm like WTF. Did a 1000 penguins all jump off the wrong end of the pool and hit their head on an iceburg?


https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt



The relevent part, I hope is this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What is initramfs?
------------------

All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is
extracted into rootfs when the kernel boots up.  After extracting, the kernel
checks to see if rootfs contains a file "init", and if so it executes it as PID
1.  If found, this init process is responsible for bringing the system the
rest of the way up, including locating and mounting the real root device (if
any).  If rootfs does not contain an init program after the embedded cpio
archive is extracted into it, the kernel will fall through to the older code
to locate and mount a root partition, then exec some variant of /sbin/init
out of that.

All this differs from the old initrd in several ways:

  - The old initrd was always a separate file, while the initramfs archive is
    linked into the linux kernel image.  (The directory linux-*/usr is devoted
    to generating this archive during the build.)

What is initramfs?
------------------

All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is
extracted into rootfs when the kernel boots up.  After extracting, the kernel 
checks to see if rootfs contains a file "init", and if so it executes it as PID 
1.  If found, this init process is responsible for bringing the system the rest 
of the way up, including locating and mounting the real root device (if any).  
If rootfs does not contain an init program after the embedded cpio archive is 
extracted into it, the kernel will fall through to the older code to locate and 
mount a root partition, then exec some variant of /sbin/init out of that.

All this differs from the old initrd in several ways:

  - The old initrd was always a separate file, while the initramfs archive is 
linked into the linux kernel image.  (The directory linux-*/usr is devoted to 
generating this archive during the build.)
~~~~~~~~~~~~~~~~~~~~~~


There is a whole bunch of problems though.  I compile the kernel.  I look in to 
the boot directory and the initramfs are NOT internal to the kernal...

[ruben@stat13 ~]$ cd /boot
[ruben@stat13 boot]$ ls
EFI                                initramfs-314-x86_64-fallback.img  linux310-x86_64.kver  syslinux
grub                               initramfs-314-x86_64.img           linux314-x86_64.kver  vmlinuz-310-x86_64
initramfs-310-x86_64-fallback.img  initramfs-319-x86_64-fallback.img  linux319-x86_64.kver  vmlinuz-314-x86_64
initramfs-310-x86_64.img           initramfs-319-x86_64.img           memtest86+            vmlinuz-319-x86_64

grub2 is incompreshensable as well:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
insmod part_gpt
insmod part_msdos
if [ -s $prefix/grubenv ]; then
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="${saved_entry}"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

set menu_color_normal=light-gray/black
set menu_color_highlight=green/black

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos 
insmod reiserfs
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  22171af4-2b9c-4b5c-a53c-7cbb927f0a75
else
  search --no-floppy --fs-uuid --set=root 22171af4-2b9c-4b5c-a53c-7cbb927f0a75
fi
    font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_input console
terminal_output gfxterm
insmod part_msdos 
insmod reiserfs
set root='hd0,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  22171af4-2b9c-4b5c-a53c-7cbb927f0a75
else
  search --no-floppy --fs-uuid --set=root 22171af4-2b9c-4b5c-a53c-7cbb927f0a75
fi
insmod png
background_image -m stretch /usr/share/grub/background.png
if [ x$feature_timeout_style = xy ] ; then
  set timeout_style=menu
  set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
  set timeout=5
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-22171af4-2b9c-4b5c-a53c-7cbb927f0a75' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos 
	insmod reiserfs
	set root='hd0,msdos3'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  22171af4-2b9c-4b5c-a53c-7cbb927f0a75
	else
	  search --no-floppy --fs-uuid --set=root 22171af4-2b9c-4b5c-a53c-7cbb927f0a75
	fi
	echo	'Loading Linux 3.19.1-1-MANJARO x64 ...'
	linux	/boot/vmlinuz-319-x86_64 root=UUID=22171af4-2b9c-4b5c-a53c-7cbb927f0a75 rw    resume=/dev/disk/by-uuid/ee081d34-d809-4b6c-a57d-af1308eaaf6b
	echo	'Loading initial ramdisk ...'
	initrd	 /boot/initramfs-319-x86_64.img
}
submenu 'Advanced options for Manjaro Linux' $menuentry_id_option 'gnulinux-advanced-22171af4-2b9c-4b5c-a53c-7cbb927f0a75' {
	menuentry 'Manjaro Linux (Kernel: 3.19.1-1-MANJARO x64)' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.19.1-1-MANJARO x64-advanced-22171af4-2b9c-4b5c-a53c-7cbb927f0a75' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_msdos 
		insmod reiserfs
		set root='hd0,msdos3'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		else
		  search --no-floppy --fs-uuid --set=root 22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		fi
		echo	'Loading Linux 3.19.1-1-MANJARO x64 ...'
		linux	/boot/vmlinuz-319-x86_64 root=UUID=22171af4-2b9c-4b5c-a53c-7cbb927f0a75 rw    resume=/dev/disk/by-uuid/ee081d34-d809-4b6c-a57d-af1308eaaf6b
		echo	'Loading initial ramdisk ...'
		initrd	 /boot/initramfs-319-x86_64.img
	}
	menuentry 'Manjaro Linux (Kernel: 3.19.1-1-MANJARO x64 - fallback initramfs)' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.19.1-1-MANJARO x64-fallback-22171af4-2b9c-4b5c-a53c-7cbb927f0a75' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_msdos 
		insmod reiserfs
		set root='hd0,msdos3'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		else
		  search --no-floppy --fs-uuid --set=root 22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		fi
		echo	'Loading Linux 3.19.1-1-MANJARO x64 ...'
		linux	/boot/vmlinuz-319-x86_64 root=UUID=22171af4-2b9c-4b5c-a53c-7cbb927f0a75 rw    resume=/dev/disk/by-uuid/ee081d34-d809-4b6c-a57d-af1308eaaf6b
		echo	'Loading initial ramdisk ...'
		initrd	 /boot/initramfs-319-x86_64-fallback.img
	}
	menuentry 'Manjaro Linux (Kernel: 3.14.27-1-MANJARO x64)' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.14.27-1-MANJARO x64-advanced-22171af4-2b9c-4b5c-a53c-7cbb927f0a75' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_msdos 
		insmod reiserfs
		set root='hd0,msdos3'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		else
		  search --no-floppy --fs-uuid --set=root 22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		fi
		echo	'Loading Linux 3.14.27-1-MANJARO x64 ...'
		linux	/boot/vmlinuz-314-x86_64 root=UUID=22171af4-2b9c-4b5c-a53c-7cbb927f0a75 rw    resume=/dev/disk/by-uuid/ee081d34-d809-4b6c-a57d-af1308eaaf6b
		echo	'Loading initial ramdisk ...'
		initrd	 /boot/initramfs-314-x86_64.img
	}
	menuentry 'Manjaro Linux (Kernel: 3.14.27-1-MANJARO x64 - fallback initramfs)' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.14.27-1-MANJARO x64-fallback-22171af4-2b9c-4b5c-a53c-7cbb927f0a75' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_msdos 
		insmod reiserfs
		set root='hd0,msdos3'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		else
		  search --no-floppy --fs-uuid --set=root 22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		fi
		echo	'Loading Linux 3.14.27-1-MANJARO x64 ...'
		linux	/boot/vmlinuz-314-x86_64 root=UUID=22171af4-2b9c-4b5c-a53c-7cbb927f0a75 rw    resume=/dev/disk/by-uuid/ee081d34-d809-4b6c-a57d-af1308eaaf6b
		echo	'Loading initial ramdisk ...'
		initrd	 /boot/initramfs-314-x86_64-fallback.img
	}
	menuentry 'Manjaro Linux (Kernel: 3.10.63-1-MANJARO x64)' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.10.63-1-MANJARO x64-advanced-22171af4-2b9c-4b5c-a53c-7cbb927f0a75' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_msdos 
		insmod reiserfs
		set root='hd0,msdos3'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		else
		  search --no-floppy --fs-uuid --set=root 22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		fi
		echo	'Loading Linux 3.10.63-1-MANJARO x64 ...'
		linux	/boot/vmlinuz-310-x86_64 root=UUID=22171af4-2b9c-4b5c-a53c-7cbb927f0a75 rw    resume=/dev/disk/by-uuid/ee081d34-d809-4b6c-a57d-af1308eaaf6b
		echo	'Loading initial ramdisk ...'
		initrd	 /boot/initramfs-310-x86_64.img
	}
	menuentry 'Manjaro Linux (Kernel: 3.10.63-1-MANJARO x64 - fallback initramfs)' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.10.63-1-MANJARO x64-fallback-22171af4-2b9c-4b5c-a53c-7cbb927f0a75' {
		load_video
		set gfxpayload=keep
		insmod gzio
		insmod part_msdos 
		insmod reiserfs
		set root='hd0,msdos3'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		else
		  search --no-floppy --fs-uuid --set=root 22171af4-2b9c-4b5c-a53c-7cbb927f0a75
		fi
		echo	'Loading Linux 3.10.63-1-MANJARO x64 ...'
		linux	/boot/vmlinuz-310-x86_64 root=UUID=22171af4-2b9c-4b5c-a53c-7cbb927f0a75 rw    resume=/dev/disk/by-uuid/ee081d34-d809-4b6c-a57d-af1308eaaf6b
		echo	'Loading initial ramdisk ...'
		initrd	 /boot/initramfs-310-x86_64-fallback.img
	}
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###

### BEGIN /etc/grub.d/60_memtest86+ ###
if [ "${grub_platform}" == "pc" ]; then
    menuentry "Memory Tester (memtest86+)" --class memtest86 --class gnu --class tool {
        search --fs-uuid --no-floppy --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3  22171af4-2b9c-4b5c-a53c-7cbb927f0a75
        linux16 /boot/memtest86+/memtest.bin 
    }
fi
### END /etc/grub.d/60_memtest86+ ###
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`

Even after running the grub configurator it is not even finding my compiled kernel

This is the /boot directly

[ruben@manjaro linux]$ ls -l /boot
total 81464
drwxr-xr-x 2 root root     4096 Dec 31  1969 efi
drwxr-xr-x 3 root root     4096 Mar  7 23:42 EFI
drwxr-xr-x 7 root root     4096 Mar 21 03:51 grub
-rw-r--r-- 1 root root 19189717 Mar 14 15:03 initramfs-318-x86_64-fallback.img
-rw-r--r-- 1 root root  4003774 Mar 14 15:03 initramfs-318-x86_64.img
-rw-r--r-- 1 root root 19262363 Mar 15 03:21 initramfs-319-x86_64-fallback.img
-rw-r--r-- 1 root root  4004395 Mar 15 03:21 initramfs-319-x86_64.img
-rw-r--r-- 1 root root   663040 Feb  9 10:42 intel-ucode.img
-rw-r--r-- 1 root root       21 Mar  7 13:20 linux318-x86_64.kver
-rw-r--r-- 1 root root       21 Mar  7 14:01 linux319-x86_64.kver
drwx------ 2 root root    16384 Mar 14 13:58 lost+found
drwxr-xr-x 2 root root     4096 Oct  6  2013 memtest86+
drwxr-xr-x 2 root root     4096 Oct 13 18:25 syslinux
-rw-r--r-- 1 root root  3112889 Mar 21 02:49 System.map
-rw-r--r-- 1 root root 10914329 Mar 15 03:02 System.old
-rw-r--r-- 1 root root  5974592 Mar 21 02:49 vmlinuz <<-----------NEW KERNEL
-rw-r--r-- 1 root root  4087776 Mar  7 13:20 vmlinuz-318-x86_64.NO
-rw-r--r-- 1 root root  4146640 Mar  7 14:01 vmlinuz-319-x86_64
-rw-r--r-- 1 root root  7887376 Mar 15 03:02 vmlinuz.old

[ruben@manjaro linux]$ sudo grub-mkconfig -o /boot/grub/grub.cfg
[sudo] password for ruben: 
Generating grub configuration file ...
Found background: /usr/share/grub/background.png
  /run/lvm/lvmetad.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
Found memtest86+ image: /boot/memtest86+/memtest.bin
Found Intel Microcode image
Found linux image: /boot/vmlinuz-319-x86_64
Found initrd image: /boot/initramfs-319-x86_64.img
Found initrd fallback image: /boot/initramfs-319-x86_64-fallback.img
Found linux image: /boot/vmlinuz-318-x86_64.NO
done


It passed right over vmlinuz
[ruben@manjaro linux]$ file /boot/vmlinuz
/boot/vmlinuz: Linux kernel x86 boot executable bzImage, version 3.19.2 (ruben@manjaro) #1 SMP Sat Mar 21 01:28:19 EDT 2015, RO-rootFS, swap_dev 0x5, Normal VGA


I'm at a complete dead end.  I was hoping that a kernel developer with a few minutes would apear here, but evidently not.


Ruben


-- 
The Coin Hangout: http://www.coinhangout.com/home

[toc] | [prev] | [next] | [standalone]

#14186

ruben safir <dont@email.me> wrote:
> On Tue, 17 Mar 2015 19:00:59 +0000, William Unruh wrote:

> > I would advise you to install a distribution. and see what they do while
> > you are installing it. Then make a prebuilt kernel. Then look into /boot
> > and /boot/grub{,2} to see what files are there and esp the menu.lst and
> > the grub.conf files.
> > 
> > Then read man grub or man grub2

> I'm way past all this and very fustrated.  This has become another
> just broken part of what was a usable system.  I can compile the
> kernel and after that your on your own.  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?

Go install a copy of Slackware into your VM.  Slackware does not
require an initramfs, and will happly install and boot a plain kernel
compiled binary blob.

You 'can' create an initramfs, if you want one, for Slackware, but you
are not forced down that path by default up front.

Plus, you can just download a kernel.org kernel, configure it using
'make oldconfig' with the installed Slackware .config file, compile it,
and boot it straight away, no fuss, no muss.

[toc] | [prev] | [next] | [standalone]

#14196

On Sat, 21 Mar 2015 16:09:51 +0000, Rich wrote:

> Go install a copy of Slackware into your VM.  Slackware does not require
> an initramfs, and will happly install and boot a plain kernel compiled
> binary blob.
> 

I'm actually considering that.  I still have one or two slack boxes on 
ADM A4s here.  They are teaching boxes mostly.

There is in the Manjaro package for the kernel the instructions in the 
shell that create the kernel.  They run:

post_install () {
# updating module dependencies
echo ">>> Updating module dependencies. Please wait ..."
depmod ${KERNEL_VERSION}
echo ">>> Generating initial ramdisk, using mkinitcpio. Please wait..."
mkinitcpio -p linux${BASEVER}

and then
 if [ -f /usr/sbin/update-grub ]; then
update-grub


So essentially then run a depmod on the kernel version, which is what I 
was especting and seemingly missing in other documentation

adn then it makes the initramfs with a file that I'm not sure how it was 
produced

man mkinitcpio

   -p, --preset preset
     Build initramfs image(s) according to specified preset. This may be
     a file in /etc/mkinitcpio.d (without the .preset extension) or a
     full, absolute path to a file. This option may be specified
     multiple times to process multiple presets.

[ruben@stat13 ~]$ ls /etc/mkinitcpio.d/
linux310.preset  linux314.preset  linux319.preset

where these come from, I don't know.  It is yet another level of uneeded 
obstruction.

The whole initiation ram disk is something I'm struggling with at this 
point.  It has gone from a conveinence for booting to another level, 
especially with systemd.  I have a quote from another user that sums it 
up like this:

QUOTE:

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



> You 'can' create an initramfs, if you want one, for Slackware, but you
> are not forced down that path by default up front.
> 
> Plus, you can just download a kernel.org kernel, configure it using
> 'make oldconfig' with the installed Slackware .config file, compile it,
> and boot it straight away, no fuss, no muss.


Any distro should be capable of doing that :)

Maybe I should just call Patrick.

Ruben
-- 
The Coin Hangout: http://www.coinhangout.com/home

[toc] | [prev] | [next] | [standalone]

#14129

On 17.3.15 20:06, ruben safir wrote:
> On 03/17/2015 10:10 AM, Tauno Voipio wrote:
>>
>> Please get a bit more specific what you're attempting to achieve.
>> We should be convinced that you're not looking for a quick way
>> to produce malware or break the kernel licensing conditions.
>>
>> It seems to me that you're not yet up to the task. For starters,
>> you should get a good book about the Linux kernel, and read it.
>
> There is no doubt about that, hence the question.  Reading that text
> might not help much either.  I read it a  LONG time ago, and is sitting
> open on my table right now.
>
> If you want background, and you shouldn't need it, but if you want it,
> I'll tell you that after using GNU systems since 1998 and taking many
> advanced Programming classes in C, C++ Oracle etc, I decided to go back
> for a masters degree in Comp Sci.  So here I am.  I have an assignment
> to create an run an alternate Linux Scheduler but I found that compiling
> Linux Kernels is not as easy as it had in the past.  The config file
> that you get with make xconfig are enormous, and I forgot about grub.
>
> So I need to develop a completely experimental and probably useless
> linux scheduler and test it.   But there is not even Linux Source code
> any longer in the distros I'm looking at, which happens to be
> Manjaro/Arch.
>
> And I'm left with a few questions that I never really thought of before.
>
> make xconfig
> make
> make modules
> make modules_install
> make install
>
>
> there used to be a make lilo
>
> This is the procedure that I have generally used over the years.  It
> never occurred to me ask how does a module get into make xconfig?
>
> And how can I best handle multiple kernels with grub.
>
>
> Is that a clearer question?
>
> If you just want to answer with RTFM, no need.  You would have to be an
> idiot to make this your sole source of information on this topic.
>
> FWIW, the book that the course uses is Operating Systems Concepts 9th Ed
> Silbershatz et al.


I had a birthday party last June, for the fiftieth anniversary of
the first bug I created, on an IBM 1620. I've been writing O/S code well 
before Linux (regards from Helsinki, the birth city of Linux).

Your questions were so vague that there was no way to see what is
your level, just 'stuck with grub'. There was no reference to the
platform, nor if you *have* read the manual. Of course, we maybe
could guess that it is a PC, as Grub is mostly used there.

For multiple kernels, you can create separate stanzas for each
in the Grub configuration. Another possibility is to hand-boot
each using the Grub command-line interface.

If you want to really do everything yourself, have a look at LFS
<http://www.linuxfromscratch.org/>.

-- 

Tauno Voipio
MSEE

[toc] | [prev] | [next] | [standalone]

#14136

On 2015-03-17, ruben safir <dont@email.me> wrote:
> I suppose the advise I was looking for was what is folks best experience 
> to handling custom kernel builds and hacking, including the alerations 
> that have to happen in grub

In my limited experience (and none compiling kernels), GRUB2 is pretty
good at finding what exists that can be booted.  After compilng your
kernels, and creating any initrds needed, run update-grub, if I recall
correctly, and it should add your new kernel to the boot options in
grub.cfg.
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

[toc] | [prev] | [next] | [standalone]

#14183

On Wed, 18 Mar 2015 03:35:23 +0000, Chick Tower wrote:

> In my limited experience (and none compiling kernels), GRUB2 is pretty
> good at finding what exists that can be booted.  After compilng your
> kernels, and creating any initrds needed, run update-grub, if I recall
> correctly, and it should add your new kernel to the boot options in
> grub.cfg.


How do you create the initrds?  They actually using initramfs FWIW

Ruben



-- 
The Coin Hangout: http://www.coinhangout.com/home

[toc] | [prev] | [next] | [standalone]

#14197

ruben safir <dont@email.me> wrote:
> On Wed, 18 Mar 2015 03:35:23 +0000, Chick Tower wrote:
> 
>> In my limited experience (and none compiling kernels), GRUB2 is pretty
>> good at finding what exists that can be booted.  After compilng your
>> kernels, and creating any initrds needed, run update-grub, if I recall
>> correctly, and it should add your new kernel to the boot options in
>> grub.cfg.
> 
> 
> How do you create the initrds?  They actually using initramfs FWIW
> 
> Ruben

If you build all of the modules necessary for booting and accessing
the root FS into the kernel you don't need an initrd. Without an
initrd you need to specify the root device on the kernel caommand line
as root=/dev/<something>, you can't use a label or uuid. ALso the
distribution's userspace must not be expecting anything to be mounted
or started by the initrd. Slackware fulfils these requirements, some
other distros may not.

As for grub2, just edit /boot/grub/grub.conf and add a stanza for your
kernel, you'll probably have to anyway unless whatever kernel command
line the crap in /etc/grub generates will work.

[toc] | [prev] | [next] | [standalone]

#14199

On Sat, 21 Mar 2015 20:19:05 +0000, Jerry Peters wrote:

> As for grub2, just edit /boot/grub/grub.conf and add a stanza for your
> kernel, you'll probably have to anyway unless whatever kernel command
> line the crap in /etc/grub generates will work.

All my most experienced freinds say this, which is what brought me here 
in the first place.  I found it hard to believe that the big Kernel 
hackers that worlk 10 hours a day on the Kernel are hacking grub.cfg :)

ruben



-- 
The Coin Hangout: http://www.coinhangout.com/home

[toc] | [prev] | [next] | [standalone]

#14214

ruben safir <dont@email.me> wrote:
> On Sat, 21 Mar 2015 20:19:05 +0000, Jerry Peters wrote:
> 
>> As for grub2, just edit /boot/grub/grub.conf and add a stanza for your
>> kernel, you'll probably have to anyway unless whatever kernel command
>> line the crap in /etc/grub generates will work.
> 
> All my most experienced freinds say this, which is what brought me here 
> in the first place.  I found it hard to believe that the big Kernel 
> hackers that worlk 10 hours a day on the Kernel are hacking grub.cfg :)
> 
> ruben
> 

Why? Depending on your particular workflow you can just add a few
entries to grub.cfg and reuse them as necessary.

My old technique, used with grub1, was to create symlinks to the
current working kernel and another to the test kernel. The
/etc/grub/conf file contained entries for both symlinks, change where
the symlinks point and you select a different kernel, no need to edit
the config file itself.

Current technique is to let grub2 find all of the kernels at boot
time. I still use the symlinks, but only as a convenience.

[toc] | [prev] | [next] | [standalone]

#14220

On 03/22/2015 04:05 PM, Jerry Peters wrote:
> ruben safir <dont@email.me> wrote:
>> On Sat, 21 Mar 2015 20:19:05 +0000, Jerry Peters wrote:
>>
>>> As for grub2, just edit /boot/grub/grub.conf and add a stanza for your
>>> kernel, you'll probably have to anyway unless whatever kernel command
>>> line the crap in /etc/grub generates will work.
>>
>> All my most experienced freinds say this, which is what brought me here 
>> in the first place.  I found it hard to believe that the big Kernel 
>> hackers that worlk 10 hours a day on the Kernel are hacking grub.cfg :)
>>
>> ruben
>>
> 
> Why? Depending on your particular workflow you can just add a few
> entries to grub.cfg and reuse them as necessary.
> 
> My old technique, used with grub1, was to create symlinks to the
> current working kernel and another to the test kernel. The
> /etc/grub/conf file contained entries for both symlinks, change where
> the symlinks point and you select a different kernel, no need to edit
> the config file itself.
> 
> Current technique is to let grub2 find all of the kernels at boot
> time. I still use the symlinks, but only as a convenience.
> 


I have no idea and I'm not even sure what you are saying here.  The file
itself says that it should not be hacked.  Grub2 has update-grub.  the
initramfs are made from preset files using mkinitcpio

I wish I knew how to use the manjaro package tools directly.

[toc] | [prev] | [next] | [standalone]

#14234

ruben safir <ruben@mrbrklyn.com> wrote:
> On 03/22/2015 04:05 PM, Jerry Peters wrote:
>> ruben safir <dont@email.me> wrote:
>>> On Sat, 21 Mar 2015 20:19:05 +0000, Jerry Peters wrote:
>>>
>>>> As for grub2, just edit /boot/grub/grub.conf and add a stanza for your
>>>> kernel, you'll probably have to anyway unless whatever kernel command
>>>> line the crap in /etc/grub generates will work.
>>>
>>> All my most experienced freinds say this, which is what brought me here 
>>> in the first place.  I found it hard to believe that the big Kernel 
>>> hackers that worlk 10 hours a day on the Kernel are hacking grub.cfg :)
>>>
>>> ruben
>>>
>> 
>> Why? Depending on your particular workflow you can just add a few
>> entries to grub.cfg and reuse them as necessary.
>> 
>> My old technique, used with grub1, was to create symlinks to the
>> current working kernel and another to the test kernel. The
>> /etc/grub/conf file contained entries for both symlinks, change where
>> the symlinks point and you select a different kernel, no need to edit
>> the config file itself.
>> 
>> Current technique is to let grub2 find all of the kernels at boot
>> time. I still use the symlinks, but only as a convenience.
>> 
> 
> 
> I have no idea and I'm not even sure what you are saying here.  The file
> itself says that it should not be hacked.  Grub2 has update-grub.  the
> initramfs are made from preset files using mkinitcpio

It's *my* computer, I'll edit whatever files I darn well please.

What I'm saying is that I've been building my own kernels on Slackware
for over 15 years, I have an infrastructure in place to make it
convenient for me. Part of that infrastructure is custom a grub2 config
which lists all of the kernels it finds in /boot in the menu during
the boot.
Update-grub and all of the crap in /etc/grub is disabled.

I posted the grub2 shell scripts in comp.os.linux.misc on Dec 13,
2014.

> 
> I wish I knew how to use the manjaro package tools directly.

So look at the documentation, then start looking at whatever
scripts are provided.  Experiment with them and see what happens, just
be sure you have a saved kernel you can boot from, even if you have to
type the commands into the grub command prompt.

If you're going to hack the scheduler you really need to get used to
trying, and perhaps breaking things.

[toc] | [prev] | [next] | [standalone]

#14244

On Mon, 23 Mar 2015 20:27:48 +0000, Jerry Peters wrote:

> What I'm saying is that I've been building my own kernels on Slackware
> for over 15 years, I have an infrastructure in place to make it
> convenient for me. Part of that infrastructure is custom a grub2 config
> which lists all of the kernels it finds in /boot in the menu during the
> boot.
> Update-grub and all of the crap in /etc/grub is disabled.

that is pretty much exactly what I'm asking.  Thanks.
I'm trying to gleen from your experience.

Ruben



-- 
The Coin Hangout: http://www.coinhangout.com/home

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web