gohlip wrote:[1]
You have 3 disks
3 bootable drives; one internal SSD and two external USB spinning rust,
and that makes any grub-legacy boots unreliably (and that is why I suggested you remove your external mga6 for the moment).
Reason being the bios may change the sda, sdb and sdc upon
each boot and grub-legacy uses "root (hdx,y)" (you will not have this problem if using grub2) though it may use uuid in the
linux kernel line; grub 2 uses uuid in its 'search' line to map out the correct device.
I understand and have learned to work with the limitations of grub legacy when working with OS installations on removable drives. I am happy to continue working with grub legacy until I have a stable system again, comprising 4 bootable examples of MGA3,5 (2 of these) and 6.
You suggest I remove sdc (containing MGA6) leaving the machine in its normal working configuration, I can confirm that it still boots correctly in this state as none of its original Mageias have been touched in any way - either by accident or design.
All instances of MGA3 AND 5 boot with the
nokmsboot option in place, as needed for use of the fglrx display driver
gohlip wrote:[2]
I am not familiar with mc (and I don't know why your journal shows a recreation of menu.lst) but I do know that by using gedit, kate, leafpad, kwrite...the changes are kept (without update-grub or grub-install commands).
Midnight Commander is just a plain ol' text-based file manager with a host of built-in extras such as a very intuitive interface for a screen-based editor. Just select the file in the file manager and hit F4 to edit it, F2 to save it and F10 to get back to the file manager,
The journal shows the creation (and saving to back-up *.old files) of
device.map
install.sh
menu.lst
They are created, or not, by the
service_harddrake service invoking
- Code: Select all
display_driver_helper --is-kms-allowed
presumably to insert the option if it deems it is required or to remove the option if it disagrees with its presence.
If the check shows that it agrees with the state of the command line it will leave it alone. Otherwise it will re-write the line in menu.lst with what it thinks is correct (and rewrite device.map and install.sh for good measure).
This is clearly the root cause of my original problem (the disappearing
nokmsboot) but it doesn't explain why I need it to avoid the big crash.
gohlip wrote:[3]
I understand your point of 'nokmsboot', but I think the issue is more about grub booting up the wrong device, and so the wrong OS (you have 3 mga's, all using grub-legacy, all looking the same).
And that is why I suggested you use what works for you first, and then we'll talk about this later on after we fix the grub issue (so that it does not complicate the grub problem, which I think is the primary issue).
In fact there is little wrong with the MGA6 grub setup, other than that I was obliged to install grub to the root of a new extra drive due to the inability of the sta1 iso's installation process to put it on a partition of an existing drive (there was room for it on sda2 - on the internal drive). The grub problem you refer to may be the one I documented in another thread, from which I understand that many of the installer's partition-related bugs have been fixed, but I will need to wait for a new iso, or do a network install to check that.
The real show-stopper for me is the disappearing
nokmsboot option as that kills any attempt to boot MGA6 unless I remember add the option on the grub menu screen, or use the failsafe menu entry. That Is why I spent this evening trying to isolate the cause of the crash.
My first attempt was to remove the sdb USB drive (not needed for booting from sdc) and unplug the Nvidia card. I then booted MGA6 (with
nokmsboot) and re-installed the free
radeon driver (just in case it might do it differently in the absence of the Nvidia card), verified that the last boot had indeed cleared the
nokmsboot option, updated the installation and finally re-booted.
When the BIOS splash screen appeared I tapped F8 to go to the boot device selection menu and chose the MGA6 drive to boot. It booted, as usual, presenting the shiny new pale-blue MGA6 grub legacy menu so I waited for it to time out and proceed with booting the default menu entry. It crashed.
I powered down (to recover) and re-started to disable the IOMMU switch in the BIOS (just in case - besides, I don't need it yet in MGA6) and saved/restarted to repeat the MGA6 boot sequence. This time I also removed the IOMMU options on the command line, and with
nokmsboot still absent I removed the
silent and
splash options too. Executing that lot took me to another crash, but not before I could see that the boot process had filled one screen (very quickly) but all I could see for sure was that the crash happened about 3 seconds into the boot.
gohlip wrote:Now, since I know now you have 3 disks,
o I suggest you change menu.lst in all mga's to have 'nokmsboot' (as you say, it works with) and then making sure the changes remain (How? - Use leafpad as root).
o When booting, at grub menu, check the disks using command 'ls' (small 'L' and 's') at the grub prompt (type 'c' - "grub> ls") and change manually (press 'e') if the "root (hdx,y)" does not correspond to the right device.
o You may have to remove 'nokmsboot' if that does not boot and see that if by removing, it does boot this time round. But check again with 'ls' each time you start the computer (as said, bios may 'change' sda, sdb, sdc each time).
OK, for the first one, all my working grub legacy boots (3 in all) use the
nokmsboot option as all of them need it for the
fglrx display driver. The changes have always remained because
service_harddrake tests for a display driver which needs the option and will only add it if it is needed and NOT already present (MGA5 x2 for sure - I haven't bothered to check MGA3 - later perhaps). Conversely, if it determines the option is present but not needed it will remove it and re-write the three grub files listed earlier.
On your second point, as each of the grub installations shows no symptoms of not being able to find itself on (hd0) I reckon that we can skip that for now. Each grub knows only one (hd0) and is entirely independent of any other drive until the OS takes over and finds everything it needs by UUID or partition label. This is also true of the two installations sharing sdb, though in that case the MGA5 installation is on sdb10 and MGA3 provides the drive bootloader with a chainload entry for (hd0,9)
remember:
sda is the internal SSD with MGA5 only at sda1
sdb is the "permanent" USB drive with MGA3 at sdb1 and another MGA5 at sdb10 - cross-referenced by their respective grub legacy bootloaders as (hd0,4) and (hd0,9)
sdc is the new, occasional USB drive with MGA6 and no reference to any other OS on any other drive
And finally, because it is getting far too late and I am writing too much again, to summarise what happens with and without
nokmsboot:
MGA5 (on sda1 and sdb10) both need the option - else crash. This is normal and display_driver_helper gets it right, so no messing with my command line
MGA3 (on sdb5 + master boot record) needs the option and
probably crashes without it - as above, there is no messing with my command line, though I will need to check further to confirm why.
MGA6 (on sdc5 + master boot record) needs the option, but shouldn't need it. The display driver is the free
ati from Xorg which uses KMS quite happily, and indeed the X server loads it later when needed. However, without the
nokmsboot option, which is what display_driver_helper thinks is correct (and so do I), the boot process crashes within seconds of starting.
Here's a question; if booting using the
nokmsboot option when it is not required for the configured display driver is safe and booting without it when it is needed is fatal, why should there be a need in the boot process to remove it if it is found and deemed unnecessary? Leaving it alone should be safe so even if display_driver_helper thinks it shouldn't be there the only rational thing to do is leave it alone. Sure, add it in if it might be needed - that would likely do no real harm, but removing it when somebody put it there deliberately is just plain meddling.
Another fourpence worth - I must check the rationale tomorrow - add the option to a system using an Xorg driver - my bet is it won't crash.
Richard
After restart, the first 'Plasma' fails hangs in the DM, and the second one (after 'kill -6' to the X11 task) worked -reasonably fast, too.