On Wed, Mar 21, 2007 at 04:43:11PM -0700, Steve Langasek wrote: > On Wed, Mar 21, 2007 at 11:17:08PM +0100, Javier Fernández-Sanguino Peña wrote: > > > If aptitude is started after that, it will still try to remove quite a few > > > packages. Most of these are old and OK, but a few should possibly be > > > kept: > > > - openoffice.org > > > - openbsd-inetd > > > - pppoeconf > > > Ouch. Aptitude should not recommended then! > > Will this happen *any* time aptitude is started? Or does this happen only if > > you try to use it instead of apt-get in the above steps? > > No, it happens only if you use *apt-get* in the preceding steps. Has somebody attempted an upgrade run with aptitude following these steps? ( I will try this if no one has ) 1.- remove the desktop task (use tasksel) [ This seems a common denominator for all upgrades, and actually helps with #406131, as there will be more disk space available and less downloaded packages when upgrading ] 2.- edit sources.list to point to etch 3.- aptitude update 4.- apt-get install coreutils apt initrd-tools [ Removes aptitude baseconfig and tasksel, prevents #413458 ] 5.- apt-get update [ Needed to get release signature check, documenting this fixes #403496 ] 6.- apt-get install aptitude [ Restore aptitude from etch ] 7.- aptitude dist-upgrade [ Using apt-get this is clean, what about aptitude? Maybe it's not because of recommends and we should add --without-recommends there ] 8.- If using LILO as bootloader, rerun it [ Just in case, see #337779 ] 9.- aptitude install linux-image-2.6 [ For users using 2.6.8, who need to upgrade the kernel due to udev, not working with it ] [ A reboot here would be safe ] 10.- aptitude install tasksel [ Restore tasksel from etch ] 11.- select one of the Desktop tasks (or both) using tasksel I think we should recommend using tasksel (vs. apt-get install gnome) in 9-10 as this would pull in more features and is closer to the desktop task removed in step 1. In this procedure, aptitude is not used from point 4-6, and the issues due to #411123 might be prevented. The critical step is between point 7 and 9, if the system reboots before the kernel is upgraded (or LILO is rerun) problems could: - unbootable system due to LILO second stage change - devices not working because of the new udev not working with the old kernel (#325568), - any other issue due to device renaming (already documented in the RN). AFAIK (from what I've read) the only solution to these is to use the rescue mode and fix the issue (rerun lilo, download the *old* udev, make changes to /etc/fstab...) or boot with a 2.4 kernel (if available) to continue from step 8. Should we recommend users to switch to grub *before* the upgrade? It is, after all, the default bootloader in etch's d-i and we could prevent some issues. Or is that just too much? Regards Javier
Attachment:
signature.asc
Description: Digital signature