Possible addition of more mountpoints to the Release Notes
Hello,
This is just some ponderings of mine that popped into my head while
helping to "proofread" a translation of the release notes for etch.
I asked in #debian on Freenode if I were totally ofaf with my ponderings
and I were suggested to send a mail here.
So, what am I on about?
Well, in the release notes there is a part that talks about that you
need to remember to be sure that mountpoints are mounted in a way that
is correct.
Also, it speaks about upgrading perl and aptitude to hopefully avoid any
trouble, both quite essential parts of a debian system.
*4.4 Upgrading packages *
The recommended way to upgrade from previous Debian GNU/Linux releases
is to use the package management tool |aptitude|. This program makes
safer decisions about package installations than running |apt-get|
directly.
Don't forget to mount all needed partitions (notably the root and |/usr|
partitions) read-write, with a command like:
# mount -o remount,rw /mountpoint
- - - and - - -
*4.4.2 Upgrading aptitude
*Upgrade tests have shown that etch's version of |aptitude| is better at
solving the complex dependencies during an upgrade than either |apt-get|
or sarge's |aptitude|. It should therefore be upgraded first using:
# aptitude install aptitude
You will be shown a list of the changes that will be made and asked you
to confirm them. You should take a careful look at the proposed changes,
especially packages that will be removed by the upgrade, before you
confirm.
In some cases if a large number of packages is listed for removal, you
may be able to reduce this list by "pre-upgrading" selected other
packages alongside |aptitude|. An example may clarify this. During
upgrade tests for systems having KDE installed, we have seen that this
step would cause removal of a large number of KDE packages and/or perl.
The solution proved to be to install aptitude perl instead of install
aptitude.
*
*Something I've noticed when upgrading a "secure" (but still a little
misconfigured, apt has its way to deal with this) debian system is that
if /tmp is mounted with noexec most perl things have somewhat of a hard
time. So what I wonder if not /tmp should be added to the list of
filesystems that should be checked?
I cannot honestly say that I know what will actually happen if you
perform a full upgrade with /tmp noexec, if it will destroy anything
that is. But I am sure someone here would have the answer to that.
Also, now when im writing this I got to think of, what about /var?
Perhaps im totally off in my ponderings, or this has already been
decided by some person, but I thought it's better to bring it up.
/Alexander Rydekull
Reply to: