Re: [arch-general] rEFInd package being neglected by maintainer.

[Mike Cloaked via arch-general]

On Sun, Apr 12, 2020 at 6:01 PM David Runge  wrote:

> On 2020-04-07 12:54:18 (-0500), mike lojkovic via arch-general wrote:
> > rEFInd has had multiple versions came out, and the mainter has been
> > neglecting to update it for nearly two years. Is there an eta or talk
> > of changing the maintainer for that package? Pretty sure, it builds
> > find as an aur alternative has been up for awhile.
>
> Hi Mike,
>
> I've added refind to [testing] (replacing refind-efi). Feel free to
> check it out.
>
> Best,
> David
>
> --
> https://sleepmap.de
>

Fabulous - thank you.

-- 
mike c

Re: [arch-general] rEFInd package being neglected by maintainer.

[Mike Cloaked via arch-general]

On Tue, Apr 7, 2020 at 6:55 PM mike lojkovic via arch-general <
arch-general@archlinux.org> wrote:

> rEFInd has had multiple versions came out, and the mainter has been
> neglecting to update it for nearly two years. Is there an eta or talk of
> changing the maintainer for that package? Pretty sure, it builds find as an
> aur alternative has been up for awhile.
>

It does build with efi-libs easily in a few seconds on my laptop, but it
will need some work to build with tianocore. I have tried to build with
tianocore and the build fails but I haven't had time to look into what
changes are needed in the PKGBUILD file to make it work. That was just
using the PKGBUILD from the arch repo for the refind-efi package and using
the same additional files in the package file list. It would be nice to
know if there are issues that remain with the successful build that make
releasing the updated package undesirable.


-- 
mike c

Re: [arch-general] A few out of date packages

[Mike Cloaked via arch-general]

On Wed, Feb 12, 2020 at 6:46 PM Levente Polyak via arch-general <
arch-general@archlinux.org> wrote:

> On 2/12/20 12:58 AM, Genes Lists via arch-general wrote:
> > I've selected a few to highlight based on age and my own view of
> > importance (no claim its a good view).
> >
> > So, here's a few that might benefit from an update:
> >Cal Pkg
> > NameVers Updt   Flag   CVers   DateAge Age Pkger
> > ---  -- -- --- --  --- -
>

snip


> > elfutils0.177191118 191128 0.178   191126  85   8 EF
> > refind-efi  0.11.3   180723 181119 0.11.4  191112 568 112 TP [1]
> >
> > [1] 0.11.5 looks to be coming out soon
> >
> >   Cal Age = days since last update
> >   Pkg Age = days between current and arch release
> >   Cvers = Current version
> >
>
> Hi gene,
>
> thanks for taking time and trying to improve something in our distro,
> however I believe your numbers are, lets say: suboptimal
>
> snip
>


> Actually what does thunderbird even do on this list? I guess because its
> "Age" is 15? Which exactly proves my point above:
> Version 68.5.0, first offered to channel users on February 11, 2020
> which was exactly 1 day ago.
>
> On top this data set is inconsistent, thunderbird was released 200211
> and not as listed 200210 plus refind-efi was not released 191112 but
> 181112 and I didn't even check any other numbers besides those two.
>
> cheers,
> Levente
>
> https://sourceforge.net/projects/refind/files/0.11.4/
> https://www.thunderbird.net/en-US/thunderbird/68.5.0/releasenotes/
>
>
refind-efi has now been released and the source tarball can be obtained
from
http://sourceforge.net/projects/refind/files/0.11.5/refind-src-0.11.5.tar.gz/download

-- 
mike c

Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required

[Mike Cloaked via arch-general]

On Tue, Oct 8, 2019 at 9:49 PM Genes Lists via arch-general <
arch-general@archlinux.org> wrote:

> On 10/8/19 4:34 PM, Eli Schwartz via arch-general wrote:
>
> > Really, I wish we would do as I'd wanted and transfer the "essential
> > packages" which aren't actually essential and were thus not included in
> > base.. to a new *group* called "base-extras", which would reflect its
> > status as being mere recommendations, while providing a convenient way
> > to choose to interactively install them, and allowing the Installation
> > Guide to transition from:
>
> Sounds good to me - do you have a suggested list of packages for
> base-extras or at least the list of what was pulled from the old base.
>
> Might be good for folks to add those to private install script / meta
> package until such time as base-extras may be available.
>
> Thanks for mentioning linux-firmware -  I just added kernels and a few
> other items to my own, but I missed that one
>

Possibly intel-ucode would be very useful for many installs as well?
-- 
mike c

Re: [arch-general] Intel microcode - latest version not loading

[Mike Cloaked via arch-general]

>
>
>> That's excellent information.  Apparently, my 8 year old Core2 may soon be
>> getting its first MCU!
>>
>
>
>
My apologies for top posting - it was accidental.

There is a newer version of that file dated February 26th but I can't
remember where I downloaded it from.

I've put it at
https://filebin.net/q3s5in117kp7mkut/microcode-update-guidance.pdf if you
want to see it.

-- 
mike c

Re: [arch-general] Intel microcode - latest version not loading

[Mike Cloaked via arch-general]

There is a newer version of that file dated February 26th but I can't
remember where I downloaded it from.

On Thu, Mar 1, 2018 at 7:59 PM, Dutch Ingraham  wrote:

> On Thu, Mar 01, 2018 at 08:13:08PM +0100, ProgAndy wrote:
> > Am 01.03.2018 um 00:41 schrieb Dutch Ingraham:
> > > On Wed, Feb 28, 2018 at 04:54:03PM -0600, Doug Newgard via
> arch-general wrote:
> > > > On Wed, 28 Feb 2018 12:43:26 -0600
> > > > Dutch Ingraham  wrote:
> > > >
> > > > > On Wed, Feb 28, 2018 at 11:50:09AM -0600, Doug Newgard via
> arch-general wrote:
> > > > > > You're looking at the dates that the last *bundle* was released.
> That says
> > > > > > nothing about what firmware is available for your processor.
> Your microcode was
> > > > > > "updated early", so it is being loaded just fine.
> > > > > >
> > > > > > Scimmia
> > > > > Thanks, Scimmia.  I had considered that, but thought that would
> have
> > > > > been spelled-out somewhere on Intel's site and didn't want to just
> > > > > assume.  So, how does one determine what files are on the .img?
> > > > The img file can be extracted with bsdtar. iucode_tool in the AUR
> used for
> > > > working with the intel bin file inside of that .img file. It can
> list, extract,
> > > > search, and more. There's even an example on the Microcode wiki page.
> > >
> > > Did you just add that wiki page information??  (I'm just kidding, of
> > > course.)  Totally missed it - thanks for the info!
> >
> > In February Intel also released a PDF with available and planned
> microcode
> > updates. The original now asks for a login, but this is a mirror:
> >
> > http://www-pc.uni-regensburg.de/systemsw/security/
> microcode-update-guidance_02122018.pdf
> >
> >
> > Original location:
> > https://newsroom.intel.com/wp-content/uploads/sites/11/2018/
> 02/microcode-update-guidance.pdf
>
> That's excellent information.  Apparently, my 8 year old Core2 may soon be
> getting its first MCU!
>



-- 
mike c

Re: [arch-general] ReadyDLNA/MiniDLNA doesn't work behind wireless

[Mike Cloaked via arch-general]

On Mon, Jun 5, 2017 at 4:12 PM, ITwrx.org  wrote:

>
> > ---
> > No idea why MiniDLNA does not check the port.
> i just installed minidlna and got it working from vlc over wireless. it
> didn't work at first. "systemctl status minindlna" showed that it wasn't
> able to identify the network interface i provided. i have no idea
> why(old method in minidlna?). i commented that line in config back out
> and made sure minidlna could read my testing media directory and it
> worked at that point. i used nmap -sS -sU -T4 -A -v 192.168.1.1 to see
> if port 8200 was open. it was.
>
> so, if "systemctl status minidlna" or "journalctl -b" shows no problems
> for minidlna then maybe test with nmap from both wired and wireless and
> see if there is a difference. If there is, then you have network config
> issue. the arch wiki page for minidlna has a section about wireless in
> the troubleshooting section i notice.
>

Although I don't run minidlna over the wireless interface on the server I
use, and only use the wired interface, I presume that the key here may be
as you suggest that the lines in /etc/minidlna.conf near the start of the
file that are relevant, which in my case are:

 # port for HTTP (descriptions, SOAP, media transfer) traffic
port=8200

# network interfaces to serve, comma delimited
#network_interface=eth0
network_interface=eth0

would need to include the correctly specified interface(s) for the server
running minidlna for the OP. I wonder what the latter line actually is for
that file in the problem machine?

-- 
mike c

Re: [arch-general] How to "decorate" a package build?

[Mike Cloaked via arch-general]

On Wed, Mar 8, 2017 at 10:55 AM, ProgAndy  wrote:

> Am 08.03.2017 um 11:45 schrieb Peter Nabbefeld:
>
>>
>> Hello,
>>
>> is it possible to decorate a package build, i.e. set some prconditions
>> (like exporting variables) and probably even change the build process
>> (compile instead of copying just the binaries)?
>> .
>>
>
> Hello,
>
>
> That is impossible with pacman.
>
> What you can do is create a local repository that is included in the
> automatic pacman upgrade. Then write a shell script that checks for updates
> of the arch package, merges it with your local changes, build it and add it
> to the repository. You should change the package name with e.g. a prefix or
> suffix and add the original package as a conflict to make it work properly.
> Now your custom version is available for the next pacman upgrade.
>

You can also use the PKGBUILD to change the name of the package you build
and make your own version which you can customise or alter as you wish for
the build process. For example build it as package called say ff (pkgname=ff
) instead of firefox, and then run it in parallel to the official build. So
long users know to run ff instead of the stock version I can't see a
problem with that?


-- 
mike c

Re: [arch-general] About linux 4.8 and 4.9...

[Mike Cloaked via arch-general]

On Tue, Jan 10, 2017 at 1:53 PM, Carsten Mattner via arch-general <
arch-general@archlinux.org> wrote:

> FYI, 4.8 has been EOL'd, leaving 4.4-lts, 4.1-lts as options for
> arch "default" kernel until 4.10 is released if we assume that
> there's a critical fix in the stable patch queue.
>
> My criticism of the stable patch queue is that they mix fixes
> with actual feature patches, making it more risky and not
> upholding a important fixes only policy.
>

Looks like there are some patches to try and are being tested for kernel
4.9 - see https://bugzilla.kernel.org/show_bug.cgi?id=191121

-- 
mike c

Re: [arch-general] New kernel repo

[Mike Cloaked via arch-general]

On Fri, Jan 6, 2017 at 7:36 PM, Simon Gomizelj via arch-general <
arch-general@archlinux.org> wrote:

> Check out https://wiki.archlinux.org/index.php/unofficial_user_reposit
> ories
>
> You may find a repository for the kernel you're looking for. Just be
> wary its obviously unofficial and thus unsupported.
>

It seems that the repo at http://arch.miffe.org/x86_64/ contains the
linux-mainline package which looks up to date.

-- 
mike c

Re: [arch-general] minidlna problems

[Mike Cloaked via arch-general]

On Sun, Dec 4, 2016 at 6:55 PM, SET  wrote:

> Le dimanche 4 décembre 2016 17:17:02 CET Mike Cloaked via arch-general a
> écrit
> :
> > The version current in arch is minidlna 1.1.6-1 but perhaps the comment
> > earlier in the thread about version 2.x is a heads-up for when the
> version
> > in arch is updated in the future at some point to make sure that 2.x does
> > support UPnP. Certainly minidlna 1.1.6-1 works fine once it is set up
> > correctly.
>
> The 2.x comment above concerns VLC, and not minidlna. I'm using the same
> version as yours, on ALARM too.
>


Current vlc in arch is version vlc 2.2.4-5, and I have just double checked
that it works for UPnP - loading vlc in my desktop, and on the LAN, I can
immediately connect to my minidlna server running on a little odroid-c2
machine on the same network and can play video and see the other media
files on UPnP. So if there was any issue on an earlier version of 2.x it
doesn't seem to be an issue currently.

-- 
mike c

Re: [arch-general] minidlna problems

[Mike Cloaked via arch-general]

On Sun, Dec 4, 2016 at 4:19 PM, Peter Nabbefeld 
wrote:

> Hello Mike,
>
> I cannot find any important differences between Your files and mine. I've
> tested VLC, and if this is broken, the test doesn't have any relevance, so
> I need some other client first.
>
> Kind regards
> Peter


In my case I can run vlc from another machine within my LAN to see the
files on my media server running minidlna - one thing worth checking is
that you don't have any firewall blocks for the required ports on the
server. Again in my case the server is entirely within my home LAN and not
visible to the wider internet, so there are less security concerns in this
case than if the server was being accessed from the WAN.

The version current in arch is minidlna 1.1.6-1 but perhaps the comment
earlier in the thread about version 2.x is a heads-up for when the version
in arch is updated in the future at some point to make sure that 2.x does
support UPnP. Certainly minidlna 1.1.6-1 works fine once it is set up
correctly.
-- 
mike c

Re: [arch-general] minidlna problems

[Mike Cloaked via arch-general]

On Sun, Dec 4, 2016 at 1:08 PM, Peter Nabbefeld 
wrote:

>
> Hello,
>
> I've installed minidlna (community/minidlna 1.1.6-1), but cannot access
> any files. When I access it on port 8200, statistics count some audio
> files, but those are videos (mp4). I also cannot see a list of the files
> (well, I even don't know, if this would be expected behaviour). If I try to
> connect via UPnP using VLC, I cannot even see any file.  Portscan detected
> port 8200 listening, but neither 80 nor 1900.
>
> So, I do have some questions:
> - Why are my mp4 files recognized as audio files?
> - Is minidlna expected t oshow a list of files in its DB somewhere?
> - How can I detect minidlna working correctly?
>
> It took me a while to get minidlna going (though I run it on an
archlinuxarm machine) -  and it is referred to with a different name in the
wiki:

https://wiki.archlinux.org/index.php/ReadyMedia

There are a number of things that have to be set right to make it work -
the permissions on directories including the home directory of the user
where the files are stored need to be set to allow the non-root user
running minidlna to access the files with the media.

eg in my case on my little media server:

$ ls -l /home
total 8
drwx-- 2 alarm alarm 4096 Feb 22  2016 alarm
drwxr-xr-x 6 mike  mike  4096 Jun  6 20:57 mike

then the minidlna.service file is:
$ cat /etc/systemd/system/minidlna.service
[Unit]
Description=minidlna server
After=network.target

[Service]
Type=simple
User=minidlna
Group=minidlna
ExecStart=/usr/bin/minidlnad -S
ProtectSystem=full
ProtectHome=read-only
PrivateDevices=on
NoNewPrivileges=on

[Install]
WantedBy=multi-user.target

and this service is started in my case with a systemd timer to avoid
startup timing issues on the small SoC on which this runs.

Then the minidlna conf file is:
$ cat /etc/minidlna.conf
# port for HTTP (descriptions, SOAP, media transfer) traffic
port=8200

# network interfaces to serve, comma delimited
#network_interface=eth0

network_interface=eth0



# specify the user account name or uid to run as

user=minidlna

#user=mike



# set this to the directory you want scanned.

# * if you want multiple directories, you can have multiple media_dir=
lines
# * if you want to restrict a media_dir to specific content types, you

#   can prepend the types, followed by a comma, to the directory:

#   + "A" for audio  (eg. media_dir=A,/home/jmaggard/Music)

#   + "V" for video  (eg. media_dir=V,/home/jmaggard/Videos)

#   + "P" for images (eg. media_dir=P,/home/jmaggard/Pictures)

#   + "PV" for pictures and video (eg.
media_dir=PV,/home/jmaggard/digital_camera)
#media_dir=/opt
media_dir=A,/home/mike/Music/
media_dir=P,/home/mike/Pictures/
media_dir=V,/home/mike/Videos/

# set this to merge all media_dir base contents into the root container
# note: the default is no
#merge_media_dirs=no

# set this if you want to customize the name that shows up on your clients
#friendly_name=My DLNA Server

friendly_name=Odroid Media Server

# set this if you would like to specify the directory where you want
MiniDLNA to store its database and album art cache
#db_dir=/var/cache/minidlna

db_dir=/var/cache/minidlna

# set this if you would like to specify the directory where you want
MiniDLNA to store its log file
#log_dir=/var/log

# set this to change the verbosity of the information that is logged
# each section can use a different level: off, fatal, error, warn, info, or
debug
#log_level=general,artwork,database,inotify,scanner,metadata,http,ssdp,tivo=warn

# this should be a list of file names to check for when searching for album
art
# note: names should be delimited with a forward slash ("/")
album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg/AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg/Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg

# set this to no to disable inotify monitoring to automatically discover
new files
# note: the default is yes
inotify=yes

# set this to yes to enable support for streaming .jpg and .mp3 files to a
TiVo supporting HMO
enable_tivo=no

