You are not logged in.

#26 2009-02-27 04:11:06

broch
Banned
From: L.A. California
Registered: 2006-11-13
Posts: 975

Re: Kernel building with abs is convoluted

f4hy wrote:

Um.. no it doesn't again. Read my post a like 3 posts ago. I explain specifically how localversion does not allow to install in parallel with the abs version.

you have two files to modify, not one
one concerns /lib/modules
second vmlinuz, kernel26 and System.map


Ye exactly! Can you teach me B?

this is easy:
du -sh /lib/modules/2.6.28.7-slim
2.6M    /lib/modules/2.6.28.7-slim

however if you add nvidia or ati module the minimum size will grow up to 10MB. nvidia module takes 7.6MB. This means that if directory is smaller that this nvidia or ati driver was not installed.

Offline

#27 2009-02-27 04:12:33

f4hy
Member
From: Pittsburgh Pa
Registered: 2009-02-08
Posts: 55

Re: Kernel building with abs is convoluted

My point was that neither of them change vmlinuz, kernel26, and System.map. Not the one from abs.

Offline

#28 2009-02-27 04:36:48

broch
Banned
From: L.A. California
Registered: 2006-11-13
Posts: 975

Re: Kernel building with abs is convoluted

file 1
PKGBUILD
.....
cp System.map ${pkgdir}/boot/System.map26
cp arch/$KARCH/boot/bzImage ${pkgdir}/boot/vmlinuz26

replace with
cp System.map ${pkgdir}/boot/System.map261
cp arch/$KARCH/boot/bzImage ${pkgdir}/boot/vmlinuz261

file 2
kernel26.install (change kernel26.img created by /sbin/mkinitcpio -p kernel26)
search for
kernel26
and replace with
kernel261
(not all of it)

file 3 (change to /lib/modules)
config
search for
CONFIG_LOCALVERSION="-ARCH"
replace with
CONFIG_LOCALVERSION="-custom"
will generate
/lib/modules/2.6.28.7-custom

adjust grub/lilo

Offline

#29 2009-02-27 04:44:20

f4hy
Member
From: Pittsburgh Pa
Registered: 2009-02-08
Posts: 55

Re: Kernel building with abs is convoluted

Thank you, that is what one would have to do to build from abs. However my point is that it is not simple (yes it is a simple change but it is not clear as the length of this thread indicates) and not documented. One can hack the PKGBUILD to do what you want but it does not do this by default. If I have to go and change the cp command to the name of the new kernel for each new kernel, why bother doing it with abs at all? I can just build manually and cp vmlinuz myself. If what you just posted here is what was displayed on the wiki I would have no arguments as it is a perfectly valid way to build the kernel with abs, but there currently is no documentation for this.

Offline

#30 2009-02-27 04:51:34

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Kernel building with abs is convoluted

This is _exactly_ what my proposition was about in http://bugs.archlinux.org/task/12384 ... Just adding "-custom" to the pkgname would take care of that without editing further the pkgbuild...

Offline

#31 2009-02-27 05:14:46

broch
Banned
From: L.A. California
Registered: 2006-11-13
Posts: 975

Re: Kernel building with abs is convoluted

1) it was not clear what do you mean that localversion does not change anything. It does.
2) adding  "-custom"
will not really resolve anything. What if one wants to build several versions of the same kernel?

one way or another you need to modify something: when you are using ABS or build from vanilla.
Because I don't see any advantage of using ABS with exception of adding one script on top of another I use vanilla with whatever patches I want. ABS has some advantages for someone just trying/learning building custom kernels but that is about it.

why it is not simpler?
because it has to fit most of the universal requirements. Same as default kernel. And it works. However if you want something specific then it is up to you to customize (that is the word) setup.

Personally I do not understand users complaints about customizing kernels. If one does not like ABS build from sources (for whatever reason a lot of users think that ABS is a proper way in contrast to vanilla which is obviously incorrect), or the other way around. If someone does not understand how and why, read and learn.

Offline

#32 2009-02-27 05:18:32

f4hy
Member
From: Pittsburgh Pa
Registered: 2009-02-08
Posts: 55

Re: Kernel building with abs is convoluted

I agree that building without abs is the best way. However the wiki suggests that the preferred way to build kernels is with abs. This thread was just to bring up that building with abs is messy and not simple and the wiki has very confusing information about it.

Offline

#33 2009-02-27 06:36:01

mikesd
Member
From: Australia
Registered: 2008-02-01
Posts: 788
Website

Re: Kernel building with abs is convoluted

I haven't used anything but the stock kernel on arch for a long time. When I do play with alternative kernels I much prefer to build them manually. The one thing that I find akward is the nvidia binary blob driver. If I use a custom kernel I can no longer use the stock nvidia driver. In the past I have used ABS to make a kernel package and a matching nvidia package. If it wasn't for that I would just build and install kernels manually.

