Monday, November 11, 2013

How to install Atheros Wired LAN (ethernet) drivers in Fedora 19

On a *fresh* install of Fedora 19:
Step 1: From a computer having access to internet, download the following packages from pkgs.org:
cpp-4.8.1-1.fc19.x86_64.rpm
gcc-4.8.1-1.fc19.x86_64.rpm
gcc-c++-4.8.1-1.fc19.x86_64.rpm
glibc-2.17-14.fc19.x86_64.rpm
glibc-common-2.17-14.fc19.x86_64.rpm
glibc-devel-2.17-14.fc19.x86_64.rpm
glibc-headers-2.17-14.fc19.x86_64.rpm
kernel-devel-3.9.5-301.fc19.x86_64.rpm
kernel-headers-3.9.5-301.fc19.x86_64.rpm
libmpc-1.0.1-1.fc19.x86_64.rpm
libstdc++-devel-4.8.1-1.fc19.x86_64.rpm
perl-5.16.3-264.fc19.x86_64.rpm
perl-Carp-1.26-243.fc19.noarch.rpm
perl-Encode-2.51-1.fc19.x86_64.rpm
perl-Filter-1.49-1.fc19.x86_64.rpm
perl-libs-5.16.3-264.fc19.x86_64.rpm
perl-macros-5.16.3-264.fc19.x86_64.rpm
perl-PathTools-3.40-1.fc19.x86_64.rpm
perl-Pod-Escapes-1.04-264.fc19.noarch.rpm
perl-Pod-Simple-3.20-264.fc19.noarch.rpm
perl-Scalar-List-Utils-1.27-246.fc19.x86_64.rpm
perl-Socket-2.009-2.fc19.x86_64.rpm
perl-threads-1.87-1.fc19.x86_64.rpm
perl-threads-shared-1.43-2.fc19.x86_64.rpm

Step 2: Copy them to the machine and run the command:
# yum install *.rpm

Step 3: Download compat-drivers-2013-03-04-u.tar.bz2 then run the commands:
# tar -xf compat-drivers-2013-03-04-u.tar.bz2
# cd compat-drivers-2013-03-04-u
# ./scripts/driver-select alx && make && make install
# reboot

Note: If the above link(s) don't work, then use my mirror:
1: RPM packages
2: compat-drivers-2013-03-04-u.tar.bz2

Thursday, October 3, 2013

How To Install Legacy Catalyst ATI Drivers 13.1 in Fedora 18

This approach has been taken from Giuseppe Marco Randazzo's Blog Post

Note: This method will only work for kernel <=3.9.11-200

Note: This method has been tested for a fresh install of fedora 18

Note: Make sure that you have booted into the kernel version 3.6.10-4

Steps:
First download kernel-3.6.10-4.fc18.x86_64.rpm, kernel-headers-3.6.10-4.fc18.x86_64, kernel-devel-3.6.10-4.fc18.x86_64 and rpmfusion-free-release-stable
$ yum install -y kernel-3.6.10-4.fc18.x86_64.rpm kernel-headers-3.6.10-4.fc18.x86_64 \
  kernel-devel-3.6.10-4.fc18.x86_64 rpmfusion-free-release-stable 
$ yum remove audit -y
$ yum install -y qt-x11 akmods git
$ cd /var/lib; git clone https://github.com/zeld/zrepo.git
$ echo "[zrepo]
name=zrepo Repository
baseurl=file:///var/lib/zrepo/$releasever/$basearch
gpgcheck=0
enabled=1" > /etc/yum.repos.d/zrepo.repo
$ yum remove xorg-x11-drv-* -y
$ yum --disablerepo="*" --enablerepo="zrepo" downgrade \
  xorg-x11-server-common-1.12.4-3.fc18.x86_64  xorg-x11-server-Xorg-1.12.4-3.fc18.x86_64
$ yum --disablerepo="*" --enablerepo="zrepo" install \
  xorg-x11-drv-evdev xorg-x11-drv-synaptics xorg-x11-drv-catalyst-legacy akmod-catalyst-legacy
$ mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-old.img
$ dracut /boot/initramfs-$(uname -r).img $(uname -r)
$ grub2-mkconfig -o /boot/grub2/grub.cfg
$ echo "exclude=xorg-x11-server-* xorg-x11-drv-* kernel-*" >> /etc/yum.conf
$ sed -i '/^GRUB_CMDLINE_LINUX=\"/s/\"$/ rd.blacklist=radeon nomodeset radeon.audio=1 radeon.audio=1\"/' \
  /etc/default/grub

