There is an incompatibility between dhcpcd and the dhcp servers in my Linksys BEFW11S4 original and v4 routers. Converting SuSEs 10.0 and 10.2 from dhcpcd to dhclient solves the problem.

SuSE dhcpd Notes:

• SuSE supplies two clients: dhcpcd and dhclient. man 8 ifup is used to start the configuration and will call either client (via the devices config file).
• There is startup info in /etc/sysconfig/network and also /etc/dhclient.conf. YaST control center doesn’t provide much access to these programs. For example I can’t figure out how to switch from dhcpcd to dhclient, or how to pass different startup parameters to dhcpd.
• Learned from the web that the clients are somewhat interchangeable and that the DHCLIENT_BIN option in /etc/sysconfig/network/dhcp controls this. Can edit this file directly or from YaST /etc/sysconfig editor.
• dhclient would set the host and domainname so I had to turn off those switches as well.

After a recent YOU update to SuSE 10.0, Linux became unable to reacquire a DHCP lease. When booting everything worked, but after the first lease expires, an infinite loop would occur:

Dec 21 21:13:24 sr1650nx dhcpcd[11655]: DHCP_NAK server response
Dec 21 21:13:24 sr1650nx dhcpcd[11655]: DHCP_NAK server response
Dec 21 21:13:25 sr1650nx modify_resolvconf: restored /etc/resolv.conf.saved.by.dhcpcd.eth0 to /etc/resolv.conf
Dec 21 21:13:25 sr1650nx kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
Dec 21 21:13:26 sr1650nx modify_resolvconf: Service dhcpcd modified /etc/resolv.conf. See info block in this file
Dec 21 21:13:26 sr1650nx syslog-ng[11379]: SIGHUP received, restarting syslog-ng
Dec 21 21:13:26 sr1650nx ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Dec 21 21:13:26 sr1650nx ifdown: eth0 configuration: eth-id-00:13:d4:68:7b:1c
Dec 21 21:13:27 sr1650nx ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Dec 21 21:13:27 sr1650nx syslog-ng[11379]: new configuration initialized
Dec 21 21:13:27 sr1650nx syslog-ng[11379]: Changing permissions on special file /dev/xconsole
Dec 21 21:13:27 sr1650nx syslog-ng[11379]: Changing permissions on special file /dev/tty10
Dec 21 21:13:27 sr1650nx dhcpcd[11655]: DHCP_NAK server response received

I assumed that my system had become damaged, since the download was not dhcpcd specific (it was kernel and apparmor). Eventually I decided to install openSuSE 10.2 in a spare partition. It exhibits the same problem.

This eliminates damage specific to my SuSE 10.0 installation and says I have a problem between dhcpcd and my Linksys router/dhcp server.

I have been searching for an open source tool that will synchronize a remote FTP site with my local release directory for my web server code. FrontPage does this quite well under WindowsXP and I wanted a similar Linux capability.

Nvu publishing capability is limited, with the documentation referring the reader to manual FTP programs. I tried several FTP utilities in SuSE 10.0 and found them all lacking in some way:

• gFTP – works well as a manual FTP client but doesn’t offer automatic synchronization.
• kBear – Sitemanager tool is supposed to offer syncing but the KDE documentation doesn’t explain how it works or if/how you save the configuration between runs.
• Krusader – closer but also not clear if/how to save the filter configuration between runs. Doesn’t allow regexp’s in the filter, must enumerate individual files.  Regexp filters are critical for me because of .svn subdirectories.

Today I finally found a Perl script called ftpsync, which I downloaded. It works almost exactly as I would have specified such a tool. I extended it with one switch to control whether files found only on the FTP site are pruned as part of the synchronization. It has no GUI (one could be easily written) but works well enough that it doesn’t need one. Releasing from my staging area to my remote host is now fully automated.

I still think there must be an open source, easy-to-use, GUI-based FTP upload manager available as a standard Linux package; if so, why can’t I locate it?

With the 10.2 release, openSUSE announced a switch from reiserFS to ext3 as their default filesystem format. The reason given was that development work on reiserFS-3 has come to a halt and SuSE was the only Linux distribution championing it. This gave me a twinge of regret as I had dwelled on this decision when formatting my /home filesystem during SuSE 10.0 installation and eventually chose reiserFS.

Even though openSUSE 10.2 will support reiserFS partitions, the handwriting is on the wall. I decided to convert my /home filesystem before upgrading from SuSE 10 to openSUSE 10.2. After rereading a comparison review of the various Linux filesystem formats, I chose ext3.

