The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

nous · 2010-08-30 14:36:17

72linus wrote:

nous
I noticed the AUR is wanting to upgrade it again
whats changed since "pf6"?

Updates from tuxonice git tree mostly. I didn't update myself, I'll wait for the next kernel patchlevel bump.

[c/p from AUR]
Since the updates come out more often than some anticipate, it's highly recommended to have a kernel config tailored for your boxes. Use hwd or hwdetect to show you your hardware modules and build the disk controller (and tuxonice and lzo) in-kernel. Everything else can be modules and loaded at startup with /etc/rc.conf. Initrd is not needed this way and you'll reduce kernel build time to a small fraction. Keep at least one alternative kernel (e.g. the stock arch kernel) as a backup.

Last edited by nous (2010-08-30 17:52:42)

Cdh · 2010-08-30 19:58:30

http://omploader.org/vNWUxcw/kernel26-p … pkg.tar.xz

Any chance of setting up a repo which builds the kernel automatically?

ffjia · 2010-08-31 02:45:34

nous, I installed your pre-compiled kernel-26-pf6 packages, including core2 and x86_64. After the system starts, it hangs when starting acpid or laptop-tools services, I think it's really acpi related

nous · 2010-08-31 07:01:02

@Cdh I'll try with the fellas at adslgr, but the AUR vote count is still low.

@ffjia have you tried the various ACPI-related boot options?

ffjia · 2010-08-31 07:19:21

nous, I compiled kernel26-pf7, use Arch's default /proc/config.gz, then reboot. Now it seems everything is fine, hehe

gtklocker · 2010-08-31 07:31:29

nous, consider creating a repo at a service like dropbox! (yes, you can )

Cdh · 2010-09-03 16:57:14

Somehow it doesn't work on my btrfs partition:

Normal kernel with same mkinitcpio config runs normally.

nous · 2010-09-03 20:55:05

Cdh wrote:

Somehow it doesn't work on my btrfs partition:
Normal kernel with same mkinitcpio config runs normally.

I can't really help you here (i.e. I don't use btrfs). Try selecting a different I/O scheduler at boot (e.g. iosched=cfq).

Cdh · 2010-09-03 21:20:14

nous wrote:

(e.g. iosched=cfq).

Nope.

I don't know what the problem was... I created the btrfs system just copying my working system. Then I modified it to use btrfs and rebuilt the initramfs. Then the kernel did hang when processing udev events - in the logs it had a null pointer dereference in usbcore... When disabling usbcore it later hung when loading modules for the soundcard... I booted the stock arch kernel and it worked well, then I rebuilt the -pf initrd again and after that I didn't get it to boot because always init segfaulted in ld??

Now I did pacman -Rncs on the -pf kernel and reinstalled it.
It works flawlessly now.

I don't know what the problem was but it is solved now.

nous · 2010-09-04 22:05:00

gtklocker wrote:

nous, consider creating a repo at a service like dropbox! (yes, you can )

We now have an unofficial repository for pf-kernel and nvidia-pf, thanks to gtklocker!

[pfkernel]
Server = http://pfkernel.gtklocker.com/i686
or
Server = http://pfkernel.gtklocker.com/x86_64

On x86_64 you can find core2 and k8 optimized packages. I use a single PKGBUILD for all versions to make my life easier, so make sure you uninstall any existing kernel26-pf package before you install the -core2 or -k8, otherwise you'll have lots of conflicting files.

Cdh · 2010-09-07 19:56:48