Monday, June 17, 2013

Google Summer of Code 2013 Progress


 __      __               __      ____ 
/  \    /  \ ____   ____ |  | __ /_   |
\   \/\/   // __ \_/ __ \|  |/ /  |   |
 \        /\  ___/\  ___/|    <   |   |
  \__/\  /  \___  >\___  >__|_ \  |___|
       \/       \/     \/     \/       
Libvirt [Task]: Successfully build libvirt from source code (rev: v1.0.6-79-g847e1cd ) and run qemu-qeust agent.
To Compile:
$ git clone git://libvirt.org/libvirt.git
$ cd libvirt
$ ./autogen --system
$ make
Start the libvirt daemon:
$ ./daemon/libvitd -d
Make a f18 VM via virt-manager
$ ./tools/virsh
virsh # connect qemu:///system
virsh # start f18
ssh into the VM and install qemu-guest-agent
$ yum install -y qemu-guest-agent ; reboot
Make sure that qemu-guest-agent is running in the guest
$ ps -C qemu-ga # should return pid of the process
If not, then type the command:
$ qemu-ga -d
Return to host and start querying!
$ ./tools/virsh
virsh # qemu-agent-command f18 '{"execute":"guest-network-get-interfaces"}'
References:
http://aglitke.wordpress.com/2011/02/24/how-to-hack-on-a-local-copy-of-libvirt/
http://wiki.libvirt.org/page/Qemu_guest_agent
http://wiki.qemu.org/Features/QAPI/GuestAgent#Example_usage


Git: Set up the git repository: https://github.com/nehaljwani/gsoc2013-libvirt
Steps:
Make the git repo via web interface on github.com
Clone the repo:
$ git clone git://libvirt.org/libvirt.git
$ git remote add github git@github.com:nehaljwani/gsoc2013-libvirt.git
$ git push github master
To reflect changes from main repo into your repo
$ git fetch origin
$ git push github origin/master:master
To reflect local changes into your repo
$ git push github master
While building, if you get the error:
Unable to find current revision in submodule path '.gnulib'
Then do:
$ rm -fr .gnulib
$ git submodule update --init

 __      __               __     ________  
/  \    /  \ ____   ____ |  | __ \_____  \ 
\   \/\/   // __ \_/ __ \|  |/ /  /  ____/ 
 \        /\  ___/\  ___/|    <  /       \ 
  \__/\  /  \___  >\___  >__|_ \ \_______ \
       \/       \/     \/     \/         \/
Libvirt [Task]: Setting up the qemu-guest-agent
To be able to use GA users needs to create virtio serial port with special name org.qemu.guest_agent.0. In other words, one needs to add this to his/her domain XML under <devices>:
$ virsh edit <domain-name>
<channel type='unix'>
   <source mode='bind' path='/var/lib/libvirt/qemu/f16x86_64.agent'/>
   <target type='virtio' name='org.qemu.guest_agent.0'/>
</channel>

Libvirt [Update]:
        * Discussion on why virTypedParams > struct/XML: Upper layer app doesn't have to parse the returned xml string, more extensible.
        * Update Michal's patches (Struct and XML) and modify them with virTypedParameter.
        * Asked Michal to send his XML patches. (The one on list was incomplete).

Libvirt [Task]: Analyze previous patches submitted by Michal Privoznik, Re-factor the struct patch (to make it compatible with the latest version of libvirt) and understand the implementation.
Updated struct patch: https://gist.github.com/nehaljwani/5829005

 __      __               __     ________  
/  \    /  \ ____   ____ |  | __ \_____  \ 
\   \/\/   // __ \_/ __ \|  |/ /   _(__  < 
 \        /\  ___/\  ___/|    <   /       \
  \__/\  /  \___  >\___  >__|_ \ /______  /
       \/       \/     \/     \/        \/ 
Git: Setting up git branch
$ git checkout -t master -b workbranch
After making changes:
$ git push github