I have been using star to do backups and was planning to use it to backup to a file, then restore onto a newly created ext3 partition. Then I discovered the Synchronizing Filesystems section in the star man page which describes a direct filesystem to filesystem transfer. No intermediate backup file is required, cutting both the time and chances of error in half.

Conversion Plan:

• Create an ext3 clone of my existing reiserFS /home partition on an unused 30GB partition using star.
• Use this new /home with my current SUSE 10 configuration to be sure the transfer is correct before erasing the data from the reiserFS /home partition. In particular, I want to verify that the symbolic and hard links have been transferred correctly.
• Reformat the old reiserFS 80GB partition to ext3, then run star a second time to move the /home filesystem back onto the 80GB partition.

This procedure requires a spare disk or disk partition, whereas doing a backup & restore to a file only requires enough free space on an existing partition to hold the backup file. But on the plus side, I never destroy my correctly functioning partition until I’ve fully tested the new one. If something goes wrong, I just fall back to previous step and try again.

Command Sequence:

1. umount /export/sda9 # unused partition (currently formatted as reiserFS)
2. mkfs.ext3 -nv /dev/sda9 # look before leaping
   
3. mkfs.ext3 -v /dev/sda9 # reformat as ext3
4. Edit /etc/fstab to change sda9 mount from reiserfs to ext3:
   /dev/sda9 /export/sda9 ext3 defaults 1 2
   
5. mount /export/sda9
6. star -c -xdev -sparse -acl -link-dirs level=0 -C /export/sda8 . |
star -xpU -restore -C /export/sda9 # filesystem sync
   
7. diff -r /export/sda{8,9}/home # verification (takes a while)
   
8. Edit /etc/fstab to convert “bind” mount from sda8/reiserFS to sda9/ext3:
   /export/sda9/home /home ext3 bind 0 0
9. reboot

I ran the new sda9 /home partition for a few weeks to see if any latent problems surfaced. Satisfied that the procedure was sound, I performed the same sequence from sda9 to sda8, ending up with /home back on its original 80GB partition as an ext3 filesystem.

 Yesterday I replaced my failing 1600×1200 monitor with a 2048 capable monitor.  I expected X11/KDE to continue with a 1600×1200 desktop, but noooo.  The new monitor was detected and the desktop was auto-magically reconfigured to 2048×1536.  Fonts and icons were also scaled automatically.  When I switched the resolution back to 1600×1200, icons and fonts became huge,  not looking at all like with the old monitor.

Thus, X11 on SuSE Linux 10.0 continues to plague me.  Things have been off since installing the ATI driver.  Since then, SuSE has chosen to reset the xorg.conf file at least twice for no apparent reason.  And now a non-intuitive, uncontrollable desktop sizing algorithm.

In my experience, WindowsXP always uses the same number of pixels to display something until an administrator makes a change.  So as one changes the graphics card resolution from 1600×12 to 1280×1024, 800×600, objects and fonts on the desktop keep getting bigger (like zooming in).  I’ve never changed a monitor on WinXP and rebooted, so I don’t know what happens.

The KDE/X11 auto-reconfiguration was unacceptable because of the flicker at the 2048 setting.  And, unlike when I installed SuSE, it never asked what resolution I wanted to  be “standard”.  Moreover, as I played around with different resolutions, the fonts became damaged.

Solution: I created a new user (which also defaulted to 2048) and experimented with various settings until I got 1600×1200 to look good.  Then by comparing files, I was able to copy .fonts.conf from the experimental account to fix things.

Settings from  SuSE control center:

1. Display – 1600×1200, 85Hz, apply settings at KDE startup.
2. Fonts – Sans Serif 9 (or Monospace 9) for everything.
3. Icons/Desktop – 32 pixels
4. Icons/Toolbar, Main Toolbar – 22 pixels
5. Icons/Small  –  16 pixels

While this is workable, it’s still not ideal, because the login screen runs at 2048, all new user accounts will have to be manually adjusted, etc.  Presumably there is some way to solve this within the magic xorg.conf file, but its modification date wasn’t changed.  The only files  that changed were /etc/X11/qtrc and qt_plugins.  So once again with X11 and SuSE, I have no idea where it stored all of these changes it made.

Did learn about xdpyinfo, which showed that the monitor had correctly reported its max resolution and the size of the screen (400mm x 300mm).