Offline

#34 2009-02-27 07:54:11

somedrew
Member
From: Canada
Registered: 2007-05-14
Posts: 140

Re: Kernel building with abs is convoluted

mikesd wrote:

The one thing that I find akward is the nvidia binary blob driver. If I use a custom kernel I can no longer use the stock nvidia driver.

Editing the nvidia PKGBUILD for a unique $pkgname & appropriate $_kernver allows for easy building and installation of multiple blobs for each $_kernver. The only catch is you'll need each blob to be the same version as your installed nvidia-utils unless you want to do some fooling around.

cheers,

Offline

#35 2009-02-27 08:17:51

mikesd
Member
From: Australia
Registered: 2008-02-01
Posts: 788
Website

Re: Kernel building with abs is convoluted

somedrew wrote:
mikesd wrote:

The one thing that I find akward is the nvidia binary blob driver. If I use a custom kernel I can no longer use the stock nvidia driver.

Editing the nvidia PKGBUILD for a unique $pkgname & appropriate $_kernver allows for easy building and installation of multiple blobs for each $_kernver. The only catch is you'll need each blob to be the same version as your installed nvidia-utils unless you want to do some fooling around.

cheers,

Hmmm. Might have to try that sometime. For the most part the stock kernels do everything I need. The only thing that tempted me recently was 2.6.28 when ext4 went mainline. In the end I just waited for it to go into core.

Offline

#36 2009-02-27 13:35:25

broch
Banned
From: L.A. California
Registered: 2006-11-13
Posts: 975

Re: Kernel building with abs is convoluted

mikesd wrote:

I haven't used anything but the stock kernel on arch for a long time. When I do play with alternative kernels I much prefer to build them manually. The one thing that I find akward is the nvidia binary blob driver. If I use a custom kernel I can no longer use the stock nvidia driver. In the past I have used ABS to make a kernel package and a matching nvidia package. If it wasn't for that I would just build and install kernels manually.

personally, I prefer to install nvidia from nvidia site. Arch script does not allow to install video driver on all kernels installed. You can install only one nvidia module. This is quite annoying as you need to re-install nvidia after you boot to the next kernel while using original nvidia installer I can install driver for all kernels and when I switch from one to another it takes me to GUI. I am talking about installing nvidia driver for offline kernels.

Offline

#37 2009-02-27 21:03:50

methuselah
Member
Registered: 2007-10-02
Posts: 570

Re: Kernel building with abs is convoluted

I'm going to start this off by pointing out the way that I'm about to describe is PROBABLY NOT the proper way to do this, but it has worked for me for the last 8 months of kernel building with no breakages and multiple kernels of different names/versions/patches.


First check out the AUR package that I linked in my post #8: http://aur.archlinux.org/packages.php?ID=23467


I created this package but kludge is maintaining it now and probably making it better..... It's basically the way that I taught myself to make a parallel kernel that wouldn't damage my stock -ARCH kernel26 when all of the wiki guides weren't working for me.


