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

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

nous wrote:

I always use the stock -ARCH config and only modify the options related to your patchset. From what I see, crypt target support (dm-crypt) is there. But I remember I saw a thread on arch-dev-public about systemd and encrypted LVM not getting along and another one about broken encrypted LVM with 3.5.2. Right now, only the initial thread message appears on the mailing list archive, so I'm pasting below:…

Hmm, I saw that mail, but I've got no systemd on my laptop. Possible real bug in 3.5.x with LVM, not related to systemd?

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

Sorry to go slightly off topic, but speaking just about tuxonice, doesn't anybody have problems hibernating when the image size is particulary big?

For me, on two systems with kernel 3.4.x, it always fails when i left (say) firefox open with some tabs, so i keep clearing caches before going to hibernation and everything works, but that way my system is unresponsive at resume.It fails in "preparing images" stage, and then complains about wacky drivers or so, but the same drivers are loaded when the memory is free, so i guess it is wrong.

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

kokoko3k wrote:

Sorry to go slightly off topic, but speaking just about tuxonice, doesn't anybody have problems hibernating when the image size is particulary big?

For me, on two systems with kernel 3.4.x, it always fails when i left (say) firefox open with some tabs, so i keep clearing caches before going to hibernation and everything works, but that way my system is unresponsive at resume.It fails in "preparing images" stage, and then complains about wacky drivers or so, but the same drivers are loaded when the memory is free, so i guess it is wrong.

The same DOES NOT happen with 3.2 (but is on other hardware too)

I guess that is well-known issue with memory allocation, and it hasn't been fixed yet.

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

nous wrote:

Yup, I get that too. A work-around is to have hibernate script execute "sync; echo 3 >| /proc/sys/vm/drop_caches" at the beginning of hibernation.

I also had that option in /etc/hibernate/common.conf while I used uswsusp (when TOI didn't work with the first few linux 3.0 releases) but removed it when switching back to TOI and have no lags whatsoever after resume.

that replaces it by the kernel's file (which BTW was patched by aufs3-kbuild.patch, adding the lines from aufs' Kbuild) so copying it is disnecessary. Considering it's contents are already added by aufs3-kbuild.patch, it doesn't make any difference but it would be less confusing to do 'rm include/linux/Kbuild' (do not just remove the 'mv include/...' part, because if you do that it would overwrite the kernel's include/linux/Kbuild).

And also about $_kernver: I did a test, and put a 'echo ${_kernver}' right before the command that uses it in build(), and it had no output. If I run a ls ${pkgdir}/usr/src/ at the moment it asks me about the kernel's config, it shows a 'linux-' directory, so I don't know why the package doesn't have it.

that replaces it by the kernel's file (which BTW was patched by aufs3-kbuild.patch, adding the lines from aufs' Kbuild) so copying it is disnecessary. Considering it's contents are already added by aufs3-kbuild.patch, it doesn't make any difference but it would be less confusing to do 'rm include/linux/Kbuild' (do not just remove the 'mv include/...' part, because if you do that it would overwrite the kernel's include/linux/Kbuild).

And also about $_kernver: I did a test, and put a 'echo ${_kernver}' right before the command that uses it in build(), and it had no output. If I run a ls ${pkgdir}/usr/src/ at the moment it asks me about the kernel's config, it shows a 'linux-' directory, so I don't know why the package doesn't have it.

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

I was checking the PKGBUILD because I couldn't build aufs3-utils. It still fails, but now I found why:When make install_headers is executed, it puts the modified headers in usr/include folder in the kernel's source tree, not in ${pkgdir}/. It isn't copied to ${pkgdir}/ later nor anything, so the aufs_type.h file that ends in ${pkgdir}/usr/src/linux.../include/linux/ is the one copied by

To solve that, I removed the make headers_install from before the c/p from linux-ARCH, and put it near the end of package_linux-pf-headers(), so that it isn't overwritten by the previous code, with the argument INSTALL_HDR_PATH=${pkgdir}/usr/src/linux-${_kernver}.

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

hello everyone, posting for the first time.after installing linux pf 3.5.3 from the unofficial repos, i am unable to regenerate initramfs. The process fails while building fglrx. Apparently some header files are missing from /usr/src/3.5-pf/include/linux folder. those headers are absent in linux-pf-headers too. catalyst-install.log complains the following

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

Pankaj wrote:

hello everyone, posting for the first time.after installing linux pf 3.5.3 from the unofficial repos, i am unable to regenerate initramfs. The process fails while building fglrx. Apparently some header files are missing from /usr/src/3.5-pf/include/linux folder. those headers are absent in linux-pf-headers too. catalyst-install.log complains the following

I just checked my /usr/src/linux-pf/include/linux directory against linux-ARCH's one and indeed there a couple of thousand header files missing. This shouldn't happen as I copy/paste the packaging sections from linux-ARCH into linux-pf, but I'll investigate.