https://wiki.archlinux.org/api.php?action=feedcontributions&user=Rcl&feedformat=atomArchWiki - User contributions [en]2024-03-28T23:41:45ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Arch_FAQs_for_newbies&diff=13417Arch FAQs for newbies2006-06-02T12:19:06Z<p>Rcl: Added link to Wireless Setup wiki.</p>
<hr />
<div>{{stub}}<br />
=Arch Linux Newbie FAQ=<br />
This page is intended to be a page to answer some of the most commonly asked questions about Arch by new users. Feel free to add or modify any terms, but please use that particular section's edit option. <br />
==How do i automount/mount something?==<br />
if you use gnome, install gnome-volume-manager<br />
pacman -S gnome-volume-manager<br />
<br />
If you don't want to use gnome-volume-manager, check out the [http://wiki.archlinux.org/index.php/AutoFS_HowTo AutoFS HowTo].<br />
<br />
==How do I reduce the amount of kernel modules loaded/shown in lsmod?==<br />
if you are using kernel26, edit /etc/mkinitrd.conf. Enable auto-detection of HOSTCONTROLlER and FILESYSTEMS.<br />
AUTODETECT=1<br />
<br />
if you are using kernel26beyond, edit /etc/mkinitramfs.conf.<br />
<br />
==How do I connect to my wireless network?==<br />
<br />
See [[Wireless Setup]].<br />
<br />
==How do I connect to my wired network?==</div>Rclhttps://wiki.archlinux.org/index.php?title=Patching_packages&diff=11758Patching packages2006-04-18T16:27:52Z<p>Rcl: /* Applying patches */ cleaned up </code>s</p>
<hr />
<div>[[Category:Package Management]]<br />
There have been quite a few questions about creating and/or applying patches to packages when using ABS. This document outlines the steps and options required to do these tasks. http://www.kegel.com/academy/opensource.html also has some useful information on patching files.<br />
<br />
===Creating patches===<br />
If you are attempting to use a patch that you got from elsewhere (ie: you downloaded a patch to the Linux kernel), you can skip to the next section. However, if you need to edit source code, make files, configuration files, etc, you will need to be able to create a patch.<br />
<br />
Note: If you need only to change one or two lines in a file (ie: a Makefile), you may be better off investigating the properties of <code>sed</code> instead.<br />
<br />
Creating a patch for a package involves creating two copies of the package, editing the new copy, and creating a unified diff between the two files. When creating an Arch Linux package, this can be done as follows:<br />
<br />
# Add the download source of the file to the source array of the <code>PKGBUILD</code> you are creating. Of course, if you are altering an existing PKGBUILD, this step is taken care of.<br />
# Create a dummy (empty, or containing a single <code>echo</code> command is good) build() function. If you are altering an existing <code>PKGBUILD</code>, you should comment out most of the lines of the build function, as you're likely going to be running <code>makepkg</code> several times, and you won't want to spend a lot of time waiting for a broken package to build.<br />
# Run <code>makepkg</code> This will download the source files you need to edit into the <code>src</code> directory.<br />
# Change to the <code>src</code> directory. In standard cases, there will be a directory containing a bunch of files that were unzipped or untarred from a downloaded archive there (Sometimes it's a single file, but diffs work on multiple files too!) You should make two copies of these directories. One is a pristine copy that makepkg won't be allowed to manipulate, and one will be the new copy that you will create a patch from. You can name the two copies <code>package.pristine</code> and <code>package.new</code> or something similar.<br />
# Change into the <code>package.new</code> directory. Edit whichever files need to be edited. The changes needed depend on what the patch has to do; it might correct a Makefile paths, it may have to correct source errors (for example, to agree with <code>gcc 3.4</code>), and so on. You can also edit files in subfolders of the <code>package.new</code> directory, of course. '''Do not''' issue any commands that will inadvertantly create a bunch of files in the <code>package.new</code> directory; ie: do not try to compile the program to make sure your changes work. The problem is that all the new files will show up in the patch, and you don't want that. Instead, apply the patch to another copy of the directory ('''not''' the pristine directory), either manually with the <code>patch</code> command, or in the <code>PKGBUILD</code> (described below) and test the changes from there.<br />
# Change back to the <code>src</code> directory.<br />
# Run <code>diff -aur package.pristine package.new</code> This will output all the changes you made in unified diff format. You can scan these to make sure the patch is good.<br />
# Run <code>diff -aur package.pristine package.new > package.patch</code> to capture all the changes in a file named <code>package.patch</code>. This is the file that will be used by patch. You may now apply the changes to a copy of the original directory and make sure they are working properly. You should also check to ensure that the patch does not contain any extraneous details. For example, you don't want the patch to convert all tabs in the files you edited to spaces because your text editor did that behind your back. You can edit the patch either using a text editor, or to be safer (and not accidentally introduce errors into the diff file), edit the original files and create the patch afresh.<br />
<br />
===Applying patches===<br />
This section outlines how to apply patches you created or downloaded from the Internet from within a <code>PKGBUILD</code>'s <code>build()</code> function. Follow these steps:<br />
<br />
# Add an entry to the <code>source</code> array of the <code>PKGBUILD</code> for the patch file. If the file is available online, you can provide the full URL and it will automatically be downloaded and placed in the <code>src</code> directory. If it is a patch you created yourself, or is otherwise not available, you should place the file in the same directory as the <code>PKGBUILD</code> file, and just add the name of the file to the source array so that it is copied into the <code>src</code> directory. If you redistribute the <code>PKGBUILD</code>, you should, of course, include the patch with the <code>PKGBUILD</code>.<br />
# Create the <code>build()</code> function in the <code>PKGBUILD</code>. In most cases you will want to apply the patch first thing in the function, but you will know best where the patch lines need to be applied.<br />
# The first step in is to change into the directory that needs to be patched (in the <code>build()</code> function, not on your terminal! You want to automate the process of applying the patch). You can do this with something like <code>cd $startdir/src/$pkgname-$pkgver</code> or something similar. <code>$pkgname-$pkgver</code> is often the name of a directory created by untarring a downloaded source file, but not in all cases.<br />
# Now you simply need to apply the patch from within this directory. This is very simply done by adding <code>patch -p1 -i ../pkgname.patch</code> to your <code>build()</code> function, changing <code>pkgname.patch</code> to the name of the file containing the diff (the file that was automatically copied into your <code>src</code> directory because it was in the <code>source</code> array of the <code>PKGBUILD</code> file).<br />
#Run <code>makepkg</code> (from the terminal now). If all goes well, the patch will be automatically applied, and your new package will contain whatever changes were included in the patch. If not, you may have to experiment with the <code>-p</code> option of patch. read <code>man patch</code> for more information.<br />
Basically it works as follows. If the diff file was created to apply patches to files in <code>myversion/</code>, the diff files will be applied to <code>myversion/file</code>. You are running it from within the <code>yourversion/</code> directory (because you cd'd into that directory in the <code>PKGBUILD</code>), so when patch applies the file, you want it to apply it to the file <code>file</code>, taking off the <code>myversion/</code> part. <code>-p1</code> does this, by removing one directory from the path. However, if the developer patched in <code>myfiles/myversion</code>, you need to remove two directories, so you use <code>-p2</code>.<br />
<br />
If you don't apply a -p option, it will take off all directory structure. This is ok if all the files are in the base directory, but if the patch was created on <code>myversion/</code> and one of the edited files was <code>myversion/src/file</code>, and you run the patch without a <code>-p</code> option from within <code>yourversion</code>, it will try to patch a file named <code>yourversion/file</code>.<br />
<br />
Most developers create patches from the parent directory of the directory that is being patched, so <code>-p1</code> will usually be right.</div>Rclhttps://wiki.archlinux.org/index.php?title=Graphical_GRUB&diff=11176Graphical GRUB2006-04-10T18:06:47Z<p>Rcl: /* Current Issues */</p>
<hr />
<div>[[Category:Boot Process]]<br />
<br />
<br />
== Introduction ==<br />
This is a mod to the current grub package found on Arch base repository which adds support for a splash image (a background).<br />
<br />
While the patch is not officially supported by grub developers due to their policy of only bugfixes on their grub 0.9x series, it is used by many distributions like Fedora/Red Hat, SuSE, Gentoo, MEPIS, and others. The patch I use is based on the one included by Fedora Core 3 grub srpm and rediffed to the latest vanilla grub version.<br />
<br />
After the installation is done, you will have a grub screen with the following background.<br />
http://www.mundolink.net/users/mariov/images/arch-grub-096.png<br />
<br />
<br />
Due to demand, the old splash image is optionally available for those who like it more.<br />
http://www.mundolink.net/users/mariov/images/arch-grub.png<br />
<br />
'''New:''' In addition to the standard package, a new alternate one is available for those who follow the [[Reiser4FShowto]] steps and want a grub package with both reiserfs4 and splashimage.<br />
<br />
== Pre Install Notes ==<br />
# Make a copy of your menu.lst for backup. It is not replaced by the installation steps below, unless you remove your current grub package.<br />
# We are dealing with your boot system info, so there is a small chance that things can be screw up. But I haven't got any issue.<br />
# If want to compile the package with the old splash image, or your custom splash image instead of the current one, you need to edit the PKGBUILD and change the md5sum assigned to <code>splash.xpm.gz</code>.<br />
# The alternate package with reiser4 requires '''libaal''', '''reiser4progs''', and a '''reiser4 patched kernel'''. Those are not on Arch repos, you can get them and read about all the process involved on [[Reiser4FShowto]], or grab my updated PKGBUILDs:[http://www.mundolink.net/users/mariov/arch/packages/libaal/PKGBUILD libaal], and [http://www.mundolink.net/users/mariov/arch/packages/reiser4progs/PKGBUILD reiser4progs].<br />
<br />
<br />
== Installation ==<br />
'''Note:''' Reiser package not updated since reiser patch need to be rediffed.<br />
Files changed for 0.97-1: <code>PKGBUILD</code>, <code>menu.lst</code>.<br />
<br />
<br />
1. Grab the following files and save them on a folder on your <code>/var/abs/local</code> path:<br />
* [http://www.mundolink.net/users/mariov/arch/packages/grub/PKGBUILD PKGBUILD]. For reiser4 support, please get [http://www.mundolink.net/users/mariov/arch/packages/grub/reiser4/PKGBUILD this PKGBUILD] instead<br />
* [http://www.mundolink.net/users/mariov/arch/packages/grub/menu.lst menu.lst]<br />
* [http://www.mundolink.net/users/mariov/arch/packages/grub/install-grub install-grub], or copy it from <code>/var/abs/base/grub/install-grub</code><br />
* [http://www.mundolink.net/users/mariov/arch/packages/grub/grub-0.96-graphics.patch grub-0.96-graphics.patch]<br />
* [http://www.mundolink.net/users/mariov/arch/packages/grub/splash.xpm.gz splash.xpm.gz], or if you prefer the previous one, then get [http://www.mundolink.net/users/mariov/arch/packages/grub/old/splash.xpm.gz splash.xpm.gz]<br />
* '''Only for reiser4 support:''' grab the [http://www.mundolink.net/users/mariov/arch/packages/grub/reiser4/grub-0.96-reiser4.patch reiser4 patch]<br />
<br />
<br />
2. Build the package:<br />
# makepkg <br />
<br />
<br />
3. Install the package:<br />
# pacman -U grub-0.97-1.pkg.tar.gz <br />
<br />
<br />
4. Edit your <code>menu.lst</code> and add the following splash instruction anywhere before your OS's menu entries:<br />
splashimage /boot/grub/splash.xpm.gz<br />
For example:<br />
# general configuration:<br />
timeout 5<br />
default 0<br />
splashimage /boot/grub/splash.xpm.gz<br />
'''Important:''' Since grub 0.96-4 the splash path is <code>/boot/grub/splash.xpm.gz</code> and not <code>/grub/splash.xpm.gz<code>. Previous users need to correct the path.<br />
<br />
<br />
5. Install the new grub boot images to your <code>/boot</code> dir. Change ''x'' with your boot drive letter (ie. <code>hda</code>):<br />
# install-grub /dev/hd''x'' (or sd''x'')<br />
<br />
6. '''ONLY''' if your system dual boot '''AND''' your primary boot loader is '''NTLDR''' - remember to update your boot binary file (<code>dd if=/dev/hdx of=/linux.bin bs=512 count=1</code>) and copy the file to your NTFS boot partition. If you don't know what I'm talking, don't worry and just skip this step.<br />
<br />
<br />
== Troubleshooting ==<br />
==== Black display menu visible ====<br />
Stages probably not updated, try again <code>install-grub ''(your partition where /boot belongs, or MBR)''</code>. To check if your stage2 supports splash image, use [http://ruslug.rutgers.edu/~mcgrof/grub-images/checksplash.sh checksplash.sh] script.<br />
<br />
==== Black display, no menu, or corrupted display ====<br />
Check the splashimage instruction. If you have a separate <code>/boot</code> partition try <code>splashimage /grub/splash.xpm.gz</code>. Also check that you have a <code>splash.xpm.gz</code> in grub's dir.<br />
<br />
<br />
== FAQ ==<br />
==== 1. Can I use my custom image in grub? ====<br />
Yes, but it need to fullfill these requisites: 640x480 resolution, 14 color xpm picture gziped compressed.<br />
<br />
==== 2. Do I need to recompile or reinstall grub when changing a splash? ====<br />
Any splash can be used at any time, and no compilation is required after this package is installed, just replace <code>splash.xpm.gz</code> with another one, or edit <code>menu.lst</code> and change the path of splashimage instruction to match the desired picture to show.<br />
<br />
==== 3. I currently use lilo, can I replace it with grub? ====<br />
Yes you can, but AFAIK the menu.lst get your drive partition info on Arch installation and not grub installation (and same applies to <code>lilo.conf</code>). So you need to edit the menu.lst after package installation and add your boot device and kernel image configuration. That kind of problem is beyond the scope of this guide. If that's your case, first get working the the standard grub package on the current repository, and then update to this package. For more info or sample grub configs check [[Grub]] or [http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=10#doc_chap2 Gentoo Handbook - Configure the bootloader].<br />
<br />
==== 4. Where can I get more information about splash images on grub? ====<br />
[http://ruslug.rutgers.edu/~mcgrof/grub-images/ GNU Grub Splashimage Howto] - General Grub bootsplash info and sample images.<br><br />
[http://ruslug.rutgers.edu/~mcgrof/grub-images/checksplash.sh checksplash.sh] - script that check if your stage2 support splashimage.<br />
<br />
==== 5. I would like to test your package, but do not know how to build one? ====<br />
Simply, download the [http://www.mundolink.net/users/mariov/arch/packages/grub/grub-0.97-1.pkg.tar.gz pre-compiled package] and install it using step 3, 4 and 5 of the Installation guide. :-)<br />
<br />
<br />
== Current Issues ==<br />
None at the moment.<br />
<br />
== TODO ==<br />
I will investigate the patch used by SuSE/Novell. It is a new modified one that allows for a greater resolution (not just 640x480) and more fancy stuff like menus. But that will means a heavy modifed grub install, and thus completely sure it will not be accepted on Arch repos, and please don't ask when it will be done.<br />
<br />
<br />
== Change Log ==<br />
2005-05-16 Updated to 0.97<br><br />
2005-03-02 Added alternate PKGBUILD with reiser4 support and related grub patch.<br><br />
2005-02-27 PKGBUILD 0.96-4, Fix splashimage path issue by adding a boot symlink on boot.<br><br />
2005-02-26 Fixed some document steps.<br><br />
2005-02-04 Provided old splash image for those who like it more.<br><br />
2005-02-03 PKGBUILD 0.96-3, removed dependency on gzip. Splash is taken from $startdir instead of the uncompressed one on <code>$statdir/src</code>. Pre-compiled package provided. (FAQ question #4).<br><br />
2005-02-02 Updated to grub 0.96, rediffed patch, new splash based on tpowa's KDE 3.4 wallpaper.<br><br />
2005-01-09 Added autoreconf entry to fix compilation of new files added by patch. Update to FAQ.<br><br />
2005-01-06 First public release of PKGBUILD based on grub 0.95.<br><br />
<br />
<br />
----<br />
<br />
Hope you enjoy it.<br />
<br />
[http://bbs.archlinux.org/viewtopic.php?t=9081&highlight= Original by '''darkcoder''']<br><br />
Wikified by [[User:Romashka|Romashka]].</div>Rcl