Re: [arch-general] [arch-dev-public] [signoff] kernel26-lts 2.6.32.27-1
Am Fri, 10 Dec 2010 16:49:03 +0100 schrieb Andreas Radke a.ra...@arcor.de: Upstream update. Please sign off. http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.27 -Andy Anyone? It's also fixes a vulnerability.
[arch-general] perl 5.12.2 anytime soon? or just going to wait for 5.12.3 or 5.14.1
perl 5.12.2 came out at the end of august... I'm just wondering if we'll be getting it... 5.12.3 should come out... I'd rather never see a stable 5.14.0 because 5.14.1 should follow a month later... and given the current speed of updated perls in arch... -- Caleb Cushing http://xenoterracide.com
Re: [arch-general] perl 5.12.2 anytime soon? or just going to wait for 5.12.3 or 5.14.1
nvm... I just noticed the thread on -dev-public -- Caleb Cushing http://xenoterracide.com
Re: [arch-general] [arch-dev-public] glibc and minimum kernel version
On 12/11/2010 10:49 AM, Allan McRae wrote: Hi, I am in the progress of updating the toolchain and thought it time to review what our minimum required kernel version is for glibc. For those that do not know, assuming a newer kernel allows glibc to have less workarounds compiled in. So it may be advantagous to have a more recent version as the minimum required. This comes at the obvious cost of not having support for older kernels so a tradeoff is needed... When we discussed this 18 months ago, it was decided 2.6.18 was appropraite then, but much has changed since. I am going to suggest that we follow the oldest longterm support kernel. That would now be the 2.6.27.x series, which has been around for over two years. That might be being overly bold, so feel free to point out how much such an update would break... and suggest an alternative minimum. Allan The workarounds obviously make maintainence a little more difficult, but is there a performance hit too? Could a glibc and glibc-legacy/glibc-compat type of thing be a viable solution? Then the question would be what kernel defines the line between the two glibc packages (probably -lts would be good).
[arch-general] Howto Preserve Current Kernel through Update?
Guys, I want to keep the current kernel while I upgrade to 2.6.36-2 and where I confused is how to use mkinitcpio to do this. What I think I can do to preserve the current kernel as 2.6.36-dcr is: (1) cp -a /lib/modules/2.6.36-ARCH /lib/modules/2.6.36-dcr (2) mkinitcpio -k 2.6.35-dcr \ -c /etc/mkinitcpio.conf \ -g /boot/kernel26-dcr.img mkinitcpio -k 2.6.35-dcr \ -c /etc/mkinitcpio.conf \ -g /boot/kernel26-dcr-fallback.img \ -S autodetect (3) update grub menu.lst and create entries for the dcr kernel Before I wasted too much time chasing my tail, I thought would put this out to the list and see if (or what) I'm missing. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] Howto Preserve Current Kernel through Update?
On 12/11/2010 09:34 PM, David C. Rankin wrote: mkinitcpio -k 2.6.35-dcr \ -c /etc/mkinitcpio.conf \ -g /boot/kernel26-dcr.img mkinitcpio -k 2.6.35-dcr \ -c /etc/mkinitcpio.conf \ -g /boot/kernel26-dcr-fallback.img \ -S autodetect Of course that should be 2.6.36-dcr -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] VirtualBox_bin 3.12 - slow system freeze on i686, OK on x86_64
On 12/09/2010 04:46 AM, Mauro Santos wrote: Does the machine where it worked well support VT-x/AMD-V and is it enabled? The only relevant info I can remember of is [1] and the link provided by wonder [2]. Maybe that problem isn't completely fixed or it may be an unrelated bug. [1] https://bbs.archlinux.org/viewtopic.php?id=108103 [2] http://www.virtualbox.org/ticket/7605 Mauro, Thank you for the links. I'll have to check into the settings. All prior versions of virtualbox_bin have worked fine. As mentioned in just downgraded with pacman -U to 3.10 and it works perfectly. I'll let you know what I turn up. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
[arch-general] Bizarre grub drive number switch from (hd1, 5) to (hd2, 5) but no hd2 defined???
Guys, I have managed to get myself in a number of messes over the years, but usually when I figure out what went wrong, I understand why. Here, I'm at a complete loss. I was going to preserve my existing kernel through update and I described in an earlier email. (I'm still on kernel26-2.6.36.1) So I created a custom initramfs and preserved the module tree and added the entries to grub menu.lst. This box has always booted arch on (hd1,5) a device mapper array. (hd0) is another device mapper array with an old suse install on it. However, after I made may changes and went to reboot to test the custom initramfs, I got a grub 13 error for an invalid executable?? So I booted with the Arch 2010.05 install disk and chrooted my existing install and looked at grub. When I did my grub find /boot/grub/stage1, grub reported stage1 on (hd0,4) (hd2,4) WTF? I don't have an hd2 and what the heck happened to hd1?? [01:42 archangel:/boot/grub] # cat device.map (hd0) /dev/mapper/nvidia_fdaacfde (hd1) /dev/mapper/nvidia_baaccaja (fd0) /dev/fd0 So I decided to give booting to hd2 a try. So I reconfigured the suse menu.lst file to call (hd2,5) to boot Arch, and I redid the Arch menu.lst to point everything at (hd2,5) instead of (hd1,5) and rebooted. To my shock and surprise - it booted just fine with all the drive number flipped from 1-2. This makes no sense whatsoever to me. How does my device.map still correctly define my (hd0) and (hd1) arrays, but grub spontaneously require booting to /dev/mapper/nvidia_baaccaja on (hd2). Damndist thing I've ever seen. It goes without saying, but I am at a complete loss as to 'what happened' and 'why it happened'. I can't even think of any way it 'could have happened'. All I did was run mkinitcpio twice to create the custom initramfs that I would use to preserve the existing kernel when I updated by running: mkinitcpio -k 2.6.36-dcr \ -c /etc/mkinitcpio.conf \ -g /boot/kernel26-dcr.img mkinitcpio -k 2.6.36-dcr \ -c /etc/mkinitcpio.conf \ -g /boot/kernel26-dcr-fallback.img \ -S autodetect And when I rebooted, I ended up in this mess. So what say the experts. Does anybody see a way running mkinitcpio as I did above could cause the grub root to change from hd1 to hd2? I don't see how it could happen. If that isn't the culprit, does anybody have any other ideas on how this could have happened? Thanks for any insight you can give. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
