Re: [arch-general] Trust This Computer?
On 06/30/14 at 07:36pm, Hunter Jozwiak wrote: I've gotten it to mount, finally, because I was missing the ubsuxd package. But, for whatever reason, my files on the iPod have gotten garbled up, and abl the music files now have unintelligable folder and file names. As an example, I organize my music like so: ~/Music/artist/album/tracknumber trackname But that's not what happens. You go in to iTones_Control/Music to see your music files, but the folders under Music start out with F00 anto tr fxx, depending on how much music you've got. Under one of the F folders, you get files like ayx.mp3, dbnq.mp3, etc. And it's a random jumble of music from your collection, there is no ordered hierarchy at all. I think this is actually just how iPods store the music actually. I remember on my old old iPod that things were organized in this way. You can thank Apple for this awesome setup... -- Curtis Shimamoto pgpztAwtrtm_G.pgp Description: PGP signature
Re: [arch-general] Kernel updated to 3.14.5-1. Now my Lenovo IdeaPad hangs on boot...
On 06/03/14 at 03:51pm, Hong Shick Pak wrote: I get these boot issues sporadically with kernel updates. I keep a separate boot entry in gummiboot with a kernel I know boots in case I get hit with it again. I haven't found anything useful on this silly bug so I'd say this is your best option if you would like to avoid booting a liveCD every time it happens. Rather than keep an old kernel around, I just keep grub-efi set up. Since the issue Mike Cloaked is referring to is the efistub bug, grub or syslinux (or elilo) continue to work just fine. So I primarily use gummiboot, but in the gummiboot menu I have ne entry to get to grub. From grub I can boot the kernel normally. But I haven't been hit by this bug since about 3.9 I think... -- Curtis Shimamoto pgp9gbz9FuuBS.pgp Description: PGP signature
Re: [arch-general] dnsmasq w/ad-blocking hosts file (was NTP: Possible permissions bug)
On 05/10/14 at 06:43pm, luc.li...@mailoo.org wrote: On Sat, May 10, 2014 at 12:41:36PM -0400, Carl Schaefer wrote: Also, since my machine doesn't travel: . add nohook resolv.conf to /etc/dhcpcd.conf . put nameserver 127.0.0.1 in /etc/resolv.conf . add to /etc/dnsmasq.conf no-resolv server=8.8.8.8 server=8.8.4.4 I haven't set this up on a laptop yet, but I imagine that would be more complicated because sometimes the google DNS servers will be inaccessible (e.g. hotel wifi). Using OpenDNS on port 5353 might be a good alternative. Carl for that case, I have modified /etc/resolvconf.conf to make netctl generate dns information on /etc/resolvdns.conf. I then setted /etc/resolv.conf to localhost, and configured dnsmasq to use /etc/resolvdns.conf. It is a bit a a hack, but it works. Instead of all that, you can simply use /etc/resolv.conf.head. Whatever you put in there will be put in the top of /etc/resolv.conf. This only works with dhcpcd though. For dhclient, you can configure this in /etc/dhclient.conf. -- Curtis Shimamoto pgpZFiDheQ0wU.pgp Description: PGP signature
Re: [arch-general] pacman and keys
On 04/25/14 at 10:09am, Heiko Becker wrote: Me again ... Today I tried the update again. When using LANG=de_DE.UTF-8 everything runs as reported. When setting LANG=C before everything gets updated but I get some strange systemd errors on update: Why would you try to use LANG=C? That is asking for trouble. See FS#36670. The bug report is about mkinitcpio, but the comments regarding locale are relevant here. -- Curtis Shimamoto pgplwhLG4mnJo.pgp Description: PGP signature
Re: [arch-general] Non-root X on Arch Linux
On 04/06/14 at 12:43am, Mark Lee wrote: Since Fedora 21 is working on dropping X root rights via systemd-logind. Does Arch intend to follow? I imagine this will be the case eventually. But as far as I can tell, at the moment these features are not yet included in the stable packages of everything that is required. Though like all things with Arch, I also would have to guess that this would be an option for configuration and not something that would become a default in the same way as Fedora. -- Curtis Shimamoto pgpSbb1cBgW7q.pgp Description: PGP signature
Re: [arch-general] Forum registration requires INSANE captcha.
On 02/11/14 at 10:11am, Bigby James wrote: On Mon Feb 10 12:20:45 EST 2014 Kyle wrote: I'll take a little frustration of non-linux using normal human beings over a captcha that completely excludes visually impaired normal human beings any day. I can understand your concern and applaud your consideration, but which of those two groups do you suppose would flood the forums if the barrier to entry were lowered? Let's be frank: The number of visually impaired users is, always has been and always will be outstripped by the number of help vampires. If a visually impaired Arch user needs help with a complex setup, that user can still consult the wiki and mailing list without the same barrier present on the forums, as anyone who's used all three can attest. I don't know what solutions (if any) exist for IRC users who are visually impaired, but that's a third option. Really, what you're talking about here is letting in an unwanted majority to avoid upsetting an otherwise acceptable, but extremely miniscule minority. There's no simple solution to such a conundrum, but there are multiple avenues of communication in the Arch community. There just seems to be something about online BBS that attracts the intellectually lazy in a manner that other online communication media do not. I think you've missed what Kyle is saying here. From what I understand (as a non-blind user), traditional captchas that are super hard to read and easily deciphered by computers are what tend to not be usable by the visually impaired. The captcha that we currently have should be great for the visually impaired using some of the available linux tools such as espeakup. -- Curtis Shimamoto pgpGnAttdpuer.pgp Description: PGP signature
Re: [arch-general] TDE binaries for pre-R14 testing are available (i686 x86_64)
On 01/31/14 at 12:55pm, David C. Rankin wrote: On 01/30/2014 06:58 PM, Curtis Shimamoto wrote: You shouldn't tell people to ever do just '-Sy'. This can lead to partial updates and potential breakage. Well, that was in the context of just having added: [trinity] SigLevel = Never Server = http://trinity.ceux.org/r14/x86_64 Without the 'y' there would be nothing to see?? It is just never safe to do just a 'pacman -Sy' without the --upgrade, as that has the potential to lead to partial upgrades.[0] [0] https://wiki.archlinux.org/index.php/Pacman#Partial_upgrades_are_unsupported -- Curtis Shimamoto pgpT9Y45lX4Ol.pgp Description: PGP signature
Re: [arch-general] TDE binaries for pre-R14 testing are available (i686 x86_64)
On 01/30/14 at 01:50am, David C. Rankin wrote: Package for the Trinity Desktop upcoming R14 release are available for testing. These packages are within a few commits of what RC1 for the release will be. snip pacman -Sy group You shouldn't tell people to ever do just '-Sy'. This can lead to partial updates and potential breakage. -- Curtis Shimamoto pgpP6bX7GxSZL.pgp Description: PGP signature
[arch-general] connman conflicts
I was wondering why connman conflicts with openresolv. Looking through the files in each package, there don't seem to be any in common. So I figure there must be something that I am missing or just completely unaware of. I am primarily a connman user, but I use connman-git from the AUR, both because it seems to be in pretty active development and because it does not have as many of the features that I don't need built into it. In the AUR, connman-git does not conflict with openresolv. So I am kind of wondering if it should. I like having netctl on my machine as well, but if this poses some kind of risk or true conflict somehow, I would just like to know if I should make a decision between one or the other. Thanks. -- Curtis Shimamoto pgpfEZ56bJJ26.pgp Description: PGP signature
Re: [arch-general] Locale Changed
On 12/26/13 at 11:14am, Kirill Churin wrote: On Thu, Dec 26, 2013 at 8:42 AM, Silvio Siefke siefke_lis...@web.de wrote: Hello, On Wed, 25 Dec 2013 22:33:47 +0600 Kirill Churin reflex...@reflexing.ru wrote: 1) Did you run 'locale-gen' command as suggested? Yes see my mail which send before. 2) Are you sure programs you use have German locale? Maybe it doesn't :) Yes im sure VLC, Sylpheed, Thunar, Geany, Xfce can use German locale, because they do it now too. I has reinstall Arch now. Thank you Greetings Silvio Try to reinstall glibc. In the future, if you get a warning or error that a necessary file is missing, you can use pkgfile to see if there is a package that should be providing it. This is what I get: $ pkgfile /usr/share/locale/locale.alias core/glibc -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com pgpeUA7vFv7ul.pgp Description: PGP signature
Re: [arch-general] Initramfs fallback render
On 11/15/13 at 06:37pm, Ismael Bouya wrote: By the way I came to a dark point : how does systemd knows that he is started in fallbackmode ? Likely, something is broken with your fallback initramfs. Booting from the fallback should be no different than booting from the normal initramfs. The fallback simply doesn't apply the autodetect hook, so it does not try to exclude unnecessary modules. The fallback is typically useful if you have a disk that you might want to move to another machine with different hardware. It is just not machine specific like th normal one. -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com pgpQHP4T3482a.pgp Description: PGP signature
[arch-general] Fwd: Re: [aur-general] systemd 207 and btrfs
- Forwarded message from Curtis Shimamoto sugar.and.scru...@gmail.com - Date: Wed, 18 Sep 2013 18:50:16 -0700 From: Curtis Shimamoto sugar.and.scru...@gmail.com To: Discussion about the Arch User Repository (AUR) aur-gene...@archlinux.org Subject: Re: [aur-general] systemd 207 and btrfs On 09/18/13 at 08:31pm, Jameson wrote: I upgraded to systemd 207 today, and upon reboot received several messages that say, failed to open /dev/btrfs-control skipping device registration: No such file or directory. The btrfs problem faq suggests that running mknod /dev/btrfs-control c 10 234 should fix me up. However, when I run this it says that it already exists. The only significant changes that I made were to upgrade systemd, and add the systemd hook to mkinicpio.conf. I tried booting from external media, and removing the systemd hook, but after re-running mkinitcpio I still get the same result. Does anyone have any suggestions for getting past this? I will happily provide more information if you can tell me what would be helpful. Thanks, =-Jameson I think you probably meant to send this to [arch-general], not [aur-general]. So I am going to send this to both… we'll see where it goes. Your btrfs filesystem must span more than one device, yes? I too was having this problem with a multidevice btrfs filesystem, but ran into it a while back since I use [testing]. I thought it must have been something I screwed up, so since data was in 'single' anyway (different size devices), I decided to just convert it to use just one disk. I had meant to debug it later, but forgot about it shortly thereafter, and didn't even remember to do that until I saw this email. It was definitely the lack of /dev/btrfs-control that was causing the failure though, as I was getting that error message. I recall checking immediately after getting the message and seeing that /dev/btrfs-control was indeed there. So maybe this is some kind of a race condition? This is just a shot in the dark, but what if you were to put the necessary modules for btrfs in mkinitcpio.conf's MODULES list to have it loaded explicitly and early? -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com Whoops, forgot to CC arch-general like I said I would… - End forwarded message - -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com pgp2p4q4mE78U.pgp Description: PGP signature
Re: [arch-general] Initramfs doesn't ask for password to encrypted LVM
On 08/28/13 at 05:30pm, Simon Thelen wrote: On 28/08/13 at 10:47, Bartłomiej Piotrowski wrote: I guess it's trivial to fix, I usually overlook basic things... I installed Arch on encrypted LVM without issues, but for some reason initramfs doesn't ask for password to encrypted LVM and waits for root device instead. I'm not sure where the problem lies -- configuration files[1] seem correct to me. First, your HOOKS array should have lvm2 before encrypt so that the initramfs can setup the root volume before it tries decrypting it. IE: HOOKS=base udev autodetect modconf block keymap lvm2 encrypt filesystems keyboard fsck systemd This used to be the case. But now the LVM2 is assembled via udev, so it does not matter where in the order the lvm2 hook resides. -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com
Re: [arch-general] Finishing the /usr move
On 05/31/13 at 06:26pm, Karol Blazewicz wrote: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-May/025026.html 3) Update your system: $ pacman -Syu --ignore filesystem $ pacman -Su It should say '#', not '$'. Dear Arch Linux dev team, I just want to say that I went through this update this morning. Having read the chatter on arch-dev-public, it was incredibly simple to find any AUR packages that might have snagged my update. I fixed them very quickly (I only had four), and everything was amazingly smooth. So thank you for making this update nearly seamless. I think I speak for a majority of Arch Linux users when I say that your work is appreciated immensely. Though maybe you all don't hear enough about what an awesome job you do. There was one package that kept me from updating right away. I have been meaning to play with glusterfs, so I had the package installed on my system. There is still a /usr/sbin/mount.glusterfs present in that package. But since I sitll haven't gotten around to trying it out, a simple removal of the package was all I needed to move that update right along. Thanks again. Regards, -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com
Re: [arch-general] failed to mount root on raid1 after upgrade
On 04/02/13 at 09:54am, Łukasz Michalski wrote: Hi, I am a new arch user and this is my first post on this list, so welcome everyone :-) 29th I upgraded my system using pacman -Syu and after that my system does not boot. The problem is that I have root partition on software raid1 and for some reason scripts from initramfs are not able to create /dev/md device and mount it on /new_root. I am using mdadm hook. Have you tried using the mdadm_udev hook? I think this is the better way to go. In my experience in the past, it was certainly the faster more reliable hook. -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com
Re: [arch-general] Broadcom B43 problems
On 03/26/13 at 01:37pm, Julien Pecqueur wrote: Which card did you bought? Cordialement, Julien Pecqueur There was a mention above about buying a Realtek card. I just want to mention that my experience with Realtek wireless chipsets has been nothing but hell. My Thinkpad came with a Realtek that used the rtl8192ce module, and it was terrible. I recently was forced to try it again, and it had gotten better, but was still of pretty questionable quality. The first time I replaced it I was able to flash a modified bios that removed the Lenovo wifi card whitelist, and replaced it with an Intel Centrino Advanced-N 6235 which was amazing. This time, I was unable to remove the whitelist (or rather flash the newly modified bios, removal was the same as always) so I was able to find the Intel Centrino Wireless-N 2230 that was apparently an option with this laptop. My experience with Intel wireless has been fantastic, and I highly recommend them. I have also been told that Atheros support is very good as well. Though it has been quite some time since my last use of an Atheros chipset on Linux (my old MacBook 2,1 has an Atheros, but that machine has since gone back to OS X as a family computer). -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com
Re: [arch-general] Broadcom B43 problems
On 03/26/13 at 02:02pm, Sean Greenslade wrote: On Mar 26, 2013 11:56 AM, Curtis Shimamoto sugar.and.scru...@gmail.com wrote: On 03/26/13 at 01:37pm, Julien Pecqueur wrote: Which card did you bought? Cordialement, Julien Pecqueur There was a mention above about buying a Realtek card. I just want to mention that my experience with Realtek wireless chipsets has been nothing but hell. My Thinkpad came with a Realtek that used the rtl8192ce module, and it was terrible. I recently was forced to try it again, and it had gotten better, but was still of pretty questionable quality. The first time I replaced it I was able to flash a modified bios that removed the Lenovo wifi card whitelist, and replaced it with an Intel Centrino Advanced-N 6235 which was amazing. [snip] Curtis Shimamoto sugar.and.scruffy [at] gmail.com Might I ask what problems you had? My experience with the 8192 was poor only because the drivers were in staging until the 3.0 kernel release. I switched to the 8188 in my netbook and the 8171 (maybe, my memory is failing me on that one) on my main laptop. Not all realtek chipsets are equal... No not all Realtek chipsets are created equal. My issues were with some crazy latency any time I tried to do anything. Once it started loading something, likea web page for instance, it was fine. But getting to that point was just really sluggish. The first time I used it was when I got my Thinkpad in mid 2012, and it was so horribly painful it was awful. It was so bad that it would actually case other devices on the network to lose their connection sometimes. I am not sure how or why this would happen, but it wouldn't if I were not connected. The second time, was just a couple weeks ago when I had to have the mobo replaced. I now have the Lenovo wifi whitelist back, so I had to resort to the Realtek. It was much much better than the first time, but when I got an Intel to stick in the machine, it was like night and day. This particular module (the rtl8192ce) I see people having issues with all the time on the forums. So I know that the pain is not mine alone. I have not had the chance to try other Realtek cards, but you are not the first to tell me that there are others out there that work well. Still this chipset seems to be particularly common today, so I just wanted to throw this out there. I think it was the rtl8188/8192? I don't know specifically w/o putting the card back into the machine. -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com
Re: [arch-general] bluetooth headset vs. Flash Player
On 03/26/13 at 08:06pm, Nelson Marambio wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, folks, since I switched from a wired USB headset to a bluetooth headset I've got problem - using GNOME - with flash based sites like youtube. Sound is not send to the headset but to the internal speakers of my laptop. Every other media player uses the headset for output but not flash. Does anyone know why and how to fix it ? Kind regards, Nelson. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRUfGuAAoJEL11/FaGDdNAKfIH/3kM/RNX5imRyXLNRUkQx5oX G9HKwm1AfEvuuz3STZkdeABsla66O0x1r2kh1t/nzV35eyUmBlYJPCPkslMKK/Or T68lj7XGqrfMg8+AUTNONJQGQr76Getv9siHdag1j+eD3qYyaJheTVlBzpEW9oZM aJmis+f1LkA/b3cdtJhH0U7nx7sNzgE01IRd9GrvqoQIqGgnMDAJP4YUNF15jGmt EyaMzLiADuKDqOBYpMcnXkgAYpvqKKbmUK4fgQvlExwTw/AW96EmvPqyANp9IRr9 Md5hd8aciECpsGa0X2a2Xj9xw2pVYFatEXLZGuQHGS/OI2+CSRQHUB4KIcsuzbQ= =g/9D -END PGP SIGNATURE- I believe flash is not capable of using pulseaudio directly. So it uses alsa. In order to get this to work, you need to configure alsa to use pulseaudio. This is particularly easy, as the necessary configuration is the only content found in the pulseaudio-alsa package. https://wiki.archlinux.org/index.php/PulseAudio#Flash_Content -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com
Re: [arch-general] Troubleshooting random crash
full). To confirm, start thunderbird with an empty profile (such as by renaming ~/.mozilla into ~/.mozilla.old) and see what happens. The thing is, this doesn't happen everytime I start thunderbird -- rather, seemingly, after the system has been up for a long period (20 hrs or so). The filesystem is not nearly full either, though it does contain a lot of data. I'm thinking downgrading to 3.6.x will help a bit. I'm going to look for btrfs bugs in 3.7.x and see if anyone else has been having a similar issue as well. Thanks for the assistance. For downgrading, I have found the Arch Rollback Machine quite handy. You can choose a date to roll back to, sync and then have pacman reinstall all packages that it finds are newer than its database. This is of course if there was not a significant change like potentially the recent filesyatem update. I would certainly try doing just the kernel first though, as that is even easier. Just thought I would mention that amazing tool we have in our debugging arsenal. Regards, -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] UEFI experience - recommendations needed.
On 01/08/13 at 09:38am, Mike Cloaked wrote: On Tue, Jan 8, 2013 at 9:35 AM, Paul Gideon Dann pdgid...@gmail.com wrote: On Monday 07 Jan 2013 18:46:14 LANGLOIS Olivier PIS -EXT wrote: To be honest, I had 0 problem with installation and UEFI usage. Beside installation, there is very few noticeable difference between BIOS and UEFI. I have insisted to use it just because I had a MB capable of UEFI. If you want to try UEFI, my advice is. Go for it, there is not much risk to do it but do not expect a big change. This won't shake your world! Seconded. It makes very little difference, if any. The only time I've noticed is when I wanted to upgrade the laptop's firmware, and getting a FreeDOS image to boot was trickier than with BIOS. Paul That's interesting - though I guess it is possible to change the BIOS setting just to boot a freedos usbkey to reflash the firmware and then reset to uefi again to boot back into the normal system again? -- mike c Yes, this is what I have done in the past. I actually I just left UEFI and bios enabled for some time. My computer gives the option of whether to give preference to UEFI or legacy bios if both are present. Recently, though I turned off legacy bios, though I am not sure why or if I gain anything from it. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] Optimising ssd setup?
On 01/07/13 at 04:24pm, Mike Cloaked wrote:
As part of my planning for setting up a home build computer which will use
two ssd drives - one a Crucial M4 mSATA drive (for root and boot
partitions) and a second larger Crucial M4 SATA III drive for the rest, I
have been reading up about partitioning and optimising such drives -
It seems that it is important to partition with proper alignment to MiB
boundaries for partitions but I am unclear if this happens automatically or
not when setting up GPT partitions with gparted? ( I usually partition
using a liveusb running PartedMagic and then run gparted before installing
arch)
I am not user about gparted, but I know that gptfdisk handles this
automatically as does fdisk these days. I am not so familiar with parted
in general, so maybe someone else can step in here.
Also I have been seeing various bits of advice about ensuring that
excessive writes are avoided by using a non-default IO scheduler - with
deadline being the better option for SSDs than the default CFQ scheduler
- and it would seem that adding the parameter to the kernel line for boot
once a system is set up is perhaps a good way forward? How does that work
if UEFI booting?
I use a udev rule to determine what scheduler should be used for what.
At one point I had both rotational disks and a solid state drive. So I
continued to use CFQ for the rotational and I use NOOP for the flash
based media. This is what I use:
ACTION==add, KERNEL==sd[a-z], ATTR{queue/rotational}==0, \
ATTR{queue/scheduler}=noop
In addition it is suggested that for a machine with a reasonable RAM (in my
case 8GiB) then reducing the swappiness parameter to 1 via systemctl, or
altering the relevant parameter under /proc/sys is the way to do it, even
if there is a swap partition on one of the SSDs.
If you have 8GB of RAM, you probably don't need swap. I have 8GB and
don't use it. I have seen no ill effects, no OOM. But yes, if you have
it, lower your swappiness and it will avoid writing to disk as much as it
can.
I have also seen it suggested that TRIM support is important either
mounting with the discard option or running fstrim manually via a cron
job out of hours to avoid delays during writes whilst the system is in use.
Finally I have seen suggested that the noatime flag be used for mounting
SSD drives.
I use noatime in general, as I don't really care about access times. It
will still record times when you make changes to a file, so that is
enough for me. Apparently, using noatime with mutt can mess mutt's
functionality up. But this negative consequence can be minimized by
using a Maildir if you use mutt.
I personally use an anacron job to apply fstrim to my drives once a day.
I find that is more than than enough. There are some drives that
apparently are slowed down quite a bit when set to do trim on real time.
I don't think that my drives are in this category, but I like being able
to set the nice value of fstrim, so that is why I do it that way.
Can anyone on this list who has set up a recent SSD drive and has
experience of SSD wear issues, and levelling issues, offer any advice on
whether some or all of the above are important when using SSD drives in an
arch linux machine or whether partitioning and installing essentially with
defaults is going to lead to SSD problems, or not?
I don't think you need to worry about wearing out the drive. As long as
you have a quality drive, which the Crucial M4s are, you should have no
problems.
This will be my first foray into using SSD drives on any of my systems.
Thanks for any replies.
--
mike c
--
Sugar Scruffy
sugar.and.scru...@gmail.com
Re: [arch-general] UEFI experience - recommendations needed.
On 01/05/13 at 08:23pm, Mike Cloaked wrote: I am building a machine which has an EFI capable boot on the motherboard together with an mSATA drive for the root and boot partitions and an SSD for the /opt and swap partitions, and just a single arch x86_64 install when it is built - no dual booting to other OSes. I have been looking up information about UEFI with GPT partitioning and have read about various problems that people have had with such systems. So at this stage I am unsure whether to stick with what I know (BIOS/MBR and GRUB2 with full systemd) or whether to plunge into the unknown (for me!) and try EFI/GPT! (with rEFInd) Does anyone have experience with such a UEFI system on this list? Apart from the info on the arch wiki and the install wiki info (which I have been reading), are systems like this reliable once installed? Does the routine pacman update process for kernels lead to issues requiring manual intervention with EFI/GPT or it is as generally reliable as BIOS/MBR? I would be interested to hear from anyone with this kind of experience running arch - if it is useful the motherboard I am using is an Intel DQ77KB (which I intend to update with the latest BIOS firmware) and with the Intel i3-3220T CPU. Thanks for any replies (and useful links) -- mike c Mike, I use UEFI, and find it as reliable as bios booting ever was. At the moment I was only a single Arch Linux installation on my system. I have a Thinkpad with a 250GB Samsung 840, a 128GB Samsung 830, and a Mushkin Atlas 128GB mSATA. You should know that it is no problem to set things up with legacy bios bootability, and then get your setup booting with UEFI at a later time. The two standards actually don't even conflict with each other and can peacefully coexist. I actually have my system's bios set to UEFI only, but I also have syslinux installed as a just in case kind of thing. I would recommend using GPT no matter which method you choose (or if you choose both). I think MBR partitioning is getting a bit outdated, and extended partitions are to be avoided whenver possible. But from the sound of it, you won't have the need to use extended partitions anyway. Still the flexability of GPT is much greater, and I really like the fact that it puts the partition table in the beginning of the disk like normal, but also ar the end for a backup. I have actually had to restore my partition table from the backup once (while messing around with windows to do a firmware update, windows does some funky things). The only thing I have done that differs from the recommendations of the wiki is that I actually use my EFI system partition as /boot. This is partially because my system does not seem to like the initramfs anywhere but the root of the ESP (when I use an efibootmgr entry to directly boot the kernel stubloader). During updates, it is nice to have the kernel be installed to the correct place. But I still require a systemd.path/systemd.service to append '.efi' to the kernel (which designates it as a UEFI application to my firmware). So I guess just get things set up with the familiar legacy bios, but use GPT for sure. If you want to use the ESP as /boot, I know that syslinux will boot from vfat, but I am not sure about grub as I have not tried it. I hope this information helps. Regards, -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] UEFI experience - recommendations needed.
On 01/05/13 at 09:54pm, Tom Gundersen wrote: On Sat, Jan 5, 2013 at 9:23 PM, Mike Cloaked mike.cloa...@gmail.com wrote: Does anyone have experience with such a UEFI system on this list? Apart from the info on the arch wiki and the install wiki info (which I have been reading), are systems like this reliable once installed? Does the routine pacman update process for kernels lead to issues requiring manual intervention with EFI/GPT or it is as generally reliable as BIOS/MBR? I recently got an MacBook with which I use EFI/GPT, and it works shockingly well. I use gummiboot as the bootloader and partitioned my disk using gdisk. The only gotcha worth mentioning that I can think of is that your kernel/initramfs must be installed on your EFI partition (which according to some sources should be at least 512MB, though mine is not). It is simple enough to make that work automagically by mounting your EFI partition on /boot (with an /boot/EFI subdirectory), rather than having a separate /boot partition and mounting the EFI partition on /boot/EFI. HTH, Tom From what I have been reading in the forums of late, apparently rEFInd has a driver to read ext2 partitions, so can read your kernel/initramfs from there. Also, srs5694 has indicated that the git version of rEFInd now has a driver to read ext4 as well. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] UEFI experience - recommendations needed.
On 01/05/13 at 09:41pm, Mike Cloaked wrote: On Sat, Jan 5, 2013 at 9:08 PM, Curtis Shimamoto sugar.and.scru...@gmail.com wrote: From what I have been reading in the forums of late, apparently rEFInd has a driver to read ext2 partitions, so can read your kernel/initramfs from there. Also, srs5694 has indicated that the git version of rEFInd now has a driver to read ext4 as well. -- Curtis Shimamoto sugar.and.scru...@gmail.com Thank you for both replies, Curtis - your comment about a systemd service file to append .efi to the kernel implies that when there is a kernel update you need to either manually create the appropriate filename (presumably in the ESP area?) or have the service file run a command to do that (presumably once written it is automatic?) after the kernel update? Most firmware seems to want any efi application to have '.efi' at the end of it. From what I have read, there are some instances in which this is not necessary. For instance, from the uefi shell, it seems to append that for you if it is not there. Also, the gummiboot entry on the archiso does not have it either, so maybe gummiboot can do without. I know that if you are using a direct efibootmgr entry, you will more than likely need the '.efi' after it. I use gummiboot now, but I still have systemd set up to append that on every kernel update. There are some good instructions on how to set this up on the uefi wiki page. It sounds like the way forward is to set up with legacy and switch once the base install is done. Also I usually in the past format the drive before the install with partedmagic booted from a usbkey - but from what I have read partedmagic won't boot from a key with uefi! So if I start out with normal BIOS and do disc partitioning, as well as flashing the BIOS with updated firmware from a bootable dos key then I guess the main install should be as normal - and if it boots with legacy BIOS set with GPT formatted drives then it would hopefully not be too much work changing over to EFI at that stage. Yes, this should be fine. It does not matter how your system is booted when you do the partitioning. The only time you need to actually boot into UEFI is in order to create bootloader entries. This is because the efivars module must be loaded in order for your machine to access the nvram, and the module cannot be loaded unless you are booted with UEFI. A simple way around this is by using the default efi application. If you choose to boot from the disk itself, and have it set to boot UEFI, it will boot whatever is located at \EFI\boot\bootx64.efi. So you can put whatever you want there. When I first began using UEFI, I had the UEFI Shell there so that I could always fall back to something versatile. But now that I have gummiboot set up the way I like it, I have gummiboot there instead. From what I read if using rEFInd then Grub is not needed but am still reading! Yes, rEFInd is a boot manager, while grub is both a boot loader and a boot manager. The boot manager part is the selection menu, the loader part is actually loading the kernel. But the kernel now features stub loader support, which enables it to act as its own bootloader. Hence you can make an entry directly into your bios' nvram to boot the kernel directly (using efibootmgr). Instructions are also in the wiki. -- mike c -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] Install problem
On 12/31/12 at 05:39am, Martín Cigorraga wrote: On Sun, Dec 30, 2012 at 9:22 PM, Dario carotin...@yahoo.it wrote: Hi I've blacklisted pata_acpi because of random boot failures. Maybe it's your case. Wasn't that hook replaced a week or so ago with the 'block' flag? I think that Diaro is referring to the actual pata_acpi module. As the mkinitcpio hook was simply pata. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] alternative to pmount
On 12/25/12 at 10:37am, gt wrote: On Sun, Dec 23, 2012 at 09:56:32PM -0500, Juan Diego Tascón wrote: Last week pmount went from extra to aur. I used to use pmount to allow users to mount external devices as simple as: pmount /dev/sdb1 Is there an alternative to pmount in core, extra or community that allows users to mount with a simple command an external storage device? udevil. Interestingy, a thread in the forums with the exact same title came up recently. https://bbs.archlinux.org/viewtopic.php?id=154939 The answer there was also udevil, but it was pointed out also that udisks can be used in this fashion as well. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] On /etc/conf.d deprecation
On 12/09/12 at 05:23pm, Dimitrios Apostolou wrote: On Sat, 8 Dec 2012, Curtis Shimamoto wrote: On 12/09/12 at 04:01am, Dimitrios Apostolou wrote: Imagine that in /usr unit file the daemon is being called as binary -d. So I create the /etc unit file that supersedes it and calls it as blah -d -n1. Then the package gets updated and the /usr unit file changes to binary -d --lock=/whatever/path. As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called binary -d --lock=/whatever/path $BLAH_ARGS there would have been no such problem. Keep some kind of configuration fine and use the .include feature of systemd units to source the config with EnvironmentFile=. Hi Curtis, I can't see how the .include directive would help in the case I mentioned. But even in other cases that it helps, I think it's a much more heavyweight solution to the problem, than the /etc/conf.d EnvironmentFile. What do you think? Dimitris Yeah, I wrote back shortly after I sent that mentioning that it really wouldn't work, after I had thought it through a bit. I am not sure what you mean by heavyweight solution. If what you mean is that is will have to check for and then source a secondary file of the same name, I really don't think this would matter as it only has to do it once. Also, this seems like it is probably nearly the same amount of work for the system as sourcing a configuration file. Could you explain what you mean by heavyweight? I do agree with the fact that things should move towards following upstream, and the use of conf.d specifically should be deprecated. That doesn't necessarily mean that I think that you, the user, should not be able to create a config file on your own to source and use in the service. Personally, I have only made use of the .include feature once, and for something very simple. This issue of yours has made me think that it might be neat if there was a service variable to append to the ExecStart line. Thus making the .include feature more robust, as you could add to instead of replacing the actual command. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] harddisk suspending far to often
On 12/08/12 at 09:48pm, G. Schlisio wrote: Am 07.12.2012 01:49, schrieb Calvin Morrison: On 6 December 2012 17:05, G. Schlisio g.schli...@dukun.de wrote: Am 06.12.2012 21:07, schrieb Jonathan Steel: On Thu, Dec 06, 2012 at 10:59:27AM +0100, G. Schlisio wrote: after updating my laptop today [0] (no testing enabled) i notice that my harddisk keeps spinning down and up every 10 seconds or so. might this be related to the update or where can i stop this? somehow it resolved itself today. now hdd is running continuously again. If it happens again, you can check this with: hdparm -B /dev/sdx If it's spinning down too often, try: hdparm -B 254 /dev/sdx thank you for your advice. hdparm -B /device returns 254 to me now, thats quire expected, because now everything works fine. i wonder, how/whether it could have been altered yesterday. do programs like powertop touch those values? If you are messing around with powertop, yes I think that could have been it. Usually powertop can adjust hd settings i uninstalled powertop after my last post, but yesterday it happend again. when i checked the APM level it was set to 1. i only experience this after suspend to ram. how can i get to know, why this is happening, and maybe stop it? When I still had rotational hard drives, I noticed that my APM level would reset after suspend. This, I later found, is expected behavior. So you either need to put something in /usr/lib/systemd/system-sleep or make an appropriate service file to reinstate the APM. Why it defaults to 1 I have not idea though. Regards, -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] On /etc/conf.d deprecation
On 12/09/12 at 04:01am, Dimitrios Apostolou wrote: Hello list, from a reply I got to a bug report (FS#32817, reply is private) I found out that configuration files in /etc/conf.d are deprecated and that the supported way is to replicate and customize service files. Imagine that in /usr unit file the daemon is being called as binary -d. So I create the /etc unit file that supersedes it and calls it as blah -d -n1. Then the package gets updated and the /usr unit file changes to binary -d --lock=/whatever/path. As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called binary -d --lock=/whatever/path $BLAH_ARGS there would have been no such problem. /etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file. So I'm curious to know why this mechanism was deprecated? Is it speed we gain by not including the EnvironmentFile directive in the systemd unit file? Is there some other reason I might be missing? Thanks in advance, Dimitris Keep some kind of configuration fine and use the .include feature of systemd units to source the config with EnvironmentFile=. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] No suspend in systemd
On 12/04/12 at 07:25am, Δημήτρης Ζέρβας wrote: try executing the command as root This is probably a good call. But if you are able to do this as root, I think it means that your session is probably not authenticated. $ loginctl show-session $XDG_SESSION_ID Then make sure your it says Active=yes I think it should be noted that this issue has been brought up numerous times, and any quick search in the forums would probably have yeilded this answer. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] File permissions with udisks/udisk2 mounts
On 11/22/12 at 05:00pm, Paul Marwick wrote: I tried asking this on the forum, didn't get any real answers, so I'm hoping someone here can help. I have a script located on a Vfat-formatted flash drive. When mounted using udisks, there are no execute permissions showing on the files, and they cannot be set. After some research, it seems that udisks works with polkit to set things like permission on mounted devices. Unfortunately, so far my attempts at research haven't led me to any information on setting permissions the way I need them, or even where the settings are stored. So I'm hoping someone can point me in the right direction - I want to be able to modify things like execute permissions on mounted devices when I need to. I'm not all that partial to being effectively told I can't do that - reminds me much too much of Windows. I've tried a few workarounds, with little or no success. I installed pmount and used it with the -e option to mount the device. Still no execute permissions. I tried using sh to execute the script - failed again I also tried adding the device to /etc/fstab. In that instance, the file showed as executable, but any attempt to execute it, even as root, got a 'permission denied' message. Argh! Paul. Have you tried manually mounting with something like: # mount -o exec /dev/whatever /mount/point I don't use udisks, but I use pmount and (I think) it automatically mounts with the noexec option. I have never had a reason to try to get around this, so I also cannot speak to whether or not working around it is functional. But I figure if you do it manually, and specify exec, if it still doesn't work, then you at least then know that it is not specific to any of these automounting functions you use. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] Polluted login prompt
On 11/22/12 at 06:19pm, kachelaqa wrote: On 21/11/12 16:00, Sudaraka Wijesinghe wrote: I start both Apache and MySQL services on boot, and both of them display the start complete message after the login prompt. Something like this: Starting MySQL Starting Apache login: [ OK ] MySQL started [ OK ] Apache started Although this doesn't break anything it just doesn't look nice. (BTW, I'm not using any DM and getty is set NOT to clear any boot messages) I had this exact same problem with certain services spewing messages over my login prompt. I solved it by adding a slight delay to the startup of the offending service. That is, I created a file like this: [Timer] OnActiveSec=30 And saved it as /etc/systemd/system/multi-user.target.wants/httpd.timer. See man systemd.timer for further info. HTH I noticed that when I turned down logging to the console in journald.conf it started only telling me the fsck status of / instead of all of the partitions. So maybe there is some happy medium that you may be able to find without the quiet parameter and a lower MaxLevelConsole= setting. I cannot remember what level it was though, I want to say it was the equivalent to 3, but I am not certain. I have since gone back to defaults and have to agree with the sentiments of others that the quiet parameter with systemctl --failed is perfect. The speed at which the boot stuff whizzes by is too fast to really be usable anyway (though I am an SSD user). -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] LVM Thin Provisioning
Thank you for your response. I loaded the module using modprobe dm_thin_pool and it can be seen using # lsmod | grep dm_ dm_thin_pool 39196 0 dm_persistent_data 37291 1 dm_thin_pool dm_bufio 14228 1 dm_persistent_data libcrc32c 1002 1 dm_persistent_data dm_snapshot28351 0 dm_zero 1247 0 dm_mod 72105 5 dm_zero,dm_bufio,dm_thin_pool,dm_snapshot and # dmsetup targets thin-poolv1.4.0 thin v1.4.0 snapshot-merge v1.1.0 snapshot-origin v1.7.1 snapshot v1.10.0 zero v1.0.0 striped v1.5.0 linear v1.1.0 errorv1.0.1 however, I still get the same error message when trying to create a thin volume/pool. I couldn't find any options in lvm.conf that needed to be set either. Is there something else I can try? -- Yesterday is history. Tomorrow is a mystery. Today is a gift. That's why its called the present. Headmaster Squall :: The Wired/Section-9 Close the world txen eht nepo $3R14L 3XP3R1M3NT$ #L41N https://github.com/headmastersqual http://twitter.com/headmastersquall I looked through the options of LVM2 and compared them with the PKGBUILD from ABS. It would appear as though the default is to not enable thin-provisioning, and the PKGBUILD does not have any inclusion of that option either. /tmp/makepkg/src/LVM2.2.02.98 $ ./configure --help ... --with-thin=TYPEthin provisioning support: internal/shared/none [[TYPE=none]] ... It appears as though you need to edit the PKGBUILD and build yourself. Regards, -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] immediate sleep after resume
On 11/15/12 at 02:11pm, Leonidas Spyropoulos wrote: On 15 Nov 2012 13:52, Genes MailLists li...@sapience.com wrote: This started happening sometime after I switched to systemd (tho I am not finger pointing). Upon resume - the laptop immediately sleeps - the second resume is fine. Not every time either. Fresh boot - sleep - resume cycle seems to work fine. Googling suggested putting this in /etc/systemd/login.conf LidSwitchIgnoreInhibited=no However this makes no sense to me - as surely systemd knows the difference between the open and close lid events. The argument made was that there was competition between kde and systemd to sleep/resume and this would keep systemd from doing anything. Anyway - above makes no difference :-) Anyone have any ideas? testing repo fully updated - using kde and systemd. gene/ Hmm I am having the same behaviour without testing repos enabled, up to date, and with slim + xfce. I am also using systemd. It might have to do with the WiFi. Mine is a broadcom chip and unfortunately i found only the closed source drivers work (wl). I will try the suggested from Google config. Thanks, Leonidas In your apparent google adventure, I find it suprising yuo did not find the correct answer as I have seen it come up in the forums many many times. Also suprising is that when you found the suggestion to use LidSwitchIgnoreInhibited=no, you didn't then find that logind.conf has other options in that file. See the logind.conf man page for the answer. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] immediate sleep after resume
On 11/15/12 at 11:18am, Genes MailLists wrote: Forgot to mention in original post - it seems well understood that the window managers may or may not play nicely with systemd - as to who will do power management. If a user is not logged in - it is still nice to have systemd sleep system on lid close for example - and for this reason the window managers are given the ability to inhibit systemd when they are claiming to do the power management. And when they are not, then systemd does not get the inhibit. [1] Several window managers, KDE among them are supposed to play nice with systemd in this regard. So, one suggestion some have is not to use KDE at all for this - and rely solely on systemd - it is of course less configurable. I have not yet tried this approach. This can be done via the same login.conf. It's not a huge deal, as I just press power button to wake it up again, but curious what others have found. gene [1] I'd rather have a positive than a triple negative LidSwitchIgnoreInhibited=no might be easier to read as LidSwitchInhibitIsActive=yes Personally I just use xautolock, so I don't have to deal with these competing systemd. I just use the native systemd (actually in its default form), and it works well. I was not aware that you were working towards teh goal of having systemd actually handle the stuff, as other users typically wanted their DE to handle the power management, and have systemd do nothing. This is why I directed you to the man page, in hopes that you would find the HandleLidSwitch= setting. As far as doing it the way you want, I have heard (though I don't use KDE so I have no personal experience) that it's power management does not play nicely with this system. I am not sure what power management setups do play nicely, but every KDE user that I have come across all ended up just setting HandleLidSwitch=ignore and being done with it. If you can get your proposed setup working, I would love to hear about it. I do not use said systems, but I still welcome knowledge. Maybe a DE user can weigh in here. Best of luck. Regards, -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] Qingy on systemd
On 11/08/12 at 07:04am, Tom Rand wrote: On Tue, Nov 06, 2012 at 01:16:43PM -0500, David Rosenstrauch wrote: I recently switched over to systemd, and am trying to get my system set up the way I like under there. I'm trying to set up qingy on systemd right now, but it doesn't seem to be working properly. I followed the instructions here: https://wiki.archlinux.org/index.php/Qingy#Systemd ... and tried to set up qingy on tty6. But that doesn't seem to work. The systemctl command seems to always try to set up qingy on tty1: [darose@daroselin ~]$ sudo systemctl enable qingy@tty6 ln -s '/usr/lib/systemd/system/qingy@.service' '/etc/systemd/system/getty.target.wants/qingy@tty1.service' In addition, qingy seems to be freezing on me whenever I try to access it on the tty. Anyone have any idea what's going on with this? I didn't see any bug reports about it. Thanks, DR I had the same issue so i just went to /etc/systemd/system/getty.target.wants/ renamed quingy@tty1.service to quingy@tty6.service then it behaved as expected. Check out the service file for qingy. It is actually aliased to qingy@tty1. So I presume copying it over to /etc/systemd/system and changing that the the tty of your choice would solve that issue. See the bottom of the service file in the [Install] section. % cat qingy@.service cat qingy@.service [Unit] Description=Quingy on %I Documentation=info:qingy ... [Install] Alias=getty.target.wants/qingy@tty1.service Regards, -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] Qingy on systemd
On 11/08/12 at 04:00pm, David Rosenstrauch wrote: Looks like it doesn't: [darose@daroselin ~]$ sudo systemctl enable qingy@tty6 ln -s '/usr/lib/systemd/system/qingy@.service' '/etc/systemd/system/getty.target.wants/qingy@%I.service' :-) Sucks that this doesn't work as advertised. It should be a no-brainer to be able to set up qingy on tty6. Thanks, DR Maybe you could simply remove the alias altogether. I mean, if you are going to change it anyway, what is the difference between having it set via an alias or by your specification after the @? It makes me curious why it would be called qingy@.service rather than simply qingy.service if it is going to insist on being on tty1 either way. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] systemd and local group membership
On 10/29/12 at 12:46pm, Rodrigo Rivas wrote: On Mon, Oct 29, 2012 at 5:47 AM, Curtis Shimamoto sugar.and.scru...@gmail.com wrote: I did run into one problem though. I sometimes use mplayer from the console. To do this, I have set mplayer up to use fbdev2. Previously (when in all those groups), I was able to do this with no problem. but after making these changes, I suddenly had to be root to use mplayer in framebuffer mode. I realized that this was because /dev/fb0 was not included in the 70-uaccess.rules. I am no expert in udev rules, but I have written a few for various things. This file was dead simple to understand, so I copied it over to /etc/udev/rules.d and added: # framebuffer SUBSYSTEM==graphics, KERNEL==fb0, TAG+=uaccess I think it is better to add a file /etc/udev/rules.d/71-my-uaccess.rules with just the line you need to add, instead of copying the whole 70-uaccess.rules file. That way you still get the upgrades to the standard file. Note that the names of the files make no difference, other than the order of execution. Regards -- Rodrigo Yes, this was mentioned to me in the forums as well. It is a much better idea. Thanks for confirming that this is what I should be doing. So far, I have not heard any mention of this being a bad idea, or a security concern. So I guess I will be sticking with it until I find reason to do otherwise. Thanks again for the input Rodrigo -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] systemd and local group membership
On 10/29/12 at 12:46pm, Rodrigo Rivas wrote:
On Mon, Oct 29, 2012 at 5:47 AM, Curtis Shimamoto
sugar.and.scru...@gmail.com wrote:
I did run into one problem though. I sometimes use mplayer from the
console. To do this, I have set mplayer up to use fbdev2. Previously
(when in all those groups), I was able to do this with no problem. but
after making these changes, I suddenly had to be root to use mplayer in
framebuffer mode.
I realized that this was because /dev/fb0 was not included in the
70-uaccess.rules. I am no expert in udev rules, but I have written a
few for various things. This file was dead simple to understand, so I
copied it over to /etc/udev/rules.d and added:
# framebuffer
SUBSYSTEM==graphics, KERNEL==fb0, TAG+=uaccess
I think it is better to add a file /etc/udev/rules.d/71-my-uaccess.rules
with just the line you need to add, instead of copying the whole
70-uaccess.rules file. That way you still get the upgrades to the standard
file. Note that the names of the files make no difference, other than the
order of execution.
Regards
--
Rodrigo
One more thing I forgot to ask. Do I need to include the ACTION and
ENV{MAJOR} stuff in my personal rule (71-my-uaccess.rule)? Namely:
ACTION==remove, GOTO=uaccess_end
ENV{MAJOR}==, GOTO=uaccess_end
...
LABEL=uaccess_end
Because, honestly, I am not entirely sure what that does besides the
obvious part of telling it where to proceed to.
--
Curtis Shimamoto
sugar.and.scru...@gmail.com
Re: [arch-general] systemd and local group membership
On 10/29/12 at 08:09pm, Tom Gundersen wrote:
On Mon, Oct 29, 2012 at 3:24 PM, Curtis Shimamoto
sugar.and.scru...@gmail.com wrote:
One more thing I forgot to ask. Do I need to include the ACTION and
ENV{MAJOR} stuff in my personal rule (71-my-uaccess.rule)? Namely:
ACTION==remove, GOTO=uaccess_end
ENV{MAJOR}==, GOTO=uaccess_end
...
LABEL=uaccess_end
Because, honestly, I am not entirely sure what that does besides the
obvious part of telling it where to proceed to.
You should keep the GOTO/LABEL in. It makes sure the rule is ignored
in case the device is being ignored, or in case the MAJOR is not set.
-t
Awesome! Thanks so much for the input everyone. I shall go forth with
confidence in my new udev rule!
--
Curtis Shimamoto
sugar.and.scru...@gmail.com
Re: [arch-general] systemd and local group membership
On 10/29/12 at 12:00am, Tom Gundersen wrote: On Sun, Oct 28, 2012 at 7:09 PM, Fons Adriaensen f...@linuxaudio.org wrote: You (Tom) pointed out a way to disable logind modifying device ACLs recently. It could be a good thing to have that in the online docs for those users (like me) for whom this sort of thing is unwanted. The rule that tags device nodes with the uaccess tag (which means they will be managed with ACL's) is 70-uaccess.rules[0]. A brute-force way to avoid all of that is to mask it. I.e., symlink /etc/udev/rules.d/70-uaccess.rules to /dev/null. In most cases that's not the best solution, as you lose all the fast-user switching and multi-seat stuff, but it is useful to know. Hopefully the logind manpage will be updated soon to include a bit more info on these things. Logind's behaviour seems to be based on two assumptions: 1. A non-local user (not near the system's HW) can't do anything useful with e.g. audio interfaces. Not really. Logind does not at all manage non-local users, so if you want to give them access to your hardware you have to use another mechanism (such as groups). 2. A local user (having access to the system's HW) can do whatever evil he wants so there's no point in taking away any permissions. Not really. This is indeed the default behaviour, but it is set up so that you can easily restrict it (and you should if you have a multi-seat computer): a user is given all the permissions to the hardware (as specified in 70-uacces.rules) on his/her seat. By default all hardware is assigned to seat0 and the user is assigned to seat0 too, but you could easily assign some hardware to a different seat. For (2), a local user can do whatever evil only if he has unlimited time and is not supervised. I routinely let clients login to the local machines in the studio (they have to in order to do their work). That doesn't mean they should be able to copy other customer's data when I'm out for a minute to get us a coffee. So they must not be able to mount USB disks etc. logind does not allow mounting of USB disks, but your point still stands (udisks would probably allow it based on info from logind, or you could get the same sort of effect using a device that logind would allow you to access). -t [0]: http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules I have been following this thread extra closely since I had removed myself from the numerous unnecessary groups, yet didn't quite understand why. Looking over 70-uaccess.rules, it is all making sense now. I did run into one problem though. I sometimes use mplayer from the console. To do this, I have set mplayer up to use fbdev2. Previously (when in all those groups), I was able to do this with no problem. but after making these changes, I suddenly had to be root to use mplayer in framebuffer mode. I realized that this was because /dev/fb0 was not included in the 70-uaccess.rules. I am no expert in udev rules, but I have written a few for various things. This file was dead simple to understand, so I copied it over to /etc/udev/rules.d and added: # framebuffer SUBSYSTEM==graphics, KERNEL==fb0, TAG+=uaccess So I guess I just want to know if this is what I was supposed to have done. Or are there reasons why this may not have been implemented in the first place? As far as I can tell, this seems no different than previously being in the video group. If this is not a good idea, why might this be? Any insight would be greatly appreciated. Regards, -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] /etc/tmpfiles.d
On 09/17/12 at 10:31am, Matthew Monaco wrote: On 09/17/2012 09:40 AM, Mart?n Cigorraga wrote: [...]However, tmpfiles may also be used to write values into certain files on boot. For example, if you use /etc/rc.local to disable wakeup from USB devices with echo USBE /proc/acpi/wakeup, you may use the following tmpfile instead: /etc/tmpfiles.d/disable-usb-wake.conf w /proc/acpi/wakeup - - - - USBE The tmpfiles method is recommended in this case since systemd doesn't actually support /etc/rc.local. Does that means that I need to move all the content from /etc/rc.local to /etc/tmpfiles.d? For example this is my actual /etc/rc.local: ~ $ cat /etc/rc.local #!/bin/bash # # /etc/rc.local: Local multi-user startup script. # #modprobe radeon # added by hybrid-video-ati-intel install script #echo IGD /sys/kernel/debug/vgaswitcheroo/switch # added by hybrid-video-ati-intel install script echo OFF /sys/kernel/debug/vgaswitcheroo/switch # completely deactivate radeon ## ATi # Source: https://wiki.archlinux.org/index.php/ATI#Performance_tuning echo low /sys/class/drm/card0/device/power_profile #echo profile /sys/class/drm/card0/device/power_method echo dynpm /sys/class/drm/card0/device/power_method echo OFF /sys/kernel/debug/vgaswitcheroo/switch # CPUFREQ for i in 0 1 2 3; do cpufreq-set -c $i -g powersave; done ## sets powersave cpufreq governor for all CPU cores #echo -n 90 /sys/devices/system/cpu/cpufreq/ondemand/up_threshold echo -n 20 /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor # Prepare the system for Wake-on-Lan /usr/sbin/ethtool -s eth0 wol pg # Activate laptop_mode echo 5 /proc/sys/vm/laptop_mode # Performance tweaks for USB drivers under KDE SC echo madvise /sys/kernel/mm/transparent_hugepage/enabled echo madvise /sys/kernel/mm/transparent_hugepage/defrag echo 0 /sys/kernel/mm/transparent_hugepage/khugepaged/defrag If this is the case, how do you guys would convert the FOR loop!? For ethtool, just create a separate service that executes that command. Everything else you do is writing to /sys, so you can have one giant tmpfiles.d file. For the for loop: w /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor - - - - powersave w /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor - - - - powersave w /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor - - - - powersave w /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor - - - - powersave Also, I don't think it's an error if the file doesn't exist, so you can just do cpu0..cpu16 or whatever if you feel like. I am fairly certain that tmpfiles.d understands *, so you could probably get away with one line for something like that. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] amd64 systems and archlinux
On 09/11/12 at 09:58am, Rodrigo Rivas wrote: On Tue, Sep 11, 2012 at 4:14 AM, Curtis Shimamoto sugar.and.scru...@gmail.com wrote: The link I provided clearly shows you how to install to the mbr of a partition. As Bjoern Franke pointed out previously in this thread, there is no such thing as the MBR of a partition. MBRs are only at the beginning of devices, not partitions. The guide you linked explains how to install grub to the boot sector of a partition. It may seem like nit-picking, but I think that precision in this kind of issues is important, because a confused user could very well wipe out all his data... -- Rodrigo Okay, I can agree with that. In any case, it seemed as though th OP did not bother to really read through the page I linked to. If he/she had, he would have seen the incredibly not recommended option to install to the boot sector of the partition. Unfortunately, in this case, one is made to use the --force flag to make it work w/o grub complaining. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] amd64 systems and archlinux
On 09/10/12 at 04:20am, John Hutchison wrote: On Mon, Sep 10, 2012 at 04:29:22AM -0400, Jude DaShiell wrote: I have /dev/sda1 root, /dev/sda2 swap and /dev/sda3 /home. So this is not a single partition setup but a three partition setup if you count swap. Assume for this that /dev/sda is the bootloader _AND_ the device. As was said before: the first 512 bytes of the _hard drive device_ is the bootloader. (Assuming MBR) Perhaps you could go a little more in depth on your install process, maybe tell us what exactly you are trying to do. -- John Hutchison Programmieren und Informatik-Abteilung Feiern Sie 21 Jahre Linux! gplus.to/athetius The link I provided clearly shows you how to install to the mbr of a partition. I used to have to do this with my Mac as not to ruin the windows partition (I think that is why I was doing that). So it is possible. Whether it is a wise thing to do is questionable. OP, I think if you just follow Arch's grub2 wiki, you probably would have seen your error and/or resolved any problem you may have had. Grub2 has this bug because it is not how it is intended to be used. Install it to /dev/sda like normal and you should be fine. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] amd64 systems and archlinux
On 09/09/12 at 11:15pm, Jude DaShiell wrote: I am learning more about my hardware doing an archlinux installation on an amd k8 athelon system. Apparently grub won't work without use of blocklists and it complains that blocklists are unreliable so cannot embed and for that reason won't install. Fortunately another boot loader other than grub is available. I'll try that one later. Too late tonight to do it. --- jude jdash...@shellworld.net Adobe fiend for failing to Flash Are you trying to install to the mbr of a partition? If so, this error is expected. See our amazing wiki here: https://wiki.archlinux.org/index.php/GRUB2#Install_to_Partition_or_Partitionless_Disk Regards, -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] SystemD poll
On 08/26/12 at 07:55pm, Bigby James wrote: On Sat, Aug 25, 2012 at 5:13 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Aug 25, 2012 at 6:30 PM, Bigby James anokn...@gmail.com wrote: Having watched this thread (and the Beware thread) for some time, I can say without equivocation that Felipe is not trying to reason with anyone. He clearly doesn't understand the concepts he himself refers to (rules of evidence, burden of proof, logical fallacies) and is attempting to sound more knowledgeable than he is. He has failed to present evidence for his own case while ignoring that of his detractors Once again, I don't have the burden of proof. and seems to think that while his single anecdotal case counts for something, all others contradicting it are worthless You cannot prove a negative, no matter how many negative accounts you put forward, on the other hand you only need one positive account to prove a positive. You can have one million people claiming that they have never seen Congenital Generalized Hypertrichosis Terminalis, but all you need is one to prove that it does exist. This is very basic rationality. But you can ignore my anecdotal cases, you still have the burden of proof. He attacks the credibility of those clearly more competent than himself, I haven't. And for the record: An ad hominem argument is 100% fallacious only when it serves to distract others from the subject at hand by making irrelevant claims. No, that's called a red herring. It is not fallacious to, for example, point out that Jenny McArthy opposes vaccines while singing the praises of Botox on the grounds that the former are poisons. It's not fallacious to point that out, it's fallacious to conclude that because of this, his arguments against vaccines are invalid. His arguments stand or fall on their own. it serves as proof that the target is not a reliable source of information. A bum on the street might not be a reliable source of information, but he/she might still be saying the truth. Cops wouldn't take their word at face value (or almost anyone for that matter), but if a bum says there was a crime, cops could still investigate to make sure that's the case. but demanding the devs comply with his wishes. I am not demanding anything. Since your whole mail is nothing but a bunch of ad hominem attacks, I'll simply stop replying to you. Cheers. -- Felipe Contreras This is pathetic. A single instance of a bug in a piece of software may prove it's existence, but it goes nowhere with regard to proving that it matters one bit. Every piece of complex software has bugs; those bugs won't be found if the software isn't tested, and since you're not willing to participate in that process you've no right to harass those who have. The burden of proof always lies with the one postulating, and proving a negative isn't being requested. You don't have any idea what you're talking about, and your attempts to be pedantic don't cover up this fact; you don't even seem to realize your own failure. The reason you're not a reliable source of information is because you've thus far failed to share the knowledge you continually claim to have (knowledge about the faults and failings of software you don't even try to use). You speculate, you throw around FUD and you act like you know better than the people actively developing, maintaining and using the software, and outright state that you don't need to familiarize yourself with the very thing you're detracting. You're a troll, you've got nothing worthwhile to say and, sadly, you grossly overestimate the weight your own voice carries. You've accomplished nothing with this little crusade but pissing people off--something that you seem eminently talented at, judging by other exchanges you've had. If you can't learn not to speak like a fool, then it's best to just remain silent. +1 -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] SystemD poll
On 08/26/12 at 10:17pm, Chris Evans wrote: From: rafael ff1 rafael.f...@gmail.com To: General Discussion about Arch Linux arch-general@archlinux.org Sent: Sunday, August 26, 2012 11:49 PM Subject: Re: [arch-general] SystemD poll 2012/8/27 C Anthony Risinger anth...@xtfx.me: On Sat, Aug 25, 2012 at 5:13 PM, Felipe Contreras felipe.contre...@gmail.com wrote: [...] A bum on the street might not be a reliable source of information, but he/she might still be saying the truth. Cops wouldn't take their word at face value (or almost anyone for that matter), but if a bum says there was a crime, cops could still investigate to make sure that's the case. ehm ... and who the !@$# are you? ... down-trodden and cast to the curb carries no assurance that one is a quote-on-quote bum -- unfortunate things DO happen to good people you know -- and the ravages of mental illness are all too easy to dismiss when you're not among the ravaged! really!? in a past life i'd probably say something to the effect of you sir, are an arrant sack of shite -- a pitifully miserable sore spewing an egregious pus of arrogance and obstinance -- a first-class jerk-off! ... well, or some variation ;-) thankfully i reject such dead-end language, and prefer to only think it aloud. now let's review! per your allusions and my history, you've been here a whopping 10 days(!) and managed to elicit response from a growing list of ... uh ... friends? you're presence in other more visible lists i track fail to echo this recent(?) lack of restraint ... why is that? just quit now guy, while you're only ~1,000 km behind -- i say this with little more than your own interests at heart -- communication needn't be so difficult. -- C Anthony Dude, it simply doesn't worth it. Troll is troll. Arch-general wasted already too much time with this guy. I really don't get all the hoopla around this subject. Maybe since I'm relatively new here (3 months on arch) it's easier for me, then again maybe not. Everything is running fine for me and although different it's still linux and not hard to get used to new things. The whole reason I decided to move to arch is to get the latest software and the newest toys. With that is an unwritten agreement that things are gonna change, frequently and radically and maybe even not to some peoples liking. I respect the developers decision and if they say that moving to systemd is going to be better for them and for us then I will believe that. At least until I have personal proof that they don't have a clue what they are talking about. The move to systemd was easy and relatively painless. I have literally spent 10 times longer reading this back and forth god-aweful debate than I spent researching and then installing and configuring systemd. TRUTH Scroll wrap, man scroll wrap. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] SystemD poll
On 08/22/12 at 02:06am, Felipe Contreras wrote: On Wed, Aug 22, 2012 at 1:44 AM, Alexandre Ferrando alfer...@gmail.com wrote: And sysvinit didn't have those when it began? Come on. I don't know, I probably wasn't born yet, and probably there weren't even computers before. But supposing there was something before, I'm sure the people that made the transition did it in a responsible manner trying hard not to break anything. That's nothing at all like systemd. Lennart Poettering is known for not caring if his software changes break stuff (there's always somebody else to blame), and I can probably point to dozens of problems that systemd has that initscripts doesn't (today). That's enough reason to hold on the move. Do *you* care at all about breaking the boot process of your users? Some people care to the extreme, like debian, some people doesn't seem to care much, like Fedora (and it shows), and there's all kinds places in the middle of the continuum. But what I find surprising is that I haven't heard any strong advantages that would warrant the potential (already realized) of breaking people's boot process. Also, nobody is forcing you gun in hand, your life depending on it, to use systemd. Arch is going to use it by DEFAULT, if you don't like it, just install another init system and let everyone else do whatever they feel like doing. But initscripts is going to be eventually unmantained, right? So what choice would I have? Also, nobody is forcing you to move to systemd *now* is there? You could just as easily move one year later, and in fact, it would be easier. -- Felipe Contreras ...and I think that we've now hit Godwin's Law (Lennart Poettering edition)... Felipe, you lose. Please stop. -- Curtis Shimamoto sugar.and.scru...@gmail.com
