On Tue, 2006-10-03 at 11:13 -0400, Jeremy Katz wrote: > On Tue, 2006-10-03 at 15:39 +0200, Gilboa Davara wrote: > > On Tue, 2006-10-03 at 09:04 -0400, Jesse Keating wrote: > > > On Tuesday 03 October 2006 02:06, Gilboa Davara wrote: > > > > This is rather urgent, as FC6 is about to be released. > > > > Yesterday tried to upgrade a fully working copy of FC5 (with separate > > > > /boot marked as noauto,defaults). > > > > Anaconda didn't mount boot (NONBUG according to BZ#208093 [1]) which > > > > was partially fixed - Anaconda disabled the grub "update" option until > > > > I manually mounted the /boot partition. Good. (Q: wouldn't be better > > > > if Anaconda displayed a message saying: "boot marked noauto; didn't > > > > mount it; cannot update existing grub configuration; manually mount > > > > it?") > > > > The installation itself was rather event-less, and finished just fine. > > > > > > > > However, when I tried booting my shiny new FC6, I got the dreaded: > > > > "GRUB GRUB GRUB ...." and had to reboot the test4 ISO in rescue mode > > > > and fix the grub configuration (grub, root (hd0,0), setup (hd0), > > > > quit). > > > > The machine seems to be working just fine now. > > > > > > Retry with boot not marked as noauto from the get go. > > > > I'll give it a try when I get back home. > > Be aware that I manually mounted the /boot partition once I had terminal > > access and that both the kernels and the grub.conf were > > installed/configured correctly. Only grub-stageII-setup (?) failed. > > Yes, but anaconda didn't have a real idea of how your system is set > up. > > Trying to do things like this CANNOT WORK. We reinstall grub at the end > of the install and do so based on our idea of what filesystems are > mounted, where /boot is, etc. Going behind the installer's back and > mounting things from ttys is nonsense. > > If your system has a separate /boot, then the fstab must have it set so > that anaconda knows that it should mount it. And that means not > "noauto" since that's really no better than not listing it at all. > > Jeremy > OK. I can't say that I agree, but lets drop it for now. In my view, there is a bigger problem here that needs solving. The user has no way to view and modify the list detected partitions once the upgrade process has began, nor does he has an option to restart the detection process if something goes wrong during the initial this phase. (E.g. BZ#208947) In order to solve the "bigger" issue, I'd suggest the following solution: A. Once Anaconda is done scanning the fstab, it should display the list of detected devices and partitions. This options is a must - especially when upgrading a machine with LVM over MD array(s). B. Either (1) enable the "Back" button, giving the user an option to restart the detection phase or (2) add a UI button "Terminal", giving the user an option to load missing drivers/fix the fstab/fix a bad software RAID array/etc. C. Once the user selects "Back" (B1) or exists the terminal (B2), goto step A. Of the top of my head, A -> B1 -> C -> A sounds like a rather simple solution to implement - but I don't know Python and/or Anaconda well enough to verify this bold assessment. If you consider it an acceptable solution, I'll post an RFE for FC7. - Gilboa -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list