You are not logged in.
OK... I just build 3.12.1-1 and bumped nvidia-304xx to 304.108-8. Please try it. All packages on the repo have the same md5sums as my local versions... if there is something funky going on, blame godaddy.
You sir are awesomeness, upgrade worked without a hitch.
Is there a way I can slide you a few bucks for your repo-ck efforts, or should I donate to Arch Linux directly?
Offline
As far as I know, every other tier 1 distribution has been including this patch with their kernels since the revelation of this bug.
Have you opened a flyspray against core/linux with this info? I will consider including it even if the Arch devs do not.
Is there a way I can slide you a few bucks for your repo-ck efforts, or should I donate to Arch Linux directly?
I'm flattered but there is no need. This is one of the ways I give back to the Arch Community. Enjoy.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Well, it was expected that the patch would be merged quickly, so I figured I would just wait for it to be backported. But it is taking longer than expected... though Chris Mason just submitted another pull request for a whole bunch of maintenance patches. So maybe it will go this time.
I just keep seeing these pull requests on linux-btrfs, so I think "Oh yeah, it'll be fixed now!" But right after 3.12 was released, there was talk about having that one patch put into 3.12 even though the merge window wasn't open while Linus was on his diving vacation. But it just never actually happened. It was forgotten in the first place, so just kind of a f*cked up situation all around.
Now that I see this latest pull request, maybe you should hold off for a bit and see if things get taken care of this time. We are just coming up on the end of the merge window, so I was starting to get worried. Hopefully things will just work themselves out though... I'll keep you posted.
Offline
@WW - I do see it in the fedora 3.12.0-2 package; just grep for btrfs in the build.log. Regardless of the merge window state, if it is a critical fix, I see no reason why the Arch devs would be resistant. Open a fly spray. I will bump it into 3.12.1-2-ck. Thanks for the heads-up. BTW, my SSD is 250 MB ext4 (/boot) and the rest btrfs (/); since I have a single drive setup, there is no need to balance for me, but I can appreciate that others users may have a RAID setup.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Yeah, I didn't think that there would actually be resistance to this, t just kept looking as though it would be quickly fixed... over and over and over again. That is why I never reported it in the flyspray. I guess since 3.12.1 was just released, we would be at least a week away from seeing a fix make it to teh Arch kernel. I'll report it, and if they think it is fine to wait, then great, if not, they can bump their pkgrel as well.
BTW, I have checked several distributions for the presence of this patch, and it is indeed included in every one that I have checked. I'm not saying that I have done extensive research, but in a random sampling it was consistently there.
Anyway, thanks for taking such good care of us repo-ck users
Edit: Flyspray
Last edited by WonderWoofy (2013-11-21 20:14:37)
Offline
Hey Graysky.
I'm unable to -Syu now, in x86_64 repo linux-ck-headers is missing.
Offline
Neat! Thanks for the update graysky. Just to let you know, godaddy has been kicking ass for me of late. I was just able to get 6MB/s installing 3.12.1-2-ck (yes bytes)!
Offline
@Osleg - Thanks for reporting; try now.
@WW - Good, glad to see those morons do something right albeit it only temporary
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
OOps! Kernel panic at boot. I can't reproduce any logs in this case, it seems. I'm using ck-k10 since a long time.
Offline
OOps! Kernel panic at boot. I can't reproduce any logs in this case, it seems. I'm using ck-k10 since a long time.
Is this with the latest release (3.12.1-1)?
Claire is fine.
Problems? I have dysgraphia, so clear and concise please.
My public GPG key for package signing
My x86_64 package repository
Offline
It's repo-ck/linux-ck-k10 3.12.1-2 (ck-k10) [installed]
Offline
There should be a 3.12.1-2, but I don't think the difference between pkgrel 1 and 2 shouldn't make a difference in terms of bootability. That was just a small change to fs/btrfs/relocation.c to make 'btrfs balance' work properly with preallocated files (fallocate).
@graysky, the changes have now been merged into 3.13rc1 (which was just tagged midday today). So it should soon be backported to the stable releases some time now. Of course leaving what you have already done with 3.12.1-2 should be fine as we won't see the changes hit 3.12 until at least 3.12.2. Thanks again!
BTW, my flyspray hasn't gone anywhere, and still remains undecided with no comments... I don't know if anything will come of it.
Offline
Hi,
I just had a kernel panic using VirtualBox. What should I do to pass along relevant information to those more qualified to investigate than I? journalctl shows nothing.
pacman -Qs ck
(...)
local/broadcom-wl-ck-ivybridge 6.30.223.141-5 (ck-ivybridge)
local/linux-ck-ivybridge 3.12.1-2 (ck-ivybridge)
local/virtualbox-ck-host-modules-ivybridge 4.3.2-4 (ck-ivybridge)
Offline
Just to keep you updated, the btrfs patch to properly relocate preallocated checksums has been applied to the Arch kernel. It is now in [testing] as linux{,-docs,-headers} 3.12.1-2. Horray, I can stop building at least one of my kernels!
As a side note graysky, you say that you don't have a use for balance. For the most part, that is pretty true since your btrfs is single disk only. But there is still work being done on properly releasing the chunks in order to free space. It works properly for most people most of the time, but from time to time, I do notice that when I delete several old snapshots, I do end up with far more in the "total" than the "used" in btrfs filesystem df /. So this is a case where balancing can readjust the used space to properly use the allocated chunks.
Offline
Thanks for the info, ww. I actually don't use snapshots with it.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Greg HK, as indicated in an email to linux-btrfs that he has the preallocated checksums patch queued up and ready to be added to 3.12. Soon...
Offline
Hi, can I ask what kinda settings u use for the linux-ck-atom and nvidia-ck-atom? I'd like to use them myself when building linux-ck from AUR.
Offline
Hi, can I ask what kinda settings u use for the linux-ck-atom and nvidia-ck-atom? I'd like to use them myself when building linux-ck from AUR.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Hi, still can't download the kernel from the repo:
Il file /var/cache/pacman/pkg/linux-ck-core2-3.12.1-3-x86_64.pkg.tar.xz è corrotto (il pacchetto non è valido oppure è corrotto (firma PGP)).
It's italian, it says that the file is not valid or corrupted..
Offline
@franz - The md5sums locally and on the repo check out; if I download the file in question and verify it with `pacman-key -v linux-ck-core2-3.12.1-3-x86_64.pkg.tar.xz.sig`it is also fine. Recommend you delete /var/cache/pacman/pkg/linux-ck-core2-3.12.1-3-x86_64.pkg.tar.xz* and try again.
Last edited by graysky (2013-11-29 10:31:52)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I deleted those files and did pacman -Syu again, but still there's something wrong.. is there a way to delete the pgp key of the repo and download it again? perhaps the key is the problem..
Offline
Try this:
wget http://repo-ck.com/x86_64/linux-ck-core2-3.12.1-3-x86_64.pkg.tar.xz
wget http://repo-ck.com/x86_64/linux-ck-core2-3.12.1-3-x86_64.pkg.tar.xz.sig
pacman-key -v linux-ck-core2-3.12.1-3-x86_64.pkg.tar.xz.sig
Post the output of the last command.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
pacman-key -v linux-ck-core2-3.12.1-3-x86_64.pkg.tar.xz.sig
==> Checking linux-ck-core2-3.12.1-3-x86_64.pkg.tar.xz.sig ...
gpg: Signature made mer 27 nov 2013 01:18:06 CET using RSA key ID 5EE46C4C
gpg: NOTA: il trustdb non è scrivibile
gpg: Good signature from "graysky (used to sign repo-ck packages) <graysky@archlinux.us>"
gpg: aka "[jpeg image of size 5969]"
gpg: ATTENZIONE: questa chiave non è certificata con una firma fidata!
gpg: Non ci sono indicazioni che la firma appartenga al proprietario.
Impronta digitale della chiave primaria: 4E22 BB63 7E26 407D 5DEE 5509 88A0 3286 5EE4 6C4C
==> ERRORE: La firma identificata da linux-ck-core2-3.12.1-3-x86_64.pkg.tar.xz.sig non può essere verificata.
It says: "this sign is not certified as a trusted sign" and something like "no clue this sign belong to owner"
Offline
Hmmm... as root:
pacman-key -r 5EE46C4C && pacman-key --lsign-key 5EE46C4C
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Hmmm... as root:
pacman-key -r 5EE46C4C && pacman-key --lsign-key 5EE46C4C
It went all ok and now I can download from the repo.. don't know why it happened sincerely..
Offline