It might help you to look at the how every file is written for that package (use gnome's "Meld" app to compare the files to the ABS kernel26 files).

Meld: http://www.archlinux.org/packages/?q=meld

Compare these AUR kernel26parallel files with the current ABS kernel26 files:

PKGBUILD
kernel26parallel.install
kernel26parallel.preset
config or config.x86_64 (for the local version = -ARCHparallel).....


As for the patch, kludge is doing it in a different way than I did, I would usually download the current -ARCH patch: wget -c ftp://ftp.archlinux.org/other/kernel26/ … 1-ARCH.bz2


.... and use the "Mousepad" find/replace feature (ctrl +H) to change every part of the patch that used -ARCH with -ARCHparallel. It's simple for me to just use the find/replace 'ctrl + h' with 'Match Case' and 'Replace all at once' set to replace the 908 -ARCH parts with -ARCHparallel.


Then I change the name of the patch to patch-2.6.28.7-1-ARCHparallel


adjust all of the md5sums and then build the new kernel (using make menuconfig in the PKGBUILD).



This is how I am able to build a separate kernel that doesn't overwrite anything when you depmod or install:

/boot/kernel26parallel.img
/boot/kernel26parallel-fallback.img
/boot/vmlinuz26paralle
/boot/Systemmap26parallel
/usr/src/linux-2.6.28-ARCHparallel
/lib/modules/2.6.28-ARCHparallel
/etc/mkinitcpio.d/kernel26parallel.preset
/etc/mkinitcpio.d/kernel26parallel.kver



You could also change the patch to any linux patch and just edit the names to be different (like: -mm or -zen)


Of course this is a simple manual way that I am able to build parallel kernels, I would prefer to know how to write an actual script that automates all of this like big_gie is able to do.


Since kludges package is different than the one I created, I'll post my latest PKGBUILD so you can see how I did the patch part:

# $Id: PKGBUILD 23223 2009-01-06 10:22:31Z tpowa $
# Maintainer: Tobias Powalowski <tpowa@archlinux.org>
# Maintainer: Thomas Baechler <thomas@archlinux.org>
# -ARCHparallel rename: methuselah <newb@nerdshack.com>
pkgname=kernel26parallel
_basekernel=2.6.28
pkgver=2.6.28.7
pkgrel=1
_patchset="-ARCHparallel"
pkgdesc="The Linux Kernel and modules"
arch=(i686 x86_64)
license=('GPL2')
groups=('base')
url="http://www.kernel.org"
backup=(etc/mkinitcpio.d/${pkgname}.preset)
depends=('coreutils' 'module-init-tools' 'mkinitcpio>=0.5.20')
# pwc, ieee80211 and hostap-driver26 modules are included in kernel26 now
# nforce package support was abandoned by nvidia, kernel modules should cover everything now.
# kernel24 support is dropped since glibc24
replaces=('kernel24' 'kernel24-scsi' 'kernel26-scsi'
          'alsa-driver' 'ieee80211' 'hostap-driver26'
          'pwc' 'nforce' 'squashfs' 'unionfs' 'ivtv'
          'zd1211' 'kvm-modules' 'iwlwifi' 'rt2x00-cvs'
          'gspcav1' 'atl2' 'wlan-ng26')
install=kernel26parallel.install
source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$_basekernel.tar.bz2
        patch-2.6.28.7-1-ARCHparallel
        config.x86_64
        kernel26parallel.preset
    kernel26parallel.install)
optdepends=('crda: to set the correct wireless channels of your country')
md5sums=('d351e44709c9810b85e29b877f50968a'
     '28573513c3033d24c21aeb0cbe107c5f'
     '04b777e2aaf5a81b9cf7c3519d1cc66d'
         '968d82dc0acdd7d12f46a9cece7510a1'
     '4c40908b172c924b2b316ea7ad90d2e2')

