Fedora 17 and 18 headphone socket fix

The Problem...

My headphones produce no sound from jack socket when using Fedora 17 and also Fedora 18. The sounds card I have is:

• 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
• 02:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Redwood HDMI Audio [Radeon HD 5000 Series]

I found the above be executing the "lspci" command, you can use "lspci | grep Audio" and that should find similar to the above.

The Solution...

I got my solution from here.
All I did was to create the file /etc/modprobe.d/dist-alsa.conf and add the following lines:

• options snd-hda-intel model=dell-m6-amic
• options snd-hda-intel enable_msi=1

Ok I found an issue when I tried the above setting of setting the model to dell-m6-amic, my microphone stopped working, I then found a little information on this thread that stated that was for the analog mic, so I changed the setting to dell-m6-dmic which is for a digital mic.

How to know which model to choose this link is very useful! This has some info too but pretty much the same.

Then reboot, potentially you don't need to reboot and there is a command to restart the sound system, I am not sure on this, so reboot it was for me :-)

Hope this helps someone else out too :-)

Installing ATI drivers on Fedora 18

I followed mostly what was in this link, but when installing the driver I just did yum install akmod-catalyst as it pulls in required dependencies.

I managed to get a black screen by just installing the akmod-catalyst without some of those instructions, so it was either the first instruction or last that fixed my black screen problem after booting. reinstalling mesa-libGL or the dracut of a new image after making sure the Radeon drivers were uninstalled.

Only problem I have is a nice watermark at the bottom right of my screen. Its not so bad for now, but would be nice to get rid of :-)

There are some fixes out there on how to remove it, but I am sure the new builds releases will come soon. :-)

Nice shortcut editor for Fedora 18

I used alacarte and seems to be able to set up all the shortcuts and modify the icons etc. Very nice! straight forward.

yum install alacarte

Setting up Fedora 18 for an SSD

Just some short points on setting up Fedora 18 or for that matter probably most Linux flavours for an SSD.

I've highlighted the bits I changed:

/etc/fstab changes:

• /dev/sda   /   ext4   noatime,nodiratime,discard,errors=remount-ro 0 1
• tmpfs   /tmp       tmpfs   defaults,noatime,mode=1777   0  0
• tmpfs   /var/spool tmpfs   defaults,noatime,mode=1777   0  0
• tmpfs   /var/tmp   tmpfs   defaults,noatime,mode=1777   0  0
• tmpfs   /var/log   tmpfs   defaults,noatime,mode=0755   0  0 (only do this if you don't care about loosing logs on reboot!)

/etc/default/grub changes:

• GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=deadline" add the elevator bit to the end.
• grub2-mkconfig -o /boot/grub2/grub.cfg

Chrome to use its cache directory as the tmp director, which is in memory already add the following to the shortcut.

• --disk-cache-dir="/tmp" --disk-cache-size=104857600

The link I got most this information from :-)

Setting up Broadcom 4312 with Fedora 18

This was a bit of a pain and felt like I had to jump through hoops to get this damn thing to work. In the end its not actually too much to do, you can either to try and follow the instructions in this link (I have had to do this recently) or mine.

First off, by using the command line rpm and yum commands I seemed to be more successful installing all the required packages.

So here goes...

Step 1:
Change user as root:

• su -

Step 2:
You need to add a couple of repos, the rpmfusion free and nonfree repos.

• rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm
• rpm -Uvh http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

Step 3:
You will probably then need to download and import the keys for these repos from rpmfusion-keys:

• get [attachment:RPM-GPG-KEY-rpmfusion-free-fedora-18]
• get [attachment:RPM-GPG-KEY-rpmfusion-nonfree-fedora-18]

Step 4:
Import the keys:

• rpm --import <Directory where you downloaded the [attachment:RPM-GPG-KEY-rpmfusion-free-fedora-18] Key>
• rpm --import <Directory where you downloaded the [attachment:RPM-GPG-KEY-rpmfusion-nonfree-fedora-18] Key>

Step 5:
Now with these keys imported, you should now be able to update:

• yum update

Step 6:

Ok this got a bit weird when I tried to install kmod-wl but try it out it could work straight out for you, but I had issues with it failing to install due to "uname -r" not matching with build of kmod-wl not correct.

• yum install kmod-wl

If the above fails then try:

• yum install akmod-wl

