[arch-general] [signoff] linux-3.5.5-1
Hi guys, please signoff 3.5.5 series for both arches. package is not in testing, please grab it from here: http://dev.archlinux.org/~tpowa/linux/ This will move to [core] directly, because 3.6.0 is in [testing]. greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature
Re: [arch-general] [signoff] linux-3.5.5-1
On 03/10/12, Tobias Powalowski wrote: | Hi guys, | please signoff 3.5.5 series for both arches. | package is not in testing, please grab it from here: | http://dev.archlinux.org/~tpowa/linux/ | | This will move to [core] directly, because 3.6.0 is in [testing]. Working fine on 2 x x86_64 VPS boxes. On my laptop (also x86_64), nvidia 304.51-1 drivers are incompatible: [9.138797] nvidia: disagrees about version of symbol module_layout [ 10.530243] nvidia: disagrees about version of symbol module_layout [ 10.786405] nvidia: disagrees about version of symbol module_layout etc Cheers. -- Simon Perry (aka Pezz) pgppu4aw3dRie.pgp Description: PGP signature
[arch-general] kernel 3.6 feedback
kernel 3.6-1 testing report: I am running 3.6 from testing on 3 machines. 1 laptop and 2 desktops. All are fully updated from testing repo. 1 of the desktop didn't come up right - seemed to have trouble with root filesystem (initiscripts still not systemd). On second reboot it came up fine. No logs obviously - will report if any further issues arise. Could be a coincidental hardware problem I suppose. Other desktop and laptop are both totally fine. laptop has intel on board graphics and sandy bridge i7 with intel 6300 wifi (lenovo w520). gene
[arch-general] mkinitcpio: mdadm_udev Hook
Hi, I've just been re-installing a box, and saw that the wiki says regarding using the mdadm_udev hook: This is the preferred method of mdadm assembly (rather than using the above mdadm hook). I've tried to use the mdadm_udev hook, but the devices get named: normal md0 (/boot) is md127 normal md1 (encrypted, then lvm with swap and / on it ) is md126 I found this out with cat /proc/partitions once my box failed to boot and dropped to the initramfs shell. Seems pretty random, the first actual device isn't even the lowest number. There doesn't seem to be any documented way to have my raid1 devices named so I can use: cryptdevice=/dev/md1:crypt in my kernel arg line. The only way to get things to work is to use the mdadm hook and have my devices specified in /etc/mdadm.conf Can I rely on md127 and md126 being the same across every boot, and therefore resign myself to using this numbering (instead of the much nicer md0 and md1), and use it in my cryptdevice kernel arg and be done with it? Given this thread: https://bbs.archlinux.org/viewtopic.php?id=149358 And the comment: I have little interest in supporting the mdadm hook. Assembly via udev is the preferred method here. What is the right way to do this? Cheers. -- Simon Perry (aka Pezz) pgpvrJ2XKsISs.pgp Description: PGP signature
Re: [arch-general] mkinitcpio: mdadm_udev Hook
Am 03.10.2012 14:41, schrieb Simon Perry: Hi, I've just been re-installing a box, and saw that the wiki says regarding using the mdadm_udev hook: This is the preferred method of mdadm assembly (rather than using the above mdadm hook). I've tried to use the mdadm_udev hook, but the devices get named: normal md0 (/boot) is md127 normal md1 (encrypted, then lvm with swap and / on it ) is md126 I found this out with cat /proc/partitions once my box failed to boot and dropped to the initramfs shell. Seems pretty random, the first actual device isn't even the lowest number. You need to create a file /etc/mdadm.conf. mdadm --examine --scan will generate the right lines for you. This file will be added to the initramfs and your names will be fine again. signature.asc Description: OpenPGP digital signature
Re: [arch-general] kernel 3.6 feedback
On Wed, Oct 3, 2012 at 12:33 PM, Genes MailLists li...@sapience.com wrote: kernel 3.6-1 testing report: I am running 3.6 from testing on 3 machines. 1 laptop and 2 desktops. All are fully updated from testing repo. 1 of the desktop didn't come up right - seemed to have trouble with root filesystem (initiscripts still not systemd). On second reboot it came up fine. No logs obviously - will report if any further issues arise. Could be a coincidental hardware problem I suppose. Other desktop and laptop are both totally fine. laptop has intel on board graphics and sandy bridge i7 with intel 6300 wifi (lenovo w520). What hardware (processor/graphics/architecture) was the machine that had the boot problem with 3.6? Maybe anyone else with the same hardware might be able to confirm if a similar problem has been seen? Might just help. -- mike c
[arch-general] GHC 7.6.1 now in [testing]
Hey everyone! It's that time again for arch to get the latest ghc! GHC 7.6.1 comes with a bunch of new and exciting features: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html This morning, all the haskell packages should have been rebuilt against the latest ghc and I have moved all haskell pkgs to testing. One caveat is that cabal-install wasn't rebuilt but it should still work while upstream works on patching it for ghc 7.6.1 It took just under a month to do the full rebuild because of the amount of patching and coordination with upstream we had to do. I will let it sit in testing for a week so that aur maintainers for haskell pkgs have time to investigate and patch their packages. I would like to thank everyone who worked on this rebuild! Cheers!
[arch-general] pacman update dependency problem today for kdegames
Today I tried to update with pacman -Syu I got this: :: Starting full system upgrade... resolving dependencies... warning: cannot resolve kdegames-knavalbattle, a dependency of kde-meta-kdegames warning: cannot resolve kdegames-ksnakeduel, a dependency of kde-meta-kdegames :: The following package cannot be upgraded due to unresolvable dependencies: kde-meta-kdegames Do you want to skip the above package for this upgrade? [y/N] I tried to find the two packages: [root@lapmike3 ~]# pacman -Ss kdegames-ksnakeduel [root@lapmike3 ~]# pacman -Ss kdegames-knavalbattle [root@lapmike3 ~]# Seems these don't exist!! I also don't have either package installed from any previous update or pacman install! What is the advice here? Wait for the update system to get fixed or carry on regardless and go ahead and update? Thanks -- mike c
Re: [arch-general] pacman update dependency problem today for kdegames
On Wed, Oct 3, 2012 at 4:40 PM, mike cloaked mike.cloa...@gmail.com wrote: Today I tried to update with pacman -Syu I got this: :: Starting full system upgrade... resolving dependencies... warning: cannot resolve kdegames-knavalbattle, a dependency of kde-meta-kdegames warning: cannot resolve kdegames-ksnakeduel, a dependency of kde-meta-kdegames :: The following package cannot be upgraded due to unresolvable dependencies: kde-meta-kdegames Do you want to skip the above package for this upgrade? [y/N] I tried to find the two packages: [root@lapmike3 ~]# pacman -Ss kdegames-ksnakeduel [root@lapmike3 ~]# pacman -Ss kdegames-knavalbattle [root@lapmike3 ~]# Seems these don't exist!! I also don't have either package installed from any previous update or pacman install! What is the advice here? Wait for the update system to get fixed or carry on regardless and go ahead and update? Looks like I was just too impatient and need to wait for the mirror to properly sync! So this is solved. -- mike c
Re: [arch-general] kernel 3.6 feedback
I'm suffering from this regression: https://lkml.org/lkml/2012/9/26/53 https://bugzilla.kernel.org/show_bug.cgi?id=47961 which causes my HDA intel sound to be distorted and cracky. Reverting the change mentioned in the LKML thread fixes it. I already mailed the Arch linux kernel maintainer about it. I'm fairly sure that this fix should land in 3.6.1, but because I didn't want to wait I patched my kernel myself... On Wed, Oct 3, 2012 at 5:21 PM, mike cloaked mike.cloa...@gmail.com wrote: On Wed, Oct 3, 2012 at 12:33 PM, Genes MailLists li...@sapience.com wrote: kernel 3.6-1 testing report: I am running 3.6 from testing on 3 machines. 1 laptop and 2 desktops. All are fully updated from testing repo. 1 of the desktop didn't come up right - seemed to have trouble with root filesystem (initiscripts still not systemd). On second reboot it came up fine. No logs obviously - will report if any further issues arise. Could be a coincidental hardware problem I suppose. Other desktop and laptop are both totally fine. laptop has intel on board graphics and sandy bridge i7 with intel 6300 wifi (lenovo w520). What hardware (processor/graphics/architecture) was the machine that had the boot problem with 3.6? Maybe anyone else with the same hardware might be able to confirm if a similar problem has been seen? Might just help. -- mike c -- Bastian Beischer RWTH Aachen University of Technology @CERN Office: Bdg 32-4-B12 Phone: +41-22-76-75750 E-mail: bastian.beisc...@cern.ch Address: CERN, CH-1211 Geneve 23 @RWTH Aachen Office: 28 C 203 Phone: +49-241-80-27205 E-mail: beisc...@physik.rwth-aachen.de Address: I. Physikalisches Institut B, Sommerfeldstr. 14, D-52074 Aachen
Re: [arch-general] kernel 3.6 feedback
On 03/10/12||07:33, Genes MailLists wrote: kernel 3.6-1 testing report: I am running 3.6 from testing on 3 machines. 1 laptop and 2 desktops. All are fully updated from testing repo. 1 of the desktop didn't come up right - seemed to have trouble with root filesystem (initiscripts still not systemd). On second reboot it came up fine. No logs obviously - will report if any further issues arise. Could be a coincidental hardware problem I suppose. Other desktop and laptop are both totally fine. laptop has intel on board graphics and sandy bridge i7 with intel 6300 wifi (lenovo w520). gene X86_64 on Intel7 NVIDIA video card btrfs systemd Booting fine and overall system OK.
Re: [arch-general] mkinitcpio: mdadm_udev Hook
On 03/10/12, Thomas Bächler wrote: | You need to create a file /etc/mdadm.conf. mdadm --examine --scan will | generate the right lines for you. This file will be added to the | initramfs and your names will be fine again. Yep, that's what I've done, and I've used the mdadm hook as I have in the past. Based on the mkinitcpio wiki page, and the forum post, I'm under the impression that using mdadm_udev to auto-assemble the arrays is what I should be using (and is what will be supported in the future). The mdadm_udev hook does work as advertised, but I don't see how I can use it when I need a known /dev/mdx device for use in something like a cryptdevice= kernel arg. Cheers. -- Simon Perry (aka Pezz) pgpGJdmleQplX.pgp Description: PGP signature
Re: [arch-general] mkinitcpio: mdadm_udev Hook
Am 03.10.2012 22:07, schrieb Simon Perry: Based on the mkinitcpio wiki page, and the forum post, I'm under the impression that using mdadm_udev to auto-assemble the arrays is what I should be using (and is what will be supported in the future). The mdadm_udev hook does work as advertised, but I don't see how I can use it when I need a known /dev/mdx device for use in something like a cryptdevice= kernel arg. First of all, once you add the mdadm.conf file, the mdX names will follow the naming usual scheme - the md126+ names will only be used when the array is not mentioned in mdadm.conf. Second, you can always use /dev/disk/by-uuid/. signature.asc Description: OpenPGP digital signature
Re: [arch-general] kernel 3.6 feedback
I have not been hit by this - but there is some buzz around the symlink security addition - see this thread for more details: https://lkml.org/lkml/2012/10/3/473 gene
[arch-general] mkinitcpio: mdadm_udev Hook
On 03/10/12, Thomas B?chler wrote: You need to create a file /etc/mdadm.conf. mdadm --examine --scan will generate the right lines for you. This file will be added to the initramfs and your names will be fine again. Yep, that's what I've done, and I've used the mdadm hook as I have in the past. Based on the mkinitcpio wiki page, and the forum post, I'm under the impression that using mdadm_udev to auto-assemble the arrays is what I should be using (and is what will be supported in the future). The mdadm_udev hook does work as advertised, but I don't see how I can use it when I need a known /dev/mdx device for use in something like a cryptdevice= kernel arg. Thomas is pointing out that the mdadm_udev hook will (should?) still honor your /etc/mdadm.conf if it has ARRAY decls in it (you'll see it being picked up on the mkinitcpio run if this is true). If that isn't happening, or it isn't being honored, we should find out why. Alternatively, cryptdevice understands tags, e.g: cryptdevice=UUID=46c78135-8ac0-4928-8b26-5d23a77b1ff1:cryptrewt Of course, since there isn't a filesystem involved, UUID is the only one that makes sense for MBR disks. PARTUUID is also supported, and PARTLABEL support will be available in the next mkinitcpio release. Cheers, Dave
Re: [arch-general] mkinitcpio: mdadm_udev Hook
On 03/10/12, Thomas Bächler wrote: | First of all, once you add the mdadm.conf file, the mdX names will | follow the naming usual scheme - the md126+ names will only be used when | the array is not mentioned in mdadm.conf. | | Second, you can always use /dev/disk/by-uuid/. Cool, makes sense, and damn me for not going one step further and setting up mdadm.conf before giving up and going back to the mdadm hook. :) - Running build hook: [mdadm_udev] Custom /etc/mdadm.conf file will be used in initramfs for assembling arrays. Cheers for the info fellas. -- Simon Perry (aka Pezz) pgpoN9t1iVzrn.pgp Description: PGP signature
Re: [arch-general] kernel 3.6 feedback
There is also some noise around udev as well and firmware loading: https://lkml.org/lkml/2012/10/2/194 (it's a bit of a long thread) gene
Re: [arch-general] Full mailing-list moderation
[2012-10-03 12:01:55 +1000] Allan McRae: All post to the mailing list are now moderated. As this takes time away from us actually maintaining the distribution, this will only occur intermittently. I have disabled full list moderation but turned on everyone's moderation bit. Therefore, the next message you will send to this list will be held for moderation - hopefully for no more than a couple hours. Provided your message contains *factual bits of useful information*, it will be allowed through to the list and we will turn off your moderation bit, so from then on you will be able to post freely. And this list will be a joy to read again. :) -- Gaetan
Re: [arch-general] kernel 3.6 feedback
On 10/03/2012 08:52 PM, Genes MailLists wrote: ... https://lkml.org/lkml/2012/10/2/194 For those not following the entire thread - there seems to be some debate about firmware loading in udev vs in kernel space and some recent changes leading to some problems. Best I can tell, while there may be issues in specific drivers, one symptom is a delayed boot (10-30 secs). It seems likely this issue is only effecting a subset of systems. Work is being done and it looks like this will be quickly improved quite soon and presumably find its way quickly to in 3.6.1. gene/