build() {
  KARCH=x86

  cd ${srcdir}/linux-$_basekernel
  # Add -ARCHparallel patches
  # See http://projects.archlinux.org/git/?p=linux-2.6-ARCHparallel.git;a=summary
  patch -Np1 -i ${srcdir}/patch-2.6.28.7-1-ARCHparallel || return 1

  if [ "$CARCH" = "x86_64" ]; then
    cat ../config.x86_64 >./.config
  else
    cat ../config >./.config
  fi
  # get kernel version  
  make prepare
  _kernver="${_basekernel}${_patchset}"
  # load configuration
  make menuconfig
  # build!
  ####################
  # stop here
  # this is useful to configure the kernel
  #msg "Stopping build"
  #return 1
  ####################
  make bzImage modules || return 1
  mkdir -p ${pkgdir}/{lib/modules,boot}
  make INSTALL_MOD_PATH=${pkgdir} modules_install || return 1
  cp System.map ${pkgdir}/boot/System.map26parallel
  cp arch/$KARCH/boot/bzImage ${pkgdir}/boot/vmlinuz26parallel
  install -D -m644 Makefile \
    ${pkgdir}/usr/src/linux-${_kernver}/Makefile
  install -D -m644 kernel/Makefile \
    ${pkgdir}/usr/src/linux-${_kernver}/kernel/Makefile
  install -D -m644 .config \
    ${pkgdir}/usr/src/linux-${_kernver}/.config
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/include

  for i in acpi asm-{generic,x86} config linux math-emu media net pcmcia scsi sound video; do
    cp -a include/$i ${pkgdir}/usr/src/linux-${_kernver}/include/
  done

  # copy arch includes for external modules
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/arch/x86
  cp -a arch/x86/include ${pkgdir}/usr/src/linux-${_kernver}/arch/x86/

  # copy files necessary for later builds, like nvidia and vmware
  cp Module.symvers ${pkgdir}/usr/src/linux-${_kernver}
  cp -a scripts ${pkgdir}/usr/src/linux-${_kernver}
  # fix permissions on scripts dir
  chmod og-w -R ${pkgdir}/usr/src/linux-${_kernver}/scripts
  #mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/.tmp_versions

  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/arch/$KARCH/kernel

  cp arch/$KARCH/Makefile ${pkgdir}/usr/src/linux-${_kernver}/arch/$KARCH/
  if [ "$CARCH" = "i686" ]; then
    cp arch/$KARCH/Makefile_32.cpu ${pkgdir}/usr/src/linux-${_kernver}/arch/$KARCH/
  fi
  cp arch/$KARCH/kernel/asm-offsets.s ${pkgdir}/usr/src/linux-${_kernver}/arch/$KARCH/kernel/

  # add headers for lirc package
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/drivers/media/video
  cp drivers/media/video/*.h  ${pkgdir}/usr/src/linux-${_kernver}/drivers/media/video/
  for i in bt8xx cpia2 cx25840 cx88 em28xx et61x251 pwc saa7134 sn9c102 usbvideo zc0301; do
   mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/drivers/media/video/$i
   cp -a drivers/media/video/$i/*.h ${pkgdir}/usr/src/linux-${_kernver}/drivers/media/video/$i
  done
  # add dm headers
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/drivers/md
  cp drivers/md/*.h  ${pkgdir}/usr/src/linux-${_kernver}/drivers/md
  # add inotify.h
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/include/linux
  cp include/linux/inotify.h ${pkgdir}/usr/src/linux-${_kernver}/include/linux/
  # add CLUSTERIP file for iptables
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/net/ipv4/netfilter/
  # add wireless headers
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/net/mac80211/
  cp net/mac80211/*.h ${pkgdir}/usr/src/linux-${_kernver}/net/mac80211/
  # add dvb headers for external modules
  # in reference to:
  # http://bugs.archlinux.org/task/9912
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/drivers/media/dvb/dvb-core
  cp drivers/media/dvb/dvb-core/*.h ${pkgdir}/usr/src/linux-${_kernver}/drivers/media/dvb/dvb-core/
  # add dvb headers for external modules
  # in reference to:
  # http://bugs.archlinux.org/task/11194
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/include/config/dvb/
  cp include/config/dvb/*.h ${pkgdir}/usr/src/linux-${_kernver}/include/config/dvb/
  # add dvb headers for http://mcentral.de/hg/~mrec/em28xx-new
  # in reference to:
  # http://bugs.archlinux.org/task/13146
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/drivers/media/dvb/frontends/
  cp drivers/media/dvb/frontends/lgdt330x.h ${pkgdir}/usr/src/linux-${_kernver}/drivers/media/dvb/frontends/
  cp drivers/media/video/msp3400-driver.h ${pkgdir}/usr/src/linux-${_kernver}/drivers/media/dvb/frontends/
  # add xfs and shmem for aufs building
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/fs/xfs
  mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/mm
  cp fs/xfs/xfs_sb.h ${pkgdir}/usr/src/linux-${_kernver}/fs/xfs/xfs_sb.h
  # add vmlinux
  cp vmlinux ${pkgdir}/usr/src/linux-${_kernver}
  # copy in Kconfig files
  for i in `find . -name "Kconfig*"`; do 
    mkdir -p ${pkgdir}/usr/src/linux-${_kernver}/`echo $i | sed 's|/Kconfig.*||'`
    cp $i ${pkgdir}/usr/src/linux-${_kernver}/$i
  done

  cd ${pkgdir}/usr/src/linux-${_kernver}/include && ln -s asm-$KARCH asm

  chown -R root.root ${pkgdir}/usr/src/linux-${_kernver}
  find ${pkgdir}/usr/src/linux-${_kernver} -type d -exec chmod 755 {} \;
  cd ${pkgdir}/lib/modules/${_kernver} && \
    (rm -f source build; ln -sf ../../../usr/src/linux-${_kernver} build)
  # install fallback mkinitcpio.conf file and preset file for kernel
  install -m644 -D ${srcdir}/${pkgname}.preset ${pkgdir}/etc/mkinitcpio.d/${pkgname}.preset || return 1
  # set correct depmod command for install
  sed -i -e "s/KERNEL_VERSION=.*/KERNEL_VERSION=${_kernver}/g" $startdir/kernel26parallel.install
  echo -e "# DO NOT EDIT THIS FILE\nALL_kver='${_kernver}'" > ${startdir}/pkg/etc/mkinitcpio.d/${pkgname}.kver
  # remove unneeded architectures
  rm -rf ${pkgdir}/usr/src/linux-${_kernver}/arch/{alpha,arm,arm26,avr32,blackfin,cris,frv,h8300,ia64,m32r,m68k,m68knommu,mips,mn10300,parisc,powerpc,ppc,s390,sh,sh64,sparc,sparc64,um,v850,xtensa}
}

I haven't tried to build kludges version yet, maybe I don't need to edit the patch to change the name.... maybe he has made it in a simpler and better way.... but all I know is that this template of mine also works for patches like the -mm and -zen patches.


kernel26parallel.preset:

# modified file for -ARCHparallel
# mkinitcpio preset file for kernel26parallel

