Problem 1. What is occurring with my discs?

English Install/Boot/Login
1

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. I’ve 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 doesn’t 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, (I’m 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, what’s wrong with it? I’ve 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 didn’t 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 didn’t learn why I couldn’t install grub on anything but the default partition in a stripped machine.

Question 1: (Finally)(multi-part)
i) Why doesn’t 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 that’s 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; it’s a RAID set, not a device. It’s 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 couldn’t tell you which one though. How on god’s green earth is anyone who doesn’t 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 couldn’t 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 ideas……Please………cause I know that just when I’m 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 I’m pretty sure I’m going to have to repartition this drive, the 6G partition for / isn’t going to be big enough.

2

Your problem. It’s not a real RAID controller - it’s simply a fakeraid-software solution.

And a badly supported one at it.

3

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

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 :slight_smile:

5

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 device.map 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 device.map 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

Will this link be of any help to you ?

[SOLVED] Booting into an installed opensuse 11 system with grub4dos - Boot Land](http://www.boot-land.net/forums/index.php?showtopic=4983)

7

WhoWhatWhere@

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

This may also be of interest:

SDB:The Boot Manager Grub - openSUSE

9

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 :slight_smile:

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

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/device.map 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)
makeactive
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 device.map). 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 device.map, 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)
>quit
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 device.map 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 device.map 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
grub>device (fd0) /dev/fd0
grub>root (fd0)
grub>setup (fd0)
grub>quit

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.

11

I’m sorry to be a pain …

I thought I’d got some sort of a hold on this stuff but now you’ve gone and deleted my understanding file on this.

I sort of figured out that the order that the drives were being passed from the BIOS was as below, mainly because of the order they were assigned sd? names (I added the bits at the end to identify the drives):

dmraid -r
/dev/sda: pdc, “pdc_ecfjjhcj”, stripe, ok, 781422592 sectors, data@ 0 // 400Gb SATA RAID Data
/dev/sdb: pdc, “pdc_ehhhhahd”, stripe, ok, 781422592 sectors, data@ 0 // 400Gb SATA RAID Data
/dev/sdc: pdc, “pdc_cggheeib”, stripe, ok, 234441472 sectors, data@ 0 // 110Gb PATA RAID XP
/dev/sdd: pdc, “pdc_caaghchii”, stripe, ok, 33683200 sectors, data@ 0 // 16Gb PATA IDE LINUX

Your last post says that my linux boot drive should therefore be hd3 to grub, but my device.map file is:

/boot/device.map
(fd0) /dev/fd0
(hd0) /dev/mapper/pdc_caaghchii
(hd1) /dev/mapper/pdc_caggheeib

If it should be hd3, and I agree that seems the logical choice, why does hd0 work? I guess my XP boot drive should be hd2 as well. Not that I’m going to change them now it’s finally working, “If it ain’t broke, don’t fix it!”

I need the map commands in the XP section cause it doesn’t work without them, grub tries to boot the right partition, but I get a message saying NTLDR IS MISSING.

12

. . . but now you’ve gone and deleted my understanding file on this.

What does that mean???

I sort of figured out that the order that the drives were being passed from the BIOS was as below, mainly because of the order they were assigned sd?

Where this can get very confusing is that the device sequence and the boot sequence can be different from one another. The OS is going to read the device sequence vis-a-vis the bios. I’ve seen this done IDE (PATA)/chipset SATA/on-board SATA/PCI bus, but also done differently. On my machine, the BIOS startup displays the IDE devices before SATA, but the OS sequence begins with the SATA; the display is deceptive. I suspect - I have not been able to verify this yet - that there was a change in the kernel to arbitrarily start with SATA because of inconsistencies with how bios’s construct the sequence.

In any event, grub can’t know anything about this. What it knows is the boot sequence. This is why if you setup device.map and menu.lst one way and then change the boot sequence in the bios, you can confuse grub. Keep that in mind if you get into multi-boot configurations with OS instances on different drives; you need one instance’s device.map and menu.lst to be a master for all instances, or you need a separate device.map and menu.lst for each instance with grub installed in the boot sectors of each instance and then chainload between them or switch using the bios. I’ve used all these methods and they all work fine, it just takes a while to learn how to set everything up consistently.

As far as using the map command, that’s to be expected. The Windows boot manager is totally stupid; Windows must “think” it is on the first drive, with the boot volume the active primary. Now, Vista’s BCD is much more flexible, but still not as much as grub. Bottom line, unless the bios boot sequence has the Windows drive defined as the first boot device, then grub must use the map command to “virtually” re-define the drive Windows is on to be the first drive. Otherwise, you’ll get an “ntldr not found” error which is Windows saying it can’t find the boot volume.

Bottom line is, you got is working. Now don’t touch. Hopefully some of the theory in this thread will be helpful sometime.

13

mingus725 wrote:

> Where this can get very confusing is that the device sequence and the
> boot sequence can be different from one another. The OS is going to
> read the device sequence vis-a-vis the bios. I’ve seen this done IDE
> (PATA)/chipset SATA/on-board SATA/PCI bus, but also done differently.
> On my machine, the BIOS startup displays the IDE devices before SATA,
> but the OS sequence begins with the SATA; the display is deceptive. I
> suspect - I have not been able to verify this yet - that there was a
> change in the kernel to arbitrarily start with SATA because of
> inconsistencies with how bios’s construct the sequence.

I’m looking at this same issue and my BIOS (Lenovo J-series) seems to make
thing even more interesting. When I had ONLY the SATA drive installed, sda
was (naturally) the SATA drive. When I added a PATA drive, suddenly that
showed up as sda, shifting the SATA drive to SDB. OK, I can live with that
but… after I disconnected the SATA drive, leaving the the PATA drive as
the sole drive just to get the Win restoration to use the PATA drive then
later re-installed the SATA drive, the SATA drive became sda and the PATA
drive was now sdb! Best I can tell, this particular BIOS is remembering
prior configurations and doing it’s own thing when a drive is added - talk
about musical chairs!

–
Will Honea