eclipse / pydev updates ?
Hello SL, when are the updates to eclipse-juno and pydev/matplot coming up for SL-6.3 ? I tried updating from eclipse-helios and by direct downloading, but somehow could not solve the dependency issues. Regards, -- Arun Kishore arunkisho...@imu.co.in
cloning with dd
We have a limited, small, number of IEEE 802.3 connected hardware platform identical workstations to clone -- no 802.11 nor any shared (remote, distributed) disk storage (at this time). My plan was to get one fully operational and configured, and then clone the hard drive image onto the remaining machines one hard drive at a time. Let A represent the operational (clone source) machine, and Bhd a target hard drive. The hard drive on A is /dev/sda, call it Ahd. A is shut down power off. Bhd is installed into an available bay on A, A is booted, and Bhd appears as /dev/sdb in A. Using dd on A, clone /dev/sda to /dev/sdb . Mount on A the partition of /dev/sdb that contains /etc (there are no end user home directories -- only home directories are those of the system administration users). Using a text editor (e.g., vi), modify the /etc/sysconfig/net* scripts/directories, as well as /etc/hosts. for the name and IP address of machine B that will contain Bhd (resolv.conf will be the same -- all of these machines are in the same DNS subzone, same TCP/IP subnet). Iterate through all of the target workstation hard drives. As there are no other distributed services running, this should suffice. Shutdown A, remove Bhd, install Bhd into B, boot B upon which Bhd should appear as /dev/sda . Done. Is there a better method in terms of software? At this time, I do not want to setup a remote image server that effectively will download the full image of Ahd onto Bhd over a network, nor do I want to make a custom install DVD as we only have a small number of workstations to clone, not, say, one hundred. I do understand that if Ahd and Bhd present different bad blocks to the OS, and these are not hidden by the intelligence on each individual hard drive, then dd may not work. However, the drives already have been surveyed and the bad block situation should not be an issue. A related question (that was partially addressed in a different thread): is there a way to remove/disable Network Manager and use a traditional static configuration? On a laptop that needs to move within the field from one 802.11 network to another, with a different DNS zone and TCP/IP configuration, Network Manager provides similar ease and functionality to the end user autoconfiguration applications that are used under Mac OS X or modern MS Win. This is unnecessary and in some sense dangerous for static workstations that need no such dynamic configuration. My thought was to find the RPM that installs Network Manager and simply uninstall it, either via yum or a simple rpm -e command. Is Network Manager too deeply ingrained in current EL6 (using TUV compliant model) to make this feasible? Yasha Karant
Re: cloning with dd
I've done cloning for many years with tar: On the source machine, boot from an SL live CD and mount the source's root file system. Make a tar file of this system with a command like: cd /mnt/wherever tar -cSf - . | ssh someuser@somewhere 'cat mysystem.tar' Then, on the target, boot the live CD, partition the disk, create the root filesystem and mount it. THen untar the contents with something like: cd /mnt/wherever ssh someuser@somewhere cat mysystem.tar | tar -xpSf - You may need to change /etc/fstab and /boot/grub/grub.conf, if the partition layout is different or the files use UUIDs. In the latter case, I just change to partition names (e.g./dev/sda1). Then run grub to install the boot loader: grub root (hd0,X) setup (hd0) This works great as long as the hardware is similar enough that the initrd/initramfs still works. Otherwise, there's an extra step to regenerate it, which I can explain if people want. Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Tue, 29 Jan 2013, Yasha Karant wrote: We have a limited, small, number of IEEE 802.3 connected hardware platform identical workstations to clone -- no 802.11 nor any shared (remote, distributed) disk storage (at this time). My plan was to get one fully operational and configured, and then clone the hard drive image onto the remaining machines one hard drive at a time. Let A represent the operational (clone source) machine, and Bhd a target hard drive. The hard drive on A is /dev/sda, call it Ahd. A is shut down power off. Bhd is installed into an available bay on A, A is booted, and Bhd appears as /dev/sdb in A. Using dd on A, clone /dev/sda to /dev/sdb . Mount on A the partition of /dev/sdb that contains /etc (there are no end user home directories -- only home directories are those of the system administration users). Using a text editor (e.g., vi), modify the /etc/sysconfig/net* scripts/directories, as well as /etc/hosts. for the name and IP address of machine B that will contain Bhd (resolv.conf will be the same -- all of these machines are in the same DNS subzone, same TCP/IP subnet). Iterate through all of the target workstation hard drives. As there are no other distributed services running, this should suffice. Shutdown A, remove Bhd, install Bhd into B, boot B upon which Bhd should appear as /dev/sda . Done. Is there a better method in terms of software? At this time, I do not want to setup a remote image server that effectively will download the full image of Ahd onto Bhd over a network, nor do I want to make a custom install DVD as we only have a small number of workstations to clone, not, say, one hundred. I do understand that if Ahd and Bhd present different bad blocks to the OS, and these are not hidden by the intelligence on each individual hard drive, then dd may not work. However, the drives already have been surveyed and the bad block situation should not be an issue. A related question (that was partially addressed in a different thread): is there a way to remove/disable Network Manager and use a traditional static configuration? On a laptop that needs to move within the field from one 802.11 network to another, with a different DNS zone and TCP/IP configuration, Network Manager provides similar ease and functionality to the end user autoconfiguration applications that are used under Mac OS X or modern MS Win. This is unnecessary and in some sense dangerous for static workstations that need no such dynamic configuration. My thought was to find the RPM that installs Network Manager and simply uninstall it, either via yum or a simple rpm -e command. Is Network Manager too deeply ingrained in current EL6 (using TUV compliant model) to make this feasible? Yasha Karant
Re: cloning with dd
On 01/29/2013 09:56 AM, Steve Gaarder wrote: I've done cloning for many years with tar: On the source machine, boot from an SL live CD and mount the source's root file system. Make a tar file of this system with a command like: cd /mnt/wherever tar -cSf - . | ssh someuser@somewhere 'cat mysystem.tar' Then, on the target, boot the live CD, partition the disk, create the root filesystem and mount it. THen untar the contents with something like: cd /mnt/wherever ssh someuser@somewhere cat mysystem.tar | tar -xpSf - You may need to change /etc/fstab and /boot/grub/grub.conf, if the partition layout is different or the files use UUIDs. In the latter case, I just change to partition names (e.g./dev/sda1). Then run grub to install the boot loader: grub root (hd0,X) setup (hd0) This works great as long as the hardware is similar enough that the initrd/initramfs still works. Otherwise, there's an extra step to regenerate it, which I can explain if people want. Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Tue, 29 Jan 2013, Yasha Karant wrote: We have a limited, small, number of IEEE 802.3 connected hardware platform identical workstations to clone -- no 802.11 nor any shared (remote, distributed) disk storage (at this time). My plan was to get one fully operational and configured, and then clone the hard drive image onto the remaining machines one hard drive at a time. Let A represent the operational (clone source) machine, and Bhd a target hard drive. The hard drive on A is /dev/sda, call it Ahd. A is shut down power off. Bhd is installed into an available bay on A, A is booted, and Bhd appears as /dev/sdb in A. Using dd on A, clone /dev/sda to /dev/sdb . Mount on A the partition of /dev/sdb that contains /etc (there are no end user home directories -- only home directories are those of the system administration users). Using a text editor (e.g., vi), modify the /etc/sysconfig/net* scripts/directories, as well as /etc/hosts. for the name and IP address of machine B that will contain Bhd (resolv.conf will be the same -- all of these machines are in the same DNS subzone, same TCP/IP subnet). Iterate through all of the target workstation hard drives. As there are no other distributed services running, this should suffice. Shutdown A, remove Bhd, install Bhd into B, boot B upon which Bhd should appear as /dev/sda . Done. Is there a better method in terms of software? At this time, I do not want to setup a remote image server that effectively will download the full image of Ahd onto Bhd over a network, nor do I want to make a custom install DVD as we only have a small number of workstations to clone, not, say, one hundred. I do understand that if Ahd and Bhd present different bad blocks to the OS, and these are not hidden by the intelligence on each individual hard drive, then dd may not work. However, the drives already have been surveyed and the bad block situation should not be an issue. A related question (that was partially addressed in a different thread): is there a way to remove/disable Network Manager and use a traditional static configuration? On a laptop that needs to move within the field from one 802.11 network to another, with a different DNS zone and TCP/IP configuration, Network Manager provides similar ease and functionality to the end user autoconfiguration applications that are used under Mac OS X or modern MS Win. This is unnecessary and in some sense dangerous for static workstations that need no such dynamic configuration. My thought was to find the RPM that installs Network Manager and simply uninstall it, either via yum or a simple rpm -e command. Is Network Manager too deeply ingrained in current EL6 (using TUV compliant model) to make this feasible? Yasha Karant You can use g4u (Ghost for Unix) or g4l (Ghost for Linux) to image and back up disks over the network. Usually using FTP. There are other fancier utilities such as Clonezilla that may also work well. Most have bootable media to get it on the network and a few clicks/commands to get the disks cloning. -Mark -- Mr. Mark V. Stodola Senior Control Systems Engineer National Electrostatics Corp. P.O. Box 620310 Middleton, WI 53562-0310 USA Phone: (608) 831-7600 Fax: (608) 831-9591
Re: cloning with dd
There are advantages and disadvantages of the methodology you use. I have the following questions: 1. The SL live CD presumably requires a manual configuration of the network -- this university uses /22 IPv4 subnets (we have not made the full conversion to IPv6, although we support IPv6 addresses and most IPv6 utilities/services) and Network Manager does not seem to be able to detect this. Thus, during the SL live CD boot, the network must be manually configured one machine at a time. 2. On the target machine, one must repeat step (1) and get past LAN security (assuming that the machine that contains the tar image is not on the WAN with additional issues thereby created due to network security control) to untar / onto the target machine. Note that (to the best of my knowledge), tar does not create the MBR (I am being specific to the IA-32/X86-64 typical boot architecture in this comment) and thus requires the additional manual steps you outline. dd of an entire hard drive does clone the MBR and also effectively does the formatting step of each partition (we are not using logical volumes, but old fashioned distinct partitions). You also presume a high throughput network, depending upon the size of the tar file image, as otherwise the time for getting the tar image can be substantial. Whilst the network here is adequate at switched 802.11 100BT, with only limited segments at 1 Gbit/sec or higher bandwidth, the actual throughput -- as measured -- can be less than 1 Mbit/sec causing substantial delays. These workstations are NOT on a 1 Gbit/sec segment, but only at 100BT, and we (locally) have network issues. As the workstations have physical security locks and are cabled through raised flooring, physically moving the machines to a location with a proper 1 Gbit/sec LAN segment, bypassing the local university security implementations, VLAN segments, etc., is a significant amount of physical work. Am I misstating your methodology? Yasha Karant On 01/29/2013 07:56 AM, Steve Gaarder wrote: I've done cloning for many years with tar: On the source machine, boot from an SL live CD and mount the source's root file system. Make a tar file of this system with a command like: cd /mnt/wherever tar -cSf - . | ssh someuser@somewhere 'cat mysystem.tar' Then, on the target, boot the live CD, partition the disk, create the root filesystem and mount it. THen untar the contents with something like: cd /mnt/wherever ssh someuser@somewhere cat mysystem.tar | tar -xpSf - You may need to change /etc/fstab and /boot/grub/grub.conf, if the partition layout is different or the files use UUIDs. In the latter case, I just change to partition names (e.g./dev/sda1). Then run grub to install the boot loader: grub root (hd0,X) setup (hd0) This works great as long as the hardware is similar enough that the initrd/initramfs still works. Otherwise, there's an extra step to regenerate it, which I can explain if people want. Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Tue, 29 Jan 2013, Yasha Karant wrote: We have a limited, small, number of IEEE 802.3 connected hardware platform identical workstations to clone -- no 802.11 nor any shared (remote, distributed) disk storage (at this time). My plan was to get one fully operational and configured, and then clone the hard drive image onto the remaining machines one hard drive at a time. Let A represent the operational (clone source) machine, and Bhd a target hard drive. The hard drive on A is /dev/sda, call it Ahd. A is shut down power off. Bhd is installed into an available bay on A, A is booted, and Bhd appears as /dev/sdb in A. Using dd on A, clone /dev/sda to /dev/sdb . Mount on A the partition of /dev/sdb that contains /etc (there are no end user home directories -- only home directories are those of the system administration users). Using a text editor (e.g., vi), modify the /etc/sysconfig/net* scripts/directories, as well as /etc/hosts. for the name and IP address of machine B that will contain Bhd (resolv.conf will be the same -- all of these machines are in the same DNS subzone, same TCP/IP subnet). Iterate through all of the target workstation hard drives. As there are no other distributed services running, this should suffice. Shutdown A, remove Bhd, install Bhd into B, boot B upon which Bhd should appear as /dev/sda . Done. Is there a better method in terms of software? At this time, I do not want to setup a remote image server that effectively will download the full image of Ahd onto Bhd over a network, nor do I want to make a custom install DVD as we only have a small number of workstations to clone, not, say, one hundred. I do understand that if Ahd and Bhd present different bad blocks to the OS, and these are not hidden by the intelligence on each individual hard drive, then dd may not work. However, the drives already have been
Re: cloning with dd
On 01/29/2013 10:43 AM, Yasha Karant wrote: There are advantages and disadvantages of the methodology you use. I have the following questions: 1. The SL live CD presumably requires a manual configuration of the network -- this university uses /22 IPv4 subnets (we have not made the full conversion to IPv6, although we support IPv6 addresses and most IPv6 utilities/services) and Network Manager does not seem to be able to detect this. Thus, during the SL live CD boot, the network must be manually configured one machine at a time. 2. On the target machine, one must repeat step (1) and get past LAN security (assuming that the machine that contains the tar image is not on the WAN with additional issues thereby created due to network security control) to untar / onto the target machine. Note that (to the best of my knowledge), tar does not create the MBR (I am being specific to the IA-32/X86-64 typical boot architecture in this comment) and thus requires the additional manual steps you outline. dd of an entire hard drive does clone the MBR and also effectively does the formatting step of each partition (we are not using logical volumes, but old fashioned distinct partitions). You also presume a high throughput network, depending upon the size of the tar file image, as otherwise the time for getting the tar image can be substantial. Whilst the network here is adequate at switched 802.11 100BT, with only limited segments at 1 Gbit/sec or higher bandwidth, the actual throughput -- as measured -- can be less than 1 Mbit/sec causing substantial delays. These workstations are NOT on a 1 Gbit/sec segment, but only at 100BT, and we (locally) have network issues. As the workstations have physical security locks and are cabled through raised flooring, physically moving the machines to a location with a proper 1 Gbit/sec LAN segment, bypassing the local university security implementations, VLAN segments, etc., is a significant amount of physical work. Am I misstating your methodology? Yasha Karant On 01/29/2013 07:56 AM, Steve Gaarder wrote: I've done cloning for many years with tar: On the source machine, boot from an SL live CD and mount the source's root file system. Make a tar file of this system with a command like: cd /mnt/wherever tar -cSf - . | ssh someuser@somewhere 'cat mysystem.tar' Then, on the target, boot the live CD, partition the disk, create the root filesystem and mount it. THen untar the contents with something like: cd /mnt/wherever ssh someuser@somewhere cat mysystem.tar | tar -xpSf - You may need to change /etc/fstab and /boot/grub/grub.conf, if the partition layout is different or the files use UUIDs. In the latter case, I just change to partition names (e.g./dev/sda1). Then run grub to install the boot loader: grub root (hd0,X) setup (hd0) This works great as long as the hardware is similar enough that the initrd/initramfs still works. Otherwise, there's an extra step to regenerate it, which I can explain if people want. Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Tue, 29 Jan 2013, Yasha Karant wrote: We have a limited, small, number of IEEE 802.3 connected hardware platform identical workstations to clone -- no 802.11 nor any shared (remote, distributed) disk storage (at this time). My plan was to get one fully operational and configured, and then clone the hard drive image onto the remaining machines one hard drive at a time. Let A represent the operational (clone source) machine, and Bhd a target hard drive. The hard drive on A is /dev/sda, call it Ahd. A is shut down power off. Bhd is installed into an available bay on A, A is booted, and Bhd appears as /dev/sdb in A. Using dd on A, clone /dev/sda to /dev/sdb . Mount on A the partition of /dev/sdb that contains /etc (there are no end user home directories -- only home directories are those of the system administration users). Using a text editor (e.g., vi), modify the /etc/sysconfig/net* scripts/directories, as well as /etc/hosts. for the name and IP address of machine B that will contain Bhd (resolv.conf will be the same -- all of these machines are in the same DNS subzone, same TCP/IP subnet). Iterate through all of the target workstation hard drives. As there are no other distributed services running, this should suffice. Shutdown A, remove Bhd, install Bhd into B, boot B upon which Bhd should appear as /dev/sda . Done. Is there a better method in terms of software? At this time, I do not want to setup a remote image server that effectively will download the full image of Ahd onto Bhd over a network, nor do I want to make a custom install DVD as we only have a small number of workstations to clone, not, say, one hundred. I do understand that if Ahd and Bhd present different bad blocks to the OS, and these are not hidden by the intelligence on each individual hard drive, then dd may not work. However, the drives already have been surveyed and
Re: cloning with dd
On 01/29/2013 08:55 AM, Mark Stodola wrote: On 01/29/2013 10:43 AM, Yasha Karant wrote: There are advantages and disadvantages of the methodology you use. I have the following questions: 1. The SL live CD presumably requires a manual configuration of the network -- this university uses /22 IPv4 subnets (we have not made the full conversion to IPv6, although we support IPv6 addresses and most IPv6 utilities/services) and Network Manager does not seem to be able to detect this. Thus, during the SL live CD boot, the network must be manually configured one machine at a time. 2. On the target machine, one must repeat step (1) and get past LAN security (assuming that the machine that contains the tar image is not on the WAN with additional issues thereby created due to network security control) to untar / onto the target machine. Note that (to the best of my knowledge), tar does not create the MBR (I am being specific to the IA-32/X86-64 typical boot architecture in this comment) and thus requires the additional manual steps you outline. dd of an entire hard drive does clone the MBR and also effectively does the formatting step of each partition (we are not using logical volumes, but old fashioned distinct partitions). You also presume a high throughput network, depending upon the size of the tar file image, as otherwise the time for getting the tar image can be substantial. Whilst the network here is adequate at switched 802.11 100BT, with only limited segments at 1 Gbit/sec or higher bandwidth, the actual throughput -- as measured -- can be less than 1 Mbit/sec causing substantial delays. These workstations are NOT on a 1 Gbit/sec segment, but only at 100BT, and we (locally) have network issues. As the workstations have physical security locks and are cabled through raised flooring, physically moving the machines to a location with a proper 1 Gbit/sec LAN segment, bypassing the local university security implementations, VLAN segments, etc., is a significant amount of physical work. Am I misstating your methodology? Yasha Karant On 01/29/2013 07:56 AM, Steve Gaarder wrote: I've done cloning for many years with tar: On the source machine, boot from an SL live CD and mount the source's root file system. Make a tar file of this system with a command like: cd /mnt/wherever tar -cSf - . | ssh someuser@somewhere 'cat mysystem.tar' Then, on the target, boot the live CD, partition the disk, create the root filesystem and mount it. THen untar the contents with something like: cd /mnt/wherever ssh someuser@somewhere cat mysystem.tar | tar -xpSf - You may need to change /etc/fstab and /boot/grub/grub.conf, if the partition layout is different or the files use UUIDs. In the latter case, I just change to partition names (e.g./dev/sda1). Then run grub to install the boot loader: grub root (hd0,X) setup (hd0) This works great as long as the hardware is similar enough that the initrd/initramfs still works. Otherwise, there's an extra step to regenerate it, which I can explain if people want. Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Tue, 29 Jan 2013, Yasha Karant wrote: We have a limited, small, number of IEEE 802.3 connected hardware platform identical workstations to clone -- no 802.11 nor any shared (remote, distributed) disk storage (at this time). My plan was to get one fully operational and configured, and then clone the hard drive image onto the remaining machines one hard drive at a time. Let A represent the operational (clone source) machine, and Bhd a target hard drive. The hard drive on A is /dev/sda, call it Ahd. A is shut down power off. Bhd is installed into an available bay on A, A is booted, and Bhd appears as /dev/sdb in A. Using dd on A, clone /dev/sda to /dev/sdb . Mount on A the partition of /dev/sdb that contains /etc (there are no end user home directories -- only home directories are those of the system administration users). Using a text editor (e.g., vi), modify the /etc/sysconfig/net* scripts/directories, as well as /etc/hosts. for the name and IP address of machine B that will contain Bhd (resolv.conf will be the same -- all of these machines are in the same DNS subzone, same TCP/IP subnet). Iterate through all of the target workstation hard drives. As there are no other distributed services running, this should suffice. Shutdown A, remove Bhd, install Bhd into B, boot B upon which Bhd should appear as /dev/sda . Done. Is there a better method in terms of software? At this time, I do not want to setup a remote image server that effectively will download the full image of Ahd onto Bhd over a network, nor do I want to make a custom install DVD as we only have a small number of workstations to clone, not, say, one hundred. I do understand that if Ahd and Bhd present different bad blocks to the OS, and these are not hidden by the intelligence on each individual hard drive, then dd may not work.
Re: cloning with dd
target hard drive. The hard drive on A is /dev/sda, call it Ahd. A is shut down power off. Bhd is installed into an available bay on A, A is booted, and Bhd appears as /dev/sdb in A. Using dd on A, clone /dev/sda to /dev/sdb . Mount on A the partition of /dev/sdb that contains /etc (there are no end user home directories -- only home directories are those of the system administration users). Using a text editor (e.g., vi), modify the /etc/sysconfig/net* scripts/directories, as well as /etc/hosts. for the name and IP address of machine B that will contain Bhd (resolv.conf will be the same -- all of these machines are in the same DNS subzone, same TCP/IP subnet). Iterate through all of the target workstation hard drives. As there are no other distributed services running, this should suffice. Using tar rather than dd would likely be faster if there's any significant amount of free space on the source disk. dd will copy all those unused blocks, while tar will copy just the Useful Data. The network interface config files (/etc/sysconfig/network-scripts/ifcfg-*) contain the interface MAC address. You'll probably need to modify that. It may be easiest to set up a one-time boot script so this can be set on the destination (B) machine the first time it boots. If you use selinux, you may want to touch .autorelabel in the B root file system so the contexts will get set properly when it boots. - Bluejay Adametz Definition: Alponium n. (chemical symbol:Ap) Initial blast of odor from a can of dog food. -- NOTICE: This message, including any attachments, is only for the use of the intended recipient(s) and may contain confidential and privileged information, or information otherwise protected from disclosure by law. If the reader of this message is not the intended recipient, you are hereby notified that any use, disclosure, copying, dissemination or distribution of this message or any of its attachments is strictly prohibited. If you received this message in error, please contact the sender immediately by reply email and destroy this message, including all attachments, and any copies thereof.
New install boot problem -
I've just replaced F-18 with SL-6.3 Live installed but I have to use the flash drive to boot from the hard drive. I believe my error is that it's looking on the wrong drive. How do I fix that? Bob -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux
RE: New install boot problem -
Do you know the bootloader you are using off the top of your head? Assuming GRUB, you just need to edit /boot/grub/grub.cfg to point it to the right location. If you run into problems with it, paste it in here and I'm sure we can get you sorted. :) Trenton Ray MIS Center for Life Resources 408 Mulberry Brownwood, TX 76801 http://cflr.us This message is intended for the use of the addressees only and may contain information that is privileged, confidential, and exempt from disclosure. Any review, disseminations, or copying of this communication by anyone other than the intended recipient is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of this original message. Thank you! -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Bob Goodwin - Zuni, Virginia, USA Sent: Tuesday, January 29, 2013 12:50 PM To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: New install boot problem - I've just replaced F-18 with SL-6.3 Live installed but I have to use the flash drive to boot from the hard drive. I believe my error is that it's looking on the wrong drive. How do I fix that? Bob -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux
Re: New install boot problem -
On 01/29/2013 01:54 PM, Trenton Ray wrote: Do you know the bootloader you are using off the top of your head? Assuming GRUB, you just need to edit /boot/grub/grub.cfg to point it to the right location. If you run into problems with it, paste it in here and I'm sure we can get you sorted. :) Trenton Ray MIS Center for Life Resources I looked at grub.conf but didn't see what pointed to boot? I'll look again as soon as it finishes yum update. Tnx, -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux
Re: New install boot problem -
On 01/29/2013 01:54 PM, Trenton Ray wrote: Do you know the bootloader you are using off the top of your head? Assuming GRUB, you just need to edit /boot/grub/grub.cfg to point it to the right location. If you run into problems with it, paste it in here and I'm sure we can get you sorted. :) Trenton Ray MIS Ok I tried changing it to /dev/sdb, it was /dev/sda, but that didn't do it so I guess I need some help. [root@box7 bobg]# cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd2,0) # kernel /vmlinuz-version ro root=/dev/sdc3 # initrd /initrd-[generic-]version.img #boot=/dev/sdb default=0 timeout=15 splashimage=(hd2,0)/grub/splash.xpm.gz hiddenmenu title Scientific Linux (2.6.32-279.19.1.el6.x86_64) root (hd2,0) kernel /vmlinuz-2.6.32-279.19.1.el6.x86_64 ro root=UUID=088eabf7-7644-4acb-9017-bc510456357b rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-279.19.1.el6.x86_64.img title Scientific Linux (2.6.32-279.5.1.el6.x86_64) root (hd2,0) kernel /vmlinuz-2.6.32-279.5.1.el6.x86_64 ro root=UUID=088eabf7-7644-4acb-9017-bc510456357b rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-279.5.1.el6.x86_64.img title Other rootnoverify (hd0,0) chainloader +1 Bob -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux
RE: New install boot problem -
GRUB has a strange methodology (well, strange to me given that I'm one of a handful of neo-luddites still using LILO) for determining disks. It's got root as hd2,0 which means (and I may be mistaken) the 2nd disk, first partition.. which makes sense in accordance with /dev/sdb but since GRUB sees 0 as a value and not a null, maybe change it to 1,0 ? I fear I'm just going to add to the confusing at this point and apologize for not being able to help offhand. -Original Message- From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Bob Goodwin - Zuni, Virginia, USA Sent: Tuesday, January 29, 2013 1:24 PM To: Trenton Ray Cc: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Re: New install boot problem - On 01/29/2013 01:54 PM, Trenton Ray wrote: Do you know the bootloader you are using off the top of your head? Assuming GRUB, you just need to edit /boot/grub/grub.cfg to point it to the right location. If you run into problems with it, paste it in here and I'm sure we can get you sorted. :) Trenton Ray MIS Ok I tried changing it to /dev/sdb, it was /dev/sda, but that didn't do it so I guess I need some help. [root@box7 bobg]# cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd2,0) # kernel /vmlinuz-version ro root=/dev/sdc3 # initrd /initrd-[generic-]version.img #boot=/dev/sdb default=0 timeout=15 splashimage=(hd2,0)/grub/splash.xpm.gz hiddenmenu title Scientific Linux (2.6.32-279.19.1.el6.x86_64) root (hd2,0) kernel /vmlinuz-2.6.32-279.19.1.el6.x86_64 ro root=UUID=088eabf7-7644-4acb-9017-bc510456357b rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-279.19.1.el6.x86_64.img title Scientific Linux (2.6.32-279.5.1.el6.x86_64) root (hd2,0) kernel /vmlinuz-2.6.32-279.5.1.el6.x86_64 ro root=UUID=088eabf7-7644-4acb-9017-bc510456357b rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-279.5.1.el6.x86_64.img title Other rootnoverify (hd0,0) chainloader +1 Bob -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux
Re: New install boot problem -
GRUB has a strange methodology (well, strange to me given that I'm one of a handful of neo-luddites still using LILO) for determining disks. It's got root as hd2,0 which means (and I may be mistaken) the 2nd disk, first partition.. which makes sense in accordance with /dev/sdb but since GRUB sees 0 as a value and not a null, maybe change it to 1,0 ? I fear I'm just going to add to the confusing at this point and apologize for not being able to help offhand. grub numbers everything starting at 0, so your first hard drive (as seen by the BOIS) is 0, the second one is 1, third is 2, etc... Same numbering for partitions. - Bluejay Adametz Mind if I smoke? -- Why, are you on fire? -- NOTICE: This message, including any attachments, is only for the use of the intended recipient(s) and may contain confidential and privileged information, or information otherwise protected from disclosure by law. If the reader of this message is not the intended recipient, you are hereby notified that any use, disclosure, copying, dissemination or distribution of this message or any of its attachments is strictly prohibited. If you received this message in error, please contact the sender immediately by reply email and destroy this message, including all attachments, and any copies thereof.
Re: New install boot problem -
On 29/01/13 20:40, Trenton Ray wrote: GRUB has a strange methodology (well, strange to me given that I'm one of a handful of neo-luddites still using LILO) for determining disks. It's got root as hd2,0 which means (and I may be mistaken) the 2nd disk, first partition.. which makes sense in accordance with /dev/sdb but since GRUB sees 0 as a value and not a null, maybe change it to 1,0 ? I fear I'm just going to add to the confusing at this point and apologize for not being able to help offhand. Most commonly you'll find that: /dev/sda - hd0 /dev/sdb - hd1 /dev/sdc - hd2 And then with partitions: /dev/sdX1 - hdX,0 /dev/sdX2 - hdX,1 /dev/sdX3 - hdX,2 ... and so forth ... [root@box7 bobg]# cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd2,0) # kernel /vmlinuz-version ro root=/dev/sdc3 # initrd /initrd-[generic-]version.img #boot=/dev/sdb This line ^^^ can set to /dev/sda if you want GRUB on your MBR of /dev/sda. But remove the leading # default=0 timeout=15 splashimage=(hd2,0)/grub/splash.xpm.gz This looks for the splashimage (background graphics) from /dev/sdb1 ... inside the grub/ directory on this partition. If you mount /dev/sdb1 on /boot ... that means /boot/grub on your file system. hiddenmenu title Scientific Linux (2.6.32-279.19.1.el6.x86_64) root (hd2,0) This expects kernels to be found on /dev/sdb1 kernel /vmlinuz-2.6.32-279.19.1.el6.x86_64 ro root=UUID=088eabf7-7644-4acb-9017-bc510456357b rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-279.19.1.el6.x86_64.img title Scientific Linux (2.6.32-279.5.1.el6.x86_64) root (hd2,0) Same here as well. kernel /vmlinuz-2.6.32-279.5.1.el6.x86_64 ro root=UUID=088eabf7-7644-4acb-9017-bc510456357b rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-279.5.1.el6.x86_64.img title Other rootnoverify (hd0,0) chainloader +1 This would typically load Windows or so, installed on /dev/sda1 Hope this helps you understand the drive references a bit better. -- kind regards, David Sommerseth
SL-6.3 Install xfce -
I would like to install xfce but there doesn't seem to be a yum rpm. What is the best way to deal with that? Bob -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux
Re: SL-6.3 Install xfce -
Bob Goodwin - Zuni, Virginia, USA writes: I would like to install xfce but there doesn't seem to be a yum rpm. What is the best way to deal with that? It's there, but in the epel repository. Go get the epel-release package from here: http://fedoraproject.org/wiki/EPEL (get the right one for your arch, links midway down the page), then yum --enablerepo=epel search xfce to see what's available. EPEL has a pretty good compatability record with RHEL (that's their whole goal in life), so odds are decent this will work in your situation. -- Alec Habig, University of Minnesota Duluth Physics Dept. ha...@neutrino.d.umn.edu http://neutrino.d.umn.edu/~habig/
Re: SL-6.3 Install xfce -
On 29/01/13 21:42, Alec T. Habig wrote: Bob Goodwin - Zuni, Virginia, USA writes: I would like to install xfce but there doesn't seem to be a yum rpm. What is the best way to deal with that? It's there, but in the epel repository. Go get the epel-release package from here: http://fedoraproject.org/wiki/EPEL Or just do: yum install yum-conf-epel And you'll get all the needed files for EPEL ... no need to go via the Fedora wiki any more :) Then just do: yum groupinstall xfce That should be it. -- kind regards David Sommerseth
Re: New install boot problem -
On 29 January 2013 18:49, Bob Goodwin - Zuni, Virginia, USA bobgood...@wildblue.net wrote: I've just replaced F-18 with SL-6.3 Live installed but I have to use the flash drive to boot from the hard drive. I believe my error is that it's looking on the wrong drive. How do I fix that? Hi Bob, Perhaps a page in the CentOS wiki [1] will help you. Regards, Alan. [1] http://wiki.centos.org/HowTos/GrubInstallation
Re: SL-6.3 Install xfce -
On 01/29/2013 03:57 PM, David Sommerseth wrote: On 29/01/13 21:42, Alec T. Habig wrote: Bob Goodwin - Zuni, Virginia, USA writes: I would like to install xfce but there doesn't seem to be a yum rpm. What is the best way to deal with that? It's there, but in the epel repository. Go get the epel-release package from here: http://fedoraproject.org/wiki/EPEL Or just do: yum install yum-conf-epel And you'll get all the needed files for EPEL ... no need to go via the Fedora wiki any more :) Then just do: yum groupinstall xfce That should be it. -- kind regards David Sommerseth Yes, thanks, that eased the pain a lot! Now if I can figure out how to shange from gnome to xfce. Maybe there's a switchdesk rpm? -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux
Re: SL-6.3 Install xfce -
On 29/01/13 22:47, Bob Goodwin - Zuni, Virginia, USA wrote: On 01/29/2013 03:57 PM, David Sommerseth wrote: On 29/01/13 21:42, Alec T. Habig wrote: Bob Goodwin - Zuni, Virginia, USA writes: I would like to install xfce but there doesn't seem to be a yum rpm. What is the best way to deal with that? It's there, but in the epel repository. Go get the epel-release package from here: http://fedoraproject.org/wiki/EPEL Or just do: yum install yum-conf-epel And you'll get all the needed files for EPEL ... no need to go via the Fedora wiki any more :) Then just do: yum groupinstall xfce That should be it. Yes, thanks, that eased the pain a lot! Now if I can figure out how to shange from gnome to xfce. Maybe there's a switchdesk rpm? When you log in via the graphical login screen, you should be able to choose desktop environment directly there. Usually at the bottom of the screen, iirc. -- kind regards, David Sommerseth
Re: SL-6.3 Install xfce -
On 01/29/2013 04:49 PM, David Sommerseth wrote: When you log in via the graphical login screen, you should be able to choose desktop environment directly there. Usually at the bottom of the screen, iirc. -- kind regards, David Sommerseth Yes, that's what I expected but it's not there? Things have gone pretty well so far, a lot more to do to get what I want ... Thanks, Bob -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux
Re: SL-6.3 Install xfce -
JE suis d'accord sur le fond mais la demande est impossible à satisfaire si on a 5 mn... Michel --On mardi 29 janvier 2013 17:09 -0500 Bob Goodwin - Zuni, Virginia, USA bobgood...@wildblue.net wrote: On 01/29/2013 04:49 PM, David Sommerseth wrote: When you log in via the graphical login screen, you should be able to choose desktop environment directly there. Usually at the bottom of the screen, iirc. -- kind regards, David Sommerseth Yes, that's what I expected but it's not there? Things have gone pretty well so far, a lot more to do to get what I want ... Thanks, Bob -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux * * Michel Jouvin Email : jou...@lal.in2p3.fr * * LAL / CNRSTel : +33 1 64468932* * B.P. 34 Fax : +33 1 69079404* * 91898 Orsay Cedex * * France* *
Re: cloning with dd
On Tue, Jan 29, 2013 at 07:48:56AM -0800, Yasha Karant wrote: We have a limited, small, number of IEEE 802.3 connected hardware platform identical workstations to clone -- no 802.11 nor any shared (remote, distributed) disk storage (at this time). My plan was to get one fully operational and configured, and then clone the hard drive image onto the remaining machines one hard drive at a time. I clone SL systems using both methods - dd (mdadm raid1, actually) and rsync. The down side of cloning with dd is that all UUIDs become cloned (root filesystem, etc) and that can cause some confusion. The down side of cloning with rsync is that things like persistent ethX naming become confused (but no more than if you replace the mobo) and you end up with eth8 and eth9 instead of eth0 and eth1, and other similar artefacts. When cloning using rsync, you have to make the target disk bootable, which requires resetting all the UUID strings in the bootloader and in /etc/fstab, a major hassle. Overall, it is faster to create new boot disks by cloning than by doing a fresh installation - because of all the required post-installation stuff that has to be done manually. My general SL post-installation instructions are here: https://www.triumf.info/wiki/DAQwiki/index.php/SLinstall Cloning using mdadm raid1: https://www.triumf.info/wiki/DAQwiki/index.php/Cloning_raid1_boot_disks Cloning using rsync manually: https://www.triumf.info/wiki/DAQwiki/index.php/VME-CPU#Clone_disk_manually Cloning using rsync using a script: https://www.triumf.info/wiki/DAQwiki/index.php/DEAP#64GB_SSD_boot_disks To defeat the persistent naming of ethX helpful helpers: https://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Configure_network -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: SL-6.3 Install xfce -
Bob I switch some time ago it was a pain to go about all the configuration scripts but it can be done unfortunately I did not keep notes just be patient and good luck. On Jan 29, 2013 4:49 PM, David Sommerseth sl+us...@lists.topphemmelig.net wrote: On 29/01/13 22:47, Bob Goodwin - Zuni, Virginia, USA wrote: On 01/29/2013 03:57 PM, David Sommerseth wrote: On 29/01/13 21:42, Alec T. Habig wrote: Bob Goodwin - Zuni, Virginia, USA writes: I would like to install xfce but there doesn't seem to be a yum rpm. What is the best way to deal with that? It's there, but in the epel repository. Go get the epel-release package from here: http://fedoraproject.org/wiki/EPEL Or just do: yum install yum-conf-epel And you'll get all the needed files for EPEL ... no need to go via the Fedora wiki any more :) Then just do: yum groupinstall xfce That should be it. Yes, thanks, that eased the pain a lot! Now if I can figure out how to shange from gnome to xfce. Maybe there's a switchdesk rpm? When you log in via the graphical login screen, you should be able to choose desktop environment directly there. Usually at the bottom of the screen, iirc. -- kind regards, David Sommerseth
Re: SL-6.3 Install xfce -
On 01/29/2013 05:42 PM, Andrew Z wrote: Bob I switch some time ago it was a pain to go about all the configuration scripts but it can be done unfortunately I did not keep notes just be patient and good luck. Yes, it will rake me a week to configure things as I want them, and then it may not be exactly what I want ... Thanks -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux
Re: cloning with dd
On 2013/01/29 10:20, Bluejay Adametz wrote:
target
hard drive. The hard drive on A is /dev/sda, call it Ahd. A is shut down
power off. Bhd is installed into an available bay on A, A is booted, and
Bhd appears as /dev/sdb in A. Using dd on A, clone /dev/sda to /dev/sdb .
Mount on A the partition of /dev/sdb that contains /etc (there are no end
user home directories -- only home directories are those of the system
administration users). Using a text editor (e.g., vi), modify the
/etc/sysconfig/net* scripts/directories, as well as /etc/hosts. for the name
and IP address of machine B that will contain Bhd (resolv.conf will be the
same -- all of these machines are in the same DNS subzone, same TCP/IP
subnet). Iterate through all of the target workstation hard drives. As
there are no other distributed services running, this should suffice.
Using tar rather than dd would likely be faster if there's any
significant amount of free space on the source disk. dd will copy all
those unused blocks, while tar will copy just the Useful Data.
The network interface config files
(/etc/sysconfig/network-scripts/ifcfg-*) contain the interface MAC
address. You'll probably need to modify that. It may be easiest to set
up a one-time boot script so this can be set on the destination (B)
machine the first time it boots.
If you use selinux, you may want to touch .autorelabel in the B root
file system so the contexts will get set properly when it boots.
- Bluejay Adametz
Definition: Alponium n. (chemical symbol:Ap) Initial blast of odor
from a can of dog food.
Do remember that when you use tar for copying you have to partition and
mkfs each of the disks. If this can be automated, so much the better.
Automating the system duplication would be the best time saver over all.
It frees the administrator's time for other activities if the process can
be automated end to end.
Whatever method is being used make sure it is amenable to scripting. It
should be possible to implant a working copy of disk B to disk C reasonably
quickly with a script that automates partitioning and/or copying. From
that point you need to mount C and make the changes for the system name
as needed and then dismount C.
Once C is ready to use, place it in the target machine. Boot the target
machine with a Live CD. Place disk D into the first prep system and disk
E into the C system. Prepare F and G simultaneously using the prep
script. Once you get up to 16 working machines you may find yourself
running around like a one armed paperhanger keeping up with the prep
process. Note that you do NOT need the network active at this time. You
simply need a script that uses sed or equivalent to make modifications
to the necessary files to make the machines appear unique on the
network and other places as needed.
The exact cloning process is not as important as automating it with
a script that accepts the new information for the sed editing. Start
it. Forget it. Wait for the script to beep at the end while you take
care of emails or other problems.
At least, that's how I'd do it. Do it once is for humans. Do it many
times is for computers, scripts, and automation.
{^_^} Joanne
Re: New install boot problem -
On 01/29/2013 04:12 PM, Alan Bartlett wrote: On 29 January 2013 18:49, Bob Goodwin - Zuni, Virginia, USA bobgood...@wildblue.net wrote: I've just replaced F-18 with SL-6.3 Live installed but I have to use the flash drive to boot from the hard drive. I believe my error is that it's looking on the wrong drive. How do I fix that? Hi Bob, Perhaps a page in the CentOS wiki [1] will help you. Regards, Alan. [1] http://wiki.centos.org/HowTos/GrubInstallation There was a drive /dev/sda that had windows and linux on it, it had been used for boot. After re-installing a couple of times I finally found the problem, simply disabled that drive in the BIOS. Last install leaves me with LVM but I guess I can live with that on this computer for now. Bob -- http://www.qrz.com/db/W2BOD box9 Fedora-18 Linux
Re: cloning with dd
On 01/29/2013 02:37 PM, Konstantin Olchanski wrote: On Tue, Jan 29, 2013 at 07:48:56AM -0800, Yasha Karant wrote: We have a limited, small, number of IEEE 802.3 connected hardware platform identical workstations to clone -- no 802.11 nor any shared (remote, distributed) disk storage (at this time). My plan was to get one fully operational and configured, and then clone the hard drive image onto the remaining machines one hard drive at a time. I clone SL systems using both methods - dd (mdadm raid1, actually) and rsync. The down side of cloning with dd is that all UUIDs become cloned (root filesystem, etc) and that can cause some confusion. The down side of cloning with rsync is that things like persistent ethX naming become confused (but no more than if you replace the mobo) and you end up with eth8 and eth9 instead of eth0 and eth1, and other similar artefacts. When cloning using rsync, you have to make the target disk bootable, which requires resetting all the UUID strings in the bootloader and in /etc/fstab, a major hassle. Overall, it is faster to create new boot disks by cloning than by doing a fresh installation - because of all the required post-installation stuff that has to be done manually. My general SL post-installation instructions are here: https://www.triumf.info/wiki/DAQwiki/index.php/SLinstall Cloning using mdadm raid1: https://www.triumf.info/wiki/DAQwiki/index.php/Cloning_raid1_boot_disks Cloning using rsync manually: https://www.triumf.info/wiki/DAQwiki/index.php/VME-CPU#Clone_disk_manually Cloning using rsync using a script: https://www.triumf.info/wiki/DAQwiki/index.php/DEAP#64GB_SSD_boot_disks To defeat the persistent naming of ethX helpful helpers: https://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Configure_network Thank you for the above suggestions -- your methodology is isomorphic to my own. One of my students who works professionally as a systems administrator has his own (personal, but work used) portable cloning station that accepts two (identical) SATA hard drives and copies (clones) one onto the other -- he has loaned me his unit. He claims that it does a 1 TByte drive in well under an hour and requires no computer (other than the built-in processor and software, assuming the unit uses more than a FPGA or ASIC). I am going to test this method -- and after each clone is made, plug the clone into an external eSATA drive adapter, mount the appropriate partition onto a temporary mount point (empty directory), and modify the hostname, IP address, and related files (e.g., /etc/hosts and other appropriate files) so that each clone will be for a different static IP and DNS named (not DHCP provisioned) machine. If this indeed works, it promises to be the fastest method. I know that such hardware is used commercially for this purpose -- but the box in question currently is available new for less than $100, not the greater than $1000 I have seen for commercial grade cloning hardware. If it does work, I am going to get one and will post back to this list the specifics (or does it violate list rules to mention a particular brand of hardware for a specialized purpose?). Yasha Karant