########################################
# DO NOT EDIT THIS LINE:
source /etc/mkinitcpio.d/kernel26parallel.kver
########################################
ALL_config="/etc/mkinitcpio.conf"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/kernel26parallel.img"
#default_options=""

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/kernel26parallel-fallback.img" 
fallback_options="-S autodetect"

kernel26parallel.install:

# edited to make -ARCHparallel
# arg 1:  the new package version
# arg 2:  the old package version

KERNEL_VERSION=2.6.28-ARCHparallel

post_install () {
  # updating module dependencies
  echo ">>> Updating module dependencies. Please wait ..."
  depmod $KERNEL_VERSION 
  # generate init ramdisks
  echo ">>> MKINITCPIO SETUP"
  echo ">>> ----------------"
  echo ">>> If you use LVM2, Encrypted root or software RAID,"
  echo ">>> Ensure you enable support in /etc/mkinitcpio.conf ."
  echo ">>> More information about mkinitcpio setup can be found here:"
  echo ">>> http://wiki.archlinux.org/index.php/Mkinitcpio"
  echo ""
  echo ">>> Generating initial ramdisk, using mkinitcpio.  Please wait..."
  /sbin/mkinitcpio -p kernel26parallel
}

post_upgrade() {
  pacman -Q grub &>/dev/null
  hasgrub=$?
  pacman -Q lilo &>/dev/null
  haslilo=$?
  # reminder notices
  if [ $haslilo -eq 0 ]; then
    echo ">>>"
    if [ $hasgrub -eq 0 ]; then
      echo ">>> If you use the LILO bootloader, you should run 'lilo' before rebooting."
    else
      echo ">>> You appear to be using the LILO bootloader. You should run"
      echo ">>> 'lilo' before rebooting."
    fi
    echo ">>>"
  fi

  if grep "/boot" /etc/fstab 2>&1 >/dev/null; then
    if ! grep "/boot" /etc/mtab 2>&1 >/dev/null; then
      echo "WARNING: /boot appears to be a seperate partition but is not mounted"
      echo "         This is most likely not what you want.  Please mount your /boot"
      echo "         partition and reinstall the kernel unless you are sure this is OK"
    fi
  fi

  if [ "`vercmp $2 2.6.13`" -lt 0 ]; then
    # important upgrade notice
    echo ">>>"
    echo ">>> IMPORTANT KERNEL UPGRADE NOTICE"
    echo ">>> -------------------------------"
    echo ">>> As of kernel 2.6.13, DevFS is NO LONGER AVAILABLE!"
    echo ">>> If you still use DevFS, please make the transition to uDev before"
    echo ">>> rebooting.  If you really need to stay with DevFS for some reason,"
    echo ">>> then you can manually downgrade to an older version:"
    echo ">>>"
    echo ">>> # pacman -U http://archlinux.org/~judd/kernel/kernel26-scsi-2.6.12.2-1.pkg.tar.gz"
    echo ">>>"
    echo ">>> If you choose to downgrade, don't forget to add kernel26-scsi to your"
    echo ">>> IgnorePkg list in /etc/pacman.conf"
    echo ">>>"
    echo ">>> (NOTE: The following portion applies to uDev users as well!)"
    echo ">>>"
    echo ">>> If you use any DevFS paths in your GRUB menu.lst, then you will not"
    echo ">>> be able to boot!  Change your root= parameter to use the classic"
    echo ">>> naming scheme."
    echo ">>>"
    echo ">>> EXAMPLES:"
    echo ">>> - change root=/dev/discs/disc0/part3 to root=/dev/sda3"
    echo ">>> - change root=/dev/md/0 to root=/dev/md0"
    echo ">>>"
  fi
  # generate new init ramdisk
  if [ "`vercmp $2 2.6.18`" -lt 0 ]; then
    echo ">>> --------------------------------------------------------------"
    echo ">>> |                          WARNING:                          |"
    echo ">>> |mkinitrd is not supported anymore in kernel >=2.6.18 series!|"
    echo ">>> |              Please change to Mkinitcpio setup.            |"
    echo ">>> --------------------------------------------------------------"
    echo ">>>"
  fi
  # updating module dependencies
  echo ">>> Updating module dependencies. Please wait ..."
  depmod $KERNEL_VERSION
  echo ">>> MKINITCPIO SETUP"
  echo ">>> ----------------"
  if [ "`vercmp $2 2.6.18`" -lt 0 ]; then
    echo ">>> Please change your bootloader config files:"
    echo ">>> Grub: /boot/grub/menu.lst | Lilo: /etc/lilo.conf"
    echo "------------------------------------------------"
    echo "| - initrd26.img to kernel26.img               |"
    echo "| - initrd26-full.img to kernel26-fallback.img |"
    echo "------------------------------------------------"
  fi
  if [ "`vercmp $2 2.6.19`" -lt 0 ]; then
    echo ""
    echo ">>> New PATA/IDE subsystem - EXPERIMENTAL"
    echo ">>> ----------"
    echo ">>> To use the new pata drivers, change the 'ide' hook "
    echo ">>> to 'pata' in /etc/mkinicpio.conf HOOKS="
    echo ">>> The new system changes: /dev/hd? to /dev/sd?"
    echo ">>> Don't forget to modify GRUB, LILO and fstab to the"
    echo ">>> new naming system. "
    echo ">>> eg: hda3 --> sda3, hdc8 --> sdc8"
    echo ""
    echo ">>> piix/ata_piix (Intel chipsets) - IMPORTANT"
    echo "----------"
    echo ">>> If you have enabled ide/pata/sata HOOKs in /etc/mkinitcpio.conf" 
    echo ">>> the 'ata_piix' module will be used."
    echo ">>> This may cause your devices to shift names, eg:"
    echo ">>> - IDE: devices from hd? to sd?"
    echo ">>> - SATA: sda might shift to sdc if you have 2 other disks on a PIIX IDE port."
    echo ">>> To check if this will affect you, check 'mkinitcpio -M' for piix/ata_piix"
    echo ""
  fi

  echo ">>> If you use LVM2, Encrypted root or software RAID,"
  echo ">>> Ensure you enable support in /etc/mkinitcpio.conf ."
  echo ">>> More information about mkinitcpio setup can be found here:"
  echo ">>> http://wiki.archlinux.org/index.php/Mkinitcpio"
  echo ""
  echo ">>> Generating initial ramdisk, using mkinitcpio.  Please wait..."
if [ "`vercmp $2 2.6.19`" -lt 0 ]; then
  /sbin/mkinitcpio -p kernel26 -m "ATTENTION:\nIf you get a kernel panic below
and are using an Intel chipset, append 'earlymodules=piix' to the
kernel commandline"
else
  /sbin/mkinitcpio -p kernel26
fi
if [ "`vercmp $2 2.6.21`" -lt 0 ]; then
  echo ""
  echo "Important ACPI Information:"
  echo ">>> Since 2.6.20.7 all possible ACPI parts are modularized."
  echo ">>> The modules are located at:"
  echo ">>> /lib/modules/$(uname -r)/kernel/drivers/acpi"
  echo ">>> For more information about ACPI modules check this wiki page:"
  echo ">>> 'http://wiki.archlinux.org/index.php/ACPI_modules'"
fi
}

