[SOLVED] generic kern swaps sda & sdb while huge doesn't
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
hugesmp keeps the bios's order of two HD's while genericsmp reverses ie sda becomes sdb and sdb becomes sda.
Supermicro pentium III server motherboard which has onboard Adaptec ultra 160 scsi controller.
I have in it a pci card sata controller. In the bios, IBM scsi HD is the first HD and sata HD is 2nd of 2 drives in that order (it's how I set it, my OS is on the scsi and data is on the larger sata).
Works fine with huge. During boot, lists sda as IBM scsi and sdb as sata HD.
I made an initrd with Eric's initrd command generator. I edited lilo.conf then ran /sbin/lilo.
generic kernel, when booted, lists sda as sata and sdb as IBM scsi. Obviously it chokes after a bit "cannot find /sbin/init"
I had earlier booted from a systemrescuecd which also lists the sata as sda and the scsi as sdb.
So, why would hugesmp be different than both genericsmp and systemrescuecd?
Does the kernel translate the bios whereby hugesmp somehow does better at this?
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810
Rep:
Quote:
You may want mounting by UUID in this case.
Or an aternative I find easier is to apply a label to the volume which e2label than alter /etc/lilo.conf and /etc/fstab to reflect the LABEL= settings for the mount and root= kernel option in lilo.conf. This way it'll always find the partitions with no problem. It's especially useful when it comes to using USB attached storage which often changes it's device name depending on what's also plugged in.
The driver initialization order is different between huge and generic assuming that you are loading your SCSI interface driver as a module. The drivers built into the generic kernel initialize first and they get the first drive assignments.
Annoying, but it is what it is. That's one of the reasons why I switched to Grub.
You could compile your own kernel that is almost exactly like the generic one only with your SCSI controller's driver built into the kernel. Your new kernel should initialize the drivers in the same order as huge.
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810
Rep:
Quote:
bgeddy,will that label method have the power to sda instead of sdb for the scsi HD?
I know what a partition label is but where do I get more info on what goes into lilo.conf and fstab?
No - the idea is to have a constant reference to the partitions no matter what device name is assigned to them.
I last had all this working some time ago as I used to cart my USB drive around and it would be assigned different device names on different machines. I primarily wanted to boot off it, if the target machine allowed, and this came to me using LABEL's in lilo.conf and fstab. I seem to remember some difficulty with this requiring changes to the initial ram disk but, to be honest, it's a bit hazy in my mind and I don't have the old setup any more.
I have been playing around with this this afternoon to test my recollections and hopefully help you out a bit but I have not managed to get it to work so far - not a good sign I know!
If my memory is not completely screwed up I seem to remember UUID's where easier to initially setup but LABEL's gave me a useful reminder of what the volumes actually where. So, for example, you could have LABEL's attached of Swap, Root, Home, etc. rather than using huge, none memorable strings as in UUID's.
Quote:
I know what a partition label is but where do I get more info on what goes into lilo.conf and fstab?
Look at man e2label, man blkid, man fstab and man lilo.conf for hints about this. They mention settings for UUID's and LABEL's in fstab and lilo.conf. You can use "e2label" to attach labels and "mkswap -L" to make a swap drive with a label attached.
I've tried finding a good tutorial about setting this all up with lilo/fstab as it seems a common problem but there isn't much on line it would seem.
And SCSI_AIC7XXX now loads very early (or doesn't even need to load since it's in the kernel) Nonetheless the bootup messages to screen show early on SCSI_AIC7XXX hooking up with the hard drive.
Aha! It finds the O.S. on SDA which is IBM scsi and SDB is the sata. This compiled generic kernel now orders the drives exactly the same as the Huge kernel.
I compiled this puppy on my dual core pentium 4 box then I copied it to my Supermicro Pentium III server where it works really great.
But when I edited the original 13.37 32 bit generic config, I only made the above edits.
What I'm lost on now is why so many changes showed up when I diffed the orig versus my edited config.
During compiling may it auto edit, say, for the dual core Pentium 4 hardware?
Here's *all* the changes that showed up to my surprise. I don't know if it is anything to be concerned about as the PIII server box now runs fine.
Code:
diff config-generic-2.6.37.6 config-ac-gen-2.6.37.6
4c4
< # Sat Apr 9 23:55:37 2011
---
> # Sat Apr 9 13:29:56 2011
48a49,52
> CONFIG_USE_GENERIC_SMP_HELPERS=y
> CONFIG_X86_32_SMP=y
> CONFIG_X86_HT=y
> CONFIG_X86_TRAMPOLINE=y
50a55
> CONFIG_ARCH_CPU_PROBE_RELEASE=y
60c65
< CONFIG_BROKEN_ON_SMP=y
---
> CONFIG_LOCK_KERNEL=y
63c68
< CONFIG_LOCALVERSION=""
---
> CONFIG_LOCALVERSION="-smp"
98c103
< # CONFIG_GENERIC_PENDING_IRQ is not set
---
> CONFIG_GENERIC_PENDING_IRQ=y
107c112
< CONFIG_TINY_RCU=y
---
> CONFIG_TREE_RCU=y
108a114,117
> # CONFIG_RCU_TRACE is not set
> CONFIG_RCU_FANOUT=32
> # CONFIG_RCU_FANOUT_EXACT is not set
> # CONFIG_RCU_FAST_NO_HZ is not set
218a228
> CONFIG_STOP_MACHINE=y
236a247
> CONFIG_PADATA=y
265c276
< # CONFIG_MUTEX_SPIN_ON_OWNER is not set
---
> CONFIG_MUTEX_SPIN_ON_OWNER=y
272c283
< # CONFIG_NO_HZ is not set
---
> CONFIG_NO_HZ=y
275c286
< # CONFIG_SMP is not set
---
> CONFIG_SMP=y
276a288
> CONFIG_X86_BIGSMP=y
284c296
< CONFIG_M486=y
---
> # CONFIG_M486 is not set
288c300
< # CONFIG_M686 is not set
---
> CONFIG_M686=y
314,315d325
< CONFIG_X86_F00F_BUG=y
< CONFIG_X86_INVD_BUG=y
320d329
< CONFIG_X86_ALIGNMENT_16=y
322c331,336
< CONFIG_X86_MINIMUM_CPU_FAMILY=4
---
> CONFIG_X86_USE_PPRO_CHECKSUM=y
> CONFIG_X86_TSC=y
> CONFIG_X86_CMPXCHG64=y
> CONFIG_X86_CMOV=y
> CONFIG_X86_MINIMUM_CPU_FAMILY=5
> CONFIG_X86_DEBUGCTLMSR=y
334c348,350
< CONFIG_NR_CPUS=1
---
> CONFIG_NR_CPUS=32
> CONFIG_SCHED_SMT=y
> CONFIG_SCHED_MC=y
339,340d354
< CONFIG_X86_UP_APIC=y
< CONFIG_X86_UP_IOAPIC=y
362a377
> # CONFIG_HIGHMEM64G is not set
389d403
< CONFIG_NEED_PER_CPU_KM=y
413a428
> CONFIG_HOTPLUG_CPU=y
422a438
> CONFIG_PM_SLEEP_SMP=y
444a461
> CONFIG_ACPI_HOTPLUG_CPU=y
512a530
> CONFIG_CPU_IDLE_GOV_MENU=y
1018a1037
> CONFIG_RPS=y
1041d1059
< # CONFIG_DMASCC is not set
1564c1582
< CONFIG_SCSI_AIC7XXX=m
---
> CONFIG_SCSI_AIC7XXX=y
1773a1792
> # CONFIG_MULTICORE_RAID456 is not set
1881d1899
< # CONFIG_NI5010 is not set
2342d2359
< # CONFIG_ISDN_DRV_LOOP is not set
2848d2864
< # CONFIG_I2C_ELEKTOR is not set
4693c4709
< CONFIG_EXT4_FS=m
---
> CONFIG_EXT4_FS=y
4700c4716
< CONFIG_JBD2=m
---
> CONFIG_JBD2=y
4702c4718
< CONFIG_FS_MBCACHE=m
---
> CONFIG_FS_MBCACHE=y
5013a5030
> # CONFIG_RCU_CPU_STALL_DETECTOR is not set
5017a5035
> CONFIG_CPU_NOTIFIER_ERROR_INJECT=m
5073a5092
> # CONFIG_DEBUG_PER_CPU_MAPS is not set
5141a5161
> CONFIG_CRYPTO_PCRYPT=m
Or an aternative I find easier is to apply a label to the volume which e2label than alter /etc/lilo.conf and /etc/fstab to reflect the LABEL= settings for the mount and root= kernel option in lilo.conf. This way it'll always find the partitions with no problem. It's especially useful when it comes to using USB attached storage which often changes it's device name depending on what's also plugged in.
Label was the way Red Hat used to go since v8 (?) or so. That was one of the reason why I dropped Red Hat. It always gave me surprise when I plugged another fixed disk into my computer.
Update: 3rd time's a charm. IOW this was the 3rd kernel compile.
1st one I botched somehow such that it had a fatal failure at 85% and stopped compiling on the Pent III server.
2nd one I compiled it on my dual core pent 4 and forgot to install the new modules (on Pent III server). It worked but ext3 module wouldn't load "invalid format". My sata HD (sdb) is still ext3
For the 3rd compile, I fresh installed 13.37 again on Pent 3 server.
Then I renamed each of the next 2 dirs to .orig (so as to not conflict with what will be the new [matching kernel edition] source and the new modules).
Code:
al@P3SRV:/lib/modules$ ls
2.6.37.6/ 2.6.37.6-smp.orig/
al@P3SRV:/lib/modules$ cd /usr/src
al@P3SRV:/usr/src$ ls
linux@ linux-2.6.37.6.orig/
al@P3SRV:/usr/src$
Then I used my slightly altered config of the generic-smp kernel (aicxxx = y, jbod2 = y, ext4 = y, mbcache_or_whatever = y) (just only enough drivers so that no initrd needed and adaptec scsi driver in the kernel so IBM scsi HD always be sda.
Then I followed the directions at Alien Bob's Slackware wiki under Linux General the kernel compile howto.
All went well. It did not choke this time. I made all. I Then installed the modules. Then copied bzImage to /boot
Works superbly! No initrd needed. Keeps scsi HD always as sda
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.