Hi Casper,
Casper.Dik at Sun.COM wrote:
>> Hi Jean, Alok,
>>
>> that service was introduced by Casper's enhancement to SV4R packaging stuff:
>>
>> http://arc.opensolaris.org/caselog/PSARC/2009/173/20090312_casper.dik
>>
>> ...
>>
>> /var/svc/manifest/system/pkgserv.xml
>> - defines svc:/system/pkgserv:default
>> - runs "pkgadm sync -q" at boot and shutdown time.
>> - write the contents file if needed, picks up the pieces
>> if pkgserv is killed, makes sure the pkgserv exits.
>>
>> ...
>>
>> I guess we could just disable it in AI and LiveCD images, but we would need
>> to check with Casper if there are no other dependencies - e.g. if SVR4
>> packaging
>> tools still work correctly even if this SMF service is disabled.
>
> The service serves two purposes:
> - when the system boots and the system wasn't properly shutdown,
> it will roll the contents logfile into the contents file
> - when the system shutdown, it makes sure that "pkgserv" quits;
> the pkgserv will write the contents file to disk before it quits.
>
> For a LiveCD or a AI-install image, I don't see any particular reason
> why it needs to be running: both a LiveCD and a AI-install image will
> not have SVr4 packages installed to the root.
They don't have by default, but we still might want to apply
SVr4 packages to the booted install environment - please see below.
>
>> I saw this on x86 as well as on Sparc in AI/LiveCD images I built for testing
>> purposes. I install testing stuff into proto area by means of SVR4 package
>> tools and I ended up with stale lock files in proto area - not sure why
>> they were not removed.
>
> I'm not sure what a stale lock file looks line; if you use pkgadd to add
> packages to the proto area, you should really run:
>
> pkgadm sync -R /root/dir -q
>
> This makes sure the pkgserv which is started to maintain the contents file
> quits before you unmount or create the image from the proto area.
I see - thank you for pointing this out.
This is what I tried:
[1] Populated Distribution Constructor proto area with IPS packages -
/var/sadm/install/ directory in proto area doesn't contain lock files
which is expected:
# ls -la
/export/home/dc/ai/ai_x86_24-26_126/build_data/pkg_image/var/sadm/install/
total 7
drwxr-xr-x 4 root bin 5 2009-11-06 11:13 .
drwxr-xr-x 8 root sys 9 2009-11-06 11:13 ..
drwxr-xr-x 2 root bin 3 2009-11-06 11:13 admin
-rw-r--r-- 1 root root 0 2009-11-06 11:13 contents
dr-xr-xr-x 2 root bin 2 2009-11-06 11:13 logs
[2] Removed IPS and added SVr4 package to the proto area -
/var/sadm/install/ directory in proto area contains lock files
# pkg -R /export/home/dc/ai/ai_x86_24-26_126/build_data/pkg_image/
uninstall SUNWauto-install
PHASE ACTIONS
Removal Phase 27/27
Deleting content cache
# pkgadd -R /export/home/dc/ai/ai_x86_24-26_126/build_data/pkg_image/ -d
/export/home/dambi/ws/os-install-ai-err-no-pep8/packages/i386/nightly-nd/
SUNWauto-install
[...]
Installation of <SUNWauto-install> was successful.
# pkgadm sync -R
/export/home/dc/ai/ai_x86_24-26_126/build_data/pkg_image/ -q
# ls -la
/export/home/dc/ai/ai_x86_24-26_126/build_data/pkg_image/var/sadm/install/
total 12
drwxr-xr-x 4 root bin 10 2009-11-06 12:09 .
drwxr-xr-x 8 root sys 9 2009-11-06 11:13 ..
-rw-r--r-- 1 root root 0 2009-11-06 12:08 .door
-rw------- 1 root root 128 2009-11-06 12:08 .lockfile
-rw-r--r-- 1 root root 0 2009-11-06 12:08 .pkg.lock
-rw-r--r-- 1 root root 0 2009-11-06 12:08 .pkg.lock.client
drwxr-xr-x 2 root bin 3 2009-11-06 11:13 admin
-rw-r--r-- 1 root root 2086 2009-11-06 12:09 contents
-rw-r--r-- 1 root root 0 2009-11-06 12:08 gz-only-packages
dr-xr-xr-x 2 root bin 2 2009-11-06 12:08 logs
[3] Finished DC build and booted resulting AI ISO image - it contains
lock files:
$ ls -la /var/sadm/install/
total 18
drwxr-xr-x 4 root bin 512 Nov 6 01:08 .
drwxr-xr-x 8 root sys 512 Nov 6 00:54 ..
-rw-r--r-- 1 root root 0 Nov 6 00:47 .door
lrwxrwxrwx 1 root root 36 Nov 6 00:58 .lockfile ->
/mnt/misc/var/sadm/install/.lockfile
lrwxrwxrwx 1 root root 36 Nov 6 00:58 .pkg.lock ->
/mnt/misc/var/sadm/install/.pkg.lock
lrwxrwxrwx 1 root root 43 Nov 6 00:58 .pkg.lock.client
-> /mnt/misc/var/sadm/install/.pkg.lock.client
drwxr-xr-x 2 root bin 512 Nov 6 01:08 admin
lrwxrwxrwx 1 root root 35 Nov 6 00:58 contents ->
/mnt/misc/var/sadm/install/contents
lrwxrwxrwx 1 root root 43 Nov 6 00:58 gz-only-packages
-> /mnt/misc/var/sadm/install/gz-only-packages
dr-xr-xr-x 2 root bin 512 Nov 6 00:47 logs
However, those are just symbolic links to the read-only area:
# mount -p
...
/tmp/solarismisc.zlib - /mnt/misc hsfs - no
ro,nosuid,noglobal,maplcase,rr,traildot
...
This leads to the situation when pkgserv SMF service goes
sometimes to the maintenance mode during boot, but not always.
If I remove those 'dot' files from DC proto area and they don't end up
in the final ISO imageimage, pkgserv is allowed to manipulate them,
since /var/sadm/install/ directory is writable:
$ su -
Password:
# rm /var/sadm/install/.lockfile
# echo $?
0
# touch /var/sadm/install/.lockfile
# echo $?
0
>
> As you surmised, there's no need to run this service on a read-only root.
Actually, root itself is writable (ramdisk), only some portions of
filesystem
(/usr, /mnt/misc) are read-only, as they are hsfs(7F) lofi mounted
compressed archives.
Assuming that we still would like to support installation of SVr4 packages
during the installation process into running installation environment as
well
as on target (e.g. in order to deliver missing third party device driver
which is in SVr4 format), can we still go with pkgserv SMF service disabled
in the installation environment or is there any reason why it should be
enabled ?
Thank you,
Jan
