Remote installing

[Willem Jan Withagen]

On 20-8-2011 13:26, Willem Jan Withagen wrote:
> On 2011-08-20 13:15, Willem Jan Withagen wrote:
>> Hi,
>>
>> Today I liked to live dangerously, and want to upgrade a backups server
>> from i386 to amd64. Just to see if we could.
>> And otherwise I'd scap it and install from usb-stick.
>>
>> So I have my server running amd64 build GENERIC.
>> export /, /var, /usr on the server to be upgraded.
>>
>> But upgrading world dus have a snag already early on:
>>
>> ----
>> empty changed
>> flags expected "schg" found "none" not modified: Operation not supported
>> ----
>>
>> This is probably where some program wants to set immutable flag on
>> /var/tmp/empy...
>>
>> But looks like NFS does not grok that.
>>
>> Now I seen plenty of sugestions to do it this way, but never saw anybody
>> come back with this complaint....
>>
>> So I must be ommiting something ??
>
> I looked at the work errors.
> -----------
> cd /mnt/; rm -f /mnt/sys; ln -s usr/src/sys sys
> cd /mnt/usr/share/man/en.ISO8859-1; ln -sf ../man* .
> ln: ./man1: Permission denied
> ln: ./man1aout: Permission denied
> ln: ./man2: Permission denied
> ln: ./man3: Permission denied
> ln: ./man4: Permission denied
> ln: ./man5: Permission denied
> ln: ./man6: Permission denied
> ln: ./man7: Permission denied
> ln: ./man8: Permission denied
> ln: ./man9: Permission denied
> ---------
>
> Which comes from the target distrib-dirs in etc
>
> Why would an ln -sf like that fail....
> the filesystems are exported with -maproot=0

Well turned out that the easiest fix was to run
	chflags -R noschg /
at the client, because certain files are immutable and once you run into 
those, it is hard to fix it after the fact.

Next would be to move /lib and /usr/lib out of the way. So that doesn't 
cause conflict in near future.
Which will cause new programs to start to fail. So better make shure 
that every thing is set before you start upgrading over NFS.

But I did manage to get it "upgraded" from i386 to amd64.

--WjW