Is preupgrade from F9 to rawhide supposed to work at the moment, and where can I report problems?
I've tried to run it and got a few depsolving problems for packages from livna... but when it gets to the boot images stage there are problems:
Traceback (most recent call last): File "/usr/share/preupgrade/preupgrade-gtk.py", line 198, in on_assistant_apply self._do_main() File "/usr/share/preupgrade/preupgrade-gtk.py", line 206, in _do_main self.main_preupgrade() File "/usr/share/preupgrade/preupgrade-gtk.py", line 349, in main_preupgrade self.pu.retrieve_treeinfo() File "/usr/lib/python2.5/site-packages/preupgrade/__init__.py", line 395, in retrieve_treeinfo self.instimage = cp.get('stage2', 'instimage') File "/usr/lib/python2.5/ConfigParser.py", line 520, in get raise NoOptionError(option, section) ConfigParser.NoOptionError: No option 'instimage' in section: 'stage2'
Any ideas?
-Cam
On Sun, 2008-10-26 at 19:05 +0100, Camilo Mesias wrote:
Is preupgrade from F9 to rawhide supposed to work at the moment, and where can I report problems?
I've tried to run it and got a few depsolving problems for packages from livna... but when it gets to the boot images stage there are problems:
You're using an old version of preupgrade. Use 0.9.8 from updates-testing.
-w
OK...
yum update --enablerepo=updates-testing-newkey preupgrade
I'll give preupgrade-0.9.8-2.fc9.noarch.rpm a try...
-Cam
A quick update on this. I successfully upgraded one machine about a week ago, so I tried another machine today and it had a problem booting during the install.
After all the packages had been downloaded and the 'reboot' button was pressed, grub was no longer able to come up. The word 'GRUB' was displayed and nothing else.
I booted with the F9 Live USB and did the following (sorry it doesn't help with diagnosis but it might help if anyone else has this problem)
mkdir /tmp/rootdir mount /dev/mapper/VolGroup00-LogVol00 /tmp/rootdir mount /dev/sda1 /tmp/rootdir/boot /tmp/rootdir/sbin/grub-install --root-directory=/tmp/rootdir /dev/sda
If there are any logs that might help diagnose the problem, let me know. I have one more desktop and one more laptop running F9 which I plan to preupgrade in the same way, Please let me know if there is anything I should note to help improve the process.
-Cam
On Fri, 2008-11-07 at 17:40 +0000, Camilo Mesias wrote:
A quick update on this. I successfully upgraded one machine about a week ago, so I tried another machine today and it had a problem booting during the install.
After all the packages had been downloaded and the 'reboot' button was pressed, grub was no longer able to come up. The word 'GRUB' was displayed and nothing else.
I booted with the F9 Live USB and did the following (sorry it doesn't help with diagnosis but it might help if anyone else has this problem)
mkdir /tmp/rootdir mount /dev/mapper/VolGroup00-LogVol00 /tmp/rootdir mount /dev/sda1 /tmp/rootdir/boot /tmp/rootdir/sbin/grub-install --root-directory=/tmp/rootdir /dev/sda
If there are any logs that might help diagnose the problem, let me know. I have one more desktop and one more laptop running F9 which I plan to preupgrade in the same way, Please let me know if there is anything I should note to help improve the process.
This is a GRUB bug that we've been unable to reproduce reliably, and therefore haven't traced fully. It's often triggered by using the grub --once flag, which is used by both preupgrade and suspend-to-disk (hibernate). We've seen it happen with both of those things, but the preupgrade case seems to be more frequent because it tends to also involve upgrading GRUB at the same time.
As far as we've been able to trace it, *something* causes GRUB stage2 (or stage 1.5) to move its physical on-disk location. But we don't know what. Nothing that we're doing to GRUB *should* cause that. But something does, and then stage1 can't find the rest of GRUB, and we get stuck with "GRUB" on-screen and an unbootable system.
Anyway. I've spent *weeks* trying to track that one down, bugging pjones (our GRUB maintainer) and esandeen (our mad ext3/ext4 hacker) endlessly, and never made any real progress. Reinstalling GRUB, as you did, is the proper fix when this happens. But we still don't know what causes it, and therefore how to keep it from happening in the first place.
Any further help or theories on this would be greatly appreciated.
-w
Any further help or theories on this would be greatly appreciated.
Is there a canonical command that will tell me if grub is in a consistent state or not?
I'm guessing it's worth running such a command (if it exists) at the point when preupgrade says "Reboot", and then at several points during the shutdown sequence to see what happens.
Stop me if this is obvious or has been tried already, but as I said I have two more systems to upgrade so it's worth experimenting a bit.
On Fri, November 7, 2008 1:21 pm, Will Woods wrote:
On Fri, 2008-11-07 at 17:40 +0000, Camilo Mesias wrote:
A quick update on this. I successfully upgraded one machine about a week ago, so I tried another machine today and it had a problem booting during the install. ...
... As far as we've been able to trace it, *something* causes GRUB stage2 (or stage 1.5) to move its physical on-disk location. But we don't know what. Nothing that we're doing to GRUB *should* cause that. But something does, and then stage1 can't find the rest of GRUB, and we get stuck with "GRUB" on-screen and an unbootable system.
Anyway. I've spent *weeks* trying to track that one down, bugging pjones (our GRUB maintainer) and esandeen (our mad ext3/ext4 hacker) endlessly, and never made any real progress. Reinstalling GRUB, as you did, is the proper fix when this happens. But we still don't know what causes it, and therefore how to keep it from happening in the first place.
Can preupgrade just re-install grub itself at some suitable point. It seems that'd work around the issue...
Hi
2008/11/7 Will Woods wwoods@redhat.com:
This is a GRUB bug that we've been unable to reproduce reliably, and therefore haven't traced fully. It's often triggered by using the grub --once flag, which is used by both preupgrade and suspend-to-disk (hibernate). We've seen it happen with both of those things, but the preupgrade case seems to be more frequent because it tends to also involve upgrading GRUB at the same time.
I've just seen this problem happen after a yum upgrade. I installed switchdesk-gui, yum updated and groupinstalled XFCE. on the next reboot I had a broken grub. Here are log excerpts showing what got updated/installed:
Could this happen just by installing a new kernel?
-Cam
Will Woods wrote:
On Fri, 2008-11-07 at 17:40 +0000, Camilo Mesias wrote:
A quick update on this. I successfully upgraded one machine about a week ago, so I tried another machine today and it had a problem booting during the install.
After all the packages had been downloaded and the 'reboot' button was pressed, grub was no longer able to come up. The word 'GRUB' was displayed and nothing else.
I booted with the F9 Live USB and did the following (sorry it doesn't help with diagnosis but it might help if anyone else has this problem)
mkdir /tmp/rootdir mount /dev/mapper/VolGroup00-LogVol00 /tmp/rootdir mount /dev/sda1 /tmp/rootdir/boot /tmp/rootdir/sbin/grub-install --root-directory=/tmp/rootdir /dev/sda
If there are any logs that might help diagnose the problem, let me know. I have one more desktop and one more laptop running F9 which I plan to preupgrade in the same way, Please let me know if there is anything I should note to help improve the process.
This is a GRUB bug that we've been unable to reproduce reliably, and therefore haven't traced fully. It's often triggered by using the grub --once flag, which is used by both preupgrade and suspend-to-disk (hibernate). We've seen it happen with both of those things, but the preupgrade case seems to be more frequent because it tends to also involve upgrading GRUB at the same time.
As far as we've been able to trace it, *something* causes GRUB stage2 (or stage 1.5) to move its physical on-disk location. But we don't know what. Nothing that we're doing to GRUB *should* cause that. But something does, and then stage1 can't find the rest of GRUB, and we get stuck with "GRUB" on-screen and an unbootable system.
Anyway. I've spent *weeks* trying to track that one down, bugging pjones (our GRUB maintainer) and esandeen (our mad ext3/ext4 hacker) endlessly, and never made any real progress. Reinstalling GRUB, as you did, is the proper fix when this happens. But we still don't know what causes it, and therefore how to keep it from happening in the first place.
Any further help or theories on this would be greatly appreciated.
-w
Ok, I just ran into this nasty little problem when I did my F9 => F10 preupgrade. All I get at the first reboot is the GRUB prompt. Has any progress been made on tracking this down? This will be a real pain if I have to go through this on 14 machines. Is there any workaround to avoid this problem?
Regards, Gerry
Gerry Reno wrote:
Will Woods wrote:
On Fri, 2008-11-07 at 17:40 +0000, Camilo Mesias wrote:
A quick update on this. I successfully upgraded one machine about a week ago, so I tried another machine today and it had a problem booting during the install.
After all the packages had been downloaded and the 'reboot' button was pressed, grub was no longer able to come up. The word 'GRUB' was displayed and nothing else.
I booted with the F9 Live USB and did the following (sorry it doesn't help with diagnosis but it might help if anyone else has this problem)
mkdir /tmp/rootdir mount /dev/mapper/VolGroup00-LogVol00 /tmp/rootdir mount /dev/sda1 /tmp/rootdir/boot /tmp/rootdir/sbin/grub-install --root-directory=/tmp/rootdir /dev/sda
If there are any logs that might help diagnose the problem, let me know. I have one more desktop and one more laptop running F9 which I plan to preupgrade in the same way, Please let me know if there is anything I should note to help improve the process.
This is a GRUB bug that we've been unable to reproduce reliably, and therefore haven't traced fully. It's often triggered by using the grub --once flag, which is used by both preupgrade and suspend-to-disk (hibernate). We've seen it happen with both of those things, but the preupgrade case seems to be more frequent because it tends to also involve upgrading GRUB at the same time.
As far as we've been able to trace it, *something* causes GRUB stage2 (or stage 1.5) to move its physical on-disk location. But we don't know what. Nothing that we're doing to GRUB *should* cause that. But something does, and then stage1 can't find the rest of GRUB, and we get stuck with "GRUB" on-screen and an unbootable system.
Anyway. I've spent *weeks* trying to track that one down, bugging pjones (our GRUB maintainer) and esandeen (our mad ext3/ext4 hacker) endlessly, and never made any real progress. Reinstalling GRUB, as you did, is the proper fix when this happens. But we still don't know what causes it, and therefore how to keep it from happening in the first place.
Any further help or theories on this would be greatly appreciated.
-w
Ok, I just ran into this nasty little problem when I did my F9 => F10 preupgrade. All I get at the first reboot is the GRUB prompt. Has any progress been made on tracking this down? This will be a real pain if I have to go through this on 14 machines. Is there any workaround to avoid this problem?
And I just reran the preupgrade and this time I see this message go by: Not enough space in /boot/upgrade to download install.img GRUBBY shows that it will download the install.img from the network.
The /boot is 100MB size on this machine.
So I did the first reboot and this time the machine booted, retrieved the install.img and ran anaconda. Maybe the GRUB prompt problem is related to my small /boot space.
Regards, Gerry
On Thu, 2009-03-19 at 02:16 -0400, Gerry Reno wrote:
Gerry Reno wrote:
Will Woods wrote:
This is a GRUB bug that we've been unable to reproduce reliably, and therefore haven't traced fully. It's often triggered by using the grub --once flag, which is used by both preupgrade and suspend-to-disk (hibernate). We've seen it happen with both of those things, but the preupgrade case seems to be more frequent because it tends to also involve upgrading GRUB at the same time.
As far as we've been able to trace it, *something* causes GRUB stage2 (or stage 1.5) to move its physical on-disk location. But we don't know what. Nothing that we're doing to GRUB *should* cause that. But something does, and then stage1 can't find the rest of GRUB, and we get stuck with "GRUB" on-screen and an unbootable system.
Anyway. I've spent *weeks* trying to track that one down, bugging pjones (our GRUB maintainer) and esandeen (our mad ext3/ext4 hacker) endlessly, and never made any real progress. Reinstalling GRUB, as you did, is the proper fix when this happens. But we still don't know what causes it, and therefore how to keep it from happening in the first place.
This remains a problem in F10; unsure if rawhide is also susceptible. I'd guess yes.
Ok, I just ran into this nasty little problem when I did my F9 => F10 preupgrade. All I get at the first reboot is the GRUB prompt. Has any progress been made on tracking this down? This will be a real pain if I have to go through this on 14 machines. Is there any workaround to avoid this problem?
None known. You can use a rescue CD / Live image to re-run grub-install to fix it, but that's about it.
And I just reran the preupgrade and this time I see this message go by: Not enough space in /boot/upgrade to download install.img GRUBBY shows that it will download the install.img from the network.
The /boot is 100MB size on this machine.
So I did the first reboot and this time the machine booted, retrieved the install.img and ran anaconda. Maybe the GRUB prompt problem is related to my small /boot space.
It's not. We've seen this happen on plenty of machines with 200MB /boot.
-w
Will Woods wrote:
On Thu, 2009-03-19 at 02:16 -0400, Gerry Reno wrote:
Gerry Reno wrote:
Will Woods wrote:
This is a GRUB bug that we've been unable to reproduce reliably, and therefore haven't traced fully. It's often triggered by using the grub --once flag, which is used by both preupgrade and suspend-to-disk (hibernate). We've seen it happen with both of those things, but the preupgrade case seems to be more frequent because it tends to also involve upgrading GRUB at the same time.
As far as we've been able to trace it, *something* causes GRUB stage2 (or stage 1.5) to move its physical on-disk location. But we don't know what. Nothing that we're doing to GRUB *should* cause that. But something does, and then stage1 can't find the rest of GRUB, and we get stuck with "GRUB" on-screen and an unbootable system.
Anyway. I've spent *weeks* trying to track that one down, bugging pjones (our GRUB maintainer) and esandeen (our mad ext3/ext4 hacker) endlessly, and never made any real progress. Reinstalling GRUB, as you did, is the proper fix when this happens. But we still don't know what causes it, and therefore how to keep it from happening in the first place.
This remains a problem in F10; unsure if rawhide is also susceptible. I'd guess yes.
Ok, I just ran into this nasty little problem when I did my F9 => F10 preupgrade. All I get at the first reboot is the GRUB prompt. Has any progress been made on tracking this down? This will be a real pain if I have to go through this on 14 machines. Is there any workaround to avoid this problem?
None known. You can use a rescue CD / Live image to re-run grub-install to fix it, but that's about it.
And I just reran the preupgrade and this time I see this message go by: Not enough space in /boot/upgrade to download install.img GRUBBY shows that it will download the install.img from the network.
The /boot is 100MB size on this machine.
So I did the first reboot and this time the machine booted, retrieved the install.img and ran anaconda. Maybe the GRUB prompt problem is related to my small /boot space.
It's not. We've seen this happen on plenty of machines with 200MB /boot.
-w
Thanks for clarifying the issue.
Is there anyway I could get anaconda to process a "grub-install" script as a post-install during preupgrade?
Regards, Gerry
Gerry Reno wrote:
Will Woods wrote:
On Thu, 2009-03-19 at 02:16 -0400, Gerry Reno wrote:
Gerry Reno wrote:
Will Woods wrote:
This is a GRUB bug that we've been unable to reproduce reliably, and therefore haven't traced fully. It's often triggered by using the grub --once flag, which is used by both preupgrade and suspend-to-disk (hibernate). We've seen it happen with both of those things, but the preupgrade case seems to be more frequent because it tends to also involve upgrading GRUB at the same time.
As far as we've been able to trace it, *something* causes GRUB stage2 (or stage 1.5) to move its physical on-disk location. But we don't know what. Nothing that we're doing to GRUB *should* cause that. But something does, and then stage1 can't find the rest of GRUB, and we get stuck with "GRUB" on-screen and an unbootable system.
Anyway. I've spent *weeks* trying to track that one down, bugging pjones (our GRUB maintainer) and esandeen (our mad ext3/ext4 hacker) endlessly, and never made any real progress. Reinstalling GRUB, as you did, is the proper fix when this happens. But we still don't know what causes it, and therefore how to keep it from happening in the first place.
This remains a problem in F10; unsure if rawhide is also susceptible. I'd guess yes.
Ok, I just ran into this nasty little problem when I did my F9 => F10 preupgrade. All I get at the first reboot is the GRUB prompt. Has any progress been made on tracking this down? This will be a real pain if I have to go through this on 14 machines. Is there any workaround to avoid this problem?
None known. You can use a rescue CD / Live image to re-run grub-install to fix it, but that's about it.
And I just reran the preupgrade and this time I see this message go by: Not enough space in /boot/upgrade to download install.img GRUBBY shows that it will download the install.img from the network.
The /boot is 100MB size on this machine.
So I did the first reboot and this time the machine booted, retrieved the install.img and ran anaconda. Maybe the GRUB prompt problem is related to my small /boot space.
It's not. We've seen this happen on plenty of machines with 200MB /boot.
-w
Thanks for clarifying the issue.
Is there anyway I could get anaconda to process a "grub-install" script as a post-install during preupgrade?
Regards, Gerry
One more thing about the grub-install script idea. I found that you need to add the --grub-shell=full_path to the grub-install line to get the grub-install to work.
Regards, Gerry
devel@lists.stg.fedoraproject.org
-
Camilo Mesias -
Gerry Reno -
Stephen Warren -
Will Woods