Problem in rebuilding all ports after major upgrade

A

ArnTA

Hello,

During major upgrade from 9.3-RELEASE-p49 to 10.4-RELEASE-p3, I want to "rebuild all third-party applications" using indications in examples of portmaster():
Code: 
     Using portmaster to do a complete reinstallation of all ports:
           1. portmaster --list-origins > ~/installed-port-list
           2. Update the ports tree
           3. portmaster -ty --clean-distfiles
           4. portmaster -Faf
           5. pkg delete -afy
           6. rm -rf /usr/local/lib/compat/pkg
           7. Back up any files in /usr/local you wish to save,
              such as configuration files in /usr/local/etc
           8. Manually check /usr/local and /var/db/pkg
              to make sure that they are really empty
           9. Install ports-mgmt/pkg and then ports-mgmt/portmaster.
              Remove both from ~/installed-port-list.
           10. portmaster --no-confirm `cat ~/installed-port-list`
but as the ports were not upgraded since more than 1 year, during execution of portmaster -Faf, I meet many problems (sommes ports moved, perl version has changed, etc).

My question is: as the next step is pkg delete -afy, is it important that the step 4 goes to the end?

And is there another way to rebuild all ports more efficiently in this situation of "not uptodate" port tree?
 
Sometimes the best way (and no, it is not more efficient) is to do it this way
a) create a list of all installed ports before the upgrade
b) check (Freshports.org for example) that all portsw you need are still in the ports tree
after the upgrade
c) remove all ports
d) get a new ports tree on the machine and install all ports from your list.
 
I think now would be a good time to evaluate if you want to continue using ports or switch to packages. If you don't change any of the options or deviate from default versions there's nothing to gain by building from ports.
 
And if you only have one or two ports you need to change options for, it might be workable to use packages + only those ports. Note: this is not necessarily a recommended way to do it.
 
Thank you for the help.

I am not sure to remember exactly, but I think I change options for perhaps 10 ports or more.
I think I prefer to stay with ports. Perhaps because I don't know enough about pkg.
For example portmaster --no-confirm `cat ~/installed-port-list`, using packages is it pkg add`cat ~/installed-port-list` ?

tingo said:
a) create a list of all installed ports before the upgrade
b) check (Freshports.org for example) that all portsw you need are still in the ports tree
after the upgrade
c) remove all ports
d) get a new ports tree on the machine and install all ports from your list.
Click to expand...
a) I have 281 installed ports ( I get the list with [CMD pkg info -q][/CMD]). May I reinstall from the list from the output of portmaster --list-origins (only 75 lines) and let dependencies working?
b) so is it possible to script the check from the list in a file?
c) I don't know how to remove the ports. I suppose rm -rf /usr/ports/* is not the good action?
d) This is OK for me, with portsnap as seen in the 4.5 section of the handbook.
 
Finally, I choose to follow the process described in portmaster(), to re-install all ports resolving issues one by one to go to the end of portmaster -Faf. but now, as I am ready to reinstall all the deleted ports, I was deconnected and password is refused when I try to reconnect.

Is it a known issue to loose root access during install?
What can I do to resolve this and connect to my server? it's vmare VM .
 
Ports have no affect on the base system they only get installed to /usr/local so no: there is no change in passwords or user accounts or anything like that.
 
And to stay several days in the middle of the ugrade process before the third freebsd-update install as I do? Is this can generate such a problem?
Actually, this is the second time I have this problem during this major upgrade. First time I start all the procces again from a backup clone.
I would like to avoid to replay it again.
 
ArnTA said:
And to stay several days in the middle of the upgrade process before the third freebsd-update install as I do? Is this can generate such a problem?
Click to expand...
No, things don't spontaneously change, there's always a cause or a reason for it.

Before the install phase, before the download phase even, you are asked if certain things look correctly or not. You typically get these if the automatic merge doesn't work (for whatever reason). Some of the files are /etc/passwd and /etc/groups for example. If you fail to correctly merge those files you can end up removing passwords, user accounts, groups, etc. during the install phase. Always pay close attention when this happens, don't just blindly accept the automatic merge.
 
freebsd-update is a different ballgame. That upgrades your base system so yeah, there's definitely chance that something could go wrong. It shouldn't take several days though, assuming you have a decent Internet connection. It's usually best not to perform these kind of upgrades from a remote location.
 
Damned! When I try to connect on the console, il see it's not a password problem:
bash: no such file bash is in a port and so is deleted. So the problem is simply the consequence of the deconnexion.
I suppose it is possible to boot on a CD and the more simple solution is to change the shell to /bin/sh in /etc/passwd?
I have no FreeBSD iso on my datastore. If I use a linux iso, is it working? Or it's better to get a FreeBSD one?
 
Can you access the console? Root is not allowed to login directly through ssh(1) but is always allowed to logon locally. Unless you changed root's shell to bash. In that case you can fix it by booting to single user mode and change the shell back to /bin/csh for root.
 
Thank you, that's what I do. It was a little bit painfull, because my VMware console give me a qwerty keyboard layout, when the physical one is azerty.
Probably, I have something to fix about that. And on the first trial I make the mistake to simply edit /etc/passwd. So the complete procedure is:

boot single user on console and then:
mount -o rw / (needing fsck -y / before, because reset),
mount /usr (device in /etc/fstab)
/usr/sbin/vipw --> change root shell to /bin/sh
reboot

And then I have reinstalled all my ports.
 
A 'shutdown' in VMWare should send an ACPI shutdown request to the VM. FreeBSD will respond to it and gracefully shutdown the machine.

The default shell for root is /bin/csh. The /bin/sh will also work but is quite Spartan when used interactively.
 
You must log in or register to reply here.
Back
Top