# set this to strictly adhere to DLNA standards.
# * This will allow server-side downscaling of very large JPEG images,
#   which may hurt JPEG serving performance on (at least) Sony DLNA
products.
strict_dlna=no

# default presentation url is http address on port 80
#presentation_url=http://www.mylan/index.php

# notify interval in seconds. default is 895 seconds.
notify_interval=900

# serial and model number the daemon will report to clients
# in its XML description
serial=12345678
model_number=1

# specify the path to the MiniSSDPd socket
#minissdpdsocket=/var/run/minissdpd.sock

# use different container as root of the tree
# possible values:
#   + "." - use standard container (this is the default)
#   + "B" - "Browse Directory"
#   + "M" - "Music"
#   + "V" - "Video"
#   + "P" - "Pictures"
#   + Or, you can specify the ObjectID of your desired root container (eg.
1$F for Music/Playlists)
# if you specify "B" an

[arch-general] Package updates for Long out of Date packages - comment

[Mike Cloaked via arch-general]

Not being able to post to arch dev public, and gaving seen that there was a
list posted by Florian Pritz today with sets of packages that have been
long out of date, I thought I would post a comment here about two
particular packages that appear in that list.

Having done some work privately recently on building refind-efi and
gnu-efi-libs, I wanted to note that refind-efi was recently updated in the
past few days, and is already at the latest version 0.10.4. I guess that
Florian will already be aware of that? Gnu-efi-libs is also on the list but
there is a very good reason that it has not been updated from version 3.0.3
to 3.0.4, which is that the newest version does not build for i686, at
least when I tried to do that in an x86_64 machine using abs, even though
it builds for x86_64, and that package is needed when building refind-efi
so that would probably need an upstream fix before it can be brought up to
date for both i686 as well as x86_64.

-- 
mike c

Re: [arch-general] Mirror issue

[Mike Cloaked via arch-general]

On Fri, Sep 16, 2016 at 8:20 PM, Jordyn Carattini via arch-general <
arch-general@archlinux.org> wrote:

> I keep getting http error 502 from the archlinux.polymorf.fr, I've been
> getting this error for the past month. Also sorry if I'm not posting this
> in the right place.
>

I have just made a connection to that mirror without any problem at all -
if you are still unable to connect then it may be a problem for a limited
set of users from specific routes to that site?

-- 
mike c

Re: [arch-general] rEFInd has been out of date for awhile.

[Mike Cloaked via arch-general]

On Fri, Aug 5, 2016 at 7:38 PM, mike lojkovic via arch-general <
arch-general@archlinux.org> wrote:

> Hey everybody,
>
>
> refind-efi package in extra has been flagged out of date for about 6
> months. The latest version is 0.10.3. There is refind-efi-bin
>  in the aur. I'm just
> wondering if there are any plans to continue supporting rEFInd officially?
>

Have you contacted the maintainer to ask if there is a problem with the
builds?

-- 
mike c

Re: [arch-general] System like glue, High IO Wait.

[Mike Cloaked]

On Sat, Apr 2, 2016 at 8:11 PM, Carsten Feuls  wrote:

> snip
> The Systems are very unresponsive (long waiting on gui interaction).
> In Htop I can see a high CPU wait time,and a high cpu load, but in iftop
> no IO
> load is on the drives.
> I have these Probelem with 3 Arch Installations.
> These systems run kf5.
> All installations runs ArchLinux Stable (not testing), and the
> Installations
> are up to date.
> On my parents PC the problem only appear after the last update.
> I have copy the output to pastebin.
> http://pastebin.com/E4xnQKhJ
>
> For me it looks like a graphics bug.
> I have downgraded the kernel to an older version but it does not resolve
> the
> problem.
> Maybe anybody know something about that. Or have an larger expertise in
> investigating this bug.
>
> I use archlinux now longer than six years. I have solved much problems. But
> this bug makes me crazy..
>
>
One question is what your hardware is - certainly for newer machines with
recent graphics hardware I have not had any serious slow response issues,
but for machines that are 5 or 6 years old I have had very considerable
limitations attempting to run plasma with its much more extensive demands
on the graphics hardware.  I have had to make the decision to only run
plasma on my machines here that are Ivybridge processor family or later.
On machines where the graphics hardware is a serious limitation I have
found that some performance can be regained by switching off all desktop
effects, and turning off desktop cube animation for switching between
desktops within plasma.  You might want to check or list the hardware on
the machines affected?  Others may have other suggestions but you would
need to provide information about your hardware and possibly diagnostics
from log files before people might be able to suggest what the problem is.


-- 
mike c

Re: [arch-general] Alternative init system proposal

[Mike Cloaked]

On Mon, Feb 8, 2016 at 12:58 AM, Ivan  wrote:

> Hello, I have a proposal for Arch Linux developers and by mailing
> on this list I would also appreciate feedback from non-developers that
> use Arch Linux.
> Note: I am not here to hate on the current status, nor
> to disapprove of current Arch choices.
>
> So, to get to the point...
> I would like to propose development and official support of an
> alternative init system and service manager. My main preference would be
>
> >snip


> me feedback on all of this and let's see what we can do about it and
> what it can develop into...
>
>
This kind of long-running, and in the end pointless, discussion that has
developed in recent days, on this ML, was the underlying reason for a huge
and extended set of threads on a number of linux forums a few years ago,
including on the Fedora Forums, that led a significant number of users to
unsubscribe from those forums because they did not want their inboxes
filled up with discussions that looked increasingly like they were going
nowhere. At the end of the day the arch developers made the decision to
support systemd as the arch linux daemon and initialisation software. They
have devoted their time to make arch linux a beautifully efficient
distribution keeping to the "Arch Way", and with the most efficient of
package manager compared to most other linux distros. It is likely no
surprise that a number of senior kernel developers use arch linux rather
than other distributions. The required systemd packages were made available
to the arch repos, advice on transisioning to systemd for those on other
inits broadcast, and over time all of the necessary unit files and support
structures were put in place, keeping arch close to upstream, and the
current arch linux system works exceptionally well on a huge range of
different types of hardware. Users are free to write their own unit files
or to adapt the default unit files (and I do this in a few cases too where
I want behaviour to match my own needs). My systems (both laptops and
desktops) start up quickly and, like many users, I am very happy with the
performance of my arch linux installed machines.

It is tough enough for TUs to voluntarily keep the packages in the repos as
close to current upstream as they do already, and adding an unnecessary
layer of additional support for a small percentage of the user base who
wish to have a second init system available, because they think it is
better than systemd, is not a proposal that looks like it would get
majority support even if there are a few people who continue to flood the
mailing list with ongoing thread postings about this.

Perhaps those who wish to pursue the alternative init idea could do so in
private on a separate mailing list devoted to that topic alone and any
interested parties can of course freely join in that discussion if they
should wish to do so.  The number of users who subscribe to that specific
ML would be a gauge of any real interest from significant numbers of users.
If that turns out to be a small handful of people only, then that would be
at least some evidence of the level of support for that proposal. However
filling people's inboxes with this discussion I suspect is not being found
valuable by quite a few people I expect.

Anyone is of course free to develop the proposed alternative init system
for their own use, or form their own developer subgroup, and could provide
their own repos if they wish, and anyone wanting to use the alternative can
then do so.

I certainly see many helpful concise and brief threads that seek to resolve
or inform in a way that is digestible. However long running flame wars
between systemd antagonists and supporters is counter-productive. The real
question is whether or not any TUs or developers think that this is worthy
of further investigation or not. Users who wish to volunteer to do the work
can of course make themselves known.

-- 
mike c

Re: [arch-general] plasma 5 crashing

[Mike Cloaked]

On Tue, Dec 29, 2015 at 1:17 PM, Genes Lists  wrote:

> Fully updated from testing repo.
>
> Since update to plasma 5.5 I am getting periodic crashes of plasmashell
> -trace back below.  Seems to be connected with dri/swrast_dri.so.
>
> i915 graphics so not sure why swrast_dri is called - but then again not
> sure what that does exactly (sounds like software rendering).
>
> Anyone got suggestions or seen similar.
>
> plasma restarts itself and things go normally for a while until the next
> crash.
>
> gene
>
>
> --- trace back
>
> Application: Plasma (plasmashell), signal: Segmentation fault
> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> [Current thread is 1 (Thread 0x7f7c26ff0800 (LWP 2502))]
>
> ...
>
> Thread 1 (Thread 0x7f7c26ff0800 (LWP 2502)):
> [KCrash Handler]
> #5  0x7f7c34c52b22 in __memmove_avx_unaligned () from
> /usr/lib/libc.so.6
> #6  0x7f7c1763dc8d in ?? () from
> /usr/lib/xorg/modules/dri/swrast_dri.so
> #7  0x7f7c1763c645 in ?? () from
> /usr/lib/xorg/modules/dri/swrast_dri.so
> #8  0x7f7c1db1e8fa in ?? () from
> /usr/lib/qt/qml/org/kde/plasma/core/libcorebindingsplugin.so
> #9  0x7f7c1db1f3f9 in ?? () from
> /usr/lib/qt/qml/org/kde/plasma/core/libcorebindingsplugin.so
> #10 0x7f7c1db1f954 in ?? () from
> /usr/lib/qt/qml/org/kde/plasma/core/libcorebindingsplugin.so
> #11 0x7f7c38652ac0 in
> QQuickWindowPrivate::updateDirtyNode(QQuickItem*) () from
> /usr/lib/libQt5Quick.so.5
> #12 0x7f7c3865331b in QQuickWindowPrivate::updateDirtyNodes() () from
> /usr/lib/libQt5Quick.so.5
> #13 0x7f7c38653490 in QQuickWindowPrivate::syncSceneGraph() () from
> /usr/lib/libQt5Quick.so.5
> #14 0x7f7c3862219c in ?? () from /usr/lib/libQt5Quick.so.5
>
> ...
>

For anyone having this kind of problem some additional useful info might be
obtained by running the suggested commands in
the page at http://dri.freedesktop.org/wiki/glxinfo/ - and getting at some
3d rendering info specifically when the system has a problem indicated by
the fact that the rendering is falling back to the swrast_dri driver. Any
chance this report relates to failed graphics drivers which may originate
in bugs in the mesa/plasma/X etc code - but at least some initial info
showing where there is a problem may point to where to look for more
problems so narrow down where the initial failure occurs?
-- 
mike c

Re: [arch-general] DHCP server package orphaned

[Mike Cloaked]

On Thu, Sep 10, 2015 at 8:55 AM, LoneVVolf  wrote:

>
>>
>> If you mean the dhcp package, the orphaning must have been temporarily .
> Felix Yan is now mentioned as maintainer.
>
> LW
>

Excellent.

-- 
mike c

[arch-general] DHCP server package orphaned

[Mike Cloaked]

Having seen that the dhcp server package has been orphaned yesterday,
hopefully this will be picked up and maintained as it is a pretty important
standard package for a server.

-- 
mike c

Re: [arch-general] systemd new dependencies impede using OpenRC

[Mike Cloaked]

On Fri, Jul 3, 2015 at 4:10 PM, Geoff  wrote:

> On Fri, 3 Jul 2015 16:51:21 +0200
> Bardur Arantsson  wrote:
>
> 
> > STOP!
>
> Although I find the discussion interesting, I have watched with growing
> amazement.  As I recall, this list became moderated due to the furore when
> systemd was introduced, and I doubt that Lennart himself could have got a
> post
> on the subject through in the aftermath.
>

The bitter flame wars concerning systemd were rife on several other mailing
lists a few years ago and led to no useful outcome other than to severely
impact on users who had significant volumes of mail in their inboxes. This
led both to some MLs being moderated but also led to some people
unsubscribing from lists to get away from the futile claim and counterclaim
spew of mail. Please stop this systemd discussion now as the majority of
people in this list are subscribed for the purpose of providing and
receiving genuine help with issues that can't be answered in the wiki or
forums. Also suggestions for positive developments that have not been
discussed elsewhere.

Times have moved on since the systemd war - and we have a very functional
arch linux operating system. Please move any further systemd rants to some
other channel.
-- 
mike c

Re: [arch-general] Why does network interface sometimes change name?

[Mike Cloaked]

On Mon, Apr 6, 2015 at 4:36 PM, Felix E. Klee  wrote:

> I am running Arch as a guest in VMware Player on Win7X64. On every odd
> boot, the name of the network interface changes. Sometimes it is:
>
> eno1636
>
> Sometimes it is:
>
> eth0
>
>
I had the corresponding issue on a machine with two nics (not vm though),
and what fixed it for me was to add a udev rule (though it does depend on
having consistent mac address for each nic):

# cat /etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="4c:72:b9:32:45:30",
NAME="eno1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="4c:72:b9:32:45:32",
NAME="eno2"

If you want to associate a specific nic to a name chosen by you then this
may help.

-- 
mike c

Re: [arch-general] filesystem update

[Mike Cloaked]

On Tue, Feb 24, 2015 at 9:12 PM, Simon Hanna  wrote:

> Hi,
>
> the latest filesystem package now owns /home
> my /home used to be a symlink to some other location, so the upgrade
> failed.
> I "fixed" it for now by just linking my home folder into /home (since I'm
> running a single user setup it's fine)
>
> However I'm curious whether the directory should be left as it is, or if
> it's "allowed to play with"
>
> cheers
>

Try bind mounting your "other" location to /home

-- 
mike c

Re: [arch-general] pacman security when importing new keys?

[Mike Cloaked]

On Tue, Feb 10, 2015 at 12:59 PM, Dennis Lange  wrote:

> Hi Manuel,
>
> thanks for posting this thread. I also wondered about the key from
> eworm. Sure he is a trusted user but accepting keys made me a little bit
> nervous. Is there a way to verify my pacman keys?
>
> Dennis
>
>
I guess you can verify fingerprints from the list at

 https://www.archlinux.org/master-keys/


-- 
mike c

Re: [arch-general] [arch-dev-public] [extra] Dropping ocaml packages

[Mike Cloaked]

On Tue, Feb 3, 2015 at 8:33 AM, Tobias Powalowski <
tobias.powalow...@googlemail.com> wrote:

> Hi guys,
> I don't use it on any of my machines anymore, anyone who wants to step up?
> Else those are candidates for AUR/community.
>
> ocaml
> ocaml-compiler-libs
> facile
> lablgtk2
> unison
>
> greetings
> tpowa
>
>
I noticed from the arch-dev-public list in the post quoted above that ocaml
is planned to be dropped to AUR or community.  I also notice that ocaml is
still a dependency for one of the kde packages.

# pacman -R ocaml
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: kdeedu-kalzium: requires ocaml

I guess it needs to be maintained else there may be problems with updates
to kde in the future?


-- 
mike c

Re: [arch-general] NFS server broke after reboot - *urgent* need help

[Mike Cloaked]

On Sun, Feb 1, 2015 at 2:25 PM, Gene Cohler  wrote:

> Only use V4 here.
> I believe the references to older versions come from the rpc-statd
> systemd  unit file. I'm away from  computers  at the moment but will double
> check. Also I believe it's nfs-server unit file that asks for rpc-statd.
>
> It's been working fine since system was installed in December 2013 other
> than the occasional quirk such as mentioned in June 2014 bug report.
>
> I forgot to mention that the new nfs-utils  came in after the first reboot
> to pick up 3.18.5. However installing that did not by itself fix anything
> either.
>
> Thank you for your help.
>
>
Is this Fedora bug related?

 https://bugzilla.redhat.com/show_bug.cgi?id=1183992

-- 
mike c

Re: [arch-general] NFS server broke after reboot - *urgent* need help

[Mike Cloaked]

On Sat, Jan 31, 2015 at 9:50 PM, Tomasz Kramkowski  wrote:

>
> I've been having a few rather strange problems recently with services
> requiring an upped network interface starting before the interface is
> up, this is using systemd-networkd-wait-online.service.
>
> In any case, it is possible you are having a similar problem, are you
> sure the interfaces nfs-server is set to listen on are up?
>

This is now reported at  https://bugs.archlinux.org/task/43647 so hopefully
some enlightenment will appear there to help too.

-- 
mike c

Re: [arch-general] CUPS : can't get driver list since last update

[Mike Cloaked]

On Sat, Dec 27, 2014 at 2:28 PM, SET  wrote:

> Hello,
>
> When installing a new printer via cups's web interface, the process blocks
> with an error message close to 'can't get driver list'. At the same time,
> cupsd and foomatic processes consume 25% CPU resources each. This is
> reproducible on two different hosts.
>
> Downgrading cups and/or cups-filters yields the same result.
>
> Some printers stop working with the error message 'filter failed'.
>
> Cups seems broken since last upgrade (today on one host, 2 or 3 weeks
> before
> on the second host).
>
> Please consider a fix.
>
> Thx.
>

Possibly related to the longish running thread at
https://bbs.archlinux.org/viewtopic.php?id=189261

-- 
mike c

Re: [arch-general] gnupg 2.1 not stable

[Mike Cloaked]

Just to add a link showing the need for help for the gnupg developers it
may be worth having a quick look at
https://gnupg.org/blog/20141214-gnupg-and-g10.html

-- 
mike c

Re: [arch-general] [arch-dev-public] Changes to microcode updates

[Mike Cloaked]

On Thu, Oct 23, 2014 at 9:42 PM, Thomas Bächler 
wrote:

> Am 23.10.2014 um 21:58 schrieb Mike Cloaked:
> > Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to
> revision
> > 0x1b, date = 2014-05-29
> >
> > Does this mean that the quoted early update has used the wrong file from
> an
> > earlier date than current, or does this journal log line confirm correct
> > early loading of the up-to-date microcode?
>
> This is the timestamp that marks Intel's internal version. This is what
> I get:
>
> [0.00] lije kernel: CPU0 microcode updated early to revision
> 0x1c, date = 2014-07-03
>
>
>
On a second machine (a Haswell laptop) I get:

Oct 23 15:16:38 localhost kernel: CPU0 microcode updated early to revision
0x1c, date = 2014-07-03

which might suggest that mine has the same CPU as yours, so that this is
indeed the latest internal version date for the microcode - (which makes me
feel a little easier seeing you get the same as me!)


-- 
mike c

Re: [arch-general] [arch-dev-public] Changes to microcode updates

[Mike Cloaked]

On Thu, Oct 23, 2014 at 4:55 PM, Thomas Bächler 
wrote:

>
> A 2 minute Google search indicates that refind merely appends the initrd
> as a kernel command line option (initrd=) - refind, like gummiboot, is
> merely an EFI bootmanager and not a bootloader and thus relies on the
> kernel's EFIstub feature. Therefore, refind does not load the initrd
> itself, but delegates that task to the kernel.
>
>
I am confused about this now. In my previous post I quoted that using
refind boots with the dual initrd files in the refind_linux.conf file, and
leads to lines in the journal log like:

Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision
0x1b, date = 2014-05-29

Does this mean that the quoted early update has used the wrong file from an
earlier date than current, or does this journal log line confirm correct
early loading of the up-to-date microcode? Or does delegating the task to
the kernel  when efistub loading produce a correctly working processor with
the intended new microcode at the early stage of booting the kernel?

Thanks

-- 
mike c

Re: [arch-general] [arch-dev-public] Changes to microcode updates

[Mike Cloaked]

On Thu, Oct 23, 2014 at 1:01 AM, Marko Hauptvogel <
marko.hauptvo...@googlemail.com> wrote:

> Referring to the comments from october 16th on the ck kernel package
> page [0] and the config of said package [1], your version of the ck
> kernel has not yet been configured to do early microcode updates. But
>

 I have just updated my arch linux system to the new kernel and new
microcode packages (linux 3.17.1-1 intel-ucode 20140913-1). This system
boots with rEFInd. The /boot/refind_linux.conf file was edited to include
the microcode image file as an initrd= entry with lines as:

cat /boot/refind_linux.conf
"Boot to X" "root=PARTUUID=b0c9c220-0f8d-49c1-b306-873d2519ce47 rw
rootfstype=ext4 add_efi_memmapinitrd=/boot/intel-ucode.img
initrd=/boot/initramfs-linux.img systemd.unit=graphical.target"
"Boot to console" "root=PARTUUID=b0c9c220-0f8d-49c1-b306-873d2519ce47 rw
rootfstype=ext4 add_efi_memmap initrd=/boot/intel-ucode.img
initrd=/boot/initramfs-linux.img systemd.unit=multi-user.target"
"Boot Fallback to console"
"root=PARTUUID=b0c9c220-0f8d-49c1-b306-873d2519ce47 rw rootfstype=ext4
add_efi_memmap initrd=/boot/intel-ucode.img
initrd=/boot/initramfs-linux-fallback.img systemd.unit=multi-user.target"

The system boots in the same time as previously with kernel 3.16 and the
journal log confirms early microcode update.

journalctl -b | grep microcode
Oct 23 15:41:56 localhost kernel: CPU0 microcode updated early to revision
0x1b, date = 2014-05-29
Oct 23 15:41:56 localhost kernel: CPU1 microcode updated early to revision
0x1b, date = 2014-05-29
Oct 23 15:41:56 localhost kernel: microcode: CPU0 sig=0x306a9, pf=0x2,
revision=0x1b
Oct 23 15:41:56 localhost kernel: microcode: CPU1 sig=0x306a9, pf=0x2,
revision=0x1b
Oct 23 15:41:56 localhost kernel: microcode: CPU2 sig=0x306a9, pf=0x2,
revision=0x1b
Oct 23 15:41:56 localhost kernel: microcode: CPU3 sig=0x306a9, pf=0x2,
revision=0x1b
Oct 23 15:41:56 localhost kernel: microcode: Microcode Update Driver: v2.00
tig...@aivazian.fsnet.co.uk, Peter Oruba

So the updated kernel works fine for early microcode update, with the small
amendment to the refind_linux.conf file as the rEFInd author suggested it
would. I have tested this on three different machines all of which use
rEFInd to boot. I note that the arch wiki has already been edited to
include the change needed for the rEFInd boot manager. So this works fine.
It is presumed that the latest microcode for the CPU in this machine is
dated correctly as 2014-05-29.
-- 
mike c

Re: [arch-general] [arch-dev-public] Changes to microcode updates

[Mike Cloaked]

On Mon, Oct 20, 2014 at 5:44 PM, Thomas Bächler 
wrote:

>
> These changes have been done precisely to avoid these problems, the
> first link and its responses summarize the situation pretty well.
>
>
The file at https://www.kernel.org/doc/Documentation/x86/early-microcode.txt
gives a method that should allow creating a combined initrd img file that
anyone booting with refind EFI may be able to test.  There are suggested
methods to implement early microcode loading for the other main bootloaders
in the arch wiki, but until now for refind it seems not to have been
verified to work. It would be nice to see verification that early microcode
loading has been successful using all the main bootloaders/bootmanagers, as
well as direct efistub boot.

-- 
mike c

Re: [arch-general] [arch-dev-public] Changes to microcode updates

[Mike Cloaked]

On Sat, Oct 18, 2014 at 10:06 PM, Genes Lists  wrote:

>
> For info - I have tried to get it working in refind and failed. I added a
> second initrd line in the boot stanza in refind.conf. But the firmware was
> not updated.
>
> I added to refind sourceforge report[1], perhaps Rod will respond.
>
> [1] https://sourceforge.net/p/refind/discussion/general/thread/7da6cd81/
>
>
>
It would seem that there might be some problems with this microcode update
apart from the issues with bootloaders. See

1) https://lkml.org/lkml/2014/9/18/218

2) https://bugs.launchpad.net/intel/+bug/1370352

-- 
mike c

Re: [arch-general] [arch-dev-public] Changes to microcode updates

[Mike Cloaked]

On Sun, Oct 12, 2014 at 9:16 PM, Mauro Santos 
wrote:

>
> I'm replying here as (obviously) I don't have posting rights at arch-dev :)
>
> From what I've been able to understand [1-3], for grub (legacy and
> grub2) it should work by using multiple initrd lines or like this:
>
> initrd /path/to/ucode/update /path/to/arch/initrd
>
> I haven't tested it though, so it might be broken and I have no idea of
> how to integrate it with the automagical grub.cfg configuration
> (grub-mkconfig).
>

In case there is interest in a related discussion there is also a thread on
this topic on the arch forum at:

https://bbs.archlinux.org/viewtopic.php?id=188252

-- 
mike c

Re: [arch-general] Messed up {g,u}id for uuidd

[Mike Cloaked]

On Wed, Aug 20, 2014 at 8:55 AM, Leonidas Spyropoulos 
wrote:

> Hello,
>
> I had the brilliant idea couple of weeks ago to merge the
> /etc/{shadow,group,passwd} . I know now that I shouldn't be merging those
> and ignore the pacnew files. Now i'd like to fix these. The status report
> from systemd is:
>
> snip

>
> Further info
> ~# cat /etc/shadow | grep uuidd
> uuidd:x:14871::
> ~# cat /etc/group | grep uuidd
> uuidd:x:997:
> ~# cat /etc/passwd | grep uuidd
> uuidd:x:68:68:uuidd:/:/sbin/nologin
> ~# /usr/bin/pwck -r
> user 'uuidd': no group 68
> pwck: no changes
>
> What should I be changing to fix this? If I change the gid from 997 to 68
> would this fix it? Would it be other implications?
>
>
If it is any help my output from the same cat commands is:

$ sudo cat /etc/passwd | grep uuidd
uuidd:x:68:68:uuidd:/:/usr/bin/nologin
$ sudo cat /etc/shadow | grep uuidd
uuidd:x:14871::
$ sudo cat /etc/group | grep uuidd
uuidd:x:68:

which indeed suggests that your /etc/group for this uuidd line might have
68 instead of 997 - but of course your files may have other differences
also. In addition I have /usr/bin/nologin in the passwd file though that
should not matter.

Did you have any backup copies of the original files before making your
merge changes?  Retrieval of the backup copies would at least allow a
comparison to be made before you made the merge.

-- 
mike c

Re: [arch-general] EFI-GPT : GRUB won't load

[Mike Cloaked]

On Thu, Jul 17, 2014 at 10:17 PM, Saleem EDAH-TALLY 
wrote:

> Hello,
>
> I'm trying to dual boot Arch with Windows 8.1 on an HP Pavilion 15-n216sf
> with
> Windows 8.1 pre-installed.
>
> I have followed
>
> https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface
> https://wiki.archlinux.org/index.php/Grub
>
>
> So I can't find a way to dual boot with ARCH and I'm stuck with this.
>
> I have noted one weird thing with efibootmgr -v from arch-chroot, with
> fails
> with an invalid pointer message and lots of backtrace, and the following
> output :
>
> BootCurrent: 0001
> Timeout: 2 seconds
> BootOrder: 0002,,3000,2001,2002,2003
> Boot* Windows Boot Manager  HD(2,c8800,82000,dc61d0de-af32-472f-8c54-
> fdafe931e191)File(\EFI\Microsoft\Boot\bootmgfw.efi)(invalid optional data
> length)
> Boot0001* USB Hard Drive (UEFI) - USB DISK 2.0
>
> I am hereby requesting help to solve this issue.
>
> Thank you.
>

It is possible that the thread at
https://bbs.archlinux.org/viewtopic.php?id=177356 may help?

-- 
mike c

Re: [arch-general] Gummiboot and EFISTUB booting irregularities

[Mike Cloaked]

On Thu, Jul 10, 2014 at 2:25 PM, Bigby James 
wrote:

> On 07/10, Murari wrote:
> > Thanks! It's nice (or maybe not...) to know that this is a problem with
> > only the EFI stub loader. I do have a standalone grub entry which I
> haven't
> > used in ages. I guess I will just add that to the gummiboot menu as a
> > fallback and wait for the next kernel update.
> >
>
> If that's your backup plan, just remember that you'll need a tiny BIOS GRUB
> parititon[1] on the disk to get GRUB to boot from a GUID partition table in
> legacy mode.
>
> [1]: https://wiki.archlinux.org/index.php/Grub#Preliminary_requirements
>
>
There is no need to do that.  I don't have any bios grub partition and
there is no need to run grub in legacy mode when using it as a backup for
uefi efi stub boot. You can do it as a grub standalone boot -
https://wiki.archlinux.org/index.php/GRUB#GRUB_Standalone



-- 
mike c

Re: [arch-general] Gummiboot and EFISTUB booting irregularities

[Mike Cloaked]

On Wed, Jul 9, 2014 at 10:30 PM, Bigby James 
wrote:

> On 07/09, Murari wrote:
>
> > When I start my laptop (or restart it) and select the Arch Linux entry
> in the
> > gummiboot menu, I sometimes only see a blank screen instead of any error
> > messages or any of the usual boot text.
>
> This is a known issue, and yes, it's hard to describe or pin down. Some
> UEFI
> firmwares just don't seem to play nice with the kernel every couple
> versions or
> so. The systems that are effected seem almost random, which is probably
> why it's
> been around for so long. There are two workarounds that seem to work for
> people:
>
> - Downgrade the kernel and wait until the next update.
> - Build a kernel with ABS. For some reason this resolves the issue on some
>   machines. And I don't mean build a *custom* kernel---for some reason,
> simply
>   downloading the PKGBUILD for the 'linux' package, running makepkg and
>   installing it seems to eliminate boot problems for some people.
>
> Personally, after this happened to me a third time I just started booting
> in
> legacy mode with Syslinux.


Another option that seems to work reliably is to use your normal uefi boot
loader/manager to chainload grub and let grub boot the kernel if uefi boot
fails due to the well-known stub loader bug. The problem appears to be only
when booting uefi with the efi stub loader, whereas grub does not use the
efi stub loader and appears not to be affected. On my own systems with
rEFInd, I have a refind stanza that chainloads a grub standalone entry, and
if there is a problem uefi booting a specific kernel on that machine, then
I can simply reboot to the grub entry and let that boot the kernel. Having
that as a fallback boot method should allow you to boot a kernel if it
turns out that your machine is affected by the efi stub loader bug. Then
simply wait for the next kernel or rebuild your kernel as per the previous
post and check if that helps.

-- 
mike c

Re: [arch-general] odd problem with NetworkManager and wired

[Mike Cloaked]

On Sun, Jul 6, 2014 at 12:19 AM, Genes Lists  wrote:

>  Haven't plugged an ethernet cable into my laptop for a while - today I
> did. Wirelss has been working flawlessly.
>
>   Plugging a wire in however refuses to connect - the error in journal is:
>
> .. dhclient[30318]: execve (/usr/lib/networkmanager/nm-dhcp-client.action,
> ...): No such file or directory
>
>  Which is correct. In fact the only script in there with dhcp is
> nm-dhcp-helper. When connected via wifi and checking to see what is running
> this script is used:
>
> ps -eaf | egrep dhcp
> root   605   555  0 18:53 ?00:00:00 /usr/bin/dhclient -d -sf
> /usr/lib/networkmanager/nm-dhcp-helper -pf /var/run/dhclient-wlp3s0.pid
> -lf 
> /var/lib/NetworkManager/dhclient-226bfd76-9c49-43fd-8dff-bf6e0809313c-wlp3s0.lease
> -cf /var/lib/NetworkManager/dhclient-wlp3s0.conf wlp3s0
>
>
> So the problem seems to only happen for the wired interface.
>
> I -know- this used to work fine, but unfortunately I have no idea when it
> stopped.
>
> Any suggestions how to get wired working again? I tried on 2 different
> laptops - same problem.
>
> Thanks for any advice.
>
>
Any chance that this is a leftover problem from when the kde nm package (
 kdeplasma-applets-plasma-nm ) was first released?  There were some initial
problems with managing the storage of connection data which were ironed out
but it is possible some users were left with some file crud. Can you delete
your wired connection in the kde nm gui, and start a new one?

-- 
mike c

Re: [arch-general] systemd 215 + filesystem 2014.07-1 => problems booting?

[Mike Cloaked]

On Sat, Jul 5, 2014 at 3:23 AM, Genes Lists  wrote:

> Anyone else having trouble booting with testing repo and systemd 215 +
> filesystem 2014.07-1 as per thie forum post?
>
> https://bbs.archlinux.org/viewtopic.php?id=183796
>
>
The forum post gives a link to a bug report on this now at
https://bugs.archlinux.org/task/41097

-- 
mike c

Re: [arch-general] Kernel updated to 3.14.5-1. Now my Lenovo IdeaPad hangs on boot...

[Mike Cloaked]

On Wed, Jun 4, 2014 at 1:57 AM, Curtis Shimamoto <
sugar.and.scru...@gmail.com> wrote:

> 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...


If it is any help what I do is to have grub installed as well as my main
boot manager, which is rEFInd, which is essentially the corresponding setup
to that which Curtis reported for gummiboot in the previous post. I have a
rEFInd config stanza that will chainload the grub bootloader to boot the
kernel when the efistub fails to boot after any particular kernel update.
Grub will always boot the same problematic kernel since it does not use the
efistub. I had a thread which details how I chainload grub from rEFInd,
when I had an issue setting it up, at
https://bbs.archlinux.org/viewtopic.php?id=181906 and the corresponding
technique can be employed for gummiboot as Curtis said in the previous post.

I too have not had a problem booting kernels with the efistub recently, but
it is certainly worthwhile setting up grub as an option so that you can
still boot your system quickly in the event that the efistub kernel fails
to boot. Then you can stay with the new kernel until the next kernel update
so it is then no longer a worry.

However it would be ideal if the underlying bug that causes occasional
efistub kernels to fail to boot on particular hardware. Thus far nobody has
been able to pin down any consistent factors that would allow diagnosing
where in the boot code or firmware the problem lies.

-- 
mike c

Re: [arch-general] Kernel updated to 3.14.5-1. Now my Lenovo IdeaPad hangs on boot...

[Mike Cloaked]

It is quite likely you have been hit by the now infamous efistub bug - see:

https://bugs.archlinux.org/task/33745?project=1

https://bugzilla.kernel.org/show_bug.cgi?id=68761

https://bbs.archlinux.org/viewtopic.php?id=156670



On Tue, Jun 3, 2014 at 4:38 PM, Manuel Reimer 
wrote:

> On 06/03/2014 05:16 PM, Anatol Pomozov wrote:
>
>> To recover your machine:
>> 1) Boot from Arch ISO. I always have an USB pan with Arch image and
>> found it useful for emergency cases.
>> 2) Find your system partitions. Use 'lsblk' for this
>> 3) mount your system partition, e.g. 'mkdir system; mount /dev/sda1
>> system'
>> 4) arch-chroot into your system: 'arch-chroot system'
>> 5) fix your system e.g. downgrade kernel to previous version 'downgrade
>> linux'
>> 6) reboot and enjoy
>>
>
> Did so, now. Now I'm on 3.14.4, again. System boots without any problems.
>
> But why can't I use the current kernel? Does someone here successfully
> boot 3.14.5 via efistub? Bug in kernel? Or maybe bug in kernel
> configuration?
>
> Greetings,
>
> Manuel
>
>


-- 
mike c

Re: [arch-general] Installing Archlinux alongside Ubuntu on a Windows 8 UEFI laptop

[Mike Cloaked]

On Thu, May 1, 2014 at 11:18 PM, Daniel Micay  wrote:

> On 01/05/14 06:15 PM, Alan E. Davis wrote:
> > Ubuntu's kernel is on the / partition.  Would I move it to the ESP
> > partition, in that case?
> >
> > And I will mount that partition on /mnt/boot ?
> >
> > I have never used gummiboot.  Since the Arch system is already to go, but
> > not yet with a boot management setup, I should manually move that kernel
> to
> > the ESP partition as well?
> >
> > Alan Davis
>
> Yes, you should mount the ESP partition as /boot so the kernels get
> installed there. Then install gummiboot and set up entries for Arch and
> Ubuntu.
>
>
The approach mentioned above should work. An alternative is to have the ESP
mounted as, say /boot/efi (which is a vfat partition) and then the (vfat)
ESP becomes /boot/efi/EFI/ which then contains the windows efi boot files,
and you can then if you wish install refind in a directory such as
/boot/efi/EFI/refind/ - and it is in principle also possible to have more
than one boot manager in that directory so that you can choose which boot
manager to use, and each can then boot all of your installed operating
systems via UEFI.