I think all the akmod-wl will do is bring all the dependencies it requires, which will be the kmod-wl and the broadcom-wl packages and a few others. I think all the akmod does is to be able to build a new version of the kmod-wl module against your version of the kernel if there doesn't exist one on the repos. Also if/when you update your kernel this akmod should make sure that the kmod-wl is built correctly.

So at this point akmod-wl, kmod-wl and broadcom-wl should be installed, and a few others required dependencies by the akmod-wl package.

Step 7:

Ok now I found at this point that there was a module loaded called ssb which conflicts with the wl module. I am not sure what this module is and why it conflicts I didn't look into it too much, so I had to remove this module permanently by adding it to a blacklist. First of all I tried:

• echo "blacklist ssb" >> /etc/modprobe.d/blacklist.conf

which didn't seem to work, so I added it directly to the grub.conf, but what I did was add it too the /etc/default/grub file so as the time comes when you may need to call grub-mkconfig then it will keep the default added in that file, so I did:

• added "rd.driver.blacklist=ssb" to the end of the GRUB_CMDLINE_LINUX in the /etc/default/grub
• then ran, "grub2-mkconfig -o /boot/grub2/grub.cfg" this regenerated the /etc/grub2.cfg file.

I am not sure why I had to blacklist like this and if anyone can explain or help out that would be much appreciated :-) So all should be prepared at this point, just one more step.

Step 8:

I removed the ssb module and added the wl module.

• rmmod ssb
• modprobe wl

Now that should be it, as far as I remember, on the network icon then should show up wireless. Try rebooting also to make sure it comes up after a reboot also. If you get any problems or some parts don't work please let me know and I will try to correct it and help.

Some useful links I found and used.

• Installing kmod-wl
• Problems blacklisting ssb
• Broadcom link
• How to use Broadcom wireless in fedora 14/15/16
• Grub2 

Hope this helps out :-)

Setting up QNAP to accept ssh connection from different users

This is a pain to do, and I always seem to forget one switch to turn on 1 file to set up 1 permission to configure. Always the same every time I need to do it. Well I have put together a few links that I have found useful and a few procedures I have found helpful to understand why a connection fails. :-)

So the steps and links I used are:

1. For setting up new ssh software on the QNAP NAS I used this link: http://blog.jameslick.com/?p=1090 brilliant, excellent! worked for me and my model. I imagine it would be a slight tweak for other models if they have different names for equivalent mounts.
2. Then I set up the users paths in /etc/passwd on the NAS box of the users.
3. Setting up the ssh keys, omg! I used this link: http://superuser.com/questions/8077/how-do-i-set-up-ssh-so-i-dont-have-to-type-my-password. So I worked out the public key goes on the NAS box in the authorized_keys file in the user .ssh directory of the user, e.g. /home/JoeBloggs/.ssh/authorized_keys  <-- This user home path should be the same as what you specified in the /etc/passwd file. BE CAREFUL - When copying the public key that it doesn't gain spaces on the copy paste route, it needs to be as it is in the generated file (from point 1) You can add more than one key to this file for this user, if the same user connects from different machines, you can generate another key from the other machine and add the public key of that one to the same authorized_keys file. You press ENTER after the first one and then paste in the new one.
4. Configure the sshd_config file this is in the location(s) specified in the link 1, don't forget to update both configs otherwise on reboot you will get your old one back. You can set up the config file with the users that are required to access via ssh.
1. So there is a section to describe where to find the authorized keys file, and you can configure it to go to the home path of the user that tries to connect, using (I believe %h means the home directory of the user connecting, but I am not 100% sure): 
• AuthorizedKeysFile %h/.ssh/authorized_keys
2. There is also a section to allow certain users: 
• AllowUsers JoeBloggs Fred
5. There are also special permissions allowed only to the authorized_keys files which I found in this link: http://recursive-design.com/blog/2010/09/14/ssh-authentication-refused/
6. Any problems that occur, when you test to connect to ssh JoeBloggs@<yourIP> you can run the ssh with a -v that can output much information that can give clues in why it fails.
7. Also you can run the QNAP sshd manually with sshd -d and then connect from the client and watch the debug output that can give clues also :-). To do this I would stop the ssh service in the QNAP web client. Then locate the sshd on the QNAP, it is usually at /usr/sbin/sshd, so you will have to execute with full path specified e.g. /usr/sbin/sshd -d and this should then start up the daemon ready for connections.
8. One more thing! If you want to map a network drive on a linux box to your QNAP, you will need to turn on the sftp option when turning on your ssh option in the web client of your QNAP box. You can also do this drive mapping nicely with sshfs JoeBloggs@<YourIP>:<Directory you want to go too on the QNAP> <Directory you want to map too on local computer> The "Directory you want to go too on the QNAP" default is your home directory of that user, so if you need somewhere out of that (and make sure you have permisions for the user set up on the QNAP), you have to specify a relative path from your home directory, e.g. sshfs JoeBloggs@<YourIP>:../../SomeSpecialData /home/JoeBloggs/SomeSpecialData

