Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Why NOT use Linux?



This should help for your last point.
I have a %pre script that runs in my kickstarts that fixes the enumeration
problem of disks if you need it.
The same could be done for the Ethernet. I have the same problem when you
don't want to use the onboard ports and you need the PCI ports to be first.
What you do is
        /etc/init.d/network stop
        remove the HWADDR= and UUID= lines from the ifcfg-eth* files
        edit /etc/udev/rules.d/70-persistent-net.rules file and
        change the NAME= entries to what you want
        /sbin/start_udev
        /etc/init.d/network start
Now they will always be what you wanted.

For the disks - 
especially when you have hardware raid and you want the disks in a specific
order - you have to load the driver modules in the order you want the disks
seen.
I also needed to wipe any OS specific raid info off the disks.

%pre
#!/bin/bash
#
# put the disks in the right order since the controllers come up in random
order on these boxes!
# internal, external array, external raw disks
#
rmmod -f megaraid_sas > /dev/null 2>&1
rmmod -f mptsas > /dev/null 2>&1
rmmod -f sd_mod > /dev/null 2>&1
modprobe sd_mod > /dev/null 2>&1
modprobe megaraid_sas > /dev/null 2>&1
modprobe mptsas > /dev/null 2>&1
#
# wipe out any partitions and raid signatures since clearpart doesn't seem
to do it
#
for disk in a b c d # obviously you need to adjust this for the number of
disks
do
        # first try brute force
        dd if=/dev/zero of=/dev/sd$disk bs=512 count=2
        seek=`fdisk -s /dev/sd$disk`
        seek=`expr $seek - 20`
        dd if=/dev/zero of=/dev/sd$disk seek=$seek bs=1k
        # wipeout any dm-raid signatures
        dmraid -D -r /dev/sd$disk > /dev/null 2>&1
        [ -d ddf1 ] && dd if=/dev/zero of=/dev/sd$disk seek=`cat
ddf1/sd${disk}.offset` bs=1 count=`cat ddf1/sd${disk}.size` > /dev/null 2>&1
        [ -d dmraid.ddf1 ] && dd if=/dev/zero of=/dev/sd$disk seek=`cat
ddf1/sd${disk}.offset` bs=1 count=`cat ddf1/sd${disk}.size` > /dev/null 2>&1
        # wipeout any mdadm raid signatures
        mdadm --zero-superblock --force /dev/sd$disk > /dev/null 2>&1
done > /dev/null 2>&1
exit 0
%end

-----Original Message-----
From: discuss-bounces+joe=polcari.com at blu.org
[mailto:discuss-bounces+joe=polcari.com at blu.org] On Behalf Of Richard Pieri
Sent: Thursday, February 13, 2014 10:08 AM
To: Boston Linux and Unix
Subject: Re: [Discuss] Why NOT use Linux?

Ted Roche wrote:
> And if you're presenting a Pro/Con argument for Linux, clearly we've 
> provided you with material for that, too. Why NOT use Linux?

My top three:

The state of desktops on Linux is terrible. Of the three leaders we have KDE
which is a disaster, Unity which is a tablet UI desperately looking for
hardware to run on, and Gnome which is trying to be the prettiest desktop
around with just a single button that doesn't do anything. If you're looking
for a desktop operating system then Linux is the last place to look. What's
most unfortunate about this is that the *BSDs suffer just as much in this
regard.

The state of file system backups is even worse. Linux has lacked native
backup tools for its file systems since around 2002 leaving things like
extended attributes and ALCs in the lurch. rsync has been hacked to be able
to replicate extended attributes but that only works when going from like to
like; you can't use it for tapes and optical storage.

Dynamic device enumeration. Ever have a node refuse to boot because the
kernel randomly changes which disk is sda with every boot? Ever have a node
stop responding after a reboot because the kernel swapped the first and
second Ethernet interfaces? I have, more times than I care to remember.
Dynamic enumeration is a stupid, stupid way to do things.

-- 
Rich P.
_______________________________________________
Discuss mailing list
Discuss at blu.org
http://lists.blu.org/mailman/listinfo/discuss





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org