Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Problem 1. What is occurring with my discs?

  1. #1

    Question Problem 1. What is occurring with my discs?

    I am an XP user (Sorry) who has decided to desert the evil empire and enter the light. At least that was the intention. So three weeks ago I installed openSUSE 10.3 KDE. Ive now got to the stage where it sort of works. But I have 1,000,001 questions. I am an experienced user of all sorts of machines, I wrote my first programme in Fortran on some single tasking IBM monstrosity at college in 1975 and worked in IT, mostly in Systems Software development, ever since.

    Problem 2, Why doesnt my printer work? Will be along soon, meanwhile.

    Problem 1. What is occurring with my discs?

    Hardware: ASUS A7V8X motherboard, AMD Athlon XP 2100+, 1.25Gb RAM with onboard Promise Fastrak 376 RAID controller. (lots of other bits and bobs)

    There are four hard drives attached,
    a) 16G pata Primary Master, empty, the home of Linux. I wanted this partitioned in a particular way, but the only way Susie would install was if I let the installation routines decide for themselves what the partitioning scheme would be.
    b) 110 G pata RAID channel 0. XP boot partition, 20G, data partition FAT32 90 G.
    c) 400G sata RAID channel 1. 20G partition empty, 200G partition Music, 180G partition empty
    d) 400G sata RAID channel 1. 20G partition empty, 200G partition Video, 180G partition empty
    b, c and d are attached to the RAID controller but are defined as 1 volume striped raid sets.

    If I tried to install Susie without first detaching b, c and d from the system, following the default partitioning scheme and without removing an internal USB multi-card reader from the system, the install stage that wrote grub would fail. It seemed to invent a new way of failing for every different combination of partitions on drive a) that I tried to use. To say the error messages were unhelpful would be, (Im struggling for a polite way to say this), mild, they were ***** !*** ****** * ****** **** terrible. A selection:
    System boots, message Loading stage1.5File not found Which file, where, what disc!
    System boots, black screen!!!
    System boots Loading grub .. (nothing else)
    (My favourite) During grub install Error 23: Error parsing number Which number, where, whats wrong with it? Ive only got three screenfuls of swahili to wade through, give me a line number at least.
    Because of the partitioning YaST is unable to install the boot loader!

    I tried some other distributions, ubuntu, kubunto, SimplyMepis, they didnt work either. I spent days booting back and forth to XP trying to google it out and got nowhere. Finally I downloaded the grub source, I am not a C programmer although I have loads of languages on my CV and can read C well enough (I hate C). The code is awful, even by C standards! I learned about lots of bugs in old kernels that had been fixed by bodging grub.

    I didnt learn why I couldnt install grub on anything but the default partition in a stripped machine.

    Question 1: (Finally)(multi-part)
    i) Why doesnt grub work? What is it about custom partition layouts that seem to confuse it so?
    ii) My understanding is that if the grub files move, I have to reinstall grub, the sector addresses are hard-coded in the loader thats written to the boot sector!?!?!. Is that correct?
    iii) When I have to rewrite grub, how can I do it without dismantling my machine again. If it goes wrong again, how can I actually determine what the bloody hell is wrong?
    iv) Can someone explain why the menu.lst file refers to disc partitions using at least 3 different names? Sometimes it uses hd0 or hd1, sometimes it uses sda or sdb and sometimes it uses /dev/mapper/pdc_ehhhhahd.
    v) I understand why /dev/mapper/pdc_ehhhhahd exists; its a RAID set, not a device. Its just happens that on my system they are devices. But really, /dev/mapper/pdc_ehhhhahd? (The others are /dev/mapper/pdc_ecfjjhcj, /dev/mapper/pdc_cggheeib and /dev/mapper/pdc_ehhhhahd) Now one of these is just a bog standard parallel ata device on a bog standard onboard ATA controller and has nothing to with RAID, I couldnt tell you which one though. How on gods green earth is anyone who doesnt have an eidetic memory supposed to cope with that.

    No matter how much I read google or the documentation or my tea-leaves, I just couldnt get any hint as to which of these names I should be using on which parameters and whether they could possibly be numeric or not!

    Any ideasPlease..cause I know that just when Im about to sit down and watch the football, or a film or Doctor Who on my nice new openSUSE powered PVR, one day sooner or later this is going to come back and bite me in the bum again.

    PS It may be sooner because Im pretty sure Im going to have to repartition this drive, the 6G partition for / isnt going to be big enough.

  2. #2
    Join Date
    Jun 2008
    Finland, European Union

    Default Re: Problem 1. What is occurring with my discs?

    Quote Originally Posted by WhoWhatWhere View Post
    Promise Fastrak 376 RAID controller.
    Your problem. It's not a real RAID controller - it's simply a fakeraid-software solution.

    And a badly supported one at it.

  3. #3

    Default Re: Problem 1. What is occurring with my discs?

    You'll want to look at getting a 3ware card. Promise is software raid only. You can do the same thing with linux's raid software and your motherboards sata connectors.

    For my desktop, I wouldn't do linux without a 3ware card. Kernel native drivers, controller only raid- don't leave home without it.

    I have a stack of promise cards laying around because of your exact issue.

  4. #4

    Default Re: Problem 1. What is occurring with my discs?

    Removing the Promise card isn't an option, it's an onboard controller, as I mentioned originally. My motherboard's sata connections are connected to this controller, if I were to disable it, I would lose 800Gb of storage and that also is not an option.

    None of which seems to really answer the question as to why I can't write the grub bootloader code to a disc that isn't even attached to the RAID controller in the first place. No other utility I have from Windows 98 DOS mode fdisk to Norton Ghost to an ancient version of a Norton boot manager have any trouble writing boot records to these devices. Just grub. If I could work out why grub was having problems I might be able to come up with a way to get round the problems.

    "Because it's crappy raid" ain't a great deal of help :-)

  5. #5
    Join Date
    Jun 2008
    Atlanta, Georgia, USA

    Default Re: Problem 1. What is occurring with my discs?

    Sharing a similar background as yourself (and probably being somewhat close in yrs), let me offer that the world of Linux and open source is very different than what we experienced in the proprietary world (my background in Unix, although a close cousin, involved a totally different paradigm). So at every level; technical, cultural, process, informational, etc., the approach is different.

    Looking at the grub source (or complaining about it) is not going to be helpful. The code may not be beautiful, but it is extremely flexible and, most importantly, it's free. While it can be rather obtuse to work with, still, in the vast majority of cases, it works great. Once you get the hang of it, it's (usually) not difficult.

    On to focusing on the problem: Do you just want to install SuSE on the PATA master? How do you want to partition this drive and correspondingly install Linux? Is this drive the first in the bios disk controller detection sequence (as opposed to the SATA's)? Is it the first drive in the bios *boot* sequence? Will this be the primary boot drive, and will you boot Windows from grub/this drive? This is all relevant to not only how to accomplish your end objective, but to answering some of your questions, some of which I'll try to address here.

    Grub has to literally guess which drives are which. That is because there is no standard re how boot sequence is reported by the bios, if it is at all. Consequently, there is the file. Here the user specifies the drive (not boot) sequence and assigns grub drive designators. The syntax grub uses is hd0 for the first drive and so on. So on your system, the IDE master may be the Linux sda and grub's hd0. Or, it's possible that the first SATA drive is sda and grub's hd0. In the menu.lst file which directs grub's actions, the "root (hd<n,n>)" statement will point grub to which drive/partition to find the boot kernel. As you can see, the sequencing must all be in alignment or grub may be looking in the wrong location.

    Also in the menu.lst file is the "kernel" statement. While the "root" statement points to the location of the kernel, the kernel statement points to the specific kernel filename (as there can be more than one) plus where the kernel once loaded should look for the root filesystem to mount. So in the kernel statement there is a phrase like "root=/dev/sda1" which is *kernel* syntax, this is different than grub's preceding "root" location syntax.

    Grub can be installed in a number of different ways. It can be put in the MBR; analagous to how the Windows MBR finds ntldr and boot.ini, grub can find menu.lst (these are called "stage 1.5" because the boot loader execution is in two chained pieces, the strap code plus the loader file located elsewhere - but unlike Windows, this can be on any partition with a kernel). Grub can also be installed in any partition's boot sector, and called from there (chainloading). There can be multiple grub's installed. Grub can be installed on a floppy (or bootable CD), with and menu.lst also on the floppy (so this is a "stage 2" installation), or it can be pointed to a menu.lst location (again, a "stage 1.5"), or it can be the strap code *and* the grub shell, allowing the user to interactively find boot loaders and kernels as well as supply what menu.lst would otherwise provide (great for debugging and recovery).

    One reason the grub installation gets borked is because the Linux distro script has to do the same guesswork as grub. This gets a bit more complicated if there are other OS's/boot loaders installed. And a lot more if the installation has not been provided a driver which enables the kernel to see the disk controller (this is analagous to the F6 requirement to add a SATA drive when installing XP). In your system, I think that kernel module is sata_promise. Now throw in that the user may wish to handle the booting in one of a number of different ways. And Windows rigid peculiarities. The script can only be so smart at figuring all this out, and frequently in complex setups, it won't. (Windows of course doesn't have anything like this problem; the system [boot] partition must be the first on the first drive, and that's the end of it.)

    Reply back with the setup you are looking for and I can suggest how to make that happen. And, also, I don't exactly follow your RAID configuration. It looks like you are using RAID1 to mirror the 3rd and 4th SATA drives. But what are you doing with the IDE slave? It's not part of any array, is it?

    Hope this is a good start. Pretty sure we can get this fixed.

  6. #6
    Join Date
    Jul 2008
    ah...on earth certainly !

    Default Re: Problem 1. What is occurring with my discs?

  7. #7
    Join Date
    Jun 2008
    Atlanta, Georgia, USA

    Default Re: Problem 1. What is occurring with my discs?


    To round out the answers to your questions (it got late last night) . . .

    More re the naming convention in menu.lst: On the "kernel" line which indicates the filename of the kernel for grub to call and passes boot parameters to the kernel, the "root=xxxx" phrase tells the kernel where to find the root directory to mount. Above, I used the example of "root=/dev/sda1"; in this case sda1 is a "device name." The kernel can identify a partition by any one of five different conventions (device name, volume label, device ID, device path, UUID). Device name has been typically used, but that has become problematic especially with SATA because bios's don't necessarily report drive sequence consistently. Device ID is more reliable, as it is the unique drive identifier from its firmware. openSUSE has switched to using device ID as the default in fstab and menu.lst for this reason. The unfamiliar numbering you saw in menu.lst was probably the UUID's, commonly used with RAID drives.

    Finally, re having to reinstall grub later: Not unless you fundamentally change your hardware (like adding a new drive for a new OS to boot) or your boot configuration (like booting from a different drive that you had not previously installed grub to its MBR). With "stage 1.5" installs (ref above), the grub code installed is the same; the variable is the menu.lst file pointed to. You will make changes to menu.lst, but that doesn't require doing anything with the grub code itself.

  8. #8
    Join Date
    Jun 2008
    Atlanta, Georgia, USA

    Default Re: Problem 1. What is occurring with my discs?

    This may also be of interest:

    SDB:The Boot Manager Grub - openSUSE

  9. #9

    Default Re: Problem 1. What is occurring with my discs?

    Thanks for your response(s),

    What I am trying to achieve is to have openSUSE on my primary IDE master, currently this is partiitioned as
    i) 74Mb boot
    ii) 1.9Gb swap
    iii) 6.6Gb root
    iv) 8.6Gb home
    home is only going to contain a minimal amount of stuff for user config files etc. My own proper data is stored elsewhere, so I want to merge the root and home partitions and then point /home/steve somewhere else.

    I'm fairly confident I can do all the shuffling around from the Live CD I have, but I don't want to find that I have to go through the "terror from beyond grub" movie again

    I have written grub to the MBR of my IDE Master. What I want grub to do is to enable me to either boot openSUSE from the primary IDE master or to boot XP from the 100Gb drive, 1st Primary Partition, on the pata slot on the raid controller. Sometime in the future I can then delete XP. (Oh Happy Days) At the moment this is working fine.

    Now to answer some of your questions.

    The devices attached to the RAID controller don't actually use RAID. They are defined as 1 volume RAID sets, the RAID controller is acting purely as an additional disc controller because I have CD and DVD drives attached to the m/b IDE controllers.

    The BIOS is set to boot from the Primary IDE Master only. Everything else has been disabled.
    I don't think the BIOS detects the raid devices at all, this seems to be done by the RAID controller, this appears to be called just before the system boots. The motherboard's primary IDE Master, my linux drive, is /dev/sdd if that helps (It seems to imply that that the RAID devices (/dev/sda, sdb and sdc) are detected first doesn't it?)

    Obviously, grub has to boot into openSUSE on this device, also it has to boot into XP on the first device attached to the RAID controller (hd1), as that's where XP lives. I have to put in grub map statements to swap hd0 and hd1 to get this to work, but I was expecting that.

    I have got the thing to work in the manner I require, I am worried about what happens when I change my configuration about, something I am apt to do because I like to fiddle, anyway, I want to adjust the partitioning on openSUSE. I read somewhere in the mounds of stuff I waded through trying to get this stuff to work that the grub stage1 loader written to the MBR contains pointers to the rest of grub such that if the rest of grub moves, for example an update, you need to rewrite grub.
    From SDB:The Boot Manager Grub - openSUSE When the boot loader is installed, the physical location of stage 2 on the hard disk is entered in the stage 1 file
    I have pretty much worked out that the yast bootloader script is wasted space for my config for the reasons that you mentioned, and I do see the problem, but I know where everything is and what the device numbers are, and I know where I want the various bits of grub to go, but I don't seem to be able to communicate this knowledge to grub from a shell. Except by trial and error. Yes, I accept that this is because I don't have an understanding as to what's going on, that's what I am trying to achieve by asking these questions.

  10. #10
    Join Date
    Jun 2008
    Atlanta, Georgia, USA

    Default Re: Problem 1. What is occurring with my discs?

    It seems that you have just about got it all worked out.

    I am still somewhat confused about your drive setup. You indicate that the optical drives are on the motherboard IDE controllers; is not the 16GB drive also on one of those controllers? Because you indicate that drives 2-4 are on the Promise controller. And the Promise is set up as ATA, so while it has RAID capability, it is not operating as such. You have a PATA/IDE drive on this controller and also 2 SATA drives on the same controller?

    In any event, what is important is that all the drives are being passed by the bios to the boot strap, and the sequence. If the 16GB IDE master is /dev/sdd, then yes, it **appears** that the 110GB drive is /dev/sda. I'm not absolutely postive, because of the questions above. My comments below assume this is correct.

    You mention that the bios doesn't seem to see the SATA drives. Yes, and no. Exactly how the device gets recognized will vary depending on whether the controller is on-board or on a card on the pci bus. What does happen either way is that the firmware is loaded and the devices are appended to the bios list for irq assignment, and made available to the boot loader Again, what is important is the sequence that this particular bios provides.

    If your IDE master is sdd and the 110GB drive is /dev/sda, then /boot/grub/ file should map /dev/sda to (hd0) and so on, so that /dev/sdd where openSUSE resides, is (hd3). And your menu.lst should have "root (hd3,0)", and the kernel line should show "root=/dev/sdd" (or one of the other partition designators, as I posted earlier).

    A small, but critical and often overlooked twist, is in your kernel and initrd lines of menu.lst. Grub is going to find these files (i.e., vmlinuz and initrd) by traversing the root partition's file system. Grub will not see the files under /boot, because the parent root (/) file system is not on that partition. On your grub root partition, boot *is* the parent directory. Hence your kernel and initrd lines should *not* be "/boot/vmlinuz" and "/boot/initrd", but rather "/vmlinuz" and "/initrd".

    If the XP drive is in fact /dev/sda, you do not need the map command. Map serves to fool Windows into thinking it is booting from the first drive when in fact it is not. But if that drive is already being reported as the first drive, not needed. Hence, if /dev/sda <> (hd0) is correct, then just use:
    rootnoverify (hd0,0)
    chainloader +1
    and grub will hand off to the Windows boot loader.

    In the Support Database article linked above, it describes how to break out of the grub boot menu to the grub shell (hitting "c"), and using the grub "find" command to locate what it thinks is the drive/partition setup (remember, using the grub hd<n> convention based on Useful also is the tab key, where in the shell you can do ">root (hd0 <tab>" and grub will display the partitions; this helps verify whether hd0 is in fact the drive you think it is, as defined in, and similar with other drives.

    You should test out the sequencing assumption that way. If the above is incorrect and the 110GB is not /dev/sda (hd0), then you will need to use the map command in menu.lst to boot XP. If for example the 110GB was /dev/sdb <> (hd1), you would need to do "map (hd0) (hd1)".

    Re the grub pointer in the MBR: "Stage-1.5" is literally the pointer. "Stage 1" is the 512Kb strap code. The pointer directs to where the "stage 2" code resides, which is the actual boot loader; it can be on any [non-Windows] drive/partition. (It is similar to Windows, except that the Windows equivalent of grub's stage-2 must always reside in the first sector of the first partition; so there is no 1.5 pointer, the location is hard-coded.) You can make any manner of changes to the disk partitioning and menu.lst, and not have to reinstall the grub mbr, UNLESS you move the drives or partitioning such that the stage-1.5 pointer becomes invalid. For example, if root is /dev/sdd (hd3), and you physically move the drive to /dev/sdb, there is going to be a problem unless you reinstall grub. Similarly, if you physically move the XP partition to a different location in the sequence, your menu.lst pointer will try to chainload to a boot sector that is not where it was, unless you reinstall grub. Or, if you move the root partition on the drive pointed to, you need to change menu.lst and reinstall grub, too. You have it now as the first partition on /dev/sdd (which is smart, by the way); if you moved it to the second partition, grub won't be able to find it without reinstall.

    Now to the method of installing grub: The SDB article ref'd above describes the /etc/grub.conf file that YaST serves to the grub shell as $stdin to direct where/how the loader should be installed. In my experience, this is where the YaST grub installation gets in trouble. First, the user may have specified a location, etc. incorrectly. Second, by default YaST will try to figure out what it should be, and it can get that wrong. You can manually modify grub.conf in YaST, but the syntax is not simple. So I stopped using /etc/grub.conf years ago, and therefore I don't use YaST to install grub, either. I just find it much, much easier and I am more sure of exactly what is being done, when I install grub directly from its shell in a terminal.

    Again, the SDB article describes how to do this, using the "setup" command. (I don't use the "install" command; that calls /etc/conf.) Since you are in the grub shell, again, you can use the "find" command, etc. to be sure that you are using the correct "root (hd<n>,<n>" statement. So, assuming your boot /dev/sdd1 directory is (hd3,0), in the shell it would be:
    >root (hd3,0)
    >setup (hd3)
    That will place the grub stage-1 strap in the (hd3) MBR, and the stage-1.5 pointer will direct to the first partition on the same drive, to find grub stage-2. (Note: grub can be installed to any partition boot sector as well, for example, to enable chainloading from other grub's; to >setup above could be >setup (hd3,0) to install grub in the boot sector of your boot partition.)

    There is another method not mentioned in the SDB article: The "grub-install" script. The Debian distros use this method. There is a man page. It's run with the parameters "dev/sd<n>" or "(hd<n>)", and executes the grub commands for you. I sometimes use it, too.

    Finally, let me suggest a helpful tool, which also serves to boot the system should the hard disk grub installation or configuration get borked: A grub boot floppy. (This can be done making a bootable CD too, I won't get into how to do that.) With a grub floppy, you can boot into the grub shell and from there (using "find" as described above, etc.) determine what the correct boot syntax should be, and interactively execute a grub stanza to boot. Also very helpful at testing a new configuration before reinstalling grub or changing menu.lst (remember that you can also do such testing from the regular grub menu by keying "c" to take you to the shell, and after returning to the menu with "escape", modify a stanza as desired; I find the floppy to be a quicker method, and a backup should your MBR grub get borked from your re-configuring).

    To create the floppy: First. the usual method with the "dd" command from the grub manual and posted all over the web, does not work anymore. Apparently the size of the stage2 file when written by dd to the floppy throws off the geometry as the bios sees it. Second, the other most frequent method which uses the grub shell and the >setup command, writes the stage-1.5 pointer to the floppy; consequently, it will boot but if the pointer is invalid, the result will be the same as having booted from the MBR; grub may freeze up. Unfortunately, the >setup command can not be forced to exclude the 1.5 pointer (which was the reason the dd method was created). My solution: Put stage-2 on the floppy along with and a menu.lst. When this is done, the floppy boots into the grub menu, it does not seek stage-2 or menu.lst on disk. You can then "c" out of that menu into the grub shell, find what is needed, and create the boot stanza. Here is how to do it, as root (after inserting floppy):
    #mke2fs /dev/fd0 ##formats the floppy
    #mount /dev/fd0 /media/floppy
    #cd /media/floppy
    #mkdirhier boot/grub ##makes a /boot/grub directory on the floppy
    #cd /boot/grub
    #cp stage1 stage2 menu.lst /media/floppy/boot/grub

    An optional step if you want to modify your copied production menu.lst, to just be a dummy, e.g., to remove the timeout, remove the gfxmenu pointer, etc.: Just open /media/floppy/boot/grub/menu.lst in a text editor and change as desired. Then:
    grub>device (fd0) /dev/fd0
    grub>root (fd0)
    grub>setup (fd0)

    Be sure to "quit" before ejecting the floppy! The setup command should reply with having installed stage-1 and stage-2, and not stage-1.5. You now have a universal/recovery grub boot floppy.

    Hopefully, this covers all the ground you need to finish your tasks. Good luck.

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts