[pkg-discuss] How to retain the content of old /kernel/drv/fp.conf
Kevin Yu
while upgrading
OpenSolaris by using 'pkg update' or bfu utility even if there is no
change since last
installation and upgrade. I did not find such a solution in the manifest
file and pkg(5)
man page.
Please let me know if you have any ideas.
Thanks in advance.
-Kevin
_______________________________________________
pkg-discuss mailing list
pkg-d...@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Bart Smaalders
> I am focusing on a work to retain the content of old /kernel/drv/fp.conf
> while upgrading
> OpenSolaris by using 'pkg update' or bfu utility even if there is no
> change since last
> installation and upgrade. I did not find such a solution in the manifest
> file and pkg(5)
> man page.
Let's ignore BFU - it's no longer supported.
What are you trying to do?
This file is marked editable (preserve=true), so from the
pkg(5) man page:
preserve This specifies that the file's contents should not be
overwritten on upgrade if they are determined to have
changed since it was installed or last upgraded.
If the value of this attribute is 'renameold', then the
existing file will be renamed, and the new file will be put
in its place.
If the value of this attribute is 'renamenew', then the
existing file will be left alone, and the new file will be
installed with a new name.
If the value of this attribute is 'strawberry', then the
existing file will be left alone, and the new file will not
be installed.
The latter is true for any value such as true as well, btw.
- Bart
--
Bart Smaalders Solaris Kernel Performance
bart.sm...@oracle.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
Shawn Walker
> I am focusing on a work to retain the content of old /kernel/drv/fp.conf
> while upgrading
> OpenSolaris by using 'pkg update' or bfu utility even if there is no
> change since last
> installation and upgrade. I did not find such a solution in the manifest
> file and pkg(5)
> man page.
Why do you need to preserve the file if it hasn't been changed from what
we delivered to the system?
-Shawn
Kevin Yu
> On 01/ 4/11 05:56 PM, Kevin Yu wrote:
>> I am focusing on a work to retain the content of old /kernel/drv/fp.conf
>> while upgrading
>> OpenSolaris by using 'pkg update' or bfu utility even if there is no
>> change since last
>> installation and upgrade. I did not find such a solution in the manifest
>> file and pkg(5)
>> man page.
>
> Why do you need to preserve the file if it hasn't been changed from
> what we delivered to the system?
>
> -Shawn
Channel disk and MPxIO
is disabled before upgrade (via entry 'mpxio-disable=yes' in fp.conf),
the device path
is in form of '/dev/dsk/c4t256000C0FFDA7AF9d1s2', but if we overwrite
the old fp.conf,
the device path will be changed to a form like
'/dev/dsk/c0t600144F0C44D70C500004D11C3C90002d0s2',
then the root file system fails at boot time, this is a sever problem
for users.
-Kevin
Bart Smaalders
>>
> Because users might boot the root file system from a remote Fibre
> Channel disk and MPxIO
> is disabled before upgrade (via entry 'mpxio-disable=yes' in fp.conf),
> the device path
> is in form of '/dev/dsk/c4t256000C0FFDA7AF9d1s2', but if we overwrite
> the old fp.conf,
> the device path will be changed to a form like
> '/dev/dsk/c0t600144F0C44D70C500004D11C3C90002d0s2',
> then the root file system fails at boot time, this is a sever problem
> for users.
Sigh.
Actually, the system will boot (since boot loader mounts root
filesystem), but your point is valid anyway.
Note that users run the current packaging system on the
their box to update to the new version; we can "back publish"
new versions if needed, but for development bits this is a real
pain.
Easiest way forward is for us to add a new meaning for preserve,
say "always". A couple (at least) of builds later, you can
start using this, provided your driver contains a origin dependency that
specifies the version in which we introduced support for the
new flag. This way anyone running an old build will upgrade first
to a version that supports the minimum level of pkg that is needed
to upgrade correctly.
Alternatively, you could add a compatibility mode to your driver that
creates both paths if it detects that they exist already in
devfs.
- Bart
--
Bart Smaalders Solaris Kernel Performance
bart.sm...@oracle.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
Kevin Yu
Could you please explain a little bit of following statement? I have no
ideas.
" provided your driver contains a origin dependency that specifies the
version in which we introduced support for the
new flag. "
I am looking forward to starting using such a new value for preserve,
what could
I do next? file a new RFE in bugster?
Thanks,
Kevin
>
> Alternatively, you could add a compatibility mode to your driver that
> creates both paths if it detects that they exist already in
> devfs.
>
> - Bart
>
>
>
>
>
_______________________________________________
Bart Smaalders
We will add preserve=always feature in the packaging gate.
Here's the issue:
When you update from one build to another, it uses the packaging
code from the build you're updating - NOT the build to which you're
updating. As a result, everyone who updates to a build containing
mpxio enabled by default MUST already be running BOTH a version of
the packaging system that understands preserve=always AND a version
of fp.conf that contains preserve=always.
Since not everyone upgrades to each build (people skip builds for
various reasons), it is not safe to just put everything back in
sequence, because if someone upgrades their machine from say
156, they will get the new version of fp.conf no matter what,
breaking their system.
As a result, you can use a dependency type which we call origin.
From the pkg(5) man page:
> Depend actions
> The 'depend' action represents an inter-package dependency. A package
> may depend on another package because the first requires functionality
> in the second for the functionality in the first to work, or even to
> install. Dependencies may be optional.
>
> The following attributes are recognized:
>
> type The type of the dependency.
>
....
> If the value is 'origin', the dependency must, if present,
> be at the specified value or better on the image to be modified
> prior to installation. If the value of the 'root-image' attribute
> is 'true', the dependency must be present on the image rooted at '/'
> in order to install this package.
What this does is allow you to place an origin dependency in the fp
package on the version of fp that first contained the preserve=always.
[Remember that when upgrading, the value of preserve from the file
being updated from is used, rather than the build being updated to!]
This will insure that if someone hasn't updated recently, they will
first (automatically) update to the build containing preserve=always
(and the updated version of pkg that supports it!), before updating
again to the latest available build.
- Bart
--
Bart Smaalders Solaris Kernel Performance
bart.sm...@oracle.com http://blogs.sun.com/barts
"You will contribute more with Mercurial than with Thunderbird."
"Civilization advances by extending the number of important
operations which we can perform without thinking about them."
Kevin Yu
Is there any CR that I could follow up? how long will it be supported?
Once this feature is done in pkg, I will continue to work on my RFE.
Thanks,
Kevin
_______________________________________________
Kevin Yu
I am involving you in this thread to get more advice if you have
any alternatives besides packaging approach as Bart commented.
Please find our discussion from the following link with subject
"[pkg-discuss] How to retain the content of old /kernel/drv/fp.conf"
http://mail.opensolaris.org/pipermail/pkg-discuss/2011-January/subject.html#25247
Thanks,
Kevin
----- Original Message -----
From: bart.sm...@oracle.com
To: kevin...@oracle.com
Cc: pkg-d...@opensolaris.org
Sent: Friday, January 14, 2011 12:08:05 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi
Subject: Re: [pkg-discuss] How to retain the content of old /kernel/drv/fp.conf
On 01/12/11 19:48, Kevin Yu wrote:
> Thanks for your explanation, Bart.
>
> Is there any CR that I could follow up? how long will it be supported?
> Once this feature is done in pkg, I will continue to work on my RFE.
Perhaps we could discuss alternatives w/ Jan Setje-Eilers... packaging
can solve your immediate problem, but other issues are likely to arise
when you want to make other changes in fp.conf.
- Bart
--
Bart Smaalders Solaris Kernel Performance
bart.sm...@oracle.com http://blogs.sun.com/barts
"You will contribute more with Mercurial than with Thunderbird."
"Civilization advances by extending the number of important
operations which we can perform without thinking about them."