You are not logged in.
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
My point was that neither of them change vmlinuz, kernel26, and System.map. Not the one from abs.
Offline
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
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
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
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
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
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
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
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
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
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
...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
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
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
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
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
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
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
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
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
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
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 . 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 .
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
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
I'm talking about the relative gain . 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 .
Got Leenucks? :: Arch: Power in simplicity :: Get Counted! Registered Linux User #392717 :: Blog thingy
Offline