If so then it is also possible to have /boot as either a separate ext4
partition, or a subdirectory of the root partition, also as ext4 (thereby
getting the advantage of a journaled filesystem). Then the kernel(s) can be
in /boot/ and using refind the refind efi binary can still read the ext4
/boot/* files for the kernel(s) and initrd(s) since refind has drivers that
can read ext4 files.  The details are in the author's refind web pages (
http://www.rodsbooks.com/refind/ ).

It is possible to either let refind automatically discover all the
available operating systems that you have set up or you can configure the
config files with specific stanzas to boot individual OSes - and each
becomes a nice icon on the graphical boot screen. You can select which is
the default system to boot, but can also intercept the boot to choose a
non-default system.

Of course you have the choice to use different boot managers, and gummiboot
and grub will in principle be able to boot all three OSes once set up.

-- 
mike c

Re: [arch-general] Optimizing boot

[Mike Cloaked]

On Wed, Apr 30, 2014 at 10:56 AM, Toyam Cox wrote:

>
> Startup finished in 4.215s (firmware) + 176ms (loader) + 2.939s (kernel) +
> 11.166s (userspace) = 18.497s
>
> Thank you very much! NetworkManager takes a much more reasonable 1.4
> seconds now. It would not have occured to me to have the journal checked. I
> also enabled readahead, and now LXDE starts before I'm finished booting, a
> very nice feature.


Just a comment about boot times. The overall boot performance will depend
not only on optimising an individual setup, but also is dependent on the
hardware as well as which boot manager is being used.  So an older laptop
with a hard drive, using BIOS boot and optimised will still see much longer
boot time than say a new laptop running a fast i7 processor, with an ssd,
using UEFI and also optimised.  Certainly I have an old laptop that takes
around 35 seconds to boot to the login prompt from when the boot manager
takes over after POST using BIOS legacy boot, but a similarly set up and
optimised new Haswell i7 laptop, with msata ssd using refind for UEFI boot
takes about 7 seconds to reach the KDM login prompt. Of course for a
specific system it may be possible to shave some seconds off the boot time,
but it will also depend on which server daemons need to be started as well.
So adding dovecot, an MTA, and maybe a DHCP server all add to the time
taken to complete the boot process.

So comparisons of absolute boot times from different machines are difficult
to interpret.

-- 
mike c

Re: [arch-general] KDE update and baloo

[Mike Cloaked]

On Thu, Apr 17, 2014 at 8:33 PM, Genes Lists  wrote:

> On 04/17/2014 10:37 AM, Lukas Jirkovsky wrote:
>
>>
>> Is it with KDE PIM? I remember a discussion in the release ML that
>> baloo was somewhat broken in PIM. I dunno if that was fixed or not.
>>
>>  No not using PIM. I killed off all the baloo processes - short term
> fix.There really should be an off button on this kind of thing.
>

What I found is after runing the current pacman update, then I did the
following. Logout and back in to kde. Then once logged back in went to the
kde system settings and into Desktop Search, and simply add the user home
directory to the list not to search.  Apply the changed setting, and then
logout and back in (there was a slight delay to the logout process at this
point due to the initial baloo processes running but I just waited out the
half minute or so till it logged out). There was be a baloo file cleaner
process running when I logged back in, which on my machines seemed to run
for a few minutes only, and then stop. At that point if I checked the file:

$ cat .kde4/share/config/baloofilerc
and found that at the top that there were already the lines:
[Basic Settings]
Indexing-Enabled=false

[General]
several other lines after this.

At that point baloo quietened down and there were no further issues with
baloo but I guess you need to have a little patience during the initial
running of the processes mentioned above, so it is a short term issue only.

I have seen a gentoo thread which suggests that allowing baloo to index
email does give a very efficient search even for tens of thousands of
mails, but of course the initial indexing process does take a little time
and CPU cycles for several minutes depending on how many directories and
files are in the mail area - but once that is complete then it is suggested
that it works extremely well.

-- 
mike c

Re: [arch-general] Thank you

[Mike Cloaked]

May I add my thanks to all the developers and maintainers for making
ArchLinux the excellent distribution that it is.  I converted all my
machines to Arch over the past couple of years, and I value the philosophy,
the up-to-datedness, and the speedy and efficient package management, as
well as the amazing level of stability given how current the packages are.
I would particularly like to thank Rod Smith for helping in herding me, as
one of the rEFInd learners, into the knowledge pen, and making UEFI boot
work well on so many relatively new machines. The rolling distro model  and
the "Arch way" really do work fantastically well.

May ArchLinux users have a great 2014 and beyond.


On Mon, Jan 6, 2014 at 12:30 PM, arnaud gaboury wrote:

> On Mon, Jan 6, 2014 at 1:05 PM, Genes Lists  wrote:
> >
> >
> >  Over the last 2 weeks I have replaced 3 fedora servers with Arch - and
> want to say thank you . That's the last of my fedora machines now and I am
> all Arch and they are all working really well.
> >
> > The new boxes are haswell UEFI and boot using refind. Setting this up
> was straightforward with Arch.
> >
> > Thank you for making Arch the best linux distro.
> >
> > Happy New Year
> >
> > gene
>
>
> I just wanted to add to your testimony I run Arch too on a server and
> it is very pleasant to use.
> And YES, running Arch as a web server is a good and feasible solution,
> even with the high number of upgrades.
> Definitively one of the best distro out there, thanks to its very
> dynamic and reactive dev community.
>
> Thanks to all and HNY.
>



-- 
mike c

Re: [arch-general] Intel SNA artifacts in Firefox

[Mike Cloaked]

On Thu, Aug 15, 2013 at 1:33 PM, Paul Gideon Dann wrote:

> Since the xf86-video-intel update that enabled SNA by default, I've noticed
> that some areas of some web pages (mostly flat backgrounds) in Firefox
> suffer
> from heavy graphical corruption, as if those areas are being used as
> rendering
> buffers elsewhere: bits of web pages from other tabs, etc...  It goes away
> when I scroll the page.  It happens regularly, every couple of minutes or
> more.
>
> This is on a Dell Latitude E5520 (Sandybridge i5) with KDE.
>
> I'm wondering if anyone else is seeing this?


You are far from alone!

See the thread at  https://bbs.archlinux.org/viewtopic.php?id=167939

-- 
mike c

Re: [arch-general] remote poweroff with systemd

[Mike Cloaked]

On Wed, Aug 7, 2013 at 11:23 AM, Joe Eaves  wrote:

>
> How about something like 'shutdown -t 5'? I know if I put that into an SSH
> session manually, it'll print me a wall message and then I have some time
> to hit CTRL-D (or exit if I'm quick), so why would an automated command not
> be able to do the same?
>

Would it be possible to delay the reboot command whilst connected in an ssh
session by using something like:

# at now + 2 minutes systemctl reboot

then exit the ssh session and wait until the remote machine has rebooted?

I haven't tested it but is there a reason why this would not work?
-- 
mike c

[arch-general] Updating KDE whilst logged in causes loss of background wallpaper image

[Mike Cloaked]

There is a KDE bug that has been around for some time which is in the
upstream report at https://bugs.kde.org/show_bug.cgi?id=300708 which seems
to be that if you update KDE (as in today's update to KDE 4.10.4-1) whilst
being logged in to KDE you can lose your background wallpaper image.
Updating from a text console without being logged in to the graphical
desktop does not cause the issue to happen.

There is a workaround in the first comment in the report link above in case
anyone gets caught by this.

-- 
mike c

Re: [arch-general] Finishing the /usr move

[Mike Cloaked]

On Sat, Jun 1, 2013 at 3:22 PM, Karol Blazewicz
wrote:

> On Sat, Jun 1, 2013 at 4:10 PM, Mike Cloaked 
> wrote:
> > OK I have also been looking at the instructions and I find:
> >
> > $ paclist  | awk ' { print $1 } ' | pacman -Ql - | grep '/s\?bin/\|
> > /usr/sbin/'
> > bash: syntax error near unexpected token `|'
> >
> > Is there an error in the command?
>
> No, no error, you should replace  with the name of the repo you
> want to check.
>

Ahh - yes thank you - I am sorry I did not notice that myself.

-- 
mike c

Re: [arch-general] Finishing the /usr move

[Mike Cloaked]

On Sat, Jun 1, 2013 at 3:07 PM, Allan McRae  wrote:

>
> Lstest instructions would have kept you from the
> /tmp/alpm_Pd1z7b/.INSTALL error:
>
> https://mailman.archlinux.org/pipermail/arch-dev-public/2013-June/025043.html
>
> Fix your grub package.
>
>
>
OK I have also been looking at the instructions and I find:

$ paclist  | awk ' { print $1 } ' | pacman -Ql - | grep '/s\?bin/\|
/usr/sbin/'
bash: syntax error near unexpected token `|'

Is there an error in the command?



-- 
mike c

Re: [arch-general] libsasl issue today with pacman updates

[Mike Cloaked]

On Wed, May 15, 2013 at 10:43 AM, Thomas Bächler wrote:

>
>
> There's clearly something wrong:
>
> # pacman -Si libsasl cyrus-sasl cyrus-sasl-gssapi | grep -e ^Repository
> -e^Name -e ^Depends -e ^Version -e ^$
> Repository : core
> Name   : libsasl
> Version: 2.1.26-2
> Depends On : openssl  krb5
>
> Repository : testing
> Name   : cyrus-sasl
> Version: 2.1.26-2
> Depends On : libsasl=2.1.26  krb5
>
> Repository : extra
> Name   : cyrus-sasl
> Version: 2.1.23-12
> Depends On : libsasl=2.1.23  krb5
>
> Repository : testing
> Name   : cyrus-sasl-gssapi
> Version: 2.1.26-2
> Depends On : libsasl=2.1.26  krb5
>
> Repository : extra
> Name   : cyrus-sasl-gssapi
> Version: 2.1.23-12
> Depends On : libsasl=2.1.23  krb5
>

The repo data have been fixed now and all is well doing the pacman updates.



-- 
mike c

[arch-general] libsasl issue today with pacman updates

[Mike Cloaked]

There seems to have been a problem with pacman update today:

:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
error: failed to prepare transaction (could not satisfy dependencies)
:: cyrus-sasl: requires libsasl=2.1.23
:: cyrus-sasl-gssapi: requires libsasl=2.1.23

Yet the current version is the above referred version but libsasl won't
update on its own!

[root@home1 ~]# pacman -Ss libsasl
core/libsasl 2.1.26-2 [installed: 2.1.23-10]
Cyrus Simple Authentication Service Layer (SASL) Library

[root@home1 ~]# pacman -S libsasl
resolving dependencies...
looking for inter-conflicts...
error: failed to prepare transaction (could not satisfy dependencies)
:: cyrus-sasl: requires libsasl=2.1.23
:: cyrus-sasl-gssapi: requires libsasl=2.1.23

I am confused!

-- 
mike c

Re: [arch-general] turn off notifications?

[Mike Cloaked]

On Sun, May 5, 2013 at 11:10 AM, David Benfell wrote:

>
> So maybe thunderbird uses a separate mechanism for popping up
> notifications?


In Thunderbird try going to Edit->Preferences then select the general tab
and uncheck the "When new messages arrive" "Show and alert" ?

-- 
mike c

Re: [arch-general] Question about mariadb replacing mysql

[Mike Cloaked]

On Wed, Mar 27, 2013 at 12:13 PM, Paul Gideon Dann wrote:

> On Wednesday 27 Mar 2013 11:21:45 Mike Cloaked wrote:
> > The question remains as to whether any action is necessary after moving
> > from mysql to mariadb for any user who is using Kontact and other KDE
> > components that rely on mariadb after the change?
> >
> > Presumably there will be some people who know whether it will continue to
> > work or not without taking any specific action once mariadb is installed?
>
> Maybe you missed my reply to the original post?  I have this setup, and
> there
> is no issue after upgrade.  Make sure you restart Akonadi (preferably stop
> it
> before upgrade), and you should be fine.
>

Thanks - my experience was that although I had ensured that the mysqld
service was stopped at the time of installing mariadb, it was also the case
that since there was no mention of KDE that I could see in the original
announcement I simply left akonadi running whilst installing mariadb.  I
have not personally had any obvious issues arising after the change, and
only realised after the event that akonadi uses it even though "systemctl
status mysqld" shows it is inactive. That was the reason for my original
post in case some surprise related to Pim in KDE may later appear for KDE
users despite the process of change being executed correctly according to
the announcement. On other machines I manage I ensured that the mysqld
service was stopped as well as executing aknodictl stop before installing
mariadb.

Since the feedback seems to indicate that there is no onward problem
relating to KDE and mariadb once installed, even if that install was done
with KDE and akonadi running at the time, I guess this thread can be
closed. I appreciate the replies.

Many thanks.


-- 
mike c

Re: [arch-general] Question about mariadb replacing mysql

[Mike Cloaked]

On Wed, Mar 27, 2013 at 9:45 AM, Paul Gideon Dann wrote:

> On Wednesday 27 Mar 2013 11:05:12 An Nguyen wrote:
> > Akonadi is using MySQL. You can disable Akonadi (personally I found it
> > useless).
> >
> > $ nano .config/akonadi/akonadiserverrc
> > StartServer=false
>
> Bear in mind that all things PIM rely on Akonadi; specifically, most of
> Kontact.


The question remains as to whether any action is necessary after moving
from mysql to mariadb for any user who is using Kontact and other KDE
components that rely on mariadb after the change?

Presumably there will be some people who know whether it will continue to
work or not without taking any specific action once mariadb is installed?

-- 
mike c

Re: [arch-general] Question about mariadb replacing mysql

[Mike Cloaked]

On Tue, Mar 26, 2013 at 3:07 PM, Paul Gideon Dann wrote:

>
> I also use KDE.  I went ahead with the switch.  I stopped akonadi first,
> though:
>
> # akonadictl stop
> 
> # akonadictl start
>
> And all seemed to go well.  I haven't done anything special for KDE when
> upgrading mysql before, so I don't think anything is required now.  I
> haven't
> noticed any issues.
>

Thank you - I had already done the mariadb install with akonadi running -
however I have just stopped and restarted it, and then checked with:
$ akonadictl status

there seemed not to be any problem so I guess restarting KDE or rebooting
would also be fine.


-- 
mike c

[arch-general] Question about mariadb replacing mysql

[Mike Cloaked]

With the move to mariadb I have the following situation:

I am not explicitely running mysqld so checking the status with systemctl
shows it is inactive.

However I am running KDE as my desktop.

After doing the suggested install after ensuring that mysqld is stopped:
pacman -S mariadb libmariadbclient mariadb-clients

and accepting the install of these packages with removal of mysql
equivalents, I then find that there is a private instance of mysql running
by the KDE desktop:

ps -eaf | egrep mysql
mike   660   657  0 Mar23 ?00:00:42 /usr/bin/mysqld
--defaults-file=/home/mike/.local/share/akonadi/mysql.conf
--datadir=/home/mike/.local/share/akonadi/db_data/
--socket=/home/mike/.local/share/akonadi/socket-home1/mysql.socket
mike  9747   761  0 13:39 pts/300:00:00 egrep mysql

So does any expert know whether a mysql_upgrade is necessary for KDE and if
so how does one go about doing that upgrade?

Thanks.

-- 
mike c

Re: [arch-general] Is last archboot iso completely busted ?

[Mike Cloaked]

On Tue, Mar 19, 2013 at 7:54 AM, fredbezies  wrote:

>
> So, this is why it doesn't work. I used autoprepare mode. I find GPT
> partitionning for UEFI to be a little complicated.
>
>
It is possible to use a live cd (or live usbkey) and run PartedMagic to do
partitioning before starting the arch install. That is pretty
straightforward to do, using the graphical parted facility once the livecd
is running. When selecting to write a partition table you just select the
GPT option from the pull down menu that is presented. Then you can choose
the new partitions and complete the partitioning before starting. My UEFI
system was done this way and works well.

-- 
mike c

Re: [arch-general] [arch-dev-public] BIND10? No, thanks.

[Mike Cloaked]

On Sat, Mar 9, 2013 at 9:37 PM, Mike Cloaked  wrote:

> having read up a little more about authoritative and caching/recursive
> namerservers - it seems that a good alternative to bind (which I use on all
> my machines especially as a local authoritative DNS server for local
> networking) would be to use nsd as the pure authoritative nameserver in
> combination with unbound as a recursive caching nameserver. Both are
> packages available in arch. Once installed both have systemd service files,
> and it seems that setting them up is not too difficult - and I already had
> ldns installed (presume from the base install) so I guess having those
> three packages running would give a pretty good alternative to
> bind/dnstools though it would be nice to know if anyone is already using
> these and could post on how well they perform?
>
> I have spent some time since I posted about the issue of dns servers to
research a little more on migrating from bind to nsd/unbound as the dns
server/resolver for my own local network.

It is useful to note that the CVE vulnerability records for both nsd and
unbound are very favourable:

http://www.cvedetails.com/product/17420/Nlnetlabs-NSD.html?vendor_id=9613
http://www.cvedetails.com/product/18208/Unbound-Unbound.html?vendor_id=10197

Secondly the process of migration turned out to be fairly straightforward
once several advice pages from the web were looked at and answers to
questions I had about specific points on configuring my own system were
available on the user lists for both packages at:

https://open.nlnetlabs.nl/pipermail/nsd-users/
https://unbound.nlnetlabs.nl/pipermail/unbound-users/

It may be of interest that the approach I took was to set up unbound
initially on a non-critical machine that was not my main server but within
the local network first. Making this a caching/recursive dns server that
forwarded dns requests for the local network to the main LAN dns server
running on another machine was achieved by setting it up to listen on port
53 using advice from the mailing list plus initial tutorial instructions
from:

https://calomel.org/unbound_dns.html

To make the changeover once the configs were ready, the config file was
tested using the unbound-checkconf command, and then was simply a matter of:
systemctl stop named
systemctl start unbound

I made sure that /etc/resolv.conf had the line:
nameserver 127.0.0.1
and then ran tests using the drill command pointing at the internal server
to check forward and reverse lookups.

Once that was done I installed nsd on the main server machine and followed
the tutorial at https://calomel.org/nsd_dns.html plus the mailing list, and
some other google searches with nsd set to listen on a high private port.
Config testing is simple with nsd-checkconf, and then the service can be
started with:

systemctl start nsd

Again testing is simple with commands such as drill @127.0.0.1 -p x
www.cnn.com for example with x being the private port on which nsd is
listening.

Once that is tested, and with bind still running at the same time, and
listening on port 53, then unbound can be setup to listen on port 53 but
with a local stub zone for local dns requests pointing to nsd on the
private port to complete the service for both internal and external
addresses.

Once ready to test, and with nsd already running then:
systemctl stop named
systemctl start unbound

will enable dns request tests to be run with commands starting drill @
127.0.0.1 sitename.com

Once the tests are all working then the named service can be disabled and
nsd and unbound enabled so that they will start at boot.

Naturally there are a multitude of different ways to set up dns servers to
suit individual requirements, but I hope that relating my own experience is
useful to others. I now have no bind services running and all the dns
requirements have been running for the past few days with nsd/unbound
without any problems at all.

For anyone planning on migrating from bind to nsd/unbound it is useful to
work on this ahead of the time when bind may no longer be a supported
package in arch - my own experience suggests that nsd/unbound are excellent
alternatives, and indeed more secure than a single server running all dns
services, as separating the authoritative dns server from the
caching/recursive server provides potentially added security.

-- 
mike c

Re: [arch-general] [arch-dev-public] BIND10? No, thanks.

[Mike Cloaked]

On Sat, Mar 9, 2013 at 8:44 PM, Mike Cloaked  wrote:

>
>>
>> Great. I was actually going to open a feature request for this on
>> flyspray.
>> The only thing: whouldn't one need community/unbound (unbound-host AFAIR)
>> to
>> replace nslookup?
>
>
> Do I interpret this as meaning that if dnstools and bind are removed from
> the arch repos, then ldns carries the tools as a replacement, but that
> "unbound" is a dependent package that would then be the authoritative
> resolver that replaces bind?  Or would it be that ldns would contain not
> only the dns tools (such as the replacement for dig etc), but also the full
> authoritative resolver merged into the code?
>
> Maybe I just don't understand the proposal here. Perhaps someone could
> clarify what the proposal means?
>
>
Apologies for replying to my own previous post, but having read up a little
more about authoritative and caching/recursive namerservers - it seems that
a good alternative to bind (which I use on all my machines especially as a
local authoritative DNS server for local networking) would be to use nsd as
the pure authoritative nameserver in combination with unbound as a
recursive caching nameserver. Both are packages available in arch. Once
installed both have systemd service files, and it seems that setting them
up is not too difficult - and I already had ldns installed (presume from
the base install) so I guess having those three packages running would give
a pretty good alternative to bind/dnstools though it would be nice to know
if anyone is already using these and could post on how well they perform?

-- 
mike c

Re: [arch-general] [arch-dev-public] BIND10? No, thanks.

[Mike Cloaked]

On Sat, Mar 9, 2013 at 7:00 PM, Leonid Isaev  wrote:

> On Sat, 9 Mar 2013 13:27:42 +1100
> Gaetan Bisson  wrote:
>
> > Hi guys,
> >
> > Currently we use the BIND code base in two packages:
> > - dnsutils from [core] provides basic DNS query tools;
> > - bind from [extra] is the actual name server.
> >
> > With the new BIND10 release, the ISC really outdid themselves: all
> > formerly standalone tools have been merged and rewritten as a python
> > script which uses bindings to the new libb10-* series of libraries that
> > are shared with the name server. Python being such a boring dependency,
> > they introduced another three: botan, log4cplus, and boost!
> >
> > That mostly means two things:
> > - We cannot keep splitting dnsutils and bind anymore.
> > - I do not want to maintain these packages any further.
> >
> > We already have ldns in [core], a much better written (and sane) DNS
> > library which includes query tools that are near drop-in replacements
> > for BIND's: use `drill` instead of `dig`, etc.
> >
> > So I suggest:
> > - Any package relying on dnsutils and its tools (dig, host, nslookup) be
> >   ported to use ldns instead - should be straightforward in most cases.
> > - We ditch dnsutils and bind out of our repos, unless somebody finds
> >   them fun and wants to maintain them in [extra] or [community].
> >
> > Comments or suggestions are welcome.
> >
> > Cheers.
> >
>
> Great. I was actually going to open a feature request for this on flyspray.
> The only thing: whouldn't one need community/unbound (unbound-host AFAIR)
> to
> replace nslookup?


Do I interpret this as meaning that if dnstools and bind are removed from
the arch repos, then ldns carries the tools as a replacement, but that
"unbound" is a dependent package that would then be the authoritative
resolver that replaces bind?  Or would it be that ldns would contain not
only the dns tools (such as the replacement for dig etc), but also the full
authoritative resolver merged into the code?

Maybe I just don't understand the proposal here. Perhaps someone could
clarify what the proposal means?

Thanks

-- 
mike c

Re: [arch-general] [arch-dev-public] BIND10? No, thanks.

[Mike Cloaked]

On Sat, Mar 9, 2013 at 2:51 PM, Genes Lists  wrote:

> On 03/08/2013 09:27 PM, Gaetan Bisson wrote:
>
>> Hi guys,
>>
>> Currently we use the BIND code base in two packages:
>> - dnsutils from [core] provides basic DNS query tools;
>> - bind from [extra] is the actual name server.
>>
> ...
>
>
>
>> We already have ldns in [core], a much better written (and sane) DNS
>> library which includes query tools that are near drop-in replacements
>> for BIND's: use `drill` instead of `dig`, etc.
>>
>>
>   Hi
>
>One observation - bind is the de facto standard and as far as I can
> tell used by the majority of the root servers [1] (and the majority of all
> major DNS servers according to wikipedia [2] and bind website [3] anyway
> :-)).
>
>We may want to be cautious stepping away from the dominant DNS
> software unless there is a sea change for the DNS community to do same.
>
>A casual look around [4] - so clearly I am not in the know here -
> but the rewrite seems not dissimilar to the postfix "re-write" of sendmail
> - modularity and security seemingly key goals. [5]
>
>
>Anyway, I'd encourage that we try and stick with bind.
>
> gene
>
> [1] 
> http://en.wikipedia.org/wiki/**Root_name_server
> [2] http://en.wikipedia.org/wiki/**BIND
> [3] 
> https://www.isc.org/wordpress/**software/bind10/
> [4] 
> http://bind10.isc.org/wiki/**DesignOverview
> [5] I am not familliar with ldns or it's benefits - security or other so I
> don't feel entitled to an opinion.
>


As a long standing bind user this raises some worries for me - maybe it is
simply unfamiliarity with ldns though...

Has there been any discussion about how ldns performs relative to bind -
particularly concerning security and simplicity of setting up as well as
functionality relative to the familiar way that bind has worked for many
years on many platforms?

Is there anyone on the list who has used ldns that can relate how well it
performs relative to bind?

-- 
mike c

Re: [arch-general] UEFI madness

[Mike Cloaked]

On Sat, Mar 2, 2013 at 2:25 PM, Maxime Gauduin  wrote:

>
> I have been succesfully using a GRUB2 based UEFI system for the past
> year, but it died on me a week ago. Didn't want to load any kernel
> anymore...
> I switched to refind and it works beautiffuly, just follow the wiki
> here: https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Using_rEFInd
> and set your ESP partition like Mike suggested.
> The tricky part is to boot the iso into efi mode, it complains about it
> having no loader config (at least for me). You can work around that if
> you already have refind on the ESP partition, if you don't, install it
> in EFI/Boot/ and name the efi file bootx64.efi (be sure that it scans
> externals, or optical if you're using a CD). You can then load refind by
> going into your EFI bios and choosing "Load EFI Shell" (note that not
> all EFI bioses have that option).
>

I followed the following to make a uefi bootable iso on a usbkey:

https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Create_UEFI_bootable_USB_from_ISO



-- 
mike c

Re: [arch-general] UEFI madness

[Mike Cloaked]

On Sat, Mar 2, 2013 at 9:26 AM, David Benfell wrote:

> On 03/02/2013 10:32 AM, Mike Cloaked wrote:
> >
> > which works really beautifully and needs no manual intervention when new
> > kernels arrive.  However it did take me some time with a lot of help from
> > Rod Smith to get it all set up correctly.
> >
> > Basic steps were:
> > 1) Format disks with GPT instead of MSDOS
> > 2) Make sure that there is a /boot/efi/EFI ESP which is formatted FAT32
> > 3) Since I also wanted /boot to contain initial ramdisk and kernel I had
> > /boot as a directory in my root (/) partition which is ext4.
> > 4) In order to get it to work I made sure that the rEFInd config files
> were
> > set up in the ESP as well as the required files in /boot (and including
> the
> > ext4 rEFInd driver files in the ESP so that rEFInd can read the initrd
> and
> > kernel files unde ext4 in /boot (and include the rEFInd driver files in
> > those directories also.
> > 5) In my system I found that the standard method to write the nvram
> entries
> > failed to work - so I had to boot to the efi shell from the arch install
> > iso on usbkey and write the nvram entries from the shell.
> >
> > If you want more details I can post more tomorrow.
> >
> > I hope this helps.
> >
> Of these, step 4 seems to me to be undocumented. And I'm assuming I
> don't need to worry about step 5 unless it bites me? How will I know?
>
> Thanks!
>

The thread on the forum where I got the information that led me to my
working system is at:

 https://bbs.archlinux.org/viewtopic.php?id=157119

This may help - you will see in that thread what led to me needing to use
the efi shell.

I hope this helps.



-- 
mike c

Re: [arch-general] UEFI madness

[Mike Cloaked]

On Sat, Mar 2, 2013 at 6:44 AM, David Benfell wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> So far, my attempt to install Arch Linux on a UEFI system is a total
> facepalm moment. The problem is in booting post-install.
>
> So, first, does anyone have actual--and successful--experience
> installing Arch on a UEFI system? Yes, I went to the Arch Wiki, which
> initially pointed me at GummiBoot. There are actually two sets of
> instructions, one given where I looked first, for the UEFI entry, and
> another under the entry for GummiBoot. Neither succeeds, but I wound up
> following the latter set of instructions (and cleaning up extra entries
> with efibootmgr, which fortunately makes this relatively easy).
>
> GummiBoot says it can't find /vmlinuz-linux. I tried modifying the
> configuration to say /boot/vmlinuz-linux, but no joy. Apparently, I'm
> really supposed to copy this file and the initrd image to the EFI
> partition, but nobody says where in the EFI partition, so I have no idea.
>
> I also tried following the instructions for grub-efi. I'm just
> mystified. I managed to install the right package, but from there I just
> wasn't understanding a thing. I've been using linux since 1999 so this
> shouldn't be so completely mystifying.
>
> I tried installing rEFInd (from sourceforge). As near as I can tell, it
> does indeed detect all the possible boot options on the system. But when
> I try booting the Arch installation, it says it can't find the root
> partition. It also detects the GummiBoot option, but that leads the same
> place as before. Finally, it detects the Windows option, which I hope
> still works (unfortunately I do need this).
>
> I guess getting something that just works--like it did with BIOS
> systems--is not in the cards. What do I do now?
>
> Thanks!
>
> I have a system that I installed a couple of weeks ago using rEFInd -
which works really beautifully and needs no manual intervention when new
kernels arrive.  However it did take me some time with a lot of help from
Rod Smith to get it all set up correctly.

Basic steps were:
1) Format disks with GPT instead of MSDOS
2) Make sure that there is a /boot/efi/EFI ESP which is formatted FAT32
3) Since I also wanted /boot to contain initial ramdisk and kernel I had
/boot as a directory in my root (/) partition which is ext4.
4) In order to get it to work I made sure that the rEFInd config files were
set up in the ESP as well as the required files in /boot (and including the
ext4 rEFInd driver files in the ESP so that rEFInd can read the initrd and
kernel files unde ext4 in /boot (and include the rEFInd driver files in
those directories also.
5) In my system I found that the standard method to write the nvram entries
failed to work - so I had to boot to the efi shell from the arch install
iso on usbkey and write the nvram entries from the shell.

If you want more details I can post more tomorrow.

I hope this helps.

-- 
mike c

Re: [arch-general] [SOLVED] pacman update with new mesa gives a failed update

[Mike Cloaked]

On Mon, Feb 25, 2013 at 9:13 PM, Ionut Biru  wrote:

>
> pacman -Qo /usr/lib/xorg/modules/dri/swrast_dri.so
> pacman -Qo /usr/lib/libGL.so.1
>
> --
> Ionuț
>
>
Thank you for fixing this in such a speedy way - much appreciated.

-- 
mike c

Re: [arch-general] pacman update with new mesa gives a failed update

[Mike Cloaked]

On Mon, Feb 25, 2013 at 9:29 PM, Mike Cloaked wrote:

> On Mon, Feb 25, 2013 at 9:13 PM, Ionut Biru  wrote:
>
>>
>> pacman -Qo /usr/lib/xorg/modules/dri/swrast_dri.so
>> pacman -Qo /usr/lib/libGL.so.1
>>
>> Thank you Ionut.  The conflicting files are owned by libgl 9.0.2-1 - but
> I am unsure whether this means that libgl needs to be removed before
> running the updates? Will mesa-libgl then replace the functionality that
> libgl currently provides?  I'd like to be sure before doing this so I don't
> do something that could cause my system graphics to fail. I did not see any
> announcement saying this was going to happen?
>
>
> OK I saw your post in arch-dev-public about removing libgl from extra, and
also that re-running the pacman update now also replaces libgl with
mesa-libgl - so this is resolved.

Thanks



-- 
mike c

Re: [arch-general] pacman update with new mesa gives a failed update

[Mike Cloaked]

On Mon, Feb 25, 2013 at 9:13 PM, Ionut Biru  wrote:

>
> pacman -Qo /usr/lib/xorg/modules/dri/swrast_dri.so
> pacman -Qo /usr/lib/libGL.so.1
>
> Thank you Ionut.  The conflicting files are owned by libgl 9.0.2-1 - but I
am unsure whether this means that libgl needs to be removed before running
the updates? Will mesa-libgl then replace the functionality that libgl
currently provides?  I'd like to be sure before doing this so I don't do
something that could cause my system graphics to fail. I did not see any
announcement saying this was going to happen?

Thanks


-- 
mike c

[arch-general] pacman update with new mesa gives a failed update

[Mike Cloaked]

I tried to update with pacman -Syu this evening (x86_64) - but the update
failed with:

Proceed with installation? [Y/n]
:: Retrieving packages from extra...
 mesa-9.1-2-x86_6431.4 MiB   651K/s
00:49 [###] 100%
 mesa-libgl-9.1-2-x86_64   2.2 KiB   622K/s
00:00 [###] 100%
 ati-dri-9.1-2-x86_64 32.8 MiB   692K/s
00:49 [###] 100%
 cairo-1.12.14-3-x86_64  671.8 KiB   748K/s
00:01 [###] 100%
 intel-dri-9.1-2-x86_64  328.8 KiB   739K/s
00:00 [###] 100%
 kdelibs3-3.5.10-16-x86_6413.6 MiB   750K/s
00:19 [###] 100%
 libx11-1.5.0-2-x86_64 2.0 MiB   673K/s
00:03 [###] 100%
 nouveau-dri-9.1-2-x86_64 15.4 MiB   752K/s
00:21 [###] 100%
 svga-dri-9.1-2-x86_64 9.9 MiB   744K/s
00:14 [###] 100%
(9/9) checking package integrity
   [###] 100%
(9/9) loading package files
  [###] 100%
(9/9) checking for file conflicts
  [###] 100%
error: failed to commit transaction (conflicting files)
mesa: /usr/lib/xorg/modules/dri/swrast_dri.so exists in filesystem
mesa-libgl: /usr/lib/libGL.so exists in filesystem
mesa-libgl: /usr/lib/libGL.so.1 exists in filesystem
mesa-libgl: /usr/lib/libGL.so.1.2.0 exists in filesystem
mesa-libgl: /usr/lib/xorg/modules/extensions/libglx.so exists in filesystem
Errors occurred, no packages were upgraded.

Can anyone advise if I need to do any manual changes before trying again?

Thank you.

-- 
mike c

Re: [arch-general] Samsung MFP (SCX-4500W) print OK - scanning fails.

[Mike Cloaked]

On Sat, Feb 23, 2013 at 9:57 AM, Mike Cloaked wrote:

> I have seen other reports from Fedora indicating that there are recent
> problems with scanners not working whereas previously they were working out
> of the box. In fact my scanner was working fine when it was connected to a
> Fedora 16 system until very recently - since I now exclusively use arch I
> need to have it working in arch as it is connected to my main machine. I
> will continue to search bug reports and then if I don't see any that are
> specific to my device I will file a bug, possibly upstream on the sane bug
> tracker.
>
>
I have filed a report at:  https://bugs.archlinux.org/task/33982


-- 
mike c

Re: [arch-general] Samsung MFP (SCX-4500W) print OK - scanning fails.

[Mike Cloaked]

On Fri, Feb 22, 2013 at 8:53 PM, Rodrigo Rivas
wrote:

>
>
> Well, it looks like your systemd services come from packages
> "system-config-printer" and "cups-pk-helper", and I have none installed.
> You can try disabling or uninstalling them and see if it makes any
> difference.
>
> Other than that, I'm out of ideas, sorry.
>

I tried removing system-config-printer but it made no difference - but
thinking about it the scanner operations should not be affected by the
print side of things. I also tried blacklisting the usblp module and that
also made no difference.

I am beginning to wonder if my problem is a bug in sane-backends - I have
been searching for bug reports and it is possible that reports such as this
one:

https://alioth.debian.org/tracker/index.php?func=detail&aid=314021&group_id=30186&atid=410366

may be related.

I have seen other reports from Fedora indicating that there are recent
problems with scanners not working whereas previously they were working out
of the box. In fact my scanner was working fine when it was connected to a
Fedora 16 system until very recently - since I now exclusively use arch I
need to have it working in arch as it is connected to my main machine. I
will continue to search bug reports and then if I don't see any that are
specific to my device I will file a bug, possibly upstream on the sane bug
tracker.

-- 
mike c

Re: [arch-general] Samsung MFP (SCX-4500W) print OK - scanning fails.

[Mike Cloaked]

On Fri, Feb 22, 2013 at 7:19 PM, Rodrigo Rivas
wrote:

>
>
> > Feb 22 10:35:04 home1 udev-configure-printer[2919]: add usb-001-006
> > Feb 22 10:35:04 home1 udev-configure-printer[2919]: device devpath is
> > /devices/pci:00/:0
> > Feb 22 10:35:04 home1 udev-configure-printer[2919]: Device already
> handled
> > Feb 22 10:35:04 home1 udev-configure-printer[2920]: add usb-001-004
> > Feb 22 10:35:04 home1 systemd[1]: Unit
> > configure-printer@usb-001-006.serviceentered failed stat
> > Feb 22 10:35:04 home1 udev-configure-printer[2920]: no device named
> > /dev/bus/usb/001/004 found
> > Feb 22 10:35:04 home1 systemd[1]: configure-printer@usb-001-004.service:
> > main process exited, co
> > Feb 22 10:35:04 home1 systemd[1]: Unit
> > configure-printer@usb-001-004.serviceentered failed stat
> >
> > So clearly I am missing something in the configs somewhere - but I don't
> > know where to look next?
> >
>
>
> That's weird... I don't have any of these. No udev-configure-printer,
> configure-printer@.service... nothing like that. Where did all of these
> come from?
>
> Other than that, I have the more or less standard configuration for the
> printer in cups, but that should not make much of a difference.
>
> A quick test... you are  member of the `lp` group, aren't you?
>
> Another one... something strange in `dmesg`?
>

Yes I am a member of both lp and scanner groups.  The lines in messages.log
are for example:

Feb 22 19:39:26 localhost kernel: [32142.463787] usblp 3-4:1.1: usblp0: USB
Bidirectional printe
r dev 8 if 1 alt 0 proto 2 vid 0x04E8 pid 0x342B
Feb 22 19:39:26 localhost colord: Device added:
sysfs-Samsung_Electronics_Co.__Ltd.-SCX-4500W_Se
ries
Feb 22 19:39:26 localhost systemd[1]: Starting Printer.
Feb 22 19:39:26 localhost systemd[1]: Reached target Printer.
Feb 22 19:39:26 localhost systemd[1]: Starting Configure Plugged-In
Printer...
Feb 22 19:39:27 localhost systemd[1]: Started Configure Plugged-In Printer.
Feb 22 19:39:27 localhost systemd[1]: configure-printer@usb-003-008.service:
main process exited
, code=exited, status=1/FAILURE
Feb 22 19:39:27 localhost systemd[1]: Unit
configure-printer@usb-003-008.service entered failed
state

I am wondering now whether this is a problem with a systemd service file
possibly?  The printer part works. Just the scanner that doesnt.
By the way there is a bug in cups awaiting the version 1.6.2 which I
"fixed" by removing the offending line in cupsd.conf as per:

https://bugs.archlinux.org/task/32768

I also tried with and without the file in /etc/udev/70-libsane.rules
containing:
ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="342b", MODE="0660",
GROUP="scanner",  ENV{libsane_matched}="yes"

Behaves the same with that included or not.

-- 
mike c

Re: [arch-general] Samsung MFP (SCX-4500W) print OK - scanning fails.

[Mike Cloaked]

On Thu, Feb 21, 2013 at 10:32 PM, Rodrigo Rivas  wrote:

> On Thu, Feb 21, 2013 at 9:17 PM, Mike Cloaked  >wrote:
>
> > I am stuck on the configuration of the scanner functionality for a
> Samsung
> > SCX-4500W multifunction printer/scanner.
> >
> > I can get the printing function of this printer to work by the following
> > steps:
> >
> > 1) Add a line to /etc/udev/rules.d/70-usbprinter.rules containing:
> > ATTR{idVendor}=="04e8", ATTR{idProduct}=="342b", MODE:="0660",
> GROUP:="lp"
> >
> >
> I have a SCX-4200 MFP, quite similar to yours, and this is my udev rule:
>
> ATTR{idVendor}=="04e8", ATTR{idProduct}=="341b", MODE:="0660", GROUP:="lp",
> ENV{libsane_matched}:="yes"
>
> The product is different, obviously, but note the added environment
> variable. I cannot remember why I put it there, but hey! there it is, and
> it works.
>
> $ scanimage -L
> device `xerox_mfp:libusb:002:002' is a SAMSUNG ORION multi-function
> peripheral
>
>
Thanks Rodrigo,

I tried adding in the additional environment variable and rebooted the
machine - when I do:
 $ scanimage -L
device `xerox_mfp:libusb:001:006' is a Samsung Samsung SCX-4500W Series
multi-function peripheral

But if I do it again then:

scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).

So it is still not working - when I went to the GIMP and tried to create a
scan it hung GIMP after not finding any scanner devices.

Plus journalctl -xn has:
Plus journalctl:
Feb 22 10:35:04 home1 systemd[1]: configure-printer@usb-001-006.service:
main process exited, co
Feb 22 10:35:04 home1 colord[365]: Device added:
sysfs-Samsung_Electronics_Co.__Ltd.-SCX-4500W_S
Feb 22 10:35:04 home1 udev-configure-printer[2919]: add usb-001-006
Feb 22 10:35:04 home1 udev-configure-printer[2919]: device devpath is
/devices/pci:00/:0
Feb 22 10:35:04 home1 udev-configure-printer[2919]: Device already handled
Feb 22 10:35:04 home1 udev-configure-printer[2920]: add usb-001-004
Feb 22 10:35:04 home1 systemd[1]: Unit
configure-printer@usb-001-006.serviceentered failed stat
Feb 22 10:35:04 home1 udev-configure-printer[2920]: no device named
/dev/bus/usb/001/004 found
Feb 22 10:35:04 home1 systemd[1]: configure-printer@usb-001-004.service:
main process exited, co
Feb 22 10:35:04 home1 systemd[1]: Unit
configure-printer@usb-001-004.serviceentered failed stat

So clearly I am missing something in the configs somewhere - but I don't
know where to look next?


-- 
mike c

[arch-general] Samsung MFP (SCX-4500W) print OK - scanning fails.

[Mike Cloaked]

I am stuck on the configuration of the scanner functionality for a Samsung
SCX-4500W multifunction printer/scanner.

I can get the printing function of this printer to work by the following
steps:

1) Add a line to /etc/udev/rules.d/70-usbprinter.rules containing:
ATTR{idVendor}=="04e8", ATTR{idProduct}=="342b", MODE:="0660", GROUP:="lp"

2) Making sure that I have the splix driver package installed I can define
a usb connected printer with the splix driver which works very well indeed.
I have cups and avahi installed and enable cups.socket and avahi-daemon.

When I try to get the scanner working I can get a sensible output from:

# sane-find-scanner

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure
that
  # you have loaded a kernel SCSI driver for your SCSI adapter.
  # Also you need support for SCSI Generic (sg) in your operating system.
  # If using Linux, try "modprobe sg".

found USB scanner (vendor=0x04e8 [Samsung Electronics Co., Ltd.],
product=0x342b [SCX-4500W Series]) at libusb:003:006
  # Your USB scanner was (probably) detected. It may or may not be
supported by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.

So the scanner seems to be detected - but when I do:

# scanimage -L

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).

If I try to create a scan via GIMP it hangs the GIMP and I have to kill it.

I tried to add a line to 75-sane.rules in /etc/udev/rules.d/ with:
ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="342b", MODE="0660",
GROUP="scanner",  ENV{libsane_matched}="yes"

But this did not work.

Can anyone suggest how to get the scanner part working?

Thanks for any help.
-- 
mike c

Re: [arch-general] A question about handling a system with two wired network interfaces?

[Mike Cloaked]

On Thu, Feb 21, 2013 at 12:46 AM, Tom Gundersen  wrote:

>
> I mentioned your problems to the systemd guys, and they would like to
> know more. If you don't mind, could you post "lspci -vvv"?
>
> I wasn't sure if I could attach a file so here is the output inline:

 [mike@home1 dual-nic]$ cat lspci.txt
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor DRAM Controller (rev 09)
Subsystem: Intel Corporation Device 2036
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR- 

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd
Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Intel Corporation Device 2036
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR-  [disabled]
Capabilities: 
Kernel driver in use: i915

00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI])
Subsystem: Intel Corporation Device 2036
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- 
Kernel driver in use: xhci_hcd

00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series
Chipset Family MEI Controller #1 (rev 04)
Subsystem: Intel Corporation Device 2036
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
Kernel driver in use: mei

00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series Chipset
Family KT Controller (rev 04) (prog-if 02 [16550])
Subsystem: Intel Corporation Device 2036
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR- 
Kernel driver in use: serial

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network
Connection (rev 04)
Subsystem: Intel Corporation Device 2036
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
Kernel driver in use: e1000e

00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI])
Subsystem: Intel Corporation Device 2036
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- 
Kernel driver in use: ehci_hcd

00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family
High Definition Audio Controller (rev 04)
Subsystem: Intel Corporation Device 2036
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family
PCI Express Root Port 1 (rev c4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family
PCI Express Root Port 7 (rev c4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI])
Subsystem: Intel Corporation Device 2036
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- 
Kernel driver in use: ehci_hcd

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4) (prog-if 01
[Subtractive decode])
Control: I/O+ Mem+ BusMaster+ Spec

Re: [arch-general] A question about handling a system with two wired network interfaces?

[Mike Cloaked]

On Wed, Feb 20, 2013 at 9:05 AM, Mike Cloaked wrote:

>
>>
> I will try to fiddle with the service files and get it to work - but
> clearly at the moment it is non-ideal as this is a server and a remote
> reboot would currently leave it without a working network connection!
>
>
I have finally found a solution that works well for me - I simply did
"systemctl enable NetworkManager-wait-online" and rebooted - the dhcpd4 and
named services are now running correctly after the system boots - so the
dhcpd4 service does indeed get held until the network is properly up so I
now have a system working as it should and therefore this particular issue
is resolved.

systemd-analyze shows a boot time of 8.7 seconds so there is no significant
delay by enabling NetworkManager-wait-online service.

-- 
mike c

Re: [arch-general] A question about handling a system with two wired network interfaces?

[Mike Cloaked]

On Tue, Feb 19, 2013 at 10:00 PM, Tom Gundersen  wrote:

> Hi Mike,
>
> Lots of stuff going on, so sorry for not answering inline.
>
>  * It looks like NetworkManager and dhcpd are stepping on eachother's
> toes. Maybe you want to disable dhcpd and only use NM?
>

I am confused here - I am running dhcpd as a server not a client - I didn't
realise NM could act as a DHCP server?


>
> * Any service that cannot deal with network devices appearing or being
> rename after it is started (is broken and) should have the
> After/Wants=systemd-udev-settle.service lines you pasted above. Note
> that this is not a perfect solution, as udev never knows exactly how
> long to wait for all the network devices, but it is the best we can do
> and gives the same behavior as we had pre-systemd.
>

Perhaps I should file a bug about this - particularly with dhcpd?

>
>  * I never used the dhcpd4 (only ever used dhcpcd), but in principle
> the correct solution should be to make it one instance per network
> device (i.e., create an dhcpd4@.service similar to dhcpcd@.service
> from the dhcpcd package). This would make sure it is only started
> after the relevant network device appears (and have been given its
> final name), and it should also make dhpcd itself happy (as it seems
> to not like being called without a specific interface judging from
> your logs).
>

I will try to fiddle with the service files and get it to work - but
clearly at the moment it is non-ideal as this is a server and a remote
reboot would currently leave it without a working network connection!


-- 
mike c

Re: [arch-general] A question about handling a system with two wired network interfaces?

[Mike Cloaked]

On Tue, Feb 19, 2013 at 9:27 PM, Mike Cloaked wrote:

>
>
> So the dhcpd4 service is fast compared to the NetworkManager service.
>
> I know this discussion is now about the incorrect start of dhcpd4 - I can
move this to a new topic title if necessary.

However I looked at journalctl for the lines when dhcpd4 fails at boot and
they are:

 Feb 19 21:37:01 home1 dhcpd[327]:
Feb 19 21:37:01 home1 dhcpd[327]: Not configured to listen on any
interfaces!
Feb 19 21:37:01 home1 dhcpd[327]:
Feb 19 21:37:01 home1 dhcpd[327]: If you did not get this software from
ftp.isc.org, please
Feb 19 21:37:01 home1 dhcpd[327]: get the latest from ftp.isc.org and
install that before
Feb 19 21:37:01 home1 dhcpd[327]: requesting help.
Feb 19 21:37:01 home1 dhcpd[327]:
Feb 19 21:37:01 home1 dhcpd[327]: If you did get this software from
ftp.isc.org and have not
Feb 19 21:37:01 home1 dhcpd[327]: yet read the README, please read it
before requesting help.
Feb 19 21:37:01 home1 dhcpd[327]: If you intend to request help from the
dhcp-ser...@isc.org
Feb 19 21:37:01 home1 dhcpd[327]: mailing list, please read the section on
the README about
Feb 19 21:37:01 home1 NetworkManager[318]:  (eno1): preparing device.
Feb 19 21:37:01 home1 NetworkManager[318]:  (eno1): deactivating
device (reason 'managed') [2]
Feb 19 21:37:01 home1 NetworkManager[318]:  failed to allocate link
cache: (-10) Operation not supported
Feb 19 21:37:01 home1 NetworkManager[318]:  (eno2): carrier is OFF
Feb 19 21:37:01 home1 NetworkManager[318]:  (eno2): new Ethernet
device (driver: 'e1000e' ifindex: 3)
Feb 19 21:37:01 home1 NetworkManager[318]:  (eno2): exported as
/org/freedesktop/NetworkManager/Devices/1
Feb 19 21:37:01 home1 dhcpd[327]: submitting bug reports and requests for
help.
Feb 19 21:37:01 home1 NetworkManager[318]:  (eno2): now managed
Feb 19 21:37:01 home1 dhcpd[327]:
Feb 19 21:37:01 home1 NetworkManager[318]:  (eno2): device state
change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Feb 19 21:37:01 home1 dhcpd[327]: Please do not under any circumstances
send requests for
Feb 19 21:37:01 home1 NetworkManager[318]:  (eno2): bringing up
device.
Feb 19 21:37:01 home1 dhcpd[327]: help directly to the authors of this
software - please
Feb 19 21:37:01 home1 dhcpd[327]: send them to the appropriate mailing list
as described in
Feb 19 21:37:01 home1 dhcpd[327]: the README file.
Feb 19 21:37:01 home1 dhcpd[327]:
Feb 19 21:37:01 home1 dhcpd[327]: exiting.
Feb 19 21:37:01 home1 kernel: e1000e :00:19.0: irq 42 for MSI/MSI-X
Feb 19 21:37:01 home1 systemd[1]: dhcpd4.service: control process exited,
code=exited status=1
Feb 19 21:37:01 home1 kernel: IPv6: ADDRCONF(NETDEV_UP): eno1: link is not
ready
Feb 19 21:37:01 home1 systemd[1]: Failed to start IPv4 DHCP server.
Feb 19 21:37:01 home1 systemd[1]: Unit dhcpd4.service entered failed state

then when I restart it manually after boot it gives line:
Feb 19 21:38:59 home1 systemd[1]: Starting IPv4 DHCP server...
Feb 19 21:38:59 home1 dhcpd[776]: Wrote 0 deleted host decls to leases file.
Feb 19 21:38:59 home1 dhcpd[776]: Wrote 0 new dynamic host decls to leases
file.
Feb 19 21:38:59 home1 dhcpd[776]: Wrote 1 leases to leases file.
Feb 19 21:38:59 home1 systemd[1]: Started IPv4 DHCP server.



-- 
mike c

Re: [arch-general] A question about handling a system with two wired network interfaces?

[Mike Cloaked]

On Tue, Feb 19, 2013 at 9:03 PM, Mike Cloaked wrote:

>
>> I will check which of the two is enabled - but I have since my last post
> now switched on dhcpd (server) and named services - after boot the dhcpd
> service had entered a failed state and I am now wondering if I need to add
> the  systemd-udev-settle.service lines in the service file for dhcpd as
> well?
>
>
To add to the information about the named and dhcpd services - I just
double checked after posting the previous reply - and although the named
service "appears" to be running normally the dhcpd4 service is failed
immediately after boot - and the DNS lookups don't work - however after the
system is booted then doing the following in the order show gets the system
working fine.

systemctl restart dhcpd4
systemctl restart named

Once that is done then both dns and dhcp server services are operating
correctly - however I then have to log out of KDE and back in again as for
example my weather applet within the KDE desktop won't restart until I have
correctly got dhcpd4 and named restarted, and then logged out and back in.

So I guess there are timing dependency issues for these two services as
well.

I would value any advice on a work around for this so that everything is
working without manual intervention once the boot is complete. If it is any
help the boot analysis gives:

[root@home1 ~]# systemd-analyze blame
  3023ms systemd-udev-settle.service
   576ms postfix.service
   139ms systemd-remount-fs.service
   138ms NetworkManager.service
   126ms tmp.mount
   113ms sys-kernel-debug.mount
   100ms dev-hugepages.mount
90ms systemd-udevd.service
87ms sys-kernel-config.mount
79ms systemd-udev-trigger.service
77ms dev-mqueue.mount
66ms boot-efi.mount
63ms iptables.service
57ms systemd-logind.service
45ms var-spool-mail.mount
36ms systemd-vconsole-setup.service
35ms udisks2.service
35ms polkit.service
31ms opt.mount
27ms chrony.service
24ms systemd-tmpfiles-setup.service
23ms dhcpd4.service
23ms systemd-sysctl.service
13ms rtkit-daemon.service
 9ms systemd-user-sessions.service
 8ms upower.service
 1ms home.mount

So the dhcpd4 service is fast compared to the NetworkManager service.

Thanks in advance.

Mike
-- 
mike c

Re: [arch-general] A question about handling a system with two wired network interfaces?

[Mike Cloaked]

On Tue, Feb 19, 2013 at 4:33 PM, Tom Gundersen  wrote:
Just to be clear: the problem is still occurring (I am confused by

> "until recently")? Was it brought on by the recent udev naming change,
> or is it a long-standing problem?
>

This is a new system that was installed very recently using the February
archiso. So I have no past history of the problem - only current experience.

What you are seeing is that udev is able to reliably name one of your

> devices (eno1), which (unless you add any custom rules) will always
> refer to the same network port between reboots (in particular, it
> refers to the first on-board network device). However, the other
> device udev is not able to reliably name, so it leaves it alone. This
> explains why it still has a name in the kernel namespace (ethX), and
> why it alternates between eth0 and eth1.
>

Thank you for that explanation - it certainly helps to understand what is
going on.


> >
> > I specify that udev fix the two interface names as eno1 and eno2
>
> It is probably better to use different names than the enoX ones
> (though not strictly speaking necessary) if you specify them using
> your custom scheme (as outlined in the wiki article you link to). The
> reason is that the enoX names have a specific meaning (they are the
> on-board devices in the order given by the hardware).
>
> Currently, udev will not give out stable interface names based on mac
> addresses even though it can. To overcome this, you could put this
> into /etc/udev/rules/80-net-name-slot.rules:
>
>   ACTION=="remove", GOTO="net_name_slot_end"
>   SUBSYSTEM!="net", GOTO="net_name_slot_end"
>   NAME!="", GOTO="net_name_slot_end"
>
>   NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}"
>   NAME=="", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}"
>   NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}"
>   NAME=="", ENV{ID_NET_NAME_MAC}!="", NAME="$env{ID_NET_NAME_MAC}"
>
>   LABEL="net_name_slot_end"
>
>
> That should, if the MAC address is reliable, name your ethX device as
> something like "enx98fe023fa538". Note, however, that udev will try to
> first ascertain if the MAC address can be trusted (for instance, some
> machines will randomly assign the MAC at every boot), so if this does
> not work for you it (probably) means that udev decided not to trust
> the MAC address so did not export the name.
>

The MAC addresses seem to be consistent - and the udev rule does seem to
make it boot consistently once I had done that in combination with the
systemd-udev-settle.service lines in the service file.

ct name associated with the
> > same hardware mac address every boot?
> >
> > If someone who understands these things in detail could confirm if my
> > understanding is correct I would appreciate it?
>
> There has been some bugs where network software grab the device before
> udev can rename it, which could be solved with the workaround you
> reference above. However, I doubt this to be the case with
> NetworkManager, as far as I know it is only a problem with
> dhcpcd.service (but dhcpcd@.service works
> correctly).
>
> I will check which of the two is enabled - but I have since my last post
now switched on dhcpd (server) and named services - after boot the dhcpd
service had entered a failed state and I am now wondering if I need to add
the  systemd-udev-settle.service lines in the service file for dhcpd as
well?

Thanks

-- 
mike c

[arch-general] A question about handling a system with two wired network interfaces?

[Mike Cloaked]

I have a system with two ethernet sockets on the motherboard, and I have
until very recently been finding that my network at random failed to come
up during the boot process.

I have the ethernet cable plugged into only one of the two sockets, and
assign the names to the interfaces as eno1 and eno2 - because left to its
own it assigned one of them as name "eno1" and the other to "eth0" or
"eth1" at random between boots! I was surprised that it chose ethX at all
for the second name, given this is running with the new naming scheme!

However following the hints at:

https://wiki.archlinux.org/index.php/Udev#Network_device

I specify that udev fix the two interface names as eno1 and eno2 - but
still the network failed to come up sometimes at boot. It seemed to be pure
chance as to whether it came up on any particular boot. I tried both
NetworkManager as well as ifplugd/netcfg and both seemed to behave the same
way - at any one time I only had one or other scheme for getting the
network up.

What I then presumed was that although the same two names are always
assigned, the hardware mac address to which of the two physical network
ports was being assigned was being assigned differently to the two names -
i.e. sometimes being en01 and sometimes being eno2.  Why this matters is
that I assign a static ip address to eno1 only and don't use eno2. This
would only be an issue if there was more than one NIC in the system.

The system boots really fast as it has SSD drives, which possibly was not
allowing enough time for the name assignment, so I then found the advice at:

https://wiki.archlinux.org/index.php/Rename_network_interfaces

where it suggests editing the systemd unit file for in my case
NetworkManager service - which I then did and this finally seems to have
fixed the problem though I will still need to boot over a period of days to
check if the network comes up "every" time now. The wiki page refers to the
network service file, but I applied this to the NetworkManager service file.

So the question that I hope someone can answer is whether in the case of
multiple NICs in a system the new network names, although the same "set" of
names is used for all the cards in the system, will still need this systemd
unit file amendment - i.e. adding the two lines:

Requires=systemd-udev-settle.service
 After=systemd-udev-settle.service

to the [unit] section in order to get the correct name associated with the
same hardware mac address every boot?

If someone who understands these things in detail could confirm if my
understanding is correct I would appreciate it?

Many thanks.

-- 
mike c

Re: [arch-general] HDMI Alsa sound problem from flashplayer 64 bit

[Mike Cloaked]

On Fri, Feb 8, 2013 at 12:57 PM, Cédric Girard wrote:

> On Thu, Feb 7, 2013 at 11:12 PM, Mike Cloaked  wrote:
> >
> > So presumably I need to set this into either ~/.sound or /etc/alsa.conf
> and
> > try to test from a text console as:
> >
> > aplay -D /usr/share/sounds/alsa/Front_Center.wav
> >
> > and if that works then the default channel will have been set as the HDMI
> > channel and then switch back to trying from KDE ?
>
> That's right.
> Put this in your ~/.asoundrc:
>
> pcm.!default {
>   type hw
>   card 0
>   device 7
> }
>
> And "aplay  /usr/share/sounds/alsa/Front_Center.wav" should work (without
> -D because you do not want to specify the device).
>
> Once this is secure, fire KDE, update your kmix conf to use the default
> device and everything should work.
>
> What is happening is that flash use your default sound device, bypassing
> kmix. This is why you need to put your HDMI as default.
>
> Thank you  Cédric - I have it working now.


-- 
mike c

[arch-general] [SOLVED] HDMI Alsa sound problem from flashplayer 64 bit

[Mike Cloaked]

I promised I would post when I had this hdmi sound problem resolved - after
a while spent trying to sort this out today I have now it working, and it
may be useful to list the details in case anyone else has had a similar
issue getting sound from flashplayer videos running in the chrome browser.

I installed pulseaudio along with three other packages:


# pacman -S pulseaudio paprefs pavucontrol pulseaudio-alsa

 I also noticed that I needed one of the gstreamer plugin packages that I
had inadvertently missed when I had previously installed the initial set of
packages via a simple script.

# pacman -S gstreamer0.10-good-plugins

It is possible that my failure to get things working with alsa alone may
have been due to not having this package installed before. However once the
following settings had been put in place all sound now works properly and
well:

>From the KDE desktop, In Kmix under Audio Hardware setup:
  selected: Builtin audio Sound Card, with:
  Profile - Digital Stereo (HDMI) Output + Analogue Stereo Input

 and under Device configuration selected:
 Playback (Builtin Audio Digital Stereo (HDMI)) with Connector
HDMI/Displayport.

Then under Device preference chose Builtin Audio Digital Stereo (HDMI) for
all the output types.

Sound works now on all applications including from flashplayer video with
audio within the chrome browser.

It is entirely possible that if I had installed
the gstreamer0.10-good-plugins package at the outset that there may not
have been a problem at all and therefore this may have been just as much an
issue with all sound connections.

Thank you for the replies to my original post and for suggesting that I
change from alsa to pulseaudio. The controls both in pavucontrol and the
now changed controls in kmix with pulseaudio are better than with alsa.

-- 
mike c

Re: [arch-general] HDMI Alsa sound problem from flashplayer 64 bit

[Mike Cloaked]

On Thu, Feb 7, 2013 at 11:35 PM, LANGLOIS Olivier PIS -EXT <
olivier.pis.langl...@transport.alstom.com> wrote:

>
> Mike,
>
> I cannot think what would stop you from running a browser without any DE
> or WM. Just edit your ~/.xinitrc.
>
> Just add firefox to it.
>
> then
>
> startx
>
> It will run fullscreen with no title bar and the usual window frame.
>
> man xinit
>
> if you want to know a little bit the role of .xinitrc file in relation
> with the X server execution scope.


Thank you for this tip about running a browser without a D.E. - despite a
decade running linux this issue concerning setting up sound is a hole in my
knowledge which I need to do some learning on.

Following the suggestions in your post plus the previous replies to my
question I will now go and work on this. In the past I have never had any
sound issues and the defaults have always just worked without adjustment
(in recent years at least). The machine I have the issue with is rather
new, and this is the first time I have needed to work with HDMI sound. Once
I get things working I will post what works with this system.  I guess that
as time passes more people will have monitors connected with HDMI and
Displayport and perhaps move away from having sound via the analogue sound
port which is what I have always done until now.

-- 
mike c

Re: [arch-general] HDMI Alsa sound problem from flashplayer 64 bit

[Mike Cloaked]

On Thu, Feb 7, 2013 at 2:47 PM, Cédric Girard wrote:

> On Thu, Feb 7, 2013 at 12:25 PM, phanisvara das wrote:
>
> > since he's using KDE anyway, why not use pulseaudio instead? it's
> > the default for the big DEs, and in my experience it doesn't screw
> > up one's system anymore, as it used to in the beginning.
> >
> > mostly, at least for me, it simply works. specially if you install
> > pavucontrol, an interface for all  hard- and software audio
> > channelsl on your machine.
> >
>
> Yes probably.
> But as he is not using pulseaudio and I have no experience with it, I was
> only speaking of what I know and what works for me.
>
> I am not sure if adding an extra layer which happens to bring new useful
> features is always the best solution to a problem.
>
> Anyway Mike has now two solutions to try, either with or without PA. What
> works for him and fits him at the end of the day is only what should
> matter.
>
> Regards,
>
> I was unsure what was meant by trying to set up without KDE in the way?  I
presumed that I could only run the chrome browser within a D.E. in order to
test the problem of flashplayer running a video with sound output? It was
not clear to me how to do that unless I had a different D.E. running (i.e.
not KDE) or window manager within which to test it? Presumably I can't test
from a text console, or can I? - apart from the command which works from a
Konsole terminal within KDE as I originally posted:

aplay -D plughw:0,7 /usr/share/sounds/alsa/Front_Center.wav

So presumably I need to set this into either ~/.sound or /etc/alsa.conf and
try to test from a text console as:

aplay -D /usr/share/sounds/alsa/Front_Center.wav

and if that works then the default channel will have been set as the HDMI
channel and then switch back to trying from KDE ?

Certainly if I can't get that to work as a solution and re-enable KDE then
of course I can follow the wiki advice on setting up pulseaudio and testing
that route for a possible solution. I will report back on how I get a
working solution if that will help others with this kind of problem. As I
said in my original post I can get sound output for everything else except
flash output from the browser.

Anyway thank you for the suggestions which I will follow up.

-- 
mike c

Re: [arch-general] HDMI Alsa sound problem from flashplayer 64 bit

[Mike Cloaked]

On Thu, Feb 7, 2013 at 9:16 AM, Cédric Girard wrote:

> On Wed, Feb 6, 2013 at 7:48 PM, Mike Cloaked wrote:
>
> > Also I can get sound coming out of the monitor speakers with:
> >
> > aplay -D plughw:0,7 /usr/share/sounds/alsa/Front_Center.wav
> >
> > However if I run chrome and play a flash video the video I can see fine -
> > but there is no sound.
> >
> > I have read all the available arch wiki articles about hdmi sound
> including
> > that at
> >
> >
> https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#HDMI_Output_Does_Not_Workbut
> > as soon as I make a ~/.asound file with either of the suggested
> > contents KDE immediately tells me that the hdmi sound for that output has
> > been selected to be removed and offers me to make that permanent!
> >
>
> I would suggest first to try without KDE on the way.
> The solution provided on the wiki should definitively work. In your case,
> the device number should be 7.
> Once setup, make new tests with speaker-test or aplay, without setting the
> device you want to use (what you try to do is to setup your hdmi device to
> be the default).
> Then, only, add KDE on the top. You will probably need to reconfigure kmix
> as your devices have changed.
>
>
> I have already used kmix to select the 0,7 HDMI device and all channels
work as expected in the test from kmix within KDE.  I think the problem
stems from the alsa default going to a different output channel and I could
not fathom out from the wiki how to change alsa to use the correct channel
apart from the suggestion to add a few lines to ~/.asound but when I used
either of the two suggested sets of contents for that file then KDE became
unhappy - so if there is a way to get alsa to default to the hdmi output
channel (0,7) in a different way then that would likely give me a working
solution.  It "should" be possible but I don't know enough about the
intricacies of alsa to know how to do it - and it seems the wiki does not
contain enough info for me to work towards that (or I am too stupid to
understand the wiki!)

I could try pulseaudio - and if I can't get a solution with pure alsa then
I will go that route - I have used pavucontrol in the past to run sound -
but it is still a challenge to solve this within alsa - and it "should"
surely be possible?

-- 
mike c

Re: [arch-general] HDMI Alsa sound problem from flashplayer 64 bit

[Mike Cloaked]

Yes I guess that is worth a shot! Thanks.


On Thu, Feb 7, 2013 at 8:57 AM, Thomas Bächler  wrote:

> Am 06.02.2013 19:48, schrieb Mike Cloaked:
> > I have a machine which has an HDMI monitor and which has sound coming
> > through the monitor via HDMI just fine when playing music from Amarok and
> > login system sounds play fine too.  I had selected the appropriate hdmi
> > channel in kmix for all the available audio playback devices.
>
> Short story: Use pulseaudio, not alsa - you can then configure (default)
> outputs on the fly for all applications.
>
>
>


-- 
mike c

[arch-general] HDMI Alsa sound problem from flashplayer 64 bit

[Mike Cloaked]

I have a machine which has an HDMI monitor and which has sound coming
through the monitor via HDMI just fine when playing music from Amarok and
login system sounds play fine too.  I had selected the appropriate hdmi
channel in kmix for all the available audio playback devices.

Also I can get sound coming out of the monitor speakers with:

aplay -D plughw:0,7 /usr/share/sounds/alsa/Front_Center.wav

However if I run chrome and play a flash video the video I can see fine -
but there is no sound.

I have read all the available arch wiki articles about hdmi sound including
that at
https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#HDMI_Output_Does_Not_Workbut
as soon as I make a ~/.asound file with either of the suggested
contents KDE immediately tells me that the hdmi sound for that output has
been selected to be removed and offers me to make that permanent!

This is for an x86_64 arch system all up to date - and I have flashplayer
installed.

Can anyone guide me as to where to look for a solution that will get this
particular system playing sound from flash content on web pages in chrome?

I have several other (non-hdmi) systems which have no problem with sound
from web pages playing flash content.

Thanks

-- 
mike c

Re: [arch-general] efi boot kernel file sync - is it still necessary for refind?

[Mike Cloaked]

On Mon, Jan 28, 2013 at 9:10 PM, Mike Cloaked wrote:

> According to
> https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Sync_EFISTUB_Kernel_in_UEFISYS_partition_using_Systemd
>
> The recent (and current) version of refind-efi auto-detects efi kernels in
> /boot and that wiki article says that it is no longer necessary to sync
> files from /boot/ to /boot/efi/EFI/arch/
>
> Does that mean when first installing arch in a uefi system then it is also
> no longer necessary to copy the vmlinuz and initramfs files to the EFI
> /arch/ directory at all? Or is it necessary only once as indicated in the
> wiki? i.e. is the wiki fully up to date?
>
> Thanks.
>
> Secondly does the Beginners Guide at
https://wiki.archlinux.org/index.php/Beginners%27_Guide need the section on
"Efistub" updating to reflect the same change for using refind-efi?



-- 
mike c

[arch-general] efi boot kernel file sync - is it still necessary for refind?

[Mike Cloaked]

According to
https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Sync_EFISTUB_Kernel_in_UEFISYS_partition_using_Systemd

The recent (and current) version of refind-efi auto-detects efi kernels in
/boot and that wiki article says that it is no longer necessary to sync
files from /boot/ to /boot/efi/EFI/arch/

Does that mean when first installing arch in a uefi system then it is also
no longer necessary to copy the vmlinuz and initramfs files to the EFI
/arch/ directory at all? Or is it necessary only once as indicated in the
wiki? i.e. is the wiki fully up to date?

Thanks.

-- 
mike c

Re: [arch-general] Help with making a bootable usbkey from arch for ssd drive firmware update - RESOLVED

[Mike Cloaked]

On Tue, Jan 15, 2013 at 9:57 PM, Mike Cloaked wrote:

> If anyone can help or suggest links to solve the following problem I would
> appreciate it.
>
> I have a new system built with an Intel DQ77KB motherboard with a Crucial
> mSATA M4 SSD, and a Crucial SATA M4 SSD drive. I want to install arch on
> this system and indeed preparing a usbkey with the archiso install media
> using dd to write the usbkey boots just fine.
>
> Also the latest PartedMagic iso written to a usbkey also boots fine so
> that I can format the SSD drives (both of them). Looking at the system
> profile I can see all the peripherals, including all the RAM and both SSD
> drives.
>
> However before starting the arch install I want to update the firmware on
> the SSD drives. This is available from the Crucial website either as a
> Windows 7/8 .exe (which I can't use) or a "manual" firmware update file
> which is an iso (containing memdisk from syslinux, and a floppy image file
> boot2880.img)
>
> Running the "file" command on the boot2880.img file after loop mounting it
> gives:
>
> # file /mnt/iso/boot/isolinux/boot2880.img
> /mnt/iso/boot/isolinux/boot2880.img: x86 boot sector, FREE-DOS Beta 0.9
> Bootloader KERNEL.SYS, code offset 0x3c, OEM-ID "FreeDOS ", sectors/cluster
> 2, root entries 240, sectors 5760 (volumes <=32 MB) , sectors/FAT 9, serial
> number 0x2b6112fe, label: "BOOTABLE   ", FAT (12 bit)
>
> Writing the iso to a usbkey won't boot - the screen goes blank and nothing
> happens when I write the iso to a usbkey with a FAT32 key with the boot
> flag.  I have tried isolinux and that does not seem to work. I have tried a
> bootable grub2 usbkey and that does not work - all are prepared from a
> working arch linux laptop.
>
> I have following numerous "recipes" for making the usbkey from various
> sources on the web and none seem to work at all!
>
> The odd thing is that for syslinux I can't even get a menu item on the
> screen when booting the key - nor for grub 2.
>
> I have used two different makes of usbkey - both 4GBsame result - and
> both keys will boot fine with the archiso or PartedMagic.
>
> I don't know if I am doing something fundamentally stupid but this is
> driving me nuts! I have used gparted, as well as fdisk, as well as trying
> parted to reformat the usbkeys. Nothing I do seems to work!
>
> There must be a good step-by-step guide somewhere on how to get a usbkey
> with sysylinux to boot the firmware updater - which seems to have a floppy
> image file (boot2880.img) and uses memdisk to boot it - though the version
> on the iso file is about two year old whereas arch current memdisk in
> syslinux is up to date.
>
> If anyone can help advise on how to make a bootable usbkey to execute
> this, I would really appreciate it.
>
> Thanks in advance.
>
>
I raised this issue above about two weeks ago - and finally tonight
resolved the problem.

I checked on the Intel site for BIOS updates for my motherboard (DQ77KB) -
and it turned out that Intel has in the interim released a new BIOS version
048 which has a bunch of fixes including " Updated VBIOS to fix issue where
there is no display in DOS."

After installing the new BIOS I was able to update the SSD drive firmware
without any problem at all - so it seems that whatever method I tried to
boot the firmware update which is DOS based would have failed until the
BIOS was updated!

So I am a happy bunny again with current Crucial SSD drive firmware!

-- 
mike c

Re: [arch-general] Request help with wired network config after initial install and reboot

[Mike Cloaked]

On Mon, Jan 21, 2013 at 4:16 PM, LANGLOIS Olivier PIS -EXT <
olivier.pis.langl...@transport.alstom.com> wrote:

> >
> > It seems that the ifconfig command is not available once rebooted into
> the
> > install and I don't know how to proceed.
> >
> > Can anyone give my any advice on how to get the network up on the newly
> > installed system?
> >
> Because it hard to get rid of a good old habit:
>
> lano1106@hpmini ~ $ pkgfile ifconfig
> core/net-tools
>
>
Indeed - thanks.


-- 
mike c

Re: [arch-general] Strange isse with my arch usb install

[Mike Cloaked]

On Mon, Jan 21, 2013 at 7:12 AM, phani  wrote:

> On Mon, 21 Jan 2013 11:35:35 +0530, kendell clark 
> wrote:
>
>  HI all
>> i've just completed a fresh install of arch on a new pendrive I just
>> bought.
>> The install went smoothly, until I try to access the internet. I setup
>> net-auto-wireless with my home wireless network, and netcfg returns with
>> this error. No such interface: wlan0. Checking dmesg with "dmesg | grep -i
>> wlan0" yields the following. Systemd-udevd: renaming network interface
>> wlan0 to wlo2
>>
>> This has never happened to me before, so I tried my ethernet port. That
>> failed too, no internet connection. Dmesg again reveals: systemd-udevd:
>> renaming network interface eth0 to enps0." This usb drive is fully updated
>> as of 12:15 a.m jan 21, 2013, stable, no testing repos enabled, multilib
>> enabled. I'm using kernel v3.6.11. I've run into this situation before and
>> I've managed to resolve it by installing nss-myhostname. However, that was
>> when I tried to install from my main hdd, which has testing repos enabled
>> to my usb drive without enabling testing repos. That caused conflicts with
>> a newer kernel, v3.7.2 and systemd 197-4, which conflicted with
>> nss-myhostname. I tried to do the same today, only to find out that systemd
>> seems to contain nss-myhostname, because pacman -S nss-myhostname tries to
>> pull in systemd itself. I'm completely stumped. Googling around doesn't
>> seem to turn up any results, My search term was, udev renames wlan0 to
>> wlo2. Any help would really be appreciated. I'm trying to create a usb
>> drive to use as a diagnostic distro for my fiance's windows computer, virus
>> scanning, password recovery, etc.
>> Thanks
>> Kendell clark
>>
>>
> did you look at this:
> https://mailman.archlinux.org/**pipermail/arch-dev-public/**
> 2013-January/024231.html
> ([arch-dev-public] network interface naming with systemd 197)
>
> or this:
> https://bbs.archlinux.org/**viewtopic.php?pid=1219361
> (forum: Index » Kernel & Hardware » systemd-udevd renames network
> interfaces)
>
> Also see the thread at
https://mailman.archlinux.org/pipermail/arch-general/2013-January/032680.html


> --
> phani.
>



-- 
mike c

Re: [arch-general] Help with tigervnc problem - may be a package update required?

[Mike Cloaked]

On Mon, Jan 21, 2013 at 2:13 AM, Uroš Vampl wrote:

> Mike Cloaked  gmail.com> writes:
>
> > Does this mean that tigervnc is out of date and needs fixing or is it s
> > problem with X?
>
> Tigervnc needs patching for xorg-server-1.13. As an alternative, you can
> use the
> svn version from AUR: https://aur.archlinux.org/packages/tigervnc-svn/
>
>
>
>
I have downloaded and compiled the tigervnc-svn package from AUR as you
suggested, and also installed the dependency fltk-snapshot from AUR as
required before making the package - it generates the package file and
installs with pacman -U just fine.  The issue I had is not a problem with
this version, and it works like a champ!  So I am very relieved and
grateful for the svn AUR package!

Thank you.

-- 
mike c

Re: [arch-general] Help with tigervnc problem - may be a package update required?

[Mike Cloaked]

On Mon, Jan 21, 2013 at 2:13 AM, Uroš Vampl wrote:

> Mike Cloaked  gmail.com> writes:
>
> > Does this mean that tigervnc is out of date and needs fixing or is it s
> > problem with X?
>
> Tigervnc needs patching for xorg-server-1.13. As an alternative, you can
> use the
> svn version from AUR: https://aur.archlinux.org/packages/tigervnc-svn/
>
>
>
>
Thank you - I will try it and thanks for the link Uroš

-- 
mike c

Re: [arch-general] Help with tigervnc problem - may be a package update required?

[Mike Cloaked]

On Sun, Jan 20, 2013 at 10:05 PM, Mike Cloaked wrote:

> I have for a long time been using tigervnc until a few months ago and
> loading the vnc module via xorg.conf with two relevant sections:
>
> Section "Module"
>  Load  "vnc"
> EndSection
>
> and
>
> Section "Screen"
> Identifier "Screen0"
> Device "Videocard0"
> DefaultDepth 24
> SubSection "Display"
> Viewport   0 0
> Depth 24
> Option  "passwordFile" "/opt/Local/etc/vnc/passwd"
> EndSubSection
> EndSection
>
> However this results in Xorg.0.log as:
>
> [ 8.219] (II) LoadModule: "vnc"
> [ 8.233] (II) Loading /usr/lib/xorg/modules/extensions/libvnc.so
> [ 8.375] (II) Module vnc: vendor="Constantin Kaplinsky"
> [ 8.375]compiled for 1.12.3, module version = 1.0.0
> [ 8.375]Module class: X.Org Server Extension
> [ 8.375]ABI class: X.Org Server Extension, version 6.0
> [ 8.375] (EE) module ABI major version (6) doesn't match the server's
> version (7)
> [ 8.375] (II) UnloadModule: "vnc"
> [ 8.375] (II) Unloading vnc
> [ 8.377] (EE) Failed to load module "vnc" (module requirement
> mismatch, 0)
>
> Does this mean that tigervnc is out of date and needs fixing or is it s
> problem with X?
>
> Thanks for any advice.
>
> --
> mike c
>

I have reported this at: https://bugs.archlinux.org/task/33481

-- 
mike c

[arch-general] Help with tigervnc problem - may be a package update required?

[Mike Cloaked]

I have for a long time been using tigervnc until a few months ago and
loading the vnc module via xorg.conf with two relevant sections:

Section "Module"
 Load  "vnc"
EndSection

and

Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
SubSection "Display"
Viewport   0 0
Depth 24
Option  "passwordFile" "/opt/Local/etc/vnc/passwd"
EndSubSection
EndSection

However this results in Xorg.0.log as:

[ 8.219] (II) LoadModule: "vnc"
[ 8.233] (II) Loading /usr/lib/xorg/modules/extensions/libvnc.so
[ 8.375] (II) Module vnc: vendor="Constantin Kaplinsky"
[ 8.375]compiled for 1.12.3, module version = 1.0.0
[ 8.375]Module class: X.Org Server Extension
[ 8.375]ABI class: X.Org Server Extension, version 6.0
[ 8.375] (EE) module ABI major version (6) doesn't match the server's
version (7)
[ 8.375] (II) UnloadModule: "vnc"
[ 8.375] (II) Unloading vnc
[ 8.377] (EE) Failed to load module "vnc" (module requirement mismatch,
0)

Does this mean that tigervnc is out of date and needs fixing or is it s
problem with X?

Thanks for any advice.

-- 
mike c