The same listing from inside the vserver ("vserver <name> exec ls -lagn /"):
... drwxr-x--- 2 0 0 4096 Nov 19 02:08 service drwxrwxrwt 3 0 0 8192 Mar 27 19:45 tmp drwxr-xr-x 14 0 0 4096 Oct 16 11:36 usr drwxr-xr-x 20 0 0 4096 Oct 15 01:38 var
When updating to the new kernel the files with the long uid's are not properly mapped anymore. We noticed this because mysql wouldn't start in any of the 10 vservers on this system. After chown'ing the related mysql.pid files and directories the mysql server started. But there are tons of files with wrong uid's left, so this wouldn't be a solution, just a temporary patch.
as I see it, you have two options to migrate to 2.4.25/vs1.27
a) change the context tagging of all files to xid=0
- this can be done on the 'old' setup by using the
old chctx tool, or by touching each file from the
host context (xid = 0)
- or with tagxid disabled, using a small script, reading the uid/gid, cropping them to 16 bits
- or by doing an xid agnostic backup (tar, dump)
b) converting the partition to the new context tagging
- again a small script, reading the uid/gid, splitting it into xid/uid/gid and reassembling them to one of the newer formats ...
So I would get the xid by dividing uid and gid by 65536, right?
What would be the right formula for reassembling the id's for vs1.27 + quota?
In a posting I read about three different xid tagging methods: UID32/GID16, UID24/GID24 and UID32/GID32.
I couldn't find a hint when looking at the latest quota patch. _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