I just wanted to say that hibernating with Tuxonice works very well now with my btrfs system and also with my other system with catalyst (it didn't with pm-utils).
I'm very, very impressed by the speed of tuxonice.

nous · 2010-09-08 07:02:57

Cdh wrote:

I just wanted to say that hibernating with Tuxonice works very well now with my btrfs system and also with my other system with catalyst (it didn't with pm-utils).
I'm very, very impressed by the speed of tuxonice.

Are you using initramfs? If so, can you post your configuration? (grub, /etc/mkinitcpio.conf etc)
I can only resume without it, with initramfs it just can't find the swap image.

Cdh · 2010-09-08 08:53:11

 ~ % cat /etc/mkinitcpio.conf
# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES="piix ide_disk reiserfs"
MODULES="lzo eeepc_laptop crc32c libcrc32c zlib_deflate btrfs"

# BINARIES
# This setting includes, into the CPIO image, and additional
# binaries a given user may wish.  This is run first, so may
# be used to override the actual binaries used in a given hook.
# (Existing files are NOT overwritten is already added)
# BINARIES are dependancy parsed, so you may safely ignore libraries
BINARIES=""

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in anyway.  This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options,
# like so:
#    FILES="/etc/modprobe.conf"
FILES=""

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
#    This setup specifies all modules in the MODULES setting above.
#    No raid, lvm2, or encrypted root is needed.
#    HOOKS="base"
#
#    This setup will autodetect all modules for your system and should
#    work as a sane default
#    HOOKS="base udev autodetect pata scsi sata filesystems"
#
#    This is identical to the above, except the old ide subsystem is
#    used for IDE devices instead of the new pata subsystem.
#    HOOKS="base udev autodetect ide scsi sata filesystems"
#
#    This setup will generate a 'full' image which supports most systems.
#    No autodetection is done.
#    HOOKS="base udev pata scsi sata usb filesystems"
#
#    This setup assembles an pata raid array with an encrypted root FS.
#    Note: See 'mkinitcpio -H raid' for more information on raid devices.
#    HOOKS="base udev pata raid encrypt filesystems"
#
#    This setup loads an lvm2 volume group on a usb device.
#    HOOKS="base udev usb lvm2 filesystems"
HOOKS="base udev autodetect pata scsi sata resume filesystems"

# COMPRESSION
# Use this to compress the initramfs image. With kernels earlier than
# 2.6.30, only gzip is supported, which is also the default. Newer kernels
# support gzip, bzip2 and lzma.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"

Anonymo · 2010-09-11 05:57:16

I installed your repo in pacman.conf

It won't let me install nvidia-pf without installing the generic 64 bit kernel. I want to use the core2 kernel

nous · 2010-09-11 13:37:11

Anonymo wrote:

I installed your repo in pacman.conf
It won't let me install nvidia-pf without installing the generic 64 bit kernel. I want to use the core2 kernel

The nvidia-pf package hosted in [pfkernel] was compiled against a generic 64-bit kernel tree. It should work with -core2, but I make no promises. Please, post feedback.

Anyway, I fixed the PKGBUILD's 'provides' array, so future packages provide the correct kernel version. Until then, force the installation with 'pacman -Sd nvidia-pf'

lucak3 · 2010-09-14 09:51:56

Can you tell me what's your new provides array? The one on AUR resolves to 'kernel26-pf=2.6.35'...
I need to fix nvidia-pf depends array anyway, as kernel26-headers should be replaced/deleted as makedepend.

nous · 2010-09-14 19:25:12

lucak3 wrote:

Can you tell me what's your new provides array? The one on AUR resolves to 'kernel26-pf=2.6.35'...

Precisely that.

lucak3 wrote:

I need to fix nvidia-pf depends array anyway, as kernel26-headers should be replaced/deleted as makedepend.

You should replace your current makedepends just with 'kernel26-pf ', as it also provides the respective headers. The provides array was updated to satisfy the kernel26-pf dependency of nvidia-pf for people that use cpu-optimized versions of the former from the repo, which before only provided the package name (e.g. kernel26-pf-core2).

lucak3 · 2010-09-16 14:38:29

I forgot to announce that I fixed the makedepend array as said

nous · 2010-09-17 21:17:00

The repo has moved to dropbox, please see first post and update your conf.

nous · 2010-09-18 13:51:15

After the local root exploit that affects 64-bit kernels (described here and confirmed to work in my 64-bit boxes), I updated the PKGBUILD in the AUR.
~~Until further notice, PLEASE DO NOT USE THE PREBUILT PACKAGES FROM THE X86_64 REPO, unless you're on a single-user machine and you really know your stuff.~~
Repo updated.

Last edited by nous (2010-09-23 14:39:57)

kazuo · 2010-09-18 14:15:19

nous wrote:

After the local root exploit that affects 64-bit kernels (describedhere and confirmed to work in my 64-bit boxes), I updated the PKGBUILD in the AUR.
Until further notice, PLEASE DO NOT USE THE PREBUILT PACKAGES FROM THE X86_64 REPO, unless you're on a single-user machine and you really know your stuff.

Nous, after I see that clyde don't says that a update for kernel-pf is available, I took a closer look at PKGBUILD and see that you use the pkgrel for pf version but the PKGBUILD man says

pkgrel
This is the release number specific to the Arch Linux release. This allows package maintainers to make updates to the package's configure flags, for example. A pkgrel of 1 is typically used for each upstream software release and is incremented for intermediate PKGBUILD updates. The variable is not allowed to contain hyphens.

So I think that using it for pf version is not a good idea, because you cant distinguish updates like this one for the exploit. I think that the practice is to use a pkgver like 2.6.35pf7 like the one used by the openssh package and this format have a correct version handling

$ vercmp 2.6.35pf7-1 2.6.35pf7-2
-1
$ vercmp 2.6.35pf7-2 2.6.35pf8-1
-1

Last edited by kazuo (2010-09-18 14:18:52)

Anonymo · 2010-09-18 15:01:35

No, all he should need to change is the last number

2.6.35pf7-2 2.6.35pf7-1
to
2.6.35pf7-2 2.6.35pf7-2 and it will be a new package.

nous · 2010-09-19 09:42:36

I updated (again) the PKGBUILD, but since I really want the version name to contain a hyphen (i.e. 2.6.35-pf7), I decided to use a period for the updates. So, the current version on the AUR is 2.6.35-pf7.1, which yaourt sees as a newer package but not clyde, reason being the following:

% vercmp pf7 pf7.1
-1
% vercmp pf7 pf7-1
0

So, since there never was a 2.6.35-pf7.0, please tell clyde to explicitly install the package.

Also, for people who build custom kernels: if the package built optimized for a certain CPU, then the pkgname variable acquires an extension reflecting the optimization. I used this approach to help me build optimized kernels with the same PKGBUILD, instead of flooding the AUR with different packages. This means that in my box that runs a tailored kernel26-pf-k8, neither yaourt nor clyde can detect the AUR update (but should update fine when the newer repo optimized packages are up). I'll include an option int the next PKGBUILD version to ask the users whether they want the optimization suffix appended to the package name or not.

Thanks for the bug reports.

72linus · 2010-09-28 13:10:33

hello
nous

not related to your -pf kernel
but i was using your PKGBUILD as template to try to make my own live kernel,etc

However, it wont build for x86 at all
please see here and do you have any idea whats wrong??
https://bbs.archlinux.org/viewtopic.php?id=105614
thanks

pankajmore · 2010-09-28 16:24:29

the nvidia-pf package from dropbox repo , throws invalid module error with the pf kernel from the repo, anyone else having such problems , please confirm...

Arch Linux

#51 2010-08-30 14:36:17

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#52 2010-08-30 19:58:30

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#53 2010-08-31 02:45:34

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#54 2010-08-31 07:01:02

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#55 2010-08-31 07:19:21

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#56 2010-08-31 07:31:29

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#57 2010-09-03 16:57:14

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#58 2010-09-03 20:55:05

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#59 2010-09-03 21:20:14

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#60 2010-09-04 22:05:00

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#61 2010-09-07 19:56:48

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#62 2010-09-08 07:02:57

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#63 2010-09-08 08:53:11

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#64 2010-09-11 05:57:16

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#65 2010-09-11 13:37:11

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#66 2010-09-14 09:51:56

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#67 2010-09-14 19:25:12

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#68 2010-09-16 14:38:29

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#69 2010-09-17 21:17:00

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#70 2010-09-18 13:51:15

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#71 2010-09-18 14:15:19

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#72 2010-09-18 15:01:35

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#73 2010-09-19 09:42:36

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#74 2010-09-28 13:10:33

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

#75 2010-09-28 16:24:29

Re: The linux-pf thread; BFS/CK, TuxOnIce, BFQ, AUFS3

Board footer