Libvirt [Update]: Main points in conversation with eblake:
        * If virTypedParamenterPtr * is to be used, it is not advisable to name it as virTypedParameterPtrPtr
        * If at all a 2D pointer is required to be used, take virDomainGetCPUStats as example.
        * It is required that new APIs should be more user-friendly, [usability feature] and return allocated answers, rather than requiring
          the user to pre-allocate
                e.g. implementation :  virConnectListAllDomains (It also has a 3D pointer implementation)
        * Before working on implementation, it is advised to make sure that all have agreement on the upstream list that the interface is sane
          Therefore, I'll be better off proposing the function signature and documentation comments to the list, to get feedback if my proposed
          API makes sense for usability
        * With reespect to the API, we definitely want a 2d result, but it is not finalized whether it will be easier to document a return where
          the user looks at array[a*n+b] or array[a][b] (where a and b are the iterators, and n is the number of parameters per interface).
          Depending on that answer, we either document the public API interface as virTypedParameterPtr *params (allocate a 1d array with
          embedded 2d information) or virTypedParameterPtr **params (allocate a 2d array)
        * Whenever VIR_TYPED_PARAM_STRING is used, it should always be strdup'd using the helper functions in src/util/virtypedparam.h
          Since virTypedParameterAssign doesn't do it, virTypedParamsAddString should be used.
        * Although we want the feature, reasons for not accepting Michal's Patch:
                -  Because the API design wasn't complete
                -  We weren't willing to add an API that wasn't extensible
        * Purpose of using virTypedParameter: It provides us extensibility - as long as we tell the user how many interfaces and how many
          parameters per interface, then we can add more parameters per interface
        * Introduction to new acl functionality: ACLs are access control lists that allow fine-grained access controls on what APIs
          individual users can use. For instance, you can state that user 'foo' can only see a subset of all domains managed by libvirt,
          rather than having global access to the entire list (Introduced by Daniel)

Libvirt [Task]:  Prepare RFC for API
 __      __               __        _____  
/  \    /  \ ____   ____ |  | __   /  |  | 
\   \/\/   // __ \_/ __ \|  |/ /  /   |  |_
 \        /\  ___/\  ___/|    <  /    ^   /
  \__/\  /  \___  >\___  >__|_ \ \____   | 
       \/       \/     \/     \/      |__| 
Libvirt [Update]: Discussion regarding updating libvirt.org/api_extension.html with eblake. It is outdated. Doesn't work with current libvirt version.

Libvirt [Update]: Main points relating to RFC on the list: [http://www.mail-archive.com/libvir-list@redhat.com/msg79793.html]
        * 2 versions of API proposed: Using 1D virTypedParams and 2D virTypedParams.
        * We find that using such structures will increase complexity. Using fixed structs/xml is more simple. Main trouble is caused by
          multiple addresses per interface.
        * Suggestions for method-name : dhcp|snoop|agent
        * Unlikeliness of extension and ease of use super power extensibility. Hence we move back to structs

Libvirt [Update]: Findings w.r.t method 3:
        * nwfilter_dhcpsnoop.c and nwfilter_learnipaddr.c contain parts for snooping. Some methods are explored.
        * Its a pre-requisite to pass the MAC address beforehand.
        * virNWFilterLearnIPAddress is the method which we are interested in. It is indirectly used by virDomainAttachDevice.
        * Discussion halted. Phase 1 is to be completed first.

Libvirt [Update]:
        * Patch using virTypedParams completely discarded. Shifting back to structs.
        * Creating new patch to work with libvirt version 1.1.1

Git: Revoking commits, solving errors
To revoke a recent commit (not pushed), do:
$ git reset --soft HEAD~1
If you are working on a remote branch, and want to update it to the latest version (removing all your changes):
$ git checkout .
$ git pull origin master
$ git reset --hard origin/master
If you still get the error: "your branch is ahead of 'origin/master' by x commits", do:
$ git fetch
Libvirt [Task]: Patch to be updated as per reviews provided by mentor.

Git: Config for git send-email with gmail id
$ git config --global sendemail.smtpserver smtp.gmail.com
$ git config --global sendemail.smtpserverport 587
$ git config --global sendemail.smtpencryption tls
$ git config --global sendemail.smtpuser nehaljw.kkd1@gmail.com

Libvirt: Before sending any patches, make sure to do:
  ./configure --enable-werror
and run the tests:
  make check
  make syntax-check
  make -C tests valgrind


 __      __               __      .________
/  \    /  \ ____   ____ |  | __  |   ____/
\   \/\/   // __ \_/ __ \|  |/ /  |____  \ 
 \        /\  ___/\  ___/|    <   /       \
  \__/\  /  \___  >\___  >__|_ \ /______  /
       \/       \/     \/     \/        \/ 
Git: Sending multiple patches via email:
$ git format patch HEAD~5 
$ git send-email --cover-letter --no-chain-reply-to --annotate --to=jyang@redhat.com --cc=nehaljw.kkd1@gmail.com
OR
$ git send-email -5 --cover-letter --no-chain-reply-to --annotate --to=jyang@redhat.com --cc=nehaljw.kkd1@gmail.com
There seems to be a bug in git, hence, after the above command, instead of letting me edit the emails, git opens the cover letter twice, and doesn't let me edit the other emails. Hence, after editing the cover letter, you'll find that the patches are located in /tmp/<some-random-folder>/, and one can edit them.

Libvirt [Task]: Patch to be updated as per reviews provided by mentor.

Libvirt [Update]:Findings w.r.t method 2:
        * bridge_driver.c is contains function networkDnsmasqLeaseFileNameDefault (retrieves driverState->dnsmasqStateDir)
          which returns location of leases file for a given virtual network
        * Experiments caried out to analyze the format of leases file, using 2 VMs and 3 virtual networks.
        * According to laine, the problem is that some day libvirt wants all of the network stuff to live in a separate daemon,
          and creating a small API to return the value of driverState->dnsmasqStateDir in the driver would instead make
          them more closely bound. Also, nwfilter can snoop for dynamically alotted as well as statically alotted ip addresses. Hence, using
          leases file is not altogether a best idea.
        * Idea is to make the API more generalized, and not for specific purpose. It should use typed parameters
          (e.g. parameter fields including VIR_NETWORK_CONFIG_DIR, VIR_NETWORK_LEASE_FILE, etc).
        * To be posted as RFC on the list.

Libvirt [Task]: Prepare RFC for Introducing API to query configurations directories.

 __      __               __       ________
/  \    /  \ ____   ____ |  | __  /  _____/
\   \/\/   // __ \_/ __ \|  |/ / /   __  \ 
 \        /\  ___/\  ___/|    <  \  |__\  \
  \__/\  /  \___  >\___  >__|_ \  \_____  /
       \/       \/     \/     \/        \/ 
Libvirt [Update]: Why API to query configurations directories doesn't exist:
        *That is internal to the network driver. Under normal circumstances there should be no reason for
          anything external to know that. Libvirt doesn't want them to rely on information that
                   1) is specific to a particular implementation of the back-end of the network driver and
                   2) may change in the future, causing their code to not work.
        *It's the same reason you would want to hide as much of the internal implementation of any piece of
         software - the more you reveal in an official API, the more you have to maintain *forever*, which is
         especially difficult if it becomes deprecated/irrelevant.