Ok I think that's it for now.

Hope it will help someone, again it will help me when I need to do this again :-)

Migrating QNAP NAS from Raid 1 to Raid 5

What a mess!!

BACKUP FIRST!! Somehow I didn't even need it in the end :-)

Well, I think I have eventually managed to work out how to get my raid migrated from Raid 1 to Raid 5 after adding a new drive (surprisingly without loosing any data), and let me tell you something I would feel sorry for the average guy who doesn't know too much about Linux or computers to be able to do this on the command line. I feel that the UI isn't up to coping with a situation that something doesn't go correctly too well. This was not a straight forward thing to do and probably the first thing I would do is to never use the UI provided to do this, its next to useless! No really! the best thing to do is to learn how to do it manually from the command line, I had a lot more confidence working with Linux directly over this UI. 

It has taken me a couple of weeks and I have my NAS back up and running at Raid level 5 with the new drive and over 50 emails back and fore to support which was very helpful and responsive and gave many clues but in the end I worked out the bulk of it myself, which gave me a great sense of achievement and knowledge. 
I think I rebuilt Raid 1, 3 - 4 times, Raid 5 twice, while removing and trying to re-add my new drive, also scanning drives for bad blocks and as they are all 2 TB drives this doesn't give results back that quickly. So now I am going to try and document what i did to get this to work with the help of a few links one of which I was guided to by the QNAP Support.

So the useful links I had were the following:
Thread 1: viewtopic.php?t=12109

This was the most useful one for clues on the process of what I needed to do, I got so far with this one and failed to unmount the drive as there were services still being used so I needed to run "/etc/init.d/services.sh stop" this stopped all the services I could then unmount the drive. Further down this thread from "abmagfab" he gives more information if you need to grow the raid also.
Thread 2:http://www.davelachapelle.ca/2008/07/25 ... to-raid-5/

This one gave more more information on how to convert the Raid 1 to Raid 5 on 2 disks and then add the new drive. Also very useful. I think I would just use this thread next time.

The trouble with doing all this from the command line is that the UI will start to look incorrect as the files that the UI relies on does not get updated when running these commands on command line. The files were /etc/storage.conf and /etc/config/raidtab. I wasn't sure what I needed to update on these files so I kind of guessed, when I had 3 drives at Raid level 5 I set them accordingly. I tried to find more information about these files and what the different parameters meant but I couldn't, so please if anyone knows where I can find information on this please post here, I would love to understand how they are used and what the possible values to the possible parameters are. thanks  

So I would just follow thread 2 but I would also unmount the /dev/md0 also so would need to run the "services.sh stop" command.

It wasn't as straight forward as the thread as I had already started playing with mdadm and I got things in a bit of a state but I managed to get it all back to a nice state and learned a lot on the way (surprisingly without loosing data too!)

I had a situation once where all was complete, but my /dev/md0 would not automount I had forgotten to turn the journaling back on with the /dev/md0 (quite easily done when you have rebuild times over night and day, I kind of forget what I did! ha ha) once I did that and rebooted, voila! auto mounted!

dmesg is your friend, it can give quite a few clues, I will explain how I found the journaling off problem...When I ran dmesg straight after boot and after I manually mounted /dev/md0 (mount /dev/md0 /share/MD0_DATA -t ext4) it gave me the following on the last line of dmesg:
EXT4-fs (md0): mounted filesystem without journal
I saw the "without journal" and that triggered my memory about whether i turned it off or not and a quick search online of what happens when mounting without journal, gave me some more clues so I just turned it back on using command in Link1 and all seemed to be fine again 

Don't ask me how I didn't loose any data, but I didn't (well not that I have noticed yet!). mdadm is very robust and usable just make sure to read the man pages for all the options that you are about to use from any links that you follow and you can learn a lot just like me 

I am sure it will help me in the future when I forget all this in a few months (well few minutes really)

I hope this helps someone else.