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

Groups > comp.os.linux.hardware > #2756 > unrolled thread

Any Kernel Hackers in the house

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

Contents

  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

Page 1 of 2  [1] 2  Next page →

#2756 — Any Kernel Hackers in the house

Hello

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


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] | [next] | [standalone]

#2757

GRUB 2 works like this:

/etc/default/grub contains customization; /etc/grub.d/ scripts contain GRUB menu information and operating system boot scripts. When the update-grub command is run, it reads the contents of the grub file and the grub.d scripts and creates the grub.cfg file.

That's all.

To change the grub.cfg file, you need to edit the grub file or the scripts under grub.d.

Scripts are meant to be executed. This means that they have the execute bit turned on. If you turn the execute bit off, they will not run.

This means that you can place as many files as you want into the grub.d directory, as long as they are not executable shell scripts that update-grub can read. If you want to use them, you will activate the executable bit, or vice versa, turn it off.

Let's examine the scripts. 


Peice of cake!

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

#2758

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.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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

#2759

Aragorn a écrit :
> 
> There is a distinction between a traditional initrd (which is a cpio 
> archive) and an initramfs (which is a RAM-based root filesystem).

The other way around. Older initrd is a filesystem image written into a
ramdisk. Newer initramfs is a cpio archive extracted into a tmpfs.

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

#2794

On Sat, 21 Mar 2015 22:48:34 +0100, Pascal Hambourg wrote:

> The other way around. Older initrd is a filesystem image written into a
> ramdisk. Newer initramfs is a cpio archive extracted into a tmpfs.



what does this mean exactly?  What is the  difference.  The file will be 
in an archive.  what is the difference between tmpfs and a ramdisk?

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

#2798

On Monday 20 April 2015 11:11, ruben conveyed the following to 
comp.os.linux.hardware...

> On Sat, 21 Mar 2015 22:48:34 +0100, Pascal Hambourg wrote:
> 
>> The other way around. Older initrd is a filesystem image written into
>> a ramdisk. Newer initramfs is a cpio archive extracted into a tmpfs.
> 
> what does this mean exactly?  What is the  difference.  The file will
> be in an archive.  what is the difference between tmpfs and a ramdisk?

A ramdisk is a block device which exists in RAM and is (usually) static 
in size, whereas a tmpfs exists in virtual memory ─ which means that its 
contents can be paged out to disk ─ and only consumes as much virtual 
memory as per the value of whatever is stored on it.  

If you create a tmpfs with nothing on it, then it won't consume any 
virtual memory (apart from an inode for its root directory).

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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

#2801

Aragorn a écrit :
> 
> A ramdisk is a block device which exists in RAM and is (usually) static 
> in size, whereas a tmpfs exists in virtual memory

To complete, a tmpfs is not a block device but a filesystem, and exists
only when it is mounted. A ramdisk does not need to be mounted to exist
and can contain any kind of data structure that can be stored in a block
device, including but not limited to disk-based filesystems (ext4, btrfs...)

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

#2802

On 04/21/2015 06:40 PM, Pascal Hambourg wrote:
> Aragorn a écrit :
>>
>> A ramdisk is a block device which exists in RAM and is (usually) static 
>> in size, whereas a tmpfs exists in virtual memory
> 
> To complete, a tmpfs is not a block device but a filesystem, and exists
> only when it is mounted. A ramdisk does not need to be mounted to exist
> and can contain any kind of data structure that can be stored in a block
> device, including but not limited to disk-based filesystems (ext4, btrfs...)
> 


what is the difference between virtual memory and ram?

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

#2803

On 04/22/2015 05:38 AM, ruben safir wrote:
> On 04/21/2015 06:40 PM, Pascal Hambourg wrote:
>> Aragorn a écrit :
>>>
>>> A ramdisk is a block device which exists in RAM and is (usually) static 
>>> in size, whereas a tmpfs exists in virtual memory
>>
>> To complete, a tmpfs is not a block device but a filesystem, and exists
>> only when it is mounted. A ramdisk does not need to be mounted to exist
>> and can contain any kind of data structure that can be stored in a block
>> device, including but not limited to disk-based filesystems (ext4, btrfs...)
>>
> 
> 
> what is the difference between virtual memory and ram?
> 
nevermind - sorry

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

#2761

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

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

#2763

On Saturday 21 March 2015 22:52, Baho Utot conveyed the following to 
comp.os.linux.hardware...

> On 03/21/15 14:04, Aragorn wrote:
>
>> 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.

