Overcoming the EXT3 32k Subdirectories limitation for ZENworks 7.x Linux Management Server Package Repository




A ZENworks Linux Management server can be installed on the supported Server platform with EXT3 file system. The package repositories for the ZENworks Linux Management server can be hosted either on a local device or a remote device that has the EXT3 file system.

In ZENworks Linux Management, the path to the package repository on the Primary Server and the Secondary Servers is /var/opt/novell/zenworks/pkg-repo/ . The rpm packages imported as content of any package bundle are stored in the packages directory under the package-repository path on the ZENworks Server. The package directory organizes the packages based on the hexadecimal 4 char directory names such as '30d1'. These directories contain zero or more rpm packages which are imported from any package bundle. This package repository on the ZENworks Primary Server is also replicated to all the ZENworks Secondary Servers during the content replication action.


The EXT3 file system can have only 32000 subdirectories under a given directory. Therefore, on a ZENworks Linux Management server installed on an EXT3 file system, the package management backend cannot create more than 32000 subdirectories under the /var/opt/novell/zenworks/pkg-repo/packages directory, for storing the packages that are imported through the package bundles.

System Environment

The solution explained in this document is applicable for the ZENworks 7.2 Linux Management and the ZENworks 7.3 Linux Management servers.

Note: This solution might not be required for package repositories on other file systems such as Reiserfs and XFS. This is because these file systems do not have a limitation of 32000 subdirectories. However, you can still perform the package repository cleaning process to free the disk space on ZENworks Server.


You can overcome the limitation of the EXT3 file system by doing any of the following:

Note: Another way to overcome the limitation of 32000 subdirectories for the EXT3 file system is to increase the directories i-nodes maximum count to 65500 for the EXT3 kernel module, then recompile and build the new kernel from existing kernel sources. This new kernel, on loading, allows you to create a maximum of 65500 subdirectories under a given directory.
This has been successfully tested on SLES10 (kernel = and RHEL4 (kernel = 2.6.9-69) devices with an EXT3 partition . On upgrading the kernel package, these changes are lost, and the new kernel must be recompiled again.
This proposed solution of patching the kernel source and recompiling the new kernel is officially not supported by Novell for the ZLM Servers with the EXT3 file systems. For more information here, you can email your queries to tarvindkumar [at] novell [dot] com.

Cleaning the ZENworks Package Repository

Cleaning the package repository is only a temporary solution to overcome the directories limitation of the EXT3 file system. This depends on the number of bundle versions and packages that are associated to bundles or are dangling in the repository.

By cleaning the Package Repository, you can reduce the risk of reaching the 32000 limitation for package directories on the ZENworks Server. The directories that are created within the /var/opt/novell/zenworks/pkg-repo/packages directory on the ZLM Server are also reduced. You can, therefore, import more packages into the package repository through bundles.

To clean the local package repository, it is recommended to do the following:

  • Delete the obsolete package bundles that are already deployed and installed on the managed devices and might not be needed for future deployments.

  • Delete the unused package bundles that are not assigned to any devices, or are used only as part of outdated catalogs . For example, you can delete the bundles that are related to some old updates, patches, applications etc, assuming that these bundles will no longer be used for future deployments .

  • Delete those bundle versions from ZCC that might not be deployable any more.

On deleting the package bundles, the packages are orphaned in the package repository if they are not associated with any other bundles. After removing the bundles or bundle versions, you can clean up the Orphan RPM packages from the ZLM Server's package repository by using either the ZCC or zlman commands.

To clean up the orphan RPM packages by using ZENworks Control Center:

  • In ZENworks Control Center, click Tools.

  • In the Management Zone Settings panel, click the Package List category to list all the imported packages in the repository.

  • Search and delete all the Orphaned RPM Packages from the package repository.

Empty directories are created within the /var/opt/novell/zenworks/pkg-repo/packages/ directory. To clean up these empty directories on the ZENworks Primary Server that has the local package repository, run the following shell script on the ZLM Server:

>>>>>>>>>>>>Package -Empty-Directories - Cleanup-Script>>>>>>>>>>>>

cd /var/opt/novell/zenworks/pkg-repo/packages/
echo "-----------------------------------------------" > $logfile
echo -n "Total packages repository directories count at `date` is : " >> $logfile
find -depth -type d -exec ls -ld {} \; | wc -l >> $logfile
#list all empty directories
echo "Logging the packages empty directories under the path : `pwd`"
echo -n "Total empty directories found under packages are : " >> $logfile
find -depth -type d -empty -exec ls -ld {} \; | wc -l >> $logfile
find -depth -type d -empty -exec echo {} \; >> $logfile
#delete empty directory under packages
echo "Deleting the packages empty directories under the path : `pwd` "
/usr/bin/perl -MFile::Find -e"finddepth(sub{rmdir},'.')"
#alternative way to delete empty directories
#find -depth -type d -empty -exec rmdir {} \
echo -n "Total packages directories count after deleting is : " >> $logfile
find -depth -type d -exec ls -ld {} \; | wc -l >> $logfile

The /var/opt/novell/log/zenworks/pkg-repo-cleanup.log file that is created lists the package directories available before and after cleaning the package repository.

Configuring a non EXT3 File System as a Package Repository

You can configure a non EXT3 file system as a ZENworks Package Repository by adding an additional disk or a new volume, and then migrate the package repository data from the EXT3 file system to the new file system. The new file system can be a Reiserfs or XFS file system.

To configure and migrate the package repository data:

  1. Stop the ZLM services on the ZENworks Primary Server or Secondary Servers, if any.

  • Add a new volume to the device that has the ZLM Server.

  • Create a device partition with the new file system.

  • Mount this file system to another directory located on the server and create packages directory under it.

    For example, mount the file system partition to the /data directory on the server and create /data/packages directory.

  • Copy the content under the /var/opt/novell/zenworks/pkg-repo/packages directory to the new /data/packages directory.

    For example, find /var/opt/novell/zenworks/pkg-repo/packages -depth -type d -exec cp -rp {} "/data/packages" \;

  • Copy the remaining directories under the path /var/opt/novell/zenworks/pkg-repo/ to /data directory on the new file system.

  • Backup or delete the /var/opt/novell/zenworks/pkg-repo/ directory and create a new /var/opt/novell/zenworks/pkg-repo/ directory, retaining the original attributes and ownership of this directory.

  • Unmount the /data directory that you created in Step 4.

  • Mount the new file system again to the /var/opt/novell/zenworks/pkg-repo/ directory.

    Note: You must see /var/opt/novell/zenworks/pkg-repo/packages directory with all its subdirectories as it existed in the old file system. Ensure that the permissions and ownership attributes for the /var/opt/novell/zenworks/pkg-repo/ directory and its subdirectories are preserved on the new file system.

  • Add the /var/opt/novell/zenworks/pkg-repo entry in the /etc/fstab file so that it is automatically mounted on device start.

  • Restart the ZLM services on the ZENworks Primary Server and Secondary Servers, if any.

Promoting a Secondary Server to a Primary Server

You can choose the disaster recovery process to promote a Secondary Server to a Primary Server only if no Secondary Servers with the EXT3 file system exist in the Management Zone.

Do the following:

  1. Add a new Secondary Server with a non EXT3 file system to the existing Primary Server.

  • Perform the Content Replication of the ZENworks Package Repository to this new Secondary Server.

  • Detach the old Primary Server from the Management Zone and allow the new Primary Server to manage all the devices that are registered to it.


Reviewer: Shubhashree D - Technical writer, Novell, Inc.


How To-Best Practice
Comment List