op=$1
shift

$op $*

and also the edit part of the config/config.x86_64:

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION="-ARCHparallel"
CONFIG_LOCALVERSION_AUTO=y

and also so I didn't build with an old version of my config from my /proc/config.gz:

CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set

That is how I do it..... it may not be the correct way, and if it isn't please let me know.

Last edited by methuselah (2009-02-27 21:39:04)

Offline

#38 2009-02-27 21:12:26

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Kernel building with abs is convoluted

methuselah wrote:

...I would prefer to know who to write an actual script that automates all of this like big_gie is able to do.

What I have done is neither a script nor a new pkgbuild. I just changed slightly the official pkgbuild to allow anyone to modify it easily and install the new kernel "in parallel"... I'd like to see that included in the official pkgbuild.

Offline

#39 2009-02-27 21:22:25

methuselah
Member
Registered: 2007-10-02
Posts: 570

Re: Kernel building with abs is convoluted

big_gie wrote:
methuselah wrote:

...I would prefer to know how to write an actual script that automates all of this like big_gie is able to do.

What I have done is neither a script nor a new pkgbuild. I just changed slightly the official pkgbuild to allow anyone to modify it easily and install the new kernel "in parallel"... I'd like to see that included in the official pkgbuild.

Sorry, I thought you had made a script to do that. Check my PKGBUILD out above your post..... I also have my .preset and .install files in the same way as the AUR package that I created..... as well as the config/config.x86_64 with -ARCHparallel in the LOCAL VERSION..... it's basically how I've done it for the last 8 months.

EDIT: I also added my .preset and .install files.

Last edited by methuselah (2009-02-27 21:27:11)

Offline

#40 2009-02-28 03:07:08

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Kernel building with abs is convoluted

