Re: USB external drive errors with many different hardware
On Thu, 10 Jul 2014 09:50:39 +0100 (BST) Dr Andrew C Aitchison wer...@dpmms.cam.ac.uk wrote: On Wed, 2 Jul 2014, Andras Horvath wrote: Anyway I tried to raise those values high again and it seemed to have enter that hanging state at once. Interesting. I also checked the SATA possibility and it's working just fine if no USB is involved in the story. Since I have no more idea, I'll stick with the SATA version. This http://lwn.net/Articles/467328/ (Huge pages, slow drives, and long delays) is a little old, but perhaps not too old to be relevant to SL6. One reply claimed that watch -n 5 sync while accessing the slow drive fixed the problem. Thank you for your suggestion but if I understand it correctly, the article speaks about times when the desktop stops responding for long or when large chunks of memory disappear. I didn't have either of them. In my case, simple the transfer rate drops (to kbytes/s) and it affects only the USB drive. All the rest of my services run and respond well and the transfer rate is normal for my inner drives that are connected to SATA controller. Andras
New binary package set for EL6 x86_64
Hi users of EL6 based distributions, I'm pleased to announce a new alternative binary package repository for EL6 x86_64. The aim is to provide a supplemental set of packages which may contain software not included in your base system. These packages are based on pkgsrc, a cross-platform package manager. In this initial release there are 13,152 packages available. For now I am specifically targetting EL6/x86_64 (the build host is CentOS 6.5) to see what kind of interest in this. If there is reasonable interest I can produce packages for other targets based on popularity. To install, download and unpack the bootstrap kit: $ curl -s http://pkgsrc.joyent.com/packages/Linux/bootstrap/bootstrap-2014Q2-el6-x86_64.tar.gz | sudo tar -zxpf - -C / Packages are self-contained under the /usr/pkg prefix: $ PATH=$PATH:/usr/pkg/sbin:/usr/pkg/bin $ MANPATH=$MANPATH:/usr/pkg/man Included is the pkgin binary package manager, which has been designed to operate similar to yum/apt-get: # Fetch latest database $ sudo pkgin update # Search for a package $ pkgin search tmux # Install it $ sudo pkgin install tmux # See what is available $ pkgin avail | less Further details and similar binary package sets for SmartOS/illumos and OSX can be found here: http://pkgsrc.joyent.com/ Feedback is highly appreciated! Let me know if there is anything we can do to improve these packages, or if they are unwelcome. You can email me or @jperkin, or alternatively get involved in the pkgsrc community - our aim is to provide cross-platform packages for over 20 different operating systems from the same source tree. Thanks, -- Jonathan Perkin - Joyent, Inc. - www.joyent.com
Re: How to keep multiple glibc release instances in use
On 07/09/2014 08:48 PM, Nico Kadel-Garcia wrote: This was me. I thought I'd sent it to the list: it's all cool. obAdministrivia: I'm not exactly a fan of the 'default reply to poster' mailing list setup, but that's what the SL list is. I hit reply-all and trim the recipients whenever replying to the list (Thunderbird's 'reply to list' function doesn't seem to work with the SL lists). The other dirty trick would be to use something like 'mock' to build a chroot cage, and put your tools inside the chroot cage. ... I have to wonder if the 'Software Collections' framework could work for glibc. Otherwise your solution should work ok, even though it is more than a bit of a kluge. But it is glibc we're talking about, the second most core part of the system.
Re: Scientific Linux 7 -- no more IA-32 ?
On 07/09/2014 05:34 PM, Konstantin Olchanski wrote: On Wed, Jul 09, 2014 at 04:16:46PM -0400, Lamar Owen wrote: FWIW, since the CentOS group is planning an IA-32 release, ... I personally wish they spend the time on the ARM release instead... I'd like to see ARM as well, but IA-32 is lower-hanging fruit, since many of the packages are already built and the same hardware can build it as builds x86_64. As smooge said, the ARM port needs builders (and by that I assume he means the hardware on which to build, or a cross-compiler devchain that works for mock building).
Re: Scientific Linux 7 -- no more IA-32 ?
On 07/09/2014 06:48 PM, Patrick J. LoPresti wrote: On Wed, Jul 9, 2014 at 1:27 PM, Lamar Owen lo...@pari.edu wrote: I don't recall if I had to specify that option or not with CentOS 5.10: +++ [root@backup-rdc ~]# df -h FilesystemSize Used Avail Use% Mounted on ... /dev/mapper/plates-cx3--80 27T 26T 805G 98% /opt/plates /dev/mapper/vg_opt-lv_backups 5.8T 5.4T 365G 94% /opt/backups [root@backup-rdc ~]# blkid You are getting a little bit lucky, I think... Perhaps. But I ran into the 16TB problem with the 32-bit install (same filesystem, by the way, lvm exported from the 32-bit install and imported on the 64-bit reinstall) as soon as the 'Used' column passed 16TB (binary TB). This is the very filesystem on which that happened. The failure happens when the first 16TB of the block device (as opposed to file system) are in use. Since XFS allocates blocks from allocation groups all over the disk, it is improbable that the first 16TB is ever actually in use until the entire file system fills up Hmm, interesting. I swear I am not making up this problem; see e.g. http://www.doc.ic.ac.uk/~dcw/xfs_16tb/ Oh, I believe you. Most likely the reason I've not hit it is due to the file mix that's on the filesystem; the number of files is pretty small, but each file is large (in the GB size range per file; they are scanned astronomical photographic plates in uncompressed FITS format). Thus all the inodes should be able to be in the first 1TB of the disk. Anyway, inode64 is the recommended mount option for large XFS file systems unless you have some specific legacy need (like exporting via NFSv2 to 32-bit Solaris... guess how I know) Oh, I believe you. It may be worthwhile for me to add that mount option; can't hurt. It's just that the 16TB issue I hit was different from this one; I hit the 4k stack size issue with the 32-bit kernel, and that issue went away with the 64-bit kernel. But this issue is different.
Re: Scientific Linux 7 -- no more IA-32 ?
On Thu, 10 Jul 2014, Lamar Owen wrote: I'd like to see ARM as well, but IA-32 is lower-hanging fruit, since many of the packages are already built and the same hardware can build it as builds x86_64. As smooge said, the ARM port needs builders (and by that I assume he means the hardware on which to build, or a cross-compiler devchain that works for mock building). [I understand the RH history and desire for 'builds for record' to be on 'real' hardware. I can advocate until I am blue in the face as well as the rest of you that the compiler is just moving ((optionally ascii, altho' ebcdic also works in Z arch ... )) 8-bit text string tokens aroung and emitting new bit patterns, BUT, there is less room for excuses / blind paths for binary partition debugging when one is 'going native'] The round one 'starter yeast' for the clefos s390 / s390x RHEL 6 sources rebuild ['Azure Duck'] was build entirely under a stable of x86_64 under Hercules -- not pretty, nor fast, but not all that bad either. Later rounds moved through native re-compiles to remove and doubt as to self-hosting, or objection as not 'built on native' As I recall, there is a qemu arm VM that runs under libvirt out there. No reason not to start there I and others have a wide stable of 32 bit arm hardware, and saw a 64 bit devkit board announcement by ARM earlier this week; and there is the overdue AMD offering to the same effect which I am waiting to see in the market; after the Blacksburg fudcon, I also 'infected' jbj with an interest in such and he too has a build farm. Most compelling of course is Gordon Bobic's 'redsleve' rebuild of the RHEL 6 sources under arm 32 It really seems more having a trusted central binary [and sources] archive and a mechanism for a federation of mutually trusted builders to do retrieval, build, and return of binary fruit, is the issue Suporting as low as one person in such a federation is of course possible, but then the tragedy of the commons costs, vs benefits returned, rears its head I personally implicitly trust each enumerated person in the CC list as we have been working together since 'testers-list days' save Gordan --- perhaps we just need to tactically solve the management of ad hoc federations, and the minimal glue for diing the 'distributed' -- the latter really a solved problem already with buildbot C and C Thoughts? My 0.02 -- Russ herrold
Re: How to keep multiple glibc release instances in use
Unfortunately, proprietary vendor applications for which the vendor does NOT release source, or does so with a dependence upon libraries or other applications for which source is not available, typically are impossible to port but instead require a container if the application requires a specific base dynamic (.so) library that fundamentally conflicts with the base Linux system. Most such vendors do not produce a self-contained version or a version using only static libraries (.a) to avoid dynamic dependencies. Some do provide full environments (e.g., Qoppa PDF Studio Pro that I use as a Linux replacement for Adobe PDF editing and composition applications), but these typically are small. That is one of the issues with RHEL as a base -- RHEL quickly gets quite far behind the current enthusiast distributions (e.g., Ubuntu), and purportedly significantly behind SuSE Enterprise. Note that a number of specialist vendors seem to be using a SuSE Enterprise base for building because that distribution seems to strike a different compromise between security, stability, and a more current environment than does RHEL. For my work, I insist on EL on all primary servers/workstations, although a colleague at our site is maintaining a small OpenSuSE based system for our own testing and compatibility purposes (OpenSuSE is similar in concept to a Fedora Red Hat system, but significantly more stable). We do not have a SuSE Enterprise license, and no one seems to have produced something akin to SL but based upon SuSE Enterprise. Does anyone on this list have current production SuSE Enterprise in use? Off list replies are fine. Yasha Karant On 07/09/2014 05:48 PM, Nico Kadel-Garcia wrote: On Wed, Jul 9, 2014 at 8:19 PM, Yasha Karant ykar...@csusb.edu wrote: This post is a follow-up to Re: [SCIENTIFIC-LINUX-USERS] glibc-2.15-60.el6.x86_64.rpm [correction]. I had forgotten this trick, but I received an off-list email that explained what to do. This sort of information should be kept in a central SL (or EL or CentOS, etc.) repository -- a practicum of how-to workarounds -- as it used to be for BSD and SunOS a rather long time in the past. As the correspondent did not use the SL list, I am assuming that she/he wishes not to be the public author of the commentary below (slightly edited). This was me. I thought I'd sent it to the list: it's all cool. Quote. Use rpm2cpio to unbundle the glibc into an alternative location in /opt. Put shell wrappers in $HOME/bin that set LD_LIBRARY_PATH, MANPATH, etc. to the new location. Install the binary, as well, in ta parallel location in /opt., also accessed by the wrapper. Try using the shell wrappers to summon the binaries with those variables set to point to the new library *DO NOT* use RPM to install this, even if you succeed you're likely to seriously break the system. It's like replacing the motor on a car while it's running, replacing a diesel with a Wankel motor. Yeah, you can kind of tell it's me from that part End quote. Note that after I update a major library, I do not attempt to keep the system running, but reboot, with the pre-updated libraries available in such a form that I can use the shell from a rescue DVD (or USB if one must) to redo the links. (E.g., if this is libmajor.so.M and it is replaced by libmajor.so.N, N .ne. M, then before any such attempted installation, I do a cp -pr of libmajor.so.M to orig-libmajor.so.M, and if the rescue method must be used, mv libmajor.so.N to new-failed-libmajor.so.N and mv orig-libmajor.so.M to libmajor.so.M. Note that is a time consuming set of steps that requires physical access. Polymorphic virtualisation of file systems nominally could avoid this methodology, but has other problems and risks.) I do thank the private correspondent for the workaround. Hopefully, the shell wrappers will work (a shell wrapper for each application file that requires the other environment.) The other dirty trick would be to use something like 'mock' to build a chroot cage, and put your tools inside the chroot cage. Then set aside the chroot cage for that application, specifically. Attempts to provide application 'containers' that start to include core components like glibc.. start getting very bulky, very fast, and lose the performance advantages of a consistent library cache in use throughoutt an operating system's working environment. It's *feasible*, and there are reasons to do it to segregate applications. But it gets really resource expensive, really fast, and Linux is *not* designed around it.
Re: Scientific Linux 7 -- no more IA-32 ?
Hi, Russ - thank you for pointing to the redsleeve package - I did not know about it - and when I was looking for such last Summer, it did not turn up - I ended up using Fedora 20 for my test system, but prefer EL based for final production. But with the redsleeve web currently down (Error establishing a database connection), do you know if they provide a preinstalled rootfs image? One that is easy to network-boot (via NFS-Root). My ARM hardware cannot run any installer (requires a custom linux kernel, low on RAM and not too speedy). Fedora 20 provides rootfs images and was easy to network boot (NFS-Root). And for development, network boot is so much faster and easier compared to writing and rewriting the very slow SD flash cards, plus having to move the flash card from crashed arm to PC and back. K.O. On Thu, Jul 10, 2014 at 11:40:48AM -0400, R P Herrold wrote: On Thu, 10 Jul 2014, Lamar Owen wrote: I'd like to see ARM as well, but IA-32 is lower-hanging fruit, since many of the packages are already built and the same hardware can build it as builds x86_64. As smooge said, the ARM port needs builders (and by that I assume he means the hardware on which to build, or a cross-compiler devchain that works for mock building). [I understand the RH history and desire for 'builds for record' to be on 'real' hardware. I can advocate until I am blue in the face as well as the rest of you that the compiler is just moving ((optionally ascii, altho' ebcdic also works in Z arch ... )) 8-bit text string tokens aroung and emitting new bit patterns, BUT, there is less room for excuses / blind paths for binary partition debugging when one is 'going native'] The round one 'starter yeast' for the clefos s390 / s390x RHEL 6 sources rebuild ['Azure Duck'] was build entirely under a stable of x86_64 under Hercules -- not pretty, nor fast, but not all that bad either. Later rounds moved through native re-compiles to remove and doubt as to self-hosting, or objection as not 'built on native' As I recall, there is a qemu arm VM that runs under libvirt out there. No reason not to start there I and others have a wide stable of 32 bit arm hardware, and saw a 64 bit devkit board announcement by ARM earlier this week; and there is the overdue AMD offering to the same effect which I am waiting to see in the market; after the Blacksburg fudcon, I also 'infected' jbj with an interest in such and he too has a build farm. Most compelling of course is Gordon Bobic's 'redsleve' rebuild of the RHEL 6 sources under arm 32 It really seems more having a trusted central binary [and sources] archive and a mechanism for a federation of mutually trusted builders to do retrieval, build, and return of binary fruit, is the issue Suporting as low as one person in such a federation is of course possible, but then the tragedy of the commons costs, vs benefits returned, rears its head I personally implicitly trust each enumerated person in the CC list as we have been working together since 'testers-list days' save Gordan --- perhaps we just need to tactically solve the management of ad hoc federations, and the minimal glue for diing the 'distributed' -- the latter really a solved problem already with buildbot C and C Thoughts? My 0.02 -- Russ herrold -- 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
SL 7 alpha -- off-topic: test build of proprietary AMD graphics driver
I have tested, successfully, the installation of SL 7 alpha DVD to a harddisk image via qemu (under SL 6.5 x86_64 on an HP Pavilion g6 laptop). To test the build of AMD proprietary graphics driver however requires the detection of the gpu hardware, hence the installation onto a physical hard disk, which is something I prefer not to do until later. For this purpose, one approach is to build a bootable iso out of the virtual harddisk image from qemu - some info on this could be found in the ubuntu community but so far nothing (that I could find) for rhel systems - is this doable? Perhaps there may be other approaches for testing the build without the installation to the hard disk. PS - One related question: how could the squashfs image file in the LiveOS directory in SL-7-x86_64-DVD.iso be accessed? An attempt to mount the img file fails with an error of 'unknown filesystem type', nor could the file be unsquashed with 'unsquashfs'. It seems reasonable to think the content of the squashfs.img could be accessible. Thanks in advance. Boryeu Mao
Re: SL 7 alpha -- off-topic: test build of proprietary AMD graphics driver
On Thu, Jul 10, 2014 at 12:23:39PM -0700, Boryeu Mao wrote: I have tested, successfully, the installation of SL 7 alpha DVD to a harddisk image via qemu (under SL 6.5 x86_64 on an HP Pavilion g6 laptop). To test the build of AMD proprietary graphics driver however requires the detection of the gpu hardware, hence the installation onto a physical hard disk, which is something I prefer not to do until later. For this purpose, one approach is to build a bootable iso out of the virtual harddisk image from qemu - some info on this could be found in the ubuntu community but so far nothing (that I could find) for rhel systems - is this doable? Perhaps there may be other approaches for testing the build without the installation to the hard disk. If you have a running system (inside a VM, whatever), you can install it to a physical media (HDD, SSD, USB flash) using cd /; rsync -avx . /mnt/destination_disk. (some people frown upon cloning running systems, but I have been doing it for years without any problems). Before rsync, you need to fdisk and mkfs your destination media, after rsync, you need to grub it and adjust the UUID values in grub.conf and etc/fstab. -- 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: Boot hangs / loops
On Thu, 10 Jul 2014, Dormition Skete (Hotmail) wrote: In looking at my previous post, it occurred to me that =93fsck didn=92t = help=94 was not very explanatory. fsck finds no errors on /dev/sda6 (my / file system) fsck found and fixed 2 errors in my /dev/sda7 (home) file system. I=92ve run this on both several times today, and it finds them both = clean every time now. It still will not boot. =20= Have you tried commenting out all of the lines in the fstab that are not needed for booting. You should verify that /dev/sda6 and /dev/sda7 are the actual partitions that you think they are. -Connie Sieh
Re: Boot hangs / loops
On Jul 10, 2014, at 3:52 PM, Connie Sieh cs...@fnal.gov wrote: Have you tried commenting out all of the lines in the fstab that are not needed for booting. You should verify that /dev/sda6 and /dev/sda7 are the actual partitions that you think they are. -Connie Sieh All I have in /etc/fstab are for: / /home swap tempfs sysfs proc Can I comment out those last three? I am sure the /dev/sda6 and 7 partitions are / and /home.
Re: Boot hangs / loops
On Jul 10, 2014, at 4:20 PM, John Lauro john.la...@covenanteyes.com wrote: Filesystem SizeUsedAvail Use% Mounted on /dev/sda63.9G133M3.8G 4% / tmpfs3.9G0 3.9G 0% /dev/shm /dev/sda73.9G133M3.8G 4% /home Well, that is not looking good. Was that booted from the rescue cd? Sometimes when you boot from a different drive (such as CD) it can switch the devices around. Maybe they are on SDB? What does fdisk -l show? Well, I don’t remember for sure how I booted to get into that, but I’m pretty sure I booted it from the hard drive. I just rebooted it using the rescue disk, and “df -h” now shows: Filesystem SizeUsedAvail Use% Mounted on /dev4.0G220K4.0G 1% /dev none250M137M114M55% /tmp /dev/loop0 137M137M0 100% /mnt/runtime /dev/sda6 20G 11M 8.6G 55% /mnt/sysimage /dev4.0G220K4.0G 1% /mnt/sysimage/dev /dev/tmpfs 4.0G0 4.0G 0% /mnt/sysimage/dev/shm /dev/sda7 111G80G 26G 76% /mnt/sysimage/home fdisk -l Gives too much to type and get back with you in a timely manner, but they are on /dev/sda, not /sdb. If you’d like that output, though, I’ll be happy to post it for you. I’ll start typing it now… I just wanted to get back with you as quickly as I could.
Re: Scientific Linux 7 -- no more IA-32 ?
On 07/10/2014 02:44 PM, Gordan Bobic wrote: ...That is why RedSleeve is built on ARMv5 hardware (Sheeva, Guru and DreamPlugs). Said hardware is sufficiently underpowered that my 8 or so builders took nearly two months (IIRC - it's been a long time since I did a full rebuild) churn through the entire build. I have available a GuruPlugServer (has an eSATA port, and I have the UART/JTAG interface). I also have access to a number of RasPi's. EL on these little gems for us is more for embedded server applications running on solar power; in particular, I'm getting ready to attempt to deploy a RasPi with RedSleeve CLI as a 'backpack' of sorts on an HP/Agilent/Symetricom Z3816A GPS-disciplined time/frequency standard as one of several stratum one NTP servers on our campus. And thanks for RedSleeve, by the way. Both the O/S and the pun.
