When I first load a system:
* built using Angstrom on top of OE-Core
* File system NFS mounted.
it takes about 20 minutes before the boot completes.
I wanted to know why, so I initialized a git tree
in the rootfs, and started doing git diff.
At least for the first minutes, the only result was
diff --git a/usr/share/icons/hicolor/icon-theme.cache
b/usr/share/icons/hicolor/icon-theme.cache
index 04fec3f..075046a 100644
Binary files a/usr/share/icons/hicolor/icon-theme.cache and
b/usr/share/icons/hicolor/icon-theme.cache differ
There are a lof of icon directories, so I suspect that the lion's part
of the long first boot time
is due to creating this cache.
It looks to me like a recipe to update
"/usr/share/icons/*/icon-theme.cache"
in the generated root fs would be good rather than having the much
slower target do it.
-------------------------------------------------------------------------------------------------------
There are alredy such files in the root fs, but when I compare what the
size of
"/usr/share/icons/hicolor/icon-theme.cache" in the tarball, with the file
after the boot, it has grown from 64 kB to close to 1 MB.
Apparently running "/usr/bin/gtk-update-icon-cache" will update the
icon-theme.cache file.
Checked the sources directory of Angstrom, and there are only a few
recipes to generate
icon-themes:
./meta-smartphone/meta-shr/recipes-shr/shr/icon-theme-neo_git.bb
./meta-angstrom/recipes-tweaks/themes/angstrom-gnome-icon-theme-enable.bb
./meta-openembedded/meta-gnome/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.12.bb
./meta-openembedded/meta-xfce/recipes-art/xfce4-icon-theme/xfce4-icon-theme_4.4.3.bb
./openembedded-core/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
./openembedded-core/meta/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.12.bb
./openembedded-core/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb
Looked at
"meta-openembedded/meta-gnome/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.12.bb"
and found no trace of any icon-theme generation, but there still appears
to be a small one there
Looking through the file system of an image derived from
systemd-GNOME-image I found
-rw-r--r-- 1 root root 137204 2012-02-06 00:06 Crux/icon-theme.cache
-rw-r--r-- 1 root root 53067356 2012-02-06 00:07 gnome/icon-theme.cache
-rw-r--r-- 1 root root 972016 2012-02-06 00:07 hicolor/icon-theme.cache
-rw-r--r-- 1 root root 1444280 2012-02-06 00:06
HighContrastLargePrint/icon-theme.cache
-rw-r--r-- 1 root root 1661336 2012-02-06 00:06
HighContrastLargePrintInverse/icon-theme.cache
-rw-r--r-- 1 root root 155260 2012-02-06 00:06
HighContrast-SVG/icon-theme.cache
-rw-r--r-- 1 root root 5348 2012-02-06 00:06
LowContrastLargePrint/icon-theme.cache
-rw-r--r-- 1 root root 5634892 2012-02-06 00:07 Mist/icon-theme.cache
tried running gtk-update-icon-cache on hicolor, and it grew to about the
same size as
the one in a booted machine and this completed almost immediately..
If this is done, before the machine is booted, then the file system
grows by ~63 MB,
so programming the flash will take longer for each machine.
What is uncertain to me, is if it is possible to "cross-update" the icon
cache.
Yet to be tested...
Also, since the file system grows significantly, we need to think if
this is OK or not.
Any thoughts?
Best Regards
Ulf Samuelsson
_______________________________________________
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
