The local7 facility is used to write into the /var/log/boot.log file.
But since the Fedora core 4, the system has been disabled waiting for a new generation system which does not seem to be available yet (see this bug report and this one)
A quick way to fix the empty /var/log/boot.log file, is to edit the /etc/rc.d/init.d/functions file.
Into the success, failure, passed and warning functions, you can add a line like the following, just before the return instruction:
/usr/bin/logger -p local7.info "$1"
It works but each time the initscripts package is updated, it is needed to edit the file ...
23 February 2008
Make Red Hat Graphical Boot detailed
There is unfortunately no configuration file allowing to switch on/off the details of Red Hat Graphical Boot.
Anyway, for it to be detailed, the /etc/rc.d/init.d/functions can be edited:
- simply add --details=yes into the update_boot_stage function on the line using the /usr/bin/rhgb-client.
It works but each time the initscripts package is updated, it is needed to edit the file ...
Anyway, for it to be detailed, the /etc/rc.d/init.d/functions can be edited:
- simply add --details=yes into the update_boot_stage function on the line using the /usr/bin/rhgb-client.
It works but each time the initscripts package is updated, it is needed to edit the file ...
22 February 2008
Updating courier-imap configuration
By default, the courier-imap creates pop3 (110), pop3s (995), imap (143) and imaps (993) servers.
Generally, they are not all needed, and for obvious security reasons, it is better to not start useless servers.
Under GNU/Linux Fedora, the corresponding configuration files, which are under /usr/lib/courier-imap/etc/, are respectively pop3d, pop3d-ssl, imapd and imapd-ssl.
Into each, there is a variable XXXSTART (with XXX corresponding to POP3D, POP3DSSL, IMAPD or IMAPDSSL) which can be YES or NO.
To not start such a server, it is enough to replace corresponding YES by NO.
Finally, restart the courier-imap service.
Generally, they are not all needed, and for obvious security reasons, it is better to not start useless servers.
Under GNU/Linux Fedora, the corresponding configuration files, which are under /usr/lib/courier-imap/etc/, are respectively pop3d, pop3d-ssl, imapd and imapd-ssl.
Into each, there is a variable XXXSTART (with XXX corresponding to POP3D, POP3DSSL, IMAPD or IMAPDSSL) which can be YES or NO.
To not start such a server, it is enough to replace corresponding YES by NO.
Finally, restart the courier-imap service.
Upgrade GNU/Linux Fedora from core 6 to 7, then 8 (with yum)
To upgrade GNU/Linux Fedora from core 6 to 7, then 8, there is no [really] problem today.
It was not the case when I've tried it as soon as Fedora 7 was available, but I've successfully performed such an upgrade without difficulties some days ago.
The principle is globally the same when upgrading from Fedora core N to Fedora core N+1 (see this post), or from Fedora 7 to Fedora 8 (see this post).
In addition, the recommendations of Fedora project have greatly evolved and seem now complete.
This is some additional instructions in case you have specific issues (like I had):
Update your /etc/fstab file:
It is very important to use label (LABEL=myLabel) to identity your device instead of path (/dev/xxx). The identification has changed from Fedora core 6 to Fedora 7, generally from /dev/hdX to /dev/sdY BUT there is absolutely no certainties that X and Y will equal between versions.
Using labels ensure your mount points are always the same.
Particularly it ensures your root partition (/) will be the good, and your computer will well boot after upgrade.
To update the label of a device, you can use the tune2fs command.
Upgrade from Fedora core 6 to Fedora 7:
- do not forget to clean all the yum metadata with yum clean all,
- upgrade the Fedora release:
rpm -Uhv ftp://download.fedora.redhat.com/pub/fedora/linux/releases/7/Fedora/i386/os/Fedora/fedora-release*.noarch.rpm
- upgrade your repository, for instance for livna:
rpm -Uvh http://rpm.livna.org/livna-release-7.rpm
- remove and reinstall authconfig to avoid specific issue.
Upgrade from Fedora 7 to Fedora 8:
- do not forget to clean all the yum metadata with yum clean all,
- upgrade the Fedora release:
rpm -Uvh http://mirror.anl.gov/pub/fedora/linux/releases/8/Everything/i386/os/Packages/fedora-release-*.noarch.rpm
- upgrade your repository, for instance for livna:
rpm -Uvh http://rpm.livna.org/livna-release-8.rpm
Ensure there is no dependencies problem like explained into this post.
Then, you should perform a great configuration files merging campaign to ensure having the up to date functionalities while keeping your own specific configuration (globally the XXX.conf and XXX.conf.rpmnew files).
It was not the case when I've tried it as soon as Fedora 7 was available, but I've successfully performed such an upgrade without difficulties some days ago.
The principle is globally the same when upgrading from Fedora core N to Fedora core N+1 (see this post), or from Fedora 7 to Fedora 8 (see this post).
In addition, the recommendations of Fedora project have greatly evolved and seem now complete.
This is some additional instructions in case you have specific issues (like I had):
Update your /etc/fstab file:
It is very important to use label (LABEL=myLabel) to identity your device instead of path (/dev/xxx). The identification has changed from Fedora core 6 to Fedora 7, generally from /dev/hdX to /dev/sdY BUT there is absolutely no certainties that X and Y will equal between versions.
Using labels ensure your mount points are always the same.
Particularly it ensures your root partition (/) will be the good, and your computer will well boot after upgrade.
To update the label of a device, you can use the tune2fs command.
Upgrade from Fedora core 6 to Fedora 7:
- do not forget to clean all the yum metadata with yum clean all,
- upgrade the Fedora release:
rpm -Uhv ftp://download.fedora.redhat.com/pub/fedora/linux/releases/7/Fedora/i386/os/Fedora/fedora-release*.noarch.rpm
- upgrade your repository, for instance for livna:
rpm -Uvh http://rpm.livna.org/livna-release-7.rpm
- remove and reinstall authconfig to avoid specific issue.
Upgrade from Fedora 7 to Fedora 8:
- do not forget to clean all the yum metadata with yum clean all,
- upgrade the Fedora release:
rpm -Uvh http://mirror.anl.gov/pub/fedora/linux/releases/8/Everything/i386/os/Packages/fedora-release-*.noarch.rpm
- upgrade your repository, for instance for livna:
rpm -Uvh http://rpm.livna.org/livna-release-8.rpm
Ensure there is no dependencies problem like explained into this post.
Then, you should perform a great configuration files merging campaign to ensure having the up to date functionalities while keeping your own specific configuration (globally the XXX.conf and XXX.conf.rpmnew files).
Clean useless packages under 64bits GNU/Linux
It seems there is some dependency "issues" when installing a 64bits GNU/Linux. It is, for instance, the case under Fedora.
Although the architecture of the installed OS is 64bits, there is some i386 or i686 installed packages.
Some are needed, but lots might be removed.
To begin, to get a sorted list of such potential packages, you can use:
rpm -qa --qf "%{NAME}.%{ARCH}\n" |grep -v x86_64 |grep -v noarch |grep -v "(none)" |sort
Then, you can remove all packages you are sure you do not need, but be careful with the dependencies.
To make it quicker, you can request the remove of package(s) you know it is needed by lots of others (like some libraries).
After all of this, ensure there is no dependencies problem. For instance, with yum utilities:
- ensure the database is up to date with rpm --rebuilddb,
- check if there is problem with package-cleanup --problems.
Finally, to complete the cleaning, you can use the package-cleanup --leaves and ensure you need all those "independent" package(s), else remove them.
Personally, I have removed about 150 packages like this.
For information, there is some i386/i686 packages which are needed by x86_64 ones.
It was the case for me with compat-libstdc++-33.i386, libgcc.i386 and glibc.i686.
Although the architecture of the installed OS is 64bits, there is some i386 or i686 installed packages.
Some are needed, but lots might be removed.
To begin, to get a sorted list of such potential packages, you can use:
rpm -qa --qf "%{NAME}.%{ARCH}\n" |grep -v x86_64 |grep -v noarch |grep -v "(none)" |sort
Then, you can remove all packages you are sure you do not need, but be careful with the dependencies.
To make it quicker, you can request the remove of package(s) you know it is needed by lots of others (like some libraries).
After all of this, ensure there is no dependencies problem. For instance, with yum utilities:
- ensure the database is up to date with rpm --rebuilddb,
- check if there is problem with package-cleanup --problems.
Finally, to complete the cleaning, you can use the package-cleanup --leaves and ensure you need all those "independent" package(s), else remove them.
Personally, I have removed about 150 packages like this.
For information, there is some i386/i686 packages which are needed by x86_64 ones.
It was the case for me with compat-libstdc++-33.i386, libgcc.i386 and glibc.i686.
Subscribe to:
Posts (Atom)