Re: don't upgrade grub or grub-pc ! what's wrong with LILO ?
>> In this case, I would back up sources.list, create a new, one-line
>> sources.list pointing at the main section of testing, purge unstable's
>> grub-common and grub-pc, apt-get update, install testing's grub-common
>> and grub-pc, delete the temporary sources.list, reinstate the original
>> sources.list, and apt-get update (and possibly pin grub-common and
>> grub-pc until the next version so that are not upgraded at the next
>> apt-get upgrade or apt-get dist-upgrade).
>> BTW, these are the 386 versions in the repositories:
>> grub-common_1.98~20100115-1_i386.deb 15-Jan-2010 20:04 1.4M
>> grub-common_1.98~20100128-1_i386.deb 28-Jan-2010 18:06 1.4M
>> grub-pc_1.98~20100115-1_i386.deb 15-Jan-2010 20:04 809K
>> grub-pc_1.98~20100128-1_i386.deb 28-Jan-2010 18:06 820K
> That sounds like a procedure for getting a down-level version
> of a package from testing if you are running sid and the sid version
> is broken. But that's not the scenario I'm talking about. In my
> scenario, I'm running pure testing. If a broken package gets uploaded
> to sid, I'll never know. I won't know until it migrates to testing.
> And once it enters testing, and I upgrade my system, and it's broken,
> and I want to go back to the version I was running before, then what?
> I've got nowhere to retrieve the old package from.
That's why I said "+1" to your previous email and said "in this case"
because it is possible to do so for grub given its dependencies.
Unstable and testing currently have just one version of grub2 each so
if someone wants to downgrade unstable's grub2, he/she has to use the
testing version.
If /boot is not lvm'd or mdadm'd or both, the OP can install lilo
(which I assume cannot handle such a setup) or grub1.
Reply to: