[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Possible addition of more mountpoints to the Release Notes


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: