[arch-dev-public] keep config file on system when upgrading to package without the config file
Hey guys, Yesterday I upgraded grub2 and changed some config file handling. Previously an example file /boot/grub/grub.cfg was installed by the PKGBUILD, which should not happen anymore as it can be created by some included config script autmotically (there are some patches on the bug tracker posted today which should allow for an even better streamlined autogenerated config). Obviously we can only run this script post-install or let the user take care of it. So the new package doesn't have the config file anymore and is now removing the old file (it seems it doesn't matter if the file is in the backup array or not). Any way around this so I can quickly fix this and people won't come in the grub shell upon next reboot ? Ronald
On Wed, Mar 17, 2010 at 11:27 AM, Ronald van Haren <pressh@gmail.com> wrote:
Hey guys,
Yesterday I upgraded grub2 and changed some config file handling. Previously an example file /boot/grub/grub.cfg was installed by the PKGBUILD, which should not happen anymore as it can be created by some included config script autmotically (there are some patches on the bug tracker posted today which should allow for an even better streamlined autogenerated config). Obviously we can only run this script post-install or let the user take care of it.
So the new package doesn't have the config file anymore and is now removing the old file (it seems it doesn't matter if the file is in the backup array or not). Any way around this so I can quickly fix this and people won't come in the grub shell upon next reboot ?
Ronald
suppose I just install the same sample config file as in the 1.97 release for now, but if there is a better way to fix this in the future let me know. Ronald
On Wed, Mar 17, 2010 at 06:27, Ronald van Haren <pressh@gmail.com> wrote:
So the new package doesn't have the config file anymore and is now removing the old file (it seems it doesn't matter if the file is in the backup array or not). Any way around this so I can quickly fix this and people won't come in the grub shell upon next reboot ?
Ronald
I don't think this is possible internally. One because it would leave unmarked untracked files on /, secondly because internally an upgrade is a remove+install
On Wed, Mar 17, 2010 at 8:03 AM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Wed, Mar 17, 2010 at 06:27, Ronald van Haren <pressh@gmail.com> wrote:
So the new package doesn't have the config file anymore and is now removing the old file (it seems it doesn't matter if the file is in the backup array or not). Any way around this so I can quickly fix this and people won't come in the grub shell upon next reboot ?
Ronald
I don't think this is possible internally. One because it would leave unmarked untracked files on /, secondly because internally an upgrade is a remove+install
I actually thought pacman USED to do this. If a file is in the backup array, and it is being removed, it is moved to .pacsav. Wasn't that the logic, or am I crazy?
On Wed, Mar 17, 2010 at 11:55 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Mar 17, 2010 at 8:03 AM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Wed, Mar 17, 2010 at 06:27, Ronald van Haren <pressh@gmail.com> wrote:
So the new package doesn't have the config file anymore and is now removing the old file (it seems it doesn't matter if the file is in the backup array or not). Any way around this so I can quickly fix this and people won't come in the grub shell upon next reboot ?
Ronald
I don't think this is possible internally. One because it would leave unmarked untracked files on /, secondly because internally an upgrade is a remove+install
I actually thought pacman USED to do this. If a file is in the backup array, and it is being removed, it is moved to .pacsav. Wasn't that the logic, or am I crazy?
Yeah, we have some complete lies being posted in this thread. I haven't looked at the package in question but I don't buy that I've heard the full truth here. 1. upgrade is not a remove+add, it does a hell of a lot more (ever try to handle backed-up files moving between packages on a system update? pacman does) 2. Config files in a backup array ****NEVER**** get deleted, except for one case- you've never changed it and moving to either a version of a package that doesn't have that file or uninstalling the package. 3. Files move to .pacsave if they are removed, never deleted (except the condition above) 4. Please look at the pactest/tests/ directory in the pacman directory if you want to see how backup file handling works with real examples. In particular, remove010, remove011, remove020, remove021, upgrade020-26, upgrade042, upgrade043, and upgrade045. (yes, there are that many tests for this stuff) -Dan
On Wed, Mar 17, 2010 at 12:56 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Wed, Mar 17, 2010 at 11:55 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Mar 17, 2010 at 8:03 AM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Wed, Mar 17, 2010 at 06:27, Ronald van Haren <pressh@gmail.com> wrote:
So the new package doesn't have the config file anymore and is now removing the old file (it seems it doesn't matter if the file is in the backup array or not). Any way around this so I can quickly fix this and people won't come in the grub shell upon next reboot ?
Ronald
I don't think this is possible internally. One because it would leave unmarked untracked files on /, secondly because internally an upgrade is a remove+install
I actually thought pacman USED to do this. If a file is in the backup array, and it is being removed, it is moved to .pacsav. Wasn't that the logic, or am I crazy?
Yeah, we have some complete lies being posted in this thread. I haven't looked at the package in question but I don't buy that I've heard the full truth here.
1. upgrade is not a remove+add, it does a hell of a lot more (ever try to handle backed-up files moving between packages on a system update? pacman does) 2. Config files in a backup array ****NEVER**** get deleted, except for one case- you've never changed it and moving to either a version of a package that doesn't have that file or uninstalling the package. 3. Files move to .pacsave if they are removed, never deleted (except the condition above) 4. Please look at the pactest/tests/ directory in the pacman directory if you want to see how backup file handling works with real examples. In particular, remove010, remove011, remove020, remove021, upgrade020-26, upgrade042, upgrade043, and upgrade045. (yes, there are that many tests for this stuff)
I remember doing a redux of some of the backup array code way back when, and I was fairly certain this was the case. Perhaps the tests of grub2 are hitting the condition in #2 here.
On Wed, Mar 17, 2010 at 15:16, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
I remember doing a redux of some of the backup array code way back when, and I was fairly certain this was the case.
Perhaps the tests of grub2 are hitting the condition in #2 here.
My understanding from reading the forum is that this is the case
On Wed, Mar 17, 2010 at 2:44 PM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Wed, Mar 17, 2010 at 15:16, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
I remember doing a redux of some of the backup array code way back when, and I was fairly certain this was the case.
Perhaps the tests of grub2 are hitting the condition in #2 here.
My understanding from reading the forum is that this is the case
In which case the behavior is normal and expected, yes? I mean, if I understand the new grub2 correctly, there should be no config, but the mkconfig command needs to be run.
On Wed, Mar 17, 2010 at 16:01, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
In which case the behavior is normal and expected, yes? I mean, if I understand the new grub2 correctly, there should be no config, but the mkconfig command needs to be run.
I think the issue was that the maintainer didn't realize removing it from backup would remove it from user systems. I don't have the thread at hand right now.
On Wed, Mar 17, 2010 at 3:03 PM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Wed, Mar 17, 2010 at 16:01, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
In which case the behavior is normal and expected, yes? I mean, if I understand the new grub2 correctly, there should be no config, but the mkconfig command needs to be run.
I think the issue was that the maintainer didn't realize removing it from backup would remove it from user systems. I don't have the thread at hand right now.
Pacman should even handle that. The backup array is checked for both the incoming package and the outgoing one, for stuff like this. Now if it was never in the backup array to begin with, that's another story
On Wednesday, March 17, 2010, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Mar 17, 2010 at 3:03 PM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Wed, Mar 17, 2010 at 16:01, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
In which case the behavior is normal and expected, yes? I mean, if I understand the new grub2 correctly, there should be no config, but the mkconfig command needs to be run.
I think the issue was that the maintainer didn't realize removing it from backup would remove it from user systems. I don't have the thread at hand right now.
Pacman should even handle that. The backup array is checked for both the incoming package and the outgoing one, for stuff like this.
Now if it was never in the backup array to begin with, that's another story
The file was in the backup array in the old package and installed by the pkgbuild. In the new package the file was still in the backup array but not installed anymore. This either removed the file or moved it to pacsave, I can't verify now which one of the two happened. Obviously you are thrown into grub shell upon reboot. In the current package i just install the file again, so people who still need ro upgrade can boot normally. People who already did the upgrade should intervene because the file was not under pacman control anymore. Hope this makes it more clear what happened. Ronald
Am Mittwoch, 17. März 2010 11:27:10 schrieb Ronald van Haren:
So the new package doesn't have the config file anymore and is now removing the old file (it seems it doesn't matter if the file is in the backup array or not). Any way around this so I can quickly fix this and people won't come in the grub shell upon next reboot ?
It looks like your are changing the config file from a single one in /boot/grub to multiple ones in /etc/grub.d/. This is quite a major change which will need user intervention. You should put such a version in testing first and prepare a news item draft. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, Mar 17, 2010 at 3:00 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
It looks like your are changing the config file from a single one in /boot/grub to multiple ones in /etc/grub.d/. This is quite a major change which will need user intervention.
the only config file that really matters is the /boot/grub/grub.cfg file, the other ones are only used by grub-mkconfig to create such a config file autmatically.
You should put such a version in testing first and prepare a news item draft.
I would have done so if I realised the old grub.cfg file would have been deleted. Suppose it's a bit too late to post a news item now, though I can draft something quick if you think it is still needed for the people that update from not up2date mirrors. Ronald
On Wed, Mar 17, 2010 at 3:10 PM, Ronald van Haren <pressh@gmail.com> wrote:
On Wed, Mar 17, 2010 at 3:00 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
It looks like your are changing the config file from a single one in /boot/grub to multiple ones in /etc/grub.d/. This is quite a major change which will need user intervention.
the only config file that really matters is the /boot/grub/grub.cfg file, the other ones are only used by grub-mkconfig to create such a config file autmatically.
You should put such a version in testing first and prepare a news item draft.
I would have done so if I realised the old grub.cfg file would have been deleted. Suppose it's a bit too late to post a news item now, though I can draft something quick if you think it is still needed for the people that update from not up2date mirrors.
Ronald
please someone review before I post this as a news item: Early version in the grub2-1.98 release removed the /boot/grub/grub.cfg file on updating. This is corrected in the -4 release, so if you're still on 1.97 update to that release. If you already installed one of the early 1.98 releases, and already re-created the /boot/grub/grub.cfg file, user intervention is needed. Back the file up and install grub2 with the force flag, after which you can move the grub.cfg file back again.
From now on you can create a sample config file using the grub-mkconfig command.
participants (5)
-
Aaron Griffin
-
Daenyth Blank
-
Dan McGee
-
Pierre Schmitz
-
Ronald van Haren