Re: [gentoo-amd64] Re: initio seen, mt -f doesn't work
Had flu, sorry for wait... The Fedora is 2.4 kernel which I will migrate to today and if this doesn't solve my probs. I will swap my scsi controller. If I remove my tape, what should I do with it? (don't be rude) I have been obsessed with backups since the time when I lost 2/3 of a book and had to spend eternity recreating. Any 'better' removable storage device suggestions are welcome. Bearing in mind it needs to hold ~15Gb and a removable hd isn't feasible. Gav. On Fri, 2005-12-16 at 13:19 -0500, Drake Donahue wrote: in addition to lshw, there is also an lsscsi in portage appears initio and linux have ended their affair is not a second /third drive a cheaper faster safer backup than scsi tape? - Original Message - From: Brett Johnson [EMAIL PROTECTED] To: gentoo-amd64@lists.gentoo.org Sent: Friday, December 16, 2005 11:46 AM Subject: Re: [gentoo-amd64] Re: initio seen, mt -f doesn't work On Fri, Dec 16, 2005 at 04:26:23PM +, Gavin Seddon wrote: This is my 1st Gentoo and the tape never worked on Debian. It does work on Redhat/Fedora but a tape's not a good reason to use this. Is the Redhat/Fedora system it works on a 2.4 or 2.6 kernel? -- gentoo-amd64@gentoo.org mailing list -- Dr Gavin Seddon School of Pharmacy and Pharmaceutical Sciences University of Manchester Oxford Road, Manchester M13 9PL, U.K. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Re: [OT] error message
Duncan wrote: The APM thing is legacy power management. You get the warning because you probably have newer equipment that doesn't use that old power management stuff any more. You can eliminate the warning by placing An 'Option NoPM' line in your xorg, in 'Section ServerFlags'. The newer power management stuff should continue to operate normally, or it does here, anyway. NoPM disables only APM or completely disables power managment (ACPI, APM etc.) ? http://www.google.com/search?q=%22nvrm%3A+xid%3A+13++02005600+1796+0c2c+00010001+0080%22 It shows 9 of the 26 hits, the rest are similar to those 9, it says. Good luck! ok.. i'll try this link at home. GOOGLE is a great tool!!! :-) Tip to disable RenderAccel in xorg.conf helps me! :-) -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: initio seen, mt -f doesn't work
On Mon, Dec 19, 2005 at 10:23:56AM +, Gavin Seddon wrote: The Fedora is 2.4 kernel which I will migrate to today and if this doesn't solve my probs. I will swap my scsi controller. If I remove my tape, what should I do with it? (don't be rude) I have been obsessed with backups since the time when I lost 2/3 of a book and had to spend eternity recreating. Any 'better' removable storage device suggestions are welcome. Bearing in mind it needs to hold ~15Gb and a removable hd isn't feasible. Gav. I am not sure what you're saying about migrating and removing the tape. If you mean you're going to install Fedora (2.4 kernel), then I would assume your tape drive will work fine. It appears that your scsi card is not fully supported in the 2.5/2.6 kernel. If you're looking for alternate solutions to use with gentoo/2.6 kernel, then I would suggest investing in a new scsi card. The tape drive and cable should be fine (assuming proper maintenance of the tape drive). I personally have moved away from tape for smaller data sets ( 100GB ), as tape has some issues. First, you need to keep the tape head clean and second tape media has a limited useful life span. I have been burned a couple times by defective tape media in a restore situation. If an external hard drive is out, how about removeable hard drives? Remeber, the point of a backup is just to keep the data in multiple places. You can easily add a removeable drive cage to a system and purchase a couple extra caddy's. This way you can alternate between 2 or 3 removable hard drives for backup devices. Some removeable trays support key locks, in case you're worried about physical security. The method I use is the dar program in conjunction with cdrecord-prodvd. I create a full backup monthly, then create a weekly incremental against the full backup, and then daily backups against the weekly. This method only requires me to burn multiple dvd's once a month (as my monthly backup is in excess of 20GB). After that, I get away with one extra dvd per month (ymmv). For a recovery scenario, I may have to go through multiple restores to bring the system current, but thats a trade off I make to save on media. Those are just a few ideas. There are many other ways to backup data. I believe there is even an online service you can sign up for, and back up to their servers. IIRC you pay by the backup size in 10GB increments. Backup solutions are unique to each enviroment and use. Things to consider are; hard costs of backup hardware and media, time required to perform backup and does data have to be taken offline, ease and automation of backup, time required to restore data, ease and automation of restore, and physical storage of backup media (it doesn't do you any good to keep all your backups in the same building as the data if the building burns down). I am sure there are other factors too, this is just to give you an idea of things to think about when trying to come up with a new backup solution. Brett -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Now I have a problem with l32 too
On 12/17/05, Peter Humphrey [EMAIL PROTECTED] wrote: Sebastian Redl wrote: Actually, emerge doesn't care about what uname reports - only some broken ebuilds might. Emerge only cares about the architecture set in the make profile. Maybe so, but the l32 utility still isn't doing what it should. -- gentoo-amd64@gentoo.org mailing list Hi Peter, Off list Billy sent me some experiments to do. I did them and sent my results back to him over the weekend I think. I've not heard back from him yet. Here's what he asked me to do: QUOTE (1) Make some placeholders so you know where you are # touch /in64.txt # touch /mnt/gentoo32/in32.txt (2) run l32 as root and as user, and see if you're in the chroot: (root)# l32 bash (root)# ls /in32.txt (root)# uname -a (2') now do it as a normal user (user)$ l32 bash (user)$ ls /in32.txt (user)$ uname -a (3) run linux32 chroot /mnt/gentoo32 bash, and see if you're in the chroot: (root)# linux32 chroot /mnt/gentoo32 bash (root)# ls /in32.txt (root)# uname -a (4) make sure the environment in /mnt/gentoo32 is really 32-bit: (root)# file /mnt/gentoo32/bin/uname (it should say something about a 32-bit LSB executable.) /QUOTE In my case l32 is taking me to the chroot'ed directory (/mnt/gentoo32 in my case) but it's not using the chroot'ed 32-bit identity. For now I continue to use Firefox as root. I'm sure this is probably something simple that we'll work out this week. - Mark -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: initio seen, mt -f doesn't work
On Mon, Dec 19, 2005 at 09:05:06AM -0600, Brett Johnson wrote: On Mon, Dec 19, 2005 at 02:56:10PM +, Gavin Seddon wrote: Hi, I am not thinking of fedora as an option. I will go to the 2.4 kernel and get removable hdds in the future. Do I put the 2.4 name in '/etc/portage/package.keywords' and emerge the source then genkernel --menuconfig kernel? If you want to run the 2.4 kernel, you will need to switch to the x86 build, as 2.4 kernel is not supported in amd64. And to answer your question, if you do switch to x86, you need to change your /etc/make.profile to point to a 2.4 profile (ie /usr/portage/profiles/default-linux/x86/2005.1/2.4) -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: initio seen, mt -f doesn't work
Will stick with 2.6 kernel and buy usb2 hard drive. On Mon, 2005-12-19 at 10:45 -0500, Drake Donahue wrote: usb2.0 external hard drive has to be feasible. less than a $100 for 80gb. nominal 60MB/sec. usb2.0\1394b external hard drive. less than $300 for 300 gb. nominal 60MB\80MB/sec. - Original Message - From: Brett Johnson [EMAIL PROTECTED] To: gentoo-amd64@lists.gentoo.org Sent: Monday, December 19, 2005 9:28 AM Subject: Re: [gentoo-amd64] Re: initio seen, mt -f doesn't work On Mon, Dec 19, 2005 at 10:23:56AM +, Gavin Seddon wrote: The Fedora is 2.4 kernel which I will migrate to today and if this doesn't solve my probs. I will swap my scsi controller. If I remove my tape, what should I do with it? (don't be rude) I have been obsessed with backups since the time when I lost 2/3 of a book and had to spend eternity recreating. Any 'better' removable storage device suggestions are welcome. Bearing in mind it needs to hold ~15Gb and a removable hd isn't feasible. Gav. I am not sure what you're saying about migrating and removing the tape. If you mean you're going to install Fedora (2.4 kernel), then I would assume your tape drive will work fine. It appears that your scsi card is not fully supported in the 2.5/2.6 kernel. If you're looking for alternate solutions to use with gentoo/2.6 kernel, then I would suggest investing in a new scsi card. The tape drive and cable should be fine (assuming proper maintenance of the tape drive). I personally have moved away from tape for smaller data sets ( 100GB ), as tape has some issues. First, you need to keep the tape head clean and second tape media has a limited useful life span. I have been burned a couple times by defective tape media in a restore situation. If an external hard drive is out, how about removeable hard drives? Remeber, the point of a backup is just to keep the data in multiple places. You can easily add a removeable drive cage to a system and purchase a couple extra caddy's. This way you can alternate between 2 or 3 removable hard drives for backup devices. Some removeable trays support key locks, in case you're worried about physical security. The method I use is the dar program in conjunction with cdrecord-prodvd. I create a full backup monthly, then create a weekly incremental against the full backup, and then daily backups against the weekly. This method only requires me to burn multiple dvd's once a month (as my monthly backup is in excess of 20GB). After that, I get away with one extra dvd per month (ymmv). For a recovery scenario, I may have to go through multiple restores to bring the system current, but thats a trade off I make to save on media. Those are just a few ideas. There are many other ways to backup data. I believe there is even an online service you can sign up for, and back up to their servers. IIRC you pay by the backup size in 10GB increments. Backup solutions are unique to each enviroment and use. Things to consider are; hard costs of backup hardware and media, time required to perform backup and does data have to be taken offline, ease and automation of backup, time required to restore data, ease and automation of restore, and physical storage of backup media (it doesn't do you any good to keep all your backups in the same building as the data if the building burns down). I am sure there are other factors too, this is just to give you an idea of things to think about when trying to come up with a new backup solution. Brett -- gentoo-amd64@gentoo.org mailing list -- Dr Gavin Seddon School of Pharmacy and Pharmaceutical Sciences University of Manchester Oxford Road, Manchester M13 9PL, U.K. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: initio seen, mt -f doesn't work
On 12/19/05, Drake Donahue [EMAIL PROTECTED] wrote: usb2.0 external hard drive has to be feasible. less than a $100 for 80gb. nominal 60MB/sec. usb2.0\1394b external hard drive. less than $300 for 300 gb. nominal 60MB\80MB/sec. Using what hardware? I've used more than a dozen different models of USB2/1394 hard drives on 4 different PCs and have never seen one exceed 30MB/s in actual thoughput, although the same disks installed internally exceed 60MB/s. -Richard -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: initio seen, mt -f doesn't work
On 12/19/05, Richard Fish [EMAIL PROTECTED] wrote: On 12/19/05, Drake Donahue [EMAIL PROTECTED] wrote: usb2.0 external hard drive has to be feasible. less than a $100 for 80gb. nominal 60MB/sec. usb2.0\1394b external hard drive. less than $300 for 300 gb. nominal 60MB\80MB/sec. Using what hardware? I've used more than a dozen different models of USB2/1394 hard drives on 4 different PCs and have never seen one exceed 30MB/s in actual thoughput, although the same disks installed internally exceed 60MB/s. -Richard Yeah, you won't get much more than 30MB/S out of any 1394a drive on Linux, and even then you may have to set gap count by hand to get there. However, faster 1394 performance is available in Linux. Here's my 1394b drive: lightning ~ # hdparm -tT /dev/sdb /dev/sdb: Timing cached reads: 2252 MB in 2.00 seconds = 1125.44 MB/sec Timing buffered disk reads: 172 MB in 3.03 seconds = 56.72 MB/sec lightning ~ # - Mark -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: initio seen, mt -f doesn't work
On 12/19/05, Mark Knecht [EMAIL PROTECTED] wrote: there. However, faster 1394 performance is available in Linux. Here's my 1394b drive: Ah thanks, good to know. Making a mental note to make sure my next laptop has a 1394_b_ port, or to pickup a new cardbus card... -Richard -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: initio seen, mt -f doesn't work
On 12/19/05, Richard Fish [EMAIL PROTECTED] wrote: On 12/19/05, Mark Knecht [EMAIL PROTECTED] wrote: there. However, faster 1394 performance is available in Linux. Here's my 1394b drive: Ah thanks, good to know. Making a mental note to make sure my next laptop has a 1394_b_ port, or to pickup a new cardbus card... -Richard I'm sure they're out there somewhere but I've personalyl never seen a laptop with 1394b. Good luck whatever you do. cheers, Mark -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Now I have a problem with l32 too
On 12/19/05, Billy Holmes [EMAIL PROTECTED] wrote: Peter Humphrey wrote: This happens whether I'm root or myself. I dare say I'm doing something stupid, but at the moment I can't see what. I made a mistake in the code. I was overzealous in commenting out lines. I have fixed it and added some more checks to ensure it does switch personalities. rename your ebuild to l32-1.1.1.ebuild, and redo the digests. emerge should automagically download the tarball from my server, redo the digests. Then just: # emerge -avt l32 and it should install version 1.1.1. Sorry about that! So version 1.1.1 is a big improvement for me, but I'm still having some troubles: 1) If I do l32 /bin/bash and then try and run Firefox it won't run. However if I run a copy of Firefox in my 64-bit environment I can then run a second copy in my 32-bit environment. 2) I'm still having to do the xhost thing to get it to work. If anyone sees the same thing or has some things I should try to get it working please write back when you get a chance. Thanks, Mark -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Now I have a problem with l32 too
On 12/19/05, Billy Holmes [EMAIL PROTECTED] wrote: Mark Knecht wrote: If anyone sees the same thing or has some things I should try to get it working please write back when you get a chance. what does df show? Are you sharing your /tmp directory between the 64-bit and the chroot? -- gentoo-amd64@gentoo.org mailing list The tmp directories do seem to be shared at the moment. In 64-bit the results are below. I'm not sure how to check this in the 32-bit area but the presumption is that it's /tmp inside that environment. [EMAIL PROTECTED] ~ $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 9614148 5320072 3805700 59% / udev255204 308254896 1% /dev /dev/sda6 3850292 1741104 1913600 48% /usr/src /dev/sda7 11543016 2439456 8517192 23% /mnt/gentoo32 /dev/sda8 14428928 3245916 10450048 24% /home shm 255204 0255204 0% /dev/shm none255204 0255204 0% /tmp/jack /dev255204 308254896 1% /mnt/gentoo32/dev /dev/shm255204 0255204 0% /mnt/gentoo32/dev/shm /usr/portage 9614148 5320072 3805700 59% /mnt/gentoo32/usr/portage /tmp 9614148 5320072 3805700 59% /mnt/gentoo32/tmp myth14:/video225373664 110128192 103797152 52% /video [EMAIL PROTECTED] ~ $ - Mark -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Now I have a problem with l32 too
Mark Knecht wrote: The tmp directories do seem to be shared at the moment. In 64-bit the results are below. I'm not sure how to check this in the 32-bit area but the presumption is that it's /tmp inside that environment. ah.. try sharing your /home as well: mount --bind /home /mnt/gentoo32/home if you can. That's how mine is setup. it could be an ~/.Xauthority issue... -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Now I have a problem with l32 too
On 12/19/05, Billy Holmes [EMAIL PROTECTED] wrote: Mark Knecht wrote: The tmp directories do seem to be shared at the moment. In 64-bit the results are below. I'm not sure how to check this in the 32-bit area but the presumption is that it's /tmp inside that environment. ah.. try sharing your /home as well: mount --bind /home /mnt/gentoo32/home if you can. That's how mine is setup. it could be an ~/.Xauthority issue... -- gentoo-amd64@gentoo.org mailing list OK, but before I do that I still have not created users in the chroot'ed environment. Should I do that before I share the /home? I know you Linux gurus totally get this stuff but I worry about creating a user killing an existing setup or something like that. Also, do I need to make sure user IDs, groups, passwords are consistent between the two environments? None of this was covered by the chroot howto so I've been going very slowly. Thanks, Mark -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Now I have a problem with l32 too
On Mon, 19 Dec 2005, Mark Knecht wrote:
a user killing an existing setup or something like that. Also, do I
need to make sure user IDs, groups, passwords are consistent between
the two environments?
I did it by doing this:
# cp -a /etc/{passwd,shadow,gshadow,group} /mnt/gentoo32/etc
and just do that everytime you add a new user or group.
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Now I have a problem with l32 too
if you can. That's how mine is setup. it could be an ~/.Xauthority issue...
--
gentoo-amd64@gentoo.org mailing list
OK, but before I do that I still have not created users in the
chroot'ed environment. Should I do that before I share the /home? I
know you Linux gurus totally get this stuff but I worry about creating
a user killing an existing setup or something like that. Also, do I
need to make sure user IDs, groups, passwords are consistent between
the two environments?
Yes - for your sanity. For just one or two users you might just use
useradd inside the chroot and give it the same parameters as in 64 land.
Here's the command I used when I set my personal chroot up a year or so ago
(from my notes)
useradd -g 1006 -u 1006 -G 5,10,11,16,18,19,100 fellows
passwd fellows
Obviously you have to use your uid, gid an groups list values.
I quickly decided I did not want to use the sam personal home directory for
both environments. So I did this (again from my notes)
I created on 64 /home/fellows/home32, copied ~/{.bashrc,bash_profile, .ssh}
to it. On 32 I did
usermod -d /home/fellows/home32 fellows
to make a different home directory
This way I could do selective sharing by means of copying or symlinks yet keep
32 and 64 bit versions of programs from using the same dot files.
Dave F
--
gentoo-amd64@gentoo.org mailing list