I did not looked at what you did exactly, but I understand how you did it (I've followed its developpement). And basically, it is the same thing. I just think we should unite our work to make things better instead of having 20 different ways of doing it...

I'll take a look at your package this weekend.

Offline

#41 2009-02-28 03:48:33

iphitus
Forum Fellow
From: Melbourne, Australia
Registered: 2004-10-09
Posts: 4,927

Re: Kernel building with abs is convoluted

IMHO the wiki methods are crap and complicated.

The most Arch like way is to just build it as you would normally build a kernel, tar -zxvf, make menuconfig, make, install the bzImage manually, and then make modules_install.

Nothing in Arch conflicts with this.
This will cause no problems in pacman.
It is simple.
Nothing is gained by using a PKGBUILD other than headaches and pointless complication.

IMHO it's the most "Arch like" way to build a kernel.

Just because the PKGBUILD builds a kernel, does not mean it's the Arch way. Kernels don't fit the PKGBUILD paradigm well. The PKGBUILD and prebuilt kernel are just because of the necessity to distribute a kernel binary.

James

Last edited by iphitus (2009-02-28 03:50:57)

Offline

#42 2009-02-28 04:16:08

methuselah
Member
Registered: 2007-10-02
Posts: 570

Re: Kernel building with abs is convoluted

big_gie wrote:

I did not looked at what you did exactly, but I understand how you did it (I've followed its developpement). And basically, it is the same thing. I just think we should unite our work to make things better instead of having 20 different ways of doing it...

I'll take a look at your package this weekend.

kludge has taken over that AUR package (he does the patch and the config files differently than I do..... I had stopped using the /proc/config.gz setting). Definitely give his AUR package a look and have a talk with him about combining your efforts for a package and/or a wiki page.


I orphaned that AUR package after the first version because I didn't get too much interest in it and I plan on being really busy soon..... so I won't be able to maintain it on time for every upgrade.


I really hope the two of you create a package or an ArchWiki page that I can link people to. It's a lot easier to post a link to something rather than try to explain it. I see this question all the time, and not just in this forum.

Offline

#43 2009-02-28 06:24:31

f4hy
Member
From: Pittsburgh Pa
Registered: 2009-02-08
Posts: 55

Re: Kernel building with abs is convoluted

iphitus wrote:

IMHO the wiki methods are crap and complicated.

The most Arch like way is to just build it as you would normally build a kernel, tar -zxvf, make menuconfig, make, install the bzImage manually, and then make modules_install.

Nothing in Arch conflicts with this.
This will cause no problems in pacman.
It is simple.
Nothing is gained by using a PKGBUILD other than headaches and pointless complication.

IMHO it's the most "Arch like" way to build a kernel.

Just because the PKGBUILD builds a kernel, does not mean it's the Arch way. Kernels don't fit the PKGBUILD paradigm well. The PKGBUILD and prebuilt kernel are just because of the necessity to distribute a kernel binary.

James

I totally agree. I started this thread hoping someone would show a sane way to build with PKGBUILD but it has only showed me the only way that makes sense is to do it manually.

Offline

#44 2009-02-28 07:54:02

methuselah
Member
Registered: 2007-10-02
Posts: 570

Re: Kernel building with abs is convoluted

f4hy wrote:
iphitus wrote:

IMHO the wiki methods are crap and complicated.

The most Arch like way is to just build it as you would normally build a kernel, tar -zxvf, make menuconfig, make, install the bzImage manually, and then make modules_install.

Nothing in Arch conflicts with this.
This will cause no problems in pacman.
It is simple.
Nothing is gained by using a PKGBUILD other than headaches and pointless complication.

IMHO it's the most "Arch like" way to build a kernel.

Just because the PKGBUILD builds a kernel, does not mean it's the Arch way. Kernels don't fit the PKGBUILD paradigm well. The PKGBUILD and prebuilt kernel are just because of the necessity to distribute a kernel binary.

James

I totally agree. I started this thread hoping someone would show a sane way to build with PKGBUILD but it has only showed me the only way that makes sense is to do it manually.

Check out my post #37 for an easy way. (sounds worse than it actually is)

If you want to do it this way you can use those 3 files (PKGBUILD, .install and .preset) and put them into a build directory.

Then download the official -ARCH patch:

wget -c ftp://ftp.archlinux.org/other/kernel26/patch-2.6.28.7-1-ARCH.bz2

Next unpack that patch with an archive manager. Then open the patch-file with Mousepad or Gedit. Then use "ctrl + h" to find and replace all 908 "-ARCH" places with the name "-ARCHparallel" using the 'all at once' and 'match case' options of "ctrl + h".

so change all:

-ARCH

to:

-ARCHparallel


save it into the same build directory as:

patch-2.6.28.7-1-ARCHparallel


Put you default config/config.x86_64 in the directory as well.


Now open up a terminal and check each file to get the correct md5sums..... and then edit the PKGBUILD so it is correct.

example:

md5sum patch-2.6.28.7-1-ARCHparallel

Now run this to build:

makepkg -c

When in the make menuconfig menu, be sure to append the LOCAL VERSION to = -ARCHparallel


also, uncheck the /proc/config.gz option to use your new config settings. Exit/Save.


Now it should build and depmod correctly, then upload with pacman -Uf to overwrite the firmware. (or delete the firmware in the finished package).


Last step is to add the new entry into /boot/grub/menu.lst



or use kludges AUR package that does close to the same thing (might even be better).

Last edited by methuselah (2009-02-28 07:58:51)

Offline

#45 2009-02-28 20:17:13

f4hy
Member
From: Pittsburgh Pa
Registered: 2009-02-08
Posts: 55

Re: Kernel building with abs is convoluted

Ya I checked out kludges package, it seems to be a pretty good solution except that it only allows for one kernel in parallel. That is not a huge issue though. Could a mention of this method or a link to kludges AUR package be put on the wiki instread of the two choices there?

I am now curious though, what exactly is in the ARCH kernel patch? Is that documented somewhere or for each patch I just need to untar and look?

Offline

#46 2009-02-28 21:24:18

tomk
Forum Fellow
From: Ireland
Registered: 2004-07-21
Posts: 9,839

Re: Kernel building with abs is convoluted

The wiki is open to all - please feel free to make any changes yourself.

The details of the kernel patch are in our git repo: http://projects.archlinux.org/?p=linux- … ;a=summary

Offline

#47 2009-02-28 22:32:50

methuselah
Member
Registered: 2007-10-02
Posts: 570

Re: Kernel building with abs is convoluted

f4hy wrote:

Ya I checked out kludges package, it seems to be a pretty good solution except that it only allows for one kernel in parallel. That is not a huge issue though. Could a mention of this method or a link to kludges AUR package be put on the wiki instread of the two choices there?

I am now curious though, what exactly is in the ARCH kernel patch? Is that documented somewhere or for each patch I just need to untar and look?

Take the kludges package and edit all files/parts that say parallel with parallel2.

Then add a new entry to the /boot/grub/menu.lst

Offline

#48 2009-02-28 22:49:36

.:B:.
Forum Fellow
Registered: 2006-11-26
Posts: 5,819
Website

Re: Kernel building with abs is convoluted

haxit wrote:
zyghom wrote:
B wrote:
[stijn@hermes ~]$ du -hs /lib/modules/2.6.28.7-vaio/
4,7M    /lib/modules/2.6.28.7-vaio/

you killed me here: mine is 69M

Ye exactly! Can you teach me B?

Trial and error tongue. A module will take more space than an in-kernel driver, that's all I can say. So anything you use (like all the time), compile it in statically. Read the descriptions in the kernel configuration interface (make {g,x,q,}config), throw out what you don't need (start with drivers, there's tons of drivers in the Arch kernel since it's a generic one-size-fits-all kernel), track your changes (diff kernel configs). It is better to do it gradually - strip stuff you know you won't need, reboot, check if all your hardware is still recognised and functional. If yes, repeat process. After you strip the drivers you can strip filesystems and stuff (e.g. network filesystems), and check each subsystem (e.g. USB) for stuff you don't need. USB has tons of extra options and drivers you probably won't use.

Basically, recompile until you hit the wall, and use different configs (diff them, save them). It takes a while to strip the stuff if you start out, but once you're in, you're in, and to keep it maintained is usually little more than updating the PKGBUILD to the new versions used. And, if you're feeling adventurous, you can still pull in some patches from e.g. the Zen kernel (I personally don't, I mostly use stable).

And also - make sure you give your own kernel another LOCALVERSION than -ARCH wink.

To counter the arguments made against putting a kernel build in a PKGBUILD: I like the checks and automation the PKGBUILD gives you. It takes a lot of work to set up at first, but that is a one-time operation. I for one am quite sure I won't forget to drop in some patch or stuff like that, you just run the PKGBUILD, install, that's it.


Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy

Offline

#49 2009-02-28 22:57:12

f4hy
Member
From: Pittsburgh Pa
Registered: 2009-02-08
Posts: 55

Re: Kernel building with abs is convoluted

A module will take more space than an in-kernel driver, that's all I can say.

Well then it won't show up in /lib/modules will it? It will just put that into the kernel binary. So ya that will make /lib/modules smaller but your kernel binary larger.

Offline

#50 2009-03-01 00:39:05

.:B:.
Forum Fellow
Registered: 2006-11-26
Posts: 5,819
Website

Re: Kernel building with abs is convoluted

I'm talking about the relative gain smile. In-kernel a driver will take less space than as a module, so over all you'll use less space. Yes, your kernel will grow fatter, but if you look at the total picture you'll gain a few bytes wink.


Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy

Offline

Board footer

Powered by FluxBB