Libvirt [Task]: To continue with RFC anyway.
Libvirt [Task]: Final review of method 1 implementation complete. Patch sent to the list [https://www.redhat.com/archives/libvir-list/2013-July/msg01553.html]

Libvirt [Task]: Post RFC of method 2 on list:
Libvirt [Task]: Start working on method 2 assuming that I have access to the leases file using XYZ API

 __      __               __     _________ 
/  \    /  \ ____   ____ |  | __ \______  \
\   \/\/   // __ \_/ __ \|  |/ /     /    /
 \        /\  ___/\  ___/|    <     /    / 
  \__/\  /  \___  >\___  >__|_ \   /____/  
       \/       \/     \/     \/           
Libvirt [Update]: Method 2 almost complete, only virsh support remaining.

Tuesday, May 21, 2013

How To Create A Multi-Partition Multi-Boot Pendrive


Step 1: Install gparted
In rpm-based operating systems:
$ yum install -y gparted
In debian-based operating systems:
$ sudo apt-get install -y gparted
Step 2: Created 5 Logical Partitions each of 850MB in your pendrive. Give appropriate label to each partition. The last 4 will hold the content for installation. The first partition can be used as a normal pen drive uses. Note: These 5 Logical partitions have been created out of a single extended partition.
Step 3: Download the images of the distros.
$ wget http://centos.mirror.euserv.net/6.4/isos/x86_64/CentOS-6.4-x86_64-LiveCD.iso 
$ wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/releases/17/Live/x86_64/Fedora-17-x86_64-Live-Desktop.iso
$ wget http://gb.releases.ubuntu.com//raring/ubuntu-13.04-desktop-amd64.iso
$ wget http://gb.releases.ubuntu.com//raring/ubuntu-13.04-desktop-i386.iso
Step 4: Mount all the 5 partitions. (In GUI mode, or any other mode you prefer)
Step 5: Mount the images one by one and then extract their contents to the respective partitions
$ mount -o loop /home/Wani/OSImages/CentOS-6.4-x86_64-LiveCD.iso /mnt
$ cp -rv /mnt/* /run/media/Wani/CENTOS
$ umount /mnt
$ mount -o loop /home/Wani/OSImages/Fedora-17-x86_64-Live-Desktop.iso /mnt
$ cp -rv /mnt/* /run/media/Wani/FEDORA
$ umount /mnt
$ mount -o loop /home/Wani/OSImages/ubuntu-13.04-desktop-amd64.iso /mnt
$ cp -rv /mnt/* /run/media/Wani/UBUNTU13.04
$ umount /mnt
$ mount -o loop /home/Wani/OSImages/ubuntu-13.04-desktop-i386.iso /mnt
$ cp -rv /mnt/* /run/media/Wani/UBUNTU13.041
$ umount /mnt
In my OS, the mount point was /run/media/Wani. It might be different in your OS.
Step 6: Install grub into the pendrive
$ grub2-install --root-directory /run/media/Wani/Partition1-Name /dev/sdx #replace x with the appropriate letter
Step 7: Find the location of files grub.cfg/grub.conf/loopback.cfg in each partition.
FEDORA:        /mnt/EFI/BOOT/grub.conf
CENTOS:        /EFI/boot/grub.conf
UBUNTU13.04:   /boot/grub/grub.cfg
UBUNTU13.041:  /boot/grub/loopback.cfg
Step 8: Find the mapping of each partition with its partition number. It will depend on the order in which these partitions were created
FEDORA: /dev/sda5
CENTOS:        /dev/sda6
UBUNTU13.04:   /dev/sda7
UBUNTU13.041:  /dev/sda8
Step 9: Configure grub file on pendrive.
$ vim /run/media/Wani/Partition1-Name/boot/grub2/grub.cfg
Template:
menuentry "OS Name" {
 root=(hd0,msdos(mapping-number))
  legacy_configfile (location-of-grub-config-file)
}

set timeout=10
set default=0

menuentry "Fedora 17 x86_64" {
 root=(hd0,msdos5)
  legacy_configfile /EFI/BOOT/grub.conf
}
menuentry "CentOS 6.4 x86_64" {
 root=(hd0,msdos6)
  legacy_configfile /EFI/boot/grub.conf
}
menuentry "Ubuntu 13.04 64bit" {
 root=(hd0,msdos7)
  configfile /boot/grub/grub.cfg
}
menuentry "Ubuntu 13.04 32-bit" {
 root=(hd0,msdos8)
  configfile /boot/grub/loopback.cfg
}
Note that Fedora and CENTOS use the old grub syntax, hence the option legacy_configfile but Ubuntu uses the new one.

Step 10: Change the grub.conf file in the partition of FEDORA and CENTOS
In /EFI/boot/grub.conf, change the value of root from
root=live:LABEL=CentOS-6.4-x86_64-LiveCD
to
root=live:LABEL=CENTOS
Note: The label needs to be changed, so that grub knows, which partition to boot from. The 'label' is the label that you put while creating the partitions. Repeat the same for FEDORA.

Step 11(Optional): Mark the partitions containing extracted images as hidden, so that they are not automatically mounted. Use the Partition-1 as for normal data transferring purposes.

Update: For Fedora 18, a following changes have to be made:

(i) Go in to the partition in which Fedora-18-x86_64-Live-Desktop.iso was extracted. Go to the folder EFI/Boot and create a file grub.conf with the following configuration: (Assumed that the label of the partition is FEDORA18)
default=0
timeout 10
hiddenmenu

title Fedora-18-x86_64-Live-Desktop.iso
  findiso
  kernel /isolinux/vmlinuz0 root=live:LABEL=FEDORA18 ro rd.live.image quiet  rhgb xdriver=vesa nomodeset
  initrd /isolinux/initrd0.img
title Verify and Boot Fedora-18-x86_64-Live-Desktop.iso
  findiso
  kernel /isolinux/vmlinuz0 root=live:LABEL=FEDORA18  ro rd.live.image quiet  rhgb rd.live.check
  initrd /isolinux/initrd0.img

(i) Add the following in the first partition's boot/grub2/grub.cfg:
menuentry "Fedora 18 x86_64" {
  root=(hd0,msdos5)
  legacy_configfile /EFI/BOOT/grub.conf
}


Monday, January 7, 2013

Install Linuxdcpp In Fedora 16/17



Step 1: Download Source: http://prdownload.berlios.de/linuxdcpp/linuxdcpp-1.0.2.tar.bz2 and extract.

Step 2: Install the packages required for compilation of source code.

Step 3: Edit the file SConstruct and add the following:

Step 4: Compile and Install!

Step 5: Now that linuxdcpp has been installed, See the above video for a small demo.