- Arch-general - lists.archlinux.org

[arch-general] Was Fwd: [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.2-1, net-tools-1.60-15, udev-171-2, yp-tools-2.12-2
by Myra Nelson 04 Jun '11

04 Jun '11

---------- Forwarded message ---------- From: Myra Nelson <myra.nelson(a)hughes.net> Date: Sat, Jun 4, 2011 at 12:10 Subject: Re: [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.2-1, net-tools-1.60-15, udev-171-2, yp-tools-2.12-2 To: Public mailing list for Arch Linux development <arch-dev-public(a)archlinux.org> On Sat, Jun 4, 2011 at 11:30, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: > On Sat, Jun 4, 2011 at 4:58 AM, Tom Gundersen <teg(a)jklm.no> wrote: >> On Sat, Jun 4, 2011 at 5:41 AM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: >>> FWIW, the instructive comments in udev.conf doesn't mention "warning" >>> as a valid value. >> >> Oops, I meant to say "info". > > I also tried info when I tried with debug. I didn't noticed any > difference with debug as far as the excessive output go. I could try > it again and check dmesg more carefully. > > >> >>> I tried it and the error message doesn't get >>> printed. Dmesg doesn't have the error message and the logs are >>> useless since the error happens when the kernel is booting, i.e. >>> rc.sysinit isn't running yet. I suppose it's mkinitcpio/udev related. >> >> If rc.sysinit is not running, then this is an mkinitcpio problem. I >> guess the reason you are seeing it again might be a race? We have sped >> things up quite a bit with this release, so things might race >> differently than before. > > That's what I believe. I didn't mentionned it but dmesg contains > output saying that the raid was assemble and all mirrors are active. > So despite the error message from udevd, the kernel still manage to > assemble the raid array. Also, I can't find the hook or config file > that contains the mdadm command line displayed in the error message. > I looked in /etc and /lib/initcpio but it's not there. > >> >>> They work as expected. The error is not fatal. My raid array gets >>> assembled without user intervention. Either it is eventually done by >>> the initscripts (I can't find where, I think that code parthas been >>> removed) or by something else. >> >> My guess is that the error you are seeing is from udev in mkinitcpio, >> and the udev in rc.sysinit works correctly. To change the error >> reporting you would need to run mkinitcpio -p kernel26 after updating >> udev.conf. > > I was updating my initcpio file when changing the udev.conf. > >> >>>>> Also, my loopback interface didn't started. When I ran "/usr/sbin/ip >>>>> link set up dev lo" manually in a terminal, it started fine. I don't >>>>> know why it didn't work when booting up. >>>> >>>> Do you see anything in the above logs? >>> >>> I found the source of this error. My /usr is on it's own partition. So >>> when rc.sysinit attemps to setup the loopback interface with >>> /usr/sbin/ip, my /usr partition is not mounted yet. So it fails. I >>> don't know what would be the best way to fix. Maybe moving ip to /sbin >>> or to postpone the lo interface setup after the partitions are >>> mounted. >> >> Ahhhh. I think this might cause many more problems than just the >> loopback. In particular, anything called in udev rules may reside on >> /usr. This means the rule will fail and it will not be rerun. >> >> Have a look at "grep /usr /lib/udev/rules.d/*" to see examples of what >> might be broken. >> >> Most other distros, and upstream projects have given up on supporting >> a separate /usr, so it will be buggy. I suggest moving your /usr to >> your rootfs, regardless of this particular problem. >> > > I recall you mentionning that on another ML thread. I wanted to ask > you for details at the time but did get to. > I'll move my /usr to my rootfs. I use lvm2 so the > resizing/repartionning should be easy. > >> As to the loopback device. I don't think it is a good idea to delay >> this to after /usr is mounted. If anything we might want to move it >> earlier in boot. That leaves moving ip out of /usr. >> >> Does anyone know the consequences of this? Do we want to keep >> supporting a separate /usr? > > If I'm the only one with the problem, you can also keep things as they > are now, i.e. not support /usr on a separate partition. As I'll be > moving my /usr, that problem will become moot. > > Eric > >> >> Cheers, >> >> Tom >> > One quick question, why do I still have udev 169 and udev 171 starting. My /usr is on a separate partition and my loopback is not starting, but everything appears to work well. From the timing I would assume one is the mkinitcpio and one is rc.sysinit but thought I would check first. [myra@gandalf /var/log]:pacman -Qi udev Name : udev Version : 171-2 [myra@gandalf ~]:dmesg | grep udev [ 1.311992] udevd[86]: starting version 169 [ 5.723615] udevd[598]: starting version 171 [myra@gandalf ~]:sudo tail -n 2000 /var/log/everything.log | grep udev Jun 3 10:18:21 localhost [ 1.318643] udevd[86]: starting version 169 Jun 3 10:18:21 localhost [ 6.176941] udevd[609]: starting version 171 Jun 4 11:33:45 localhost [ 1.311992] udevd[86]: starting version 169 Jun 4 11:33:45 localhost [ 5.723615] udevd[598]: starting version 171 Myra -- Life's fun when your sick and psychotic! -- Life's fun when your sick and psychotic!

3 3

[arch-general] archlinux touchscreen problem on aigo p8880
by 吕宗庭 03 Jun '11

03 Jun '11

hello， I run archlinux on aigo p8880 with kernel 2.6.39 GMA500 with psb-gfx-bzr follow the link: wiki.archlinux.org/index.php/Poulsbo it works OK. But,the touchscreen doesn't works . someone can help me?

1 0

[arch-general] initscripts change
by Carl Mueller 03 Jun '11

03 Jun '11

Why change the modules array in initscripts? I always read that Arch was great because almost all configurations were done in one file, namely rc.conf.

2 1

[arch-general] [translation] Pacman 3.5.3 release soon
by Dan McGee 02 Jun '11

02 Jun '11

If you are interested in updating any translations before I release this maint version early next week, please do so: https://www.transifex.net/projects/p/archlinux-pacman/r/3-5-3/ Thanks! -Dan

1 0

[arch-general] /dev/snd/seq: Group permission lost
by XeCycle 02 Jun '11

02 Jun '11

Recently I need to chmod it manually after reboot. It's now 600, belong to root, group audio, I think 660 is better. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591 Facebook: Carl Lei Twitter: XeCycle Blog: http://xecycle.blogspot.com Thu, 02 Jun 2011 10:31:13 +0800

3 2

[arch-general] "whitebox" on bootup after KMS kicks in
by C Anthony Risinger 02 Jun '11

02 Jun '11

does anyone else experience <title>? i've been getting this for sometime -- on intel, nouveau, and radeon KMS drivers -- and it looks terrible. after the module loads within initramfs, the space *within* the old resolution is pure white, surrounded by normal black. i'm pretty sure the "whitebox" corresponds to the size of the previous resolution because it's different sizes on all my machines, and pretty small on my 1920x1280 laptop (@ 15.5in ... awesome :-) anyways, long story short it turns back 2 black when written over (systemd/initscripts output) or cleared, so: echo -en '\e[H\e[2J' ... takes care of it. i basically just did a `clear > out`, looked at the codes, and made a small initramfs hook from the above. it works fine as is, but is anyone else seeing this? it annoys me because i don't run getty on tty1, so it's there forever unless i clear right away. not really a big deal, as it took longer to write this msg than fix it, but it started happening a few kernels ago IIRC and i'm wondering if we can just throw something like this into mkinitcpio (if `quiet`, or before output), because it looks terrible :-( i'll open a report unless someone feels like throwing it in there, it's a pretty simple change. -- C Anthony

7 9

[arch-general] Salt update to 0.8.8
by Thomas S Hatch 01 Jun '11

01 Jun '11

I have not mentioned this here for a while, but I am a big fan of seeing what the Arch community is developing, and in the past I have gotten some real interest from the Arch community on this front. I just released Salt 0.8.8, salt is an application used for very fast remote management of systems via zeromq. Salt allows you to manage large groups of servers from a master server with simple commands, and salt also contains functionality for configuration management. Salt is meant to fill the roles of applications like puppet, mcollective, func, cgengine, fabric, Capistrano and many others. The release announcement is here: http://red45.wordpress.com/2011/05/30/salt-0-8-8/ Arch package is here: https://aur.archlinux.org/packages.php?ID=47512 Video explaining how to use Salt and what it is in detail is here: http://blip.tv/thomas-s-hatch/salt-0-8-7-presentation-5180182 And the (under heavy development) website and docs are here: http://thatch45.github.com/salt-www/ Salt is developed on Arch, but is made to run on any Linux/BSD Let me know what you all think! -Thomas S Hatch

1 0

Re: [arch-general] [arch-dev-public] [signoff] initscripts-2011.06.1-1
by Leandro Inacio 01 Jun '11

01 Jun '11

On Wed, Jun 1, 2011 at 09:38, Tom Gundersen <teg(a)jklm.no> wrote: > Hi guys, > > A new initscripts package is in testing. > > Please test and signoff. > > Big changes: > > 1) We gain support for iproute2, and net-tools is now optional (thanks > to Dave Reisner). If you don't update your rc.conf, everything should > work as before (using net-tools), pleas shout if it does not. > > 2) MOD_AUTOLOAD is deprecated (always leave it set to "yes") > > 3) blacklisting modules in the MODULES array is no longer supported, > use modprobe's native blacklisting instead (see 'man modprobe.conf'). > An announcement will be made about this before moving to core. > Since you are removing many of the references of modules in rc.conf (like blacklist and MOD_AUTOLOAD), why do not you remove MODULES array and leaves everything to modprobe.conf do this tasks?

2 2

[arch-general] PCSX2 for Archlinux thread
by rafael ff1 31 May '11

31 May '11

Hi all! Just to let you know that there is a sticky thread in PCSX2 forum specifically for Archlinux users. The intention is to put issues, patches and other things in the same thread, which might make easier for arch users have their answer or to contribute. Y'all are welcome! http://forums.pcsx2.net/Thread-PCSX2-for-Archlinux Cheers, Rafael

1 0

[arch-general] Can't create /tmp/.X11-unix and /tmp/.ICE-unix while booting
by Myra Nelson 30 May '11

30 May '11

Just before I do something stupid, I thought I would ask about these apparent errors. Mon May 30 11:49:39 2011: ^[[1;34;40m:: ^[[1;37;40mRemoving Leftover Files^[[1;0m ^[[s^[[151G ^[[1;34;40m[^[[0;36;40mBUSY^[[1;34;40m]^[[1;0m /bin/mkdir: cannot create directory `/tmp/.X11-unix': File exists Mon May 30 11:49:40 2011: /bin/mkdir: cannot create directory `/tmp/.ICE-unix': File exists My boot log goes back to 12 May 2011 so that's the earliest I can verify this data. I've search flyspray for any bug reports about this and didn't find any. Should these two files be deleted on shutdown or should they not be created on boot? If they should be deleted, where is the error? Myra -- Life's fun when your sick and psychotic!

2 5