Well, as I said before, I have both technical and political objections 
against FreeBSD.  And nobody says you have to accept a distribution that 
uses systemd.  Gentoo supports systemd but still uses openrc as the 
default, and there is even a Gentoo-created fork of udev which does not 
play into the whole systemd thing.

Also, people who prefer GNOME ─ I'm not one of them, and I've never 
liked GNOME ─ cannot use FreeBSD anymore because GNOME (and specifically 
GDM) now requires that systemd be installed.  And systemd does not 
support anything other than a Linux-based system.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

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

#2760

Hello,

ruben safir a écrit :
> 
> I'm really struggling with compiling the kerne.  Actually installing it is the 
> trouble.

(cut)

Your subject is misleading. It has nothing to do with kernel hacking.

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

#2762

On 03/21/2015 05:50 PM, Pascal Hambourg wrote:
> Hello,
> 
> ruben safir a écrit :
>>
>> I'm really struggling with compiling the kerne.  Actually installing it is the 
>> trouble.
> 
> (cut)
> 
> Your subject is misleading. It has nothing to do with kernel hacking.
> 


Do you regularly hack on the kernel?  I would like to know how you
handle grub2 and initramfs after every compile.  If you are doing this
all the time, you must have developed a method to do this compfortably,
flexibly and quickly.

Ruben

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

#2764

ruben safir <ruben@mrbrklyn.com> wrote:
>I would like to know how you
>handle grub2 and initramfs after every compile.  If you are doing this
>all the time, you must have developed a method to do this compfortably,
>flexibly and quickly.

My distribution does that for me. Install the kernel package,
everything goes automatically.

Greetings
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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

#2795

On Sat, 21 Mar 2015 22:50:23 +0100, Pascal Hambourg wrote:


> Your subject is misleading. It has nothing to do with kernel hacking.



Your right.  It has nothing t do with kernel hacking as long as you don't 
care if your hacked kernel can be booted and tested.

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

#2765

ruben safir <dont@email.me> writes:
> 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

Upstream Grub behavior is to search for x86/64 kernels using the
following patterns:

  /boot/vmlinuz-* /vmlinuz-* /boot/kernel-*

/boot/vmlinuz does not match any of these patterns, so it is not
detected.

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

This is nothing to do with kernel development.  It’s just about working
out how Grub works.  In this case that’s basically a matter of reading
shell scripts.

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

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

#2796

On Sun, 22 Mar 2015 10:28:22 +0000, Richard Kettlewell wrote:

> Upstream Grub behavior is to search for x86/64 kernels using the
> following patterns:


what do you mean by upstream?  This is correct, but I don't see this in 
the grub man pages.

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

#2797

ruben <ceo@iran.gov> writes:
> Richard Kettlewell wrote:
>> Upstream Grub behavior is to search for x86/64 kernels using the
>> following patterns:
>
> what do you mean by upstream?  This is correct, but I don't see this
> in the grub man pages.

I mean https://www.gnu.org/software/grub/ rather than whatever changes,
if any, your distributor may have made.

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

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

#2799

On 04/20/2015 05:37 AM, Richard Kettlewell wrote:
> ruben <ceo@iran.gov> writes:
>> Richard Kettlewell wrote:
>>> Upstream Grub behavior is to search for x86/64 kernels using the
>>> following patterns:
>>
>> what do you mean by upstream?  This is correct, but I don't see this
>> in the grub man pages.
> 
> I mean https://www.gnu.org/software/grub/ rather than whatever changes,
> if any, your distributor may have made.
> 


I couldn't find documentation on that on the website, which is why I
came back the newsgroup.

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

#2800

ruben safir <ruben@mrbrklyn.com> writes:
> Richard Kettlewell wrote:
>> ruben <ceo@iran.gov> writes:
>>> Richard Kettlewell wrote:
>>>> Upstream Grub behavior is to search for x86/64 kernels using the
>>>> following patterns:
>>>
>>> what do you mean by upstream?  This is correct, but I don't see this
>>> in the grub man pages.
>> 
>> I mean https://www.gnu.org/software/grub/ rather than whatever changes,
>> if any, your distributor may have made.
>
> I couldn't find documentation on that on the website, which is why I
> came back the newsgroup.

You asked what upstream was rather than where the documentation was.
But I don’t think you can have looked very hard: if you click on
‘Documentation’ at the above URL and then follow the link at ‘The
current version is available in a number of formats’ and then select
your preferred format you will find the Grub manual.

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web