Re: Timing issue with fstab NFS mounts
> While the rest of my system is just cherry, I have not yet been able > to solve the problem of why an NFS mount and associated binds don't > work unless and until I wait a minute or two after the system comes > up [...] Sounds like the normal 90-second NFS grace period to me -- a feature, not a bug. If I run 'journalctl | grep grace' on one of my machines I get: May 12 17:50:07 fileserver kernel: NFSD: starting 90-second grace period (net 81c64a00) This _is_ configurable, but there is an open Debian (wishlist) bug about that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601335 Some further discussion justifying the "lease time"/"grace period" feature, including a possible workaround for the bug above, see: https://access.redhat.com/solutions/42868 HTH, Dave W.
Re: 0.7.46 changelog: Change /run/network ownership to root:netdev.
I don't understand that entry. Should I have /run/network group set to netdev? Should I have a netdev group somewhere? Is there a bug? You do not need to do anything. At boot, the 'network' in /run is supposed to have its ownership changed from root:root to root:netdev by /etc/init.d/networking. Some machines did not have the group called netdev on their machine (it is a system group, and was only being created if certain packages were installed) and a warning was being shown at boot time. This change makes the warning go away on machines that were affected. HTH, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1385844919.15995.yahoomail...@web181503.mail.ne1.yahoo.com
Re: Reducing kernel compilation time
From: Camaleón noela...@gmail.com Sent: Sun, September 25, 2011 10:30:30 AM Subject: Re: Reducing kernel compilation time I'd guess you're including the kitchen sink. Don't build the hundreds of driver modules your machines won't ever use. That is the key to reducing build time. Fair enough, but I wonder what to include in the recipe. If I put too much salt or leave the oven for many hours at the maximun temperature I'll get a pastiche nobody will be able to eat... So I'm afraid I'll wait for your super-customized .config file to use it in my netbook, feel free to send it to my inbox when it's ready :-) He cannot. Everyone needs a different '.config' if they are trying to customize for their own personal hardware. My own experience with this involved spending an entire day in January 2010 tracking down which options I could disable. I also changed most 'M' options to 'Y' so that drivers would be built directly into the kernel instead of as a separate loadable module. (My goal was to produce a kernel that boots without an initrd; most people will not share that goal.) Sven Joachim's suggestion to create a new '.config' using 'make localmonconfig' should mostly have the desired effect, the result could then be fine-tuned. If that option had existed when I was learning about this, it would have saved me many, many hours! Good luck! Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1316963813.47885.yahoomai...@web82102.mail.mud.yahoo.com
Re: Reducing kernel compilation time
From: Stan Hoeppner s...@hardwarefreak.com Sent: Sun, September 25, 2011 11:27:13 AM Subject: Re: Reducing kernel compilation time If that option had existed when I was learning about this, it would have saved me many, many hours! But then you wouldn't have learned as much. Easier is not always better, even though it often seems so. I take your point. I was actually reading about every single kernel option in a .config file, though, so the time I was thinking would have been saved would only have had to do with arriving more quickly at my custom .config, not on the learning about the options. But I fully agree with the truism: easier is not always better. DW -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1316970512.93510.yahoomai...@web82105.mail.mud.yahoo.com
Re: hardware acceleration, radeon driver 6.14 (unstable)
From: Jim McCloskey mccl...@ucsc.edu Sent: Mon, February 21, 2011 11:33:15 PM Subject: Re: hardware acceleration, radeon driver 6.14 (unstable) * Dave Witbrodt (dawit...@sbcglobal.net) wrote: | But when I run glxgears, it reports 60 frames per second, which isn't exactly the | level of performance that I had been hoping for. And given that, it's hardly | surprising that applications like Google Earth are unusable. | | The 'glxgears' program is not a benchmark. There is a feature | in the radeon driver (vline) which limits the 'glxgears' maximum | frame rate to your monitor's refresh rate. Try a benchmark | program, or a game that displays the current frame rate (such as | 'torcs'), to get a better idea of the performance of the driver | on your system. Thank you very much indeed; this is very helpful. I understood that glxgears was not regarded as a reliable benchmark, but the number I was getting (60FPS or thereabouts) seemed low enough that it probably indicated that something was amiss. Since then I've been trying various 3D applications to see how things stood. The results have been mixed. Some (compiz-fusion, stellarium, extremetuxracer) have no problems; others (Google Earth, foobillard) freeze the X server a few seconds after startup (not the laptop itself, though; it remains possible to ssh in from elsewhere in the home network). The Google Earth problem may have nothing to do with the radeon support on your machine. A lot of other software is in the way in that particular case, and it may target a non-accelerated rendering mechanism even though you have support for acceleration on your system. The problem with freezes may be corrected upstream already. On my HD 5750, 3D- intensive apps were causing freezes because the Evergreen support in the kernel's DRM needed a slight fix. The problem did not affect programs using classic Mesa r600 (r600c), but the GPU lockups happened when I switched to Gallium3D (r600g). That fix came very recently: a DRM patch after kernel 2.6.37 was released. It will be included with kernel 2.6.38. | Is there anyone who could give me some advice about what is missing here? Or | where would be a good place to ask? | | One good place is the Phoronix Forums. There are trolls and | flame wars there, but there are also knowledgeable people (with | regard to Radeon hardware and drivers) who are very responsive. | I do not participate there (yet) since I only toy with this | stuff in my spare time, and have not (yet) been able to dive | into it seriously. Do the developers read those forums? Something I've been unsure about it is whether or not it would make sense to file a bug-report. The only 3D applications I care about at all are compiz and Google Earth, and I can live happily without either of them. I'm exploring all of this mostly out of curiosity and a desire/willingness to help with testing, reporting etc. In general, I would always assume that developers do not read a particular forum; in this case, however, I know for a fact that all of the most important names in open radeon driver development do read (and participate) in the Phoronix Forums. Re bug reports: technically, if you have a bug you should file a bug report. In this case, I think that the Debian packaging team (X Strike Force) will not be able to solve your problems, but will be able to track the problem until you can report it to be fixed. For you to do this would not solve your immediate problems, but would be practicing good Debian citizenship. You could also file a bug report upstream: both Mesa and the radeon driver have their bug tracking system (they use Bugzilla) at freedesktop.org. Of course, the first things they will ask you will be to try compiling a new kernel, new Mesa, and new radeon drivers from their git repositories. If that's more than you are willing/able to do, my advice would be to wait until kernel 2.6.38 appears in Debian. I think the Evergreen freezes will go away for you once you can get that kernel (which isn't released yet, but hit RC6 status yesterday and should release in roughly 3 weeks), and the combination of xserver-xorg-video-radeon 6.14 and Mesa 7.11 (whenever that is released) will give you some good performance (for open drivers). Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/736371.59422...@web82105.mail.mud.yahoo.com
Old Seamonkey emails into new exim4 maildirs
Hi, I was wondering if any email gurus are reading debian-user, and are willing to share some advice? In the past, I used email client apps like Seamonkey to retrieve email from my ISP's POP3 server. I tend to save a lot of emails, sorted into directories based on who-was-the-sender or what-was-the-topic. This has left me with a large number of text files -- I assume mbox format -- on two old machines, which I used as my main desktop machine in different eras. I have already backed up those mbox files, but I just finished setting up a home network with 3 machines -- one acting as smarthost for the other two, and which connects to my ISP's SMTP server on behalf of all the machines in my home network. The local smarthost is using exim4 (with Maildirs) and courier-imap to make my email available to all of the machines inmy network (regardless of which OS is running). My question is simple: is there a way I can give exim4 those mbox files from the 2 old machines so that it will move each email into the new Maildir setup, and without sending or forwarding them to the new machine. (In other words, I would like to preserve the header info in its current state.) Thx, Dave W. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Load web page with Flash movie -- System freeze?
Hi Carl, It's not just that, though. Any Flash movie will solidly lock it. For instance, Pandora loads, then the laptop stops. I don't know if my experience will help, but when the 'flashplugin-nonfree' package was updated to the 1.7.* series, I started experiencing freezes for about 30 seconds at a time just using my ISP's webmail interface. I ended up holding version 1.6.3 up until a couple of days ago, when I investigated more carefully and found that 1.7.* switched to using the Debian alternatives system -- to allow sysadmins to select the particular library which will provide support for Flash. See bug report 497385: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=128;bug=497385 Following the instructions there, I updated to flashplugin-nonfree 1.7.2 using 'aptitude', tested that I still had the problem with freezing (I did), closed Iceweasel, ran the suggested command line incantation in the bug report, update-alternatives --auto flash-mozilla.so then ran Iceweasel again. The result was that 1.7.2 now works as good for me as 1.6.3 ever did. I'm not sure this will solve your problem, but I'm hoping it helps you (or anyone else reading this). HTH, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Load web page with Flash movie -- System freeze?
... ran the suggested command line incantation in the bug report, update-alternatives --auto flash-mozilla.so then ran Iceweasel again. The result was that 1.7.2 now works as good for me as 1.6.3 ever did. Hey, did you know that flashplugin-nonfree was removed from Lenny in preparation for stable release, because of concerns about security? Yes, but I use Sid on my desktop machine... and currently don't use X on my 2 servers. There will be a way to obtain flashplugin-nonfree for Lenny when it's released... through backports, I believe. DW -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What to do with multiple kernel images
Thanks, I ran purge on the four oldest. Three of them reported an error: rmdir: failed to remove `/lib/modules/2.6.22-3-486': Directory not empty dpkg - warning: while removing linux-image-2.6.22-3-486, directory `/lib/modules/2.6.22-3-486' not empty so not removed. koko:/lib/modules/2.6.22-3-486$ ls -al total 12 drwxr-xr-x 2 root root 4096 2008-08-15 05:33 . drwxr-xr-x 7 root root 4096 2008-08-15 05:26 .. -rw-r--r-- 1 root root 1303 2007-12-07 22:19 modules.seriomap koko:/lib/modules/2.6.22-3-486$ Do these belong to a package, or would I simply rm them? The package manager is telling you that files that were NOT part of the package are present in a directory that it should be able to delete. Either you, or some other package you installed, placed that file there. I get this warning myself, because I use the proprietary NVidia modules instead of the Debian packages. (The NVidia installer compiles a kernel module and places it in /lib/modules, and makes no attempt to use my nice package management system -- unlike the ATI proprietary drivers, which creates actual DEBs.) Since my leftover 'nvidia' module is not track by APT, I _do_ just use 'rm': # cd /lib/modules # rm -vrf 2.6.22-3-486 The last command verbosely removes the directory for that kernel's modules, and any files in it. Only use a command like that if you are SURE the kernel has been removed (i.e., 'aptitude purge kernel-version') and the directory really is not needed. Any slip of the keyboard, or PEBKAC attack, and you cannot get back the files you lost! HTH, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: uvesafb with linux-image-2.6.26-1-686
The Changelog on the latest 2.6.26 kernel in Sid has this: * [x86]: Enable modular FB_UVESA. (closes: #473180) and Sid now has v86d: http://packages.debian.org/sid/v86d [...] It says right here that installing v86d and linux-image-2.6.26-1-686 and booting with: video=uvesafb:1024x768-32,mtrr:3,ywrap in the cmdline should result in framebuffer usage on the reboot. It ain't so. Nothing more than 80x25. Has anybody tried the above? My advice is to go to bugs.debian.org, search for 473180, and get Evgeni Golov's email address so you can ask him if he has it working. I have been using UVESA FB for nearly a year, but (as you know) I compile my own kernels and pack 'v86d' directly into the kernel image with a built-in initramfs so I don't need an initrd. I also recompile 'klibc' against my self-compiled kernels, instead of using the Debian binaries -- though I do use the Debianized source packages. I know that it is _supposed_ to work, and I'm pretty sure that Evgeni has got it working on his own machines -- that was his purpose in becoming the Debian maintainer for 'v86d'. You've been having trouble with plain old VESA FB, so I would not be surprised if the problem blocking that from working is also stopping UVESA FB from working. But Evgeni should be able to tell you whether you are doing the same things he does to get it going with the stock kernel. Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: don't really need cpp-3.4, do I?
However, I would like to keep this version of gcc. cpp-3.4 appears to be just the pre-processor. I supposed I can remove this and still be able to use the 3.4 gcc compiler (I want to retain libg2c0 as well). Do I understand this right? Sure, if you want to program in C without ever using any header files with #include. [No programs with printf(), scanf(), or any other useful library functions that you are probably taking for granted.] In short, you do NOT understand that right. Looking here, http://packages.debian.org/lenny/cpp-3.4 it would seem that you should be having 3.4.6-8 show up in your package manager. If not, consider switching to a different mirror in /etc/apt/sources.list. HTH, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why can't I update libg2c0 [was: Re: don't really need cpp-3.4, do I?]
hmm ... just took another look at the package descriptions. It seems that the problem is libg2c0. How come this still depends on an older version of gcc-3.4.6? I link some of my programs with some FORTRAN libraries and need libg2c0. So for now I have been keeping gcc-3.4 at its older version during every upgrade. So, what's the deal with libg2c0? Looks like support for the old legacy compilers is reaching its end of life: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473647 You might consider transitioning to something newer, if possible. DW -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
nVidia binary on 2.6.26 [was: Benefits (and risks) of using Sid]
- Original Message From: Ron Johnson [EMAIL PROTECTED] My big problems now are: a) nvidia binary driver doesn't build on .26 (which I need for other reasons), Sorry to hear that. I've been using the beta 177.13 driver for quite a while now. I built a custom 2.6.26 kernel for my desktop on Saturday, and nvidia 177.13 runs on it very nicely. In fact, when I moved to 177.13 from the stable series, everything seemed to move noticeably faster... I was very impressed and satisfied with the results! Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nVidia binary on 2.6.26 [was: Benefits (and risks) of using Sid]
Where is the beta? Stable is at: ftp://download.nvidia.com/XFree86/Linux-x86 Browsing to nvidia.com gets you their funky home page, with a bunch of useless links -- none pointing to driver downloads. Clicking on just about anything, you then get pages that have a more useful top menu, with Download Drivers at the upper left. Clicking on that gets you to the standard download page: http://www.nvidia.com/Download/index.aspx?lang=en-us However, below the GET DRIVERS BY PRODUCT box, there is another box called OTHER DOWNLOADS SUPPORT. The first link there is Beta and Archived Drivers: http://www.nvidia.com/Download/Find.aspx?lang=en-us Entering your product and OS info into the form gets you a box full of results, with the stable drivers listed first and the beta drivers (marked with a red BETA) listed last. The driver I'm using is on a line that reads like this: Linux 64-bit Display Driver Version 177.13 BETA 177.13 June 17, 2008 I found out, the hard way, not to bookmark such links... because whenever they alter their website those bookmarks go stale. I just learned to find the drivers like a Windows-noob: point, click, point, click, etc. HTH, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [!] 2.6.26 + vga=791
From: David Witbrodt [EMAIL PROTECTED] To: Hugo Vanwoerkom [EMAIL PROTECTED] Sent: Saturday, August 2, 2008 11:41:47 AM Subject: Re: [!] 2.6.26 + vga=791 David Witbrodt wrote: So now I have to go item by item and investigate the diff in .config files, which is vast because with my .config the kernel compiles in 12 minutes and with the Debian .config it takes 1 hour + 20 minutes! That is good news. You may be getting close to a solution. Might I suggestion the following incantation: diff -y | less Good clue! But I am no closer and consider giving up: it would only be useful if I found a kernel parameter for the cmdline to avoid being without framebuffers. Any other fix entails recompiling the Debian Kernel, e.g. in order to install uvesfb you have to do that. The last Debian kernel that ran with vga=791 was 2.6.24. So I did a diff -y beteen that and 2.6.25 that does *not* allow vga=791. That file is here: http://www.geocities.com/hugovanwoerkom/config-24-25-diff.txt Well, from looking over your 'diff -y' output, it looks like the problem is either in some non-obvious config option, mostly likely before the section marked # CPU Frequency scaling or in actual source code changes. I remember trying to enable the faster ywrap feature of VESA FB, and ending up looking at the sources to find out why my boot parameter for ywrap was always rejected in favor of redraw -- and I discovered that drivers compiled 64-bits cannot talk to the 32-bit BIOS, so that VESA FB is unable to do mode changing or primitive acceleration (via BIOS calls) on amd64 systems. (This led me to trying UVESA FB, once it became available in the kernel, so that I could get my virtual terminals to run at a vertical refresh more suited to my monitor's health. So, I know how you feel. I just tried to compile the just-released 2.6.26-1 sources last night. The resulting kernel runs fine on my desktop machine, but freezes early during the boot on the other machine. I thought it was because I had enabled RAID drivers, so I can get software RAID to work, but disabling RAID did not help... and disabling LOTS of things has not helped. When I installed the stock kernel (instead of building kernel after kernel myself) I discovered it wasn't a configuration problem at all -- the stock kernel was also freezing early in boot! My 2.6.25 kernels, stock and self-built, run just fine on exactly the same hardware, so it looks like some source code change between 2.6.25 and 2.6.26 rubs my hardware the wrong way. O.O '^' I'm currently trying to isolate the problem so I can submit a useful bug report. I see that kernel-archive.buildserver.net has a newer snapshot to try, so I will spend the rest of my day off here trying to pin down the problem. If all else fails, I can just remain at 2.6.25 to have a perfectly working machine -- just like 2.6.24 is the one that works for you. The big problem is that the DDs and kernel hackers don't have our hardware, and cannot reproduce our bugs. They can see our bug reports, but without having our hardware where they can get their hands on it, sometimes all they can do is shrug and say, Well, I can't reproduce the problem here. Maybe someone else will fix it. Your VESA FB problem is particularly strange, and it would probably take a kernel hacker with 'gdb' less than 5 minutes to discover why vga=791 is rejected, and maybe even fix it. Bummer. Sorry I can't be of more help, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [!] 2.6.26 + vga=791
- Forwarded Message From: David Witbrodt [EMAIL PROTECTED] To: Hugo Vanwoerkom [EMAIL PROTECTED] Sent: Friday, August 1, 2008 10:34:51 PM Subject: Re: [!] 2.6.26 + vga=791 But I did something interesting: I recompiled 2.6.26-1-686 but changed to .config file to what I use with my homerolled kernel. And guess what: vga=791 works! The problem lies in the .config file that Debian uses and apparently my hardware. Something that Maximilian Attems pointed out in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481063: ... please enlighten us on the .config changes. we are *not* carrying any fb specific patches. ... So now I have to go item by item and investigate the diff in .config files, which is vast because with my .config the kernel compiles in 12 minutes and with the Debian .config it takes 1 hour + 20 minutes! That is good news. You may be getting close to a solution. Might I suggestion the following incantation: diff -y | less I use that after I compile my new kernels from source and respond to the questions presented by 'make oldconfig'. I keep personal documentation on the kernel config settings that are relevant for my machines, and I have found this diff trick to be the fastest way to incorporate changes with new kernel versions. The -y option gives you a side-by-side dump of both files -- no lines omitted -- with indicators of lines that are different and lines that are contained in only one file. Hopefully you have a fairly high resolution monitor! ;) I like to run that diff in an xterm that I have maximized using the F11 key. HTH, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.26 + vga=791
I reported here on 5/18/2008 that I couldn't use vga=791 with the Debian 2.6.25 kernel, but *could* with the 2.6.25 from kernel.org. Same issue with 2.6.26: vga=791 gets undefined video mode. Yet it works fine with 2.6.26 from kernel.org, so it is clearly a Debian issue. In the 2 months that have expired noone has been able to shed light on this Bug#481063. Too bad. For me 2.6.26-1-686 is unusable. What response did you get from the Debian Kernel Team debian-kernel(at)lists.debian.org ? I see that only one member of the team responded to your bug report, so maybe another member or some other knowledgeable subscriber to that list could be of help. What do you get from running 'hwinfo --framebuffer' ? The hex equivalent of decimal 791 is 0x317 -- did you try that as well? Dave Witbrodt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.26 + vga=791
And I tried vga=0x0317 and get undefined videomode. Bummer. Just for sanity's sake, did you try vga=0x317? Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xscreensaver and XDM login window
Has anyone on this list who runs XDM tried to get the 'xscreensaver' to run on the login screen? The 'man' page gives some instructions, but those do not work for me. In fact, the suggestion to place xhost +localhost in /etc/X11/xdm/xdm-config does not work. On my system, the way to run GUI apps as root under XOrg is more like this: xhost +local:root Using this in 'xdm-config' prevents the startup breakage, but still does not allow 'xscreensaver' to run. This is a matter of curiosity, just to see if anyone has been able to get it working. The 'xscreensaver' runs fine once my regular user logs in, and I have the XOrg DPMS settings adjusted so that the monitor blanks if no one logs in to the XDM login within 5 minutes. Dave Witbrodt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel update breaks network
I just updated an Etch server to linux-image-2.6.18-6-k7 (from -5-) and after a reboot network won't come up. The network card is an Intel 100mbit, uses the e100 driver. The driver loads, but trying to bring eth0 up gives me a does not exist error. [...] Any ideas appreciated Something like this happened to me just a few days ago. I bought two identical motherboards, but only 1 CPU (awaiting a free CPU from a friend). I wanted to test both mboards right away, in case any of them was dead. I built a machine around the first mboard, and then installed Lenny using a daily-build Debian-installer CD from March. It all worked fine, including the NIC being autodetected as eth0, etc. Then, I swapped in the other mboard. All worked just as well, except the NIC didn't seem to be detected. Upon closer inspection, I found (via 'dmesg | less') that the kernel was seeing it just fine but udev was renaming the NIC from eth0 to eth1. The problem turned out to be relatively simple. A list of devices discovered by udev is kept in /etc/udev. The MAC address of the NIC on the first mboard was stored in a persistent rules file there, and udev has been written to assume that any device it discovered in the past may suddenly reappear someday. In short, udev was preserving the eth0 name for the NIC from the first mboard, and was assigning eth1 to the NIC on the second mboard. This sounds very similar to the problem you are having! ;) My advice is: 1) Go to /etc/udev/rules.d in a terminal. 2) Run 'grep eth *'. (In my case, the file I found with the problem was called 'z25_persistent-net.rules'.) 3) Use your favorite editor (as root, or with 'sudo' or 'su -c', etc.) to alter the configuration to your liking. In my case, I commented out the line that was assigning eth0 only to the MAC address of the NIC on the first mboard, and then edited eth1 to eth0 on the line identifying the MAC address of the NIC on the second mboard. 4) Run 'ifup eth0'. In my case all was well. HTH, Dave Witbrodt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using 2.6.25 + Nvidia + VMware
Dave, thanks for pointing out the v86d error in the wiki. But AFAIK in Debian kernels vesafb has always been compiled into the kernel, not as a module, making its inclusion in the initrd unnecessary. That's what I thought, as well. When I checked the 'initrd.img-version' file, it wasn't there. When I added 'vesafb' to /etc/initramfs-tools/modules, and ran 'update-initramfs', I was able to use VESA FB. When I get some time, I'll ask some maintainers about it. This may actually be a bug... or it might not. Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using 2.6.25 + Nvidia + VMware
Hugo Vanwoerkom wrote: Hi, In upgrading to 2.6.25 I ran into problems, as follows: 1. When I use linux-image-2.6.25-1-686 or 2-686 from binary or from source I cannot use vga=791 or I get undefined video mode number: 317. When I compile from kernel.org's 2.6.25.3 I don't get that problem. I filed a bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481063 I ran into the same problem yesterday, installing Lenny on a new build with an integrated Radeon X1200 GPU. It turns out that the VESA framebuffer driver (vesafb) is not included in the stock kernel's initrd. (You can check the contents of your own initrd with this sort of incantation: 'gunzip -c /boot/initrd.img-version | cpio -t | less'.) You can get VESA FB working again with some commands like the following: echo vesafb /etc/initramfs-tools/modules update-initramfs editor /boot/grub/menu.lst # edit your favorite kernel line to include parameters: # vga=mode# video=vesafb Be careful of the mode#! On my main desktop system, with a GeForce 7950GT card, my preferred mode is 1280x1024 -- and the proper mode# is 795 or 0x31B. On my new Radeon X1200 server, the corresponding mode# is 794 or 0x31A. You can find out authoritative mode# values for your hardware by installing hwinfo and running hwinfo --framebuffer I solved (1) by installing uvesafb in 2.6.25-2-686 detailed here: http://wiki.debian.org/HowToUseUvesafbWithDebian I think this is overkill for most folks, but some people have fun playing around with unusual hacks. (I personally use UVESA FB, but only because I want to control the vertical refresh rate on my virtual terminals.) I think Hugo's instructions have some errors. For example, he instructs folks to install 'klibc', but later compiles the 'v86d' helper utility against x86emu instead of 'klibc': Install v86d Go to the directory that contains the v86d code and then: ./configure --with-x86emu make KDIR=path of the kernel tree that was compiled above make install To build 'v86d' using 'klibc', the configure command should be ./configure --with-klibc Also, when updating GRUB's 'menu.lst' file, Add to a kernel command line the following: video=uvesafb:1024x768-32,mtrr:3,ywrap I'm not sure that ywrap actually does anything on an AMD64 system. I can report that on my system it gets ignored and redraw is used instead of ywrap. Having said all that, I remember how much of a hassle it was to learn how to get UVESA FB running on Debian. For trying to get helpful information out to the world, Hugo should be thanked! Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.25 + vga=791
In installing linux-image-2.6.25-1-686 I find I can no longer use vga=791 on the kernel commandline. I get undefined videomode number: 317 that's 791 hex. Here's something funny: I just saw this error message tonight, building a new machine with an integrated ATI X1200 GPU. I'm too tired to troubleshoot it until tomorrow, though. Good job Dave for pointing out those klibc packages: I forgot :-( libklibc-dev. Now following Spocks website verbatim I get uvesafb at bootup. Hmm. I've been compiling my 'klibc' DEBs from scratch instead of using the precompiled packages from the repositories. It is interesting to see that you didn't have to do that, and were still able to get 'v86d' to run UVESA FB! The spock site states that 'klibc' must be built against a compiled kernel tree which has CONFIG_UVESA_FB enabled, so that's what I've been doing. Looks like I need to experiment with your (easier) way! ;) BTW I found out uvesafb was running when I had specified vga=791 and got a 80x25 FB at boot. Can you modigy uvesafb parms on the fly while running? Well, I believe that answer is yes. My purpose was to get my virtual terminals to run at 60 Hz vertical refresh, instead of the 75 Hz that my monitor (accurately) reports at boot. My monitor is able to do 75 Hz, but the manufacturer says that using 75 Hz at 1280x1024 may shorten its lifespan. I found that the NVidia FB, once the kernel developers added support for the GeForce 7XXX family, defaulted to 60 Hz because the monitor reports 60 Hz as its preferred vert. refresh. But [EMAIL PROTECTED] is not a standard VESA mode, so the VESA FB simply can't set it; after the boot sequence, VESA FB also does not allow changes to the virtual terminals' video mode. I don't want to use 'nvidiafb' because the X 'nvidia' driver cannot coexist with it. (I really hope to see a free source X driver with 3D acceleration soon that CAN work with 'nvidiafb'; it looks like the ATI drivers are already reaching a similar goal.) To answer your question: if I run 'fbset -i' in a virtual terminal (I'm talking about using Ctrl-F1, not something like an xterm) I can discover the vert. refresh rate being used by the framebuffer driver. If I supply the boot parameter video=uvesafb on my kernel line in 'menu.lst', I get 1280x1024 at 75 Hz. (So, the driver correctly detects the optimal resolution, but uses the highest possible refresh rate reported by the monitor instead of the alternate rate it reports as preferred.) OTOH, if I supply a parameter like video=uvesafb:[EMAIL PROTECTED], then the virtual terminals are set to 1280x1024 at 60 Hz. Perfect! Either way, I am also able to use 'fbset mode' to change the mode to a different vertical refresh. That makes me think I should say yes to your question. However, I never tried changing the resolution; my monitor in an LCD, and resolutions other than 1280x1024 look degraded. I would check for you right now, but that machine is in pieces in the other room because of a CPU upgrade. I can try it tomorrow, though. I believe it will work: the userspace 'v86d' utility stays in memory after boot, which makes it possible for UVESA FB to talk to the video card BIOS at any time (not just at boot time, like VESA FB). If you compile your own kernels, there is some useful documentation about how to set your video mode for UVESA FB provide with the kernel sources. Let's say we are in the directory than contains the unpacked kernel source tree. You can take a look at this file: linux-source-version/Documentation/fb/uvesafb.txt (The first kernel which had this driver was 2.6.24, BTW.) The document was written by spock himself, and it is the second best source of info I've found besides the spock website. HTH, and glad to hear about your success, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.25 + vga=791
On Mon, May 12, 2008 at 08:39:20PM +0200, Gilles Mocellin wrote: Le Monday 12 May 2008 15:52:15 Hugo Vanwoerkom, vous avez écrit : Hi, In installing linux-image-2.6.25-1-686 I find I can no longer use vga=791 on the kernel commandline. I get undefined videomode number: 317 that's 791 hex. I've been using vga=791 on kernels since time immemorial, what's wrong with it now? There is an alternative to that parameter: http://dev.gentoo.org/~spock/projects/uvesafb/ but I'd like to know if anybody else using 2.6.25 has had problems with the vga= parameter, before I go into unknown territory... Hugo Same problem here. I don't know the good solution. does this mean they have removed vesfb and moved to uvesafb ? If I could pitch in my two cents here: I have been using UVESA FB on an AMD64 machine since the beginning of the year -- it allows me to get my virtual terminals to run at 60 Hz, where VESA FB will only allow me to use 75 Hz. (Viewsonic recommends that my LCD monitor use a vert. refresh of 60 Hz at 1280x1024 in order to extend the life of the device.) The Debian Kernel Team has certainly NOT moved to UVESA FB at all: $ grep -i vesa /boot/config-2.6.25-1-amd64 # CONFIG_FB_UVESA is not set CONFIG_FB_VESA=y Usage of UVESA FB requires that 'klibc' (packaged for Debian under the names 'libklibc', 'klibc-utils', and 'libklibc-dev') be compiled against kernel sources that have been built with UVESA FB enabled; and it requires an early userspace helper program, 'v86d', that has not even been packaged for Debian. If the kernel boot parameter vga=791 is not working for someone, I would ask them for three pieces of information first, to rule out silly problems: 1. Have you changed your monitor to one that does not support the desired resolution? 2. Does your kernel configuration have the VESA framebuffer enabled? 3. If you use an initrd, is the VESA FB module present in it? Only after determining whether the monitor supports the resolution, whether VESA FB is enabled in the kernel, and whether VESA FB is present in the initrd would I move on to deeper troubleshooting. HTH, Dave Witbrodt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adding a module to an initrd.img
I generated a module called v86d which is in /sbin I want to add that to initrd.img-2.6.25-1-686 No amount of fiddling does it. When I do: zcat initrd.img-2.6.25-1-686 | cpio --list the module never appears. I tried adding a file to /etc/modprobe.d and adding v86d to /etc/initramfs-tools/modules all to no effect. How do you add a module to an initrd.img? I'm sure there's a way to do what you want, but Debian's tools for creating initrd's only grab files from /lib/modules/kernel-version, AFAIK. I use 'v86d' to support UVESA FB on my system, but my preference is to not use an initrd at all. Because of that, I have never investigated how to force 'v86d' into a Debian initrd (though, as I said, I'm sure there's a way!). What I do is pack an initramfs with my kernel image -- which is the moral equivalent of an initrd, except that the bootloader doesn't have to load an external file for the kernel. The kernel just unpacks the compressed cpio (initramfs) archive that is present in the kernel image itself. You can find some instructions for doing this here: http://dev.gentoo.org/~spock/projects/uvesafb/ Read down until you see uvesafb::installation instructions, then take a look at step 6: 6. reconfigure your kernel; in the General Setup section select: Initial RAM filesystem and RAM disk (initramfs/initrd) support and use /usr/share/v86d/initramfs in Initramfs source file(s). (that's CONFIG_INITRAMFS_SOURCE=/usr/share/v86d/initramfs) For us, the location of the file needed for CONFIG_INITRAMFS_SOURCE will not be the same. The location of that file will depend on where you unpacked and built the 'v86d' sources. For example, let's say user fred on my system unpacked his 'v86d' sources in ~/sandbox. He now has a directory like this: /home/fred/sandbox/v86d-0.1.5 Inside that dir, there is a subdir called 'misc', and in that dir is the file spock was talking about: $ ls /home/fred/sandbox/v86d-0.1.5/misc initramfs Therefore, user fred should go to his kernel source tree, run something like 'make menuconfig', find the option for CONFIG_INITRAMFS_SOURCE, and set its value to /home/fred/sandbox/v86d-0.1.5/misc/initramfs This process will cause the kernel to include an initramfs image along with the kernel image containing the files required for 'v86d' to work. (If you are using 'v86d' to get UVESA FB to work, then all of this is for nothing if you also did not have a uvesafb-aware build of 'klibc' installed when you compiled 'v86d'! You would have to rebuild 'klibc' first, pointing the build at kernel sources that have been built with UVESA FB enabled, then rebuild 'v86d' against that version of 'klibc'.) BTW, I am not saying that you will no longer need an initrd at all. If you needed one before, because certain modules required for your machine to boot were not compiled directly into the kernel, then you will still need one. I'm just saying that 'v86d' will not have to be present in that initrd: it can actually just be included with the kernel image itself, if following the method of spock indicated above. Personally, when building my own kernel I take the time (numerous hours, the first time) to completely disable the configs for hardware not present in my system and features that I cannot imagine ever using. I then make sure that any drivers necessary for booting are built into the kernel (config set to Y), and other drivers that I want (but don't need at boot time) I enable as loadable modules (config set to M). The results are mixed: my kernels are somewhat larger, but I have a lot less wasted space in /lib/modules: # ls -s /boot [...] 5876 initrd.img-2.6.25-1-amd64 [...] 2492 vmlinuz-2.6.25.080503.amd64x2.uvesafb 1692 vmlinuz-2.6.25-1-amd64 # ls -1 /lib/modules 2.6.25.080503.amd64x2.uvesafb 2.6.25-1-amd64 # du -s /lib/modules/2.6* 15020/lib/modules/2.6.25.080503.amd64x2.uvesafb 77540/lib/modules/2.6.25-1-amd64 As you can see, my self-compiled kernel image is about 800K larger than the Debian stock kernel, but the stock kernel also requires a 5800K initrd. In /lib/modules, my self-compiled kernel uses about 1/5 the amount of disk space as the stock kernel... and I went overboard turning on modules for networking support that I probably will never even use! The biggest difference is in compile time, though. My Athlon 64 X2 5600 CPU compiles my kernel in less than 4.5 minutes if I tell 'make-kpkg' to use both cores: CONCURRENCY_LEVEL=3 make-kpkg --append-to-version=... --revision=... kernel_image HTH, Dave Witbrodt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel source packages..
Can anyone shed any light on the differences between the various kernel source packages in the repository, and which is the best choice for just being able to reproduce the running kernel? The example in my Martin Kraft book refers to: apt-get install kernel-source-2.6.8 but I can't find a 'kernel-source-anything'.. The book is great, but already a bit out of date. Krafft has a website (not recently updated) which includes error corrections and new information here: http://debiansystem.info If you read the section of the book discussing the naming of kernel-related packages -- including images, headers-only packages, and source packages -- then all of the information is correct... it's just that Debian policy renamed 'kernel-*' to 'linux-*' many moons ago (back at kernel 2.6.12, I believe). See this: http://debiansystem.info/readers/changes/260-package-names HTH, Dave Witbrodt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unable to start xcdroast as root
Hi, From the root console: # /usr/bin/xcdroast The reply: (xcdroast:18770): Gtk-WARNING **: cannot open display: If I start from a user console I get the window that says you must first start as root to set up. If I set the suid bit on xcdroast it tries to start from a user but dies. Any help or ideas appreciated. Debian unstable - kernel version = 2.6.17.8 I wonder what desktop environment you are using? Gnome, KDE, XFCE4, something else? Anyway, I found that I could run GUI programs as root when using Gnome, but when I installed XFCE4 I could not. After reading various docs, I discovered a fix: xhost +local:root I'm not promising that will work for you, but it's worth a shot. HTH YMMV, Dave Witbrodt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dual Boot with win me
klkl lklk [EMAIL PROTECTED] wrote: Hi all, I am going to use fips to split my windows partition and then make the root/swap partitions. Should I install LILO in the MBR or in the first sector of the boot partition. The last time, I installed it in the boot sector, now where? What are the diofferences? Thanks! Icreated a multiboot setup a couple of weeks ago (XP, ME, DOS, and Debian). The installer defaults to 'grub' instead of 'lilo', and that works very well IMHO. If you have resized your ME partition before installing Debian, then the debian-installer should be able to install grub to your hard drive's MBR and create options for both Debian and ME for you. Dave W.
Re: Sarge Released!
Curt Howland [EMAIL PROTECTED] wrote: Ok, now that Debian 3.1 is out, does anyone know if any books will be written to cover the new distribution? A new edition of "Debian GNU/Linux Bible" has been waiting for Sarge for a few months now, slated for a mid-July release last time I checked. Hopefully some others will follow. Dave W.
How can I share a mailbox between multiple OSes
This is a newbie question. I just installed Debian and several other OSes onto my old machine. As I have been reading the docs, and have started configuring things to my liking, I found myself wondering whether an email application exists that would allow me to store my mailbox files on a common data partition, which could be then used by whatever OS was currently running. I get my email via POP3 from my ISP, so I was thinking that there might be a single program that has been ported to all of the OSes, making it possibleto usea common mailbox from each platform. Anyone out there doing this? Is is even possible? Seems to me like it should be, but I've never faced this scenario before, so I'm facing a steep learning curve... Thank, Dave W.
Re: How to move debian from one drive to another and keep it working?
"Pedro M (Morphix User)" [EMAIL PROTECTED] wrote: Can anybody improve the page http://wiki.debian.net/?Move about the same topic ?. Thank you a lot. After reviewing all of the helpful suggestions provided on this list, I chose this method; it seemed simple and elegant. It bombed out pretty badly, though. My system froze in an endless loop of error messages about "DMA table too small" on my destination drive. A local Linux guru had warned me about making sure not to copy the mounted destination partitions on top of themselves, so it (in hindsight) seems logical to me that a command like tar cvf - / | (cd /mnt/; tar xvf -) would try to copy /mnt/* to itself, unless 'tar' has built-in safeguards. (As a newb, I don't know the answers to such questions yet.) I'm going to try some variations on the above method -- excluding /mnt from the tar process, for example -- and I'll post any successes or failures back here. Thanks to everyone for the help so far, Dave W.
Re: How to move debian from one drive to another and keep it working?
Jacob S [EMAIL PROTECTED] wrote: You might want to try reading the Howto on upgrading hard drives. More specifically, step 7 lists several different ways to copy an installation from one drive to another and mentions which directories to exclude. http://www.tldp.org/HOWTO/Hard-Disk-Upgrade/index.html HTH, Jacob Ahhh! Beautiful! I wish you had seen my original post a few days ago and told me about this then. Much obliged! I think I will reformat the new partitions and try this. I was getting some out of space errors the other way, once I got it to (almost) work. Thanks, Dave W.
Re: How to move debian from one drive to another and keep it working?
David Witbrodt [EMAIL PROTECTED] wrote: tar cvf - / | (cd /mnt/; tar xvf -) I'm a dummy. I had just spend the past several days reading docs, including the 'man' page for 'tar', and failed to notice that the "cvf" and "xvf" switches for 'tar' do not have the '-' character, but the man page for 'tar' _does_ use it. I copied the command quoted above from http://wiki.debian.net/?Move, and I seem to recall using versions of 'tar' in previous years that didn't use the '-' for its commands. When I modified the above command to this, tar --exclude=/mnt -cvf - / | (cd /mnt/; tar -xvf -) things almost worked. I noticed a lot of errors as the process neared completion, and when I compared the '/' dir to the '/mnt' dir, a lot seemed to be missing. I considered making manual corrections, but when I tried to save a text file to '/mnt' I got an out of space error, from which I conclude that things are pretty messed up. JacobS just sent a very helpful reference to a HOWTO in another message posted to debian-user, and I think I will try that out now (after clearing the new partitions for a fresh start). DW
Re: How to move debian from one drive to another and keep it working?
Lee Braiden [EMAIL PROTECTED] wrote: - specifies stdin, or stdout as files, where the | pipe character sends data. You only need to use it if you use the f flag, which requires a filename. Combos along the lines of tar cv srcdir | (cd dest; tar xv) will work, too. Thanks for the clarification. I seem to remember using 'tar' without the '-' character in the past, but I noticed the Debian man pages were using the hypen, and thought it might be causing my problems. Evidently not. Actually, the copying of /mnt on top of itself seems to have been the real culprit. Thanks again, Dave W.
[SOLVED] Re: How to move debian from one drive to another and keep it working?
After having installed Debian to a partition on an old hard drive, connected to the motherboard's IDE controller, because the new drive (where I wanted to place Debian) wasn't recognized by the Debian installer CD (unsupported PCI controller), I found that I needed to transfer my working Debian system to a set of partitions on the new drive. (The kernel installed by the Debian installer did recognize the PCI controller, whereas the CD kernel would not.)
Here is my report on how I was able to solve the problem:
First, I should note that I was installing 5 operating systems including Debian, so there were partitions galore on the twohard disks. The relevant partitions on the old drive (for me) were
/dev/hda7 '/'
/dev/hda5 swap
The working copy of Debian on /dev/hda7 was used to partition the new drive (/dev/hdg) as follows:
/dev/hdg1 [other OS]
/dev/hdg2 /boot
/dev/hdg3 [other OS]
/dev/hdg4 ["extended" partition containing the following "logical" partitions]
/dev/hdg5 /
/dev/hdg6 /usr
/dev/hdg7 /tmp
/dev/hdg8 /var
/dev/hdg9 /home
/dev/hdg10 [empty]
I used 'fdisk' to create all of these partitions.
Following instructions in the
Next, I had to create file systems (format) the Linux partitions. I made hdg[25] ext2, and the rest ext3. Following the instructions in the "Hard Disk Upgrade Mini How-To", I used 'mkfs.ext2' and 'mkfs.ext3' to do the job:
mkfs.ext2 /dev/hdg2 (same for hdg5)
mkfs.ext3 /dev/hdg6 (same for 7,8,9)
Then I had to mount the new partitions so that I could copy files to them. The docs are not always newbie-friendly, so to make this absolutely clear I will show all the steps I performed. Order matters as you mount the partitions. My new root was going to be /dev/hdg5, so I ran this command:
mount -t ext2 /dev/hdg5 /mnt
Now, the other partitions need proper places to mount, so I created directories for them in /mnt (which actually creates the directories on hdg5, not on the partition you are currently using):
mkdir boot usr tmp var home
The other partitions may then be properly mounted. For my setup, this meant:
mount -t ext2 /dev/hdg2 /mnt/boot
mount -t ext3 /dev/hdg6 /mnt/usr
mount -t ext3 /dev/hdg7 /mnt/tmp
mount -t ext3 /dev/hdg8 /mnt/var
mount -t ext3 /dev/hdg9 /mnt/home
The "Hard Disk Upgrade" HOWTO recommended changing the permissions on the /tmp directory for technical reasons. As a newbie myself, I don't pretend to understand, but I went along with the expert advice:
chmod 1777 /mnt/tmp
With the partitions properly mounted, it was time to copy files. In order to kill most running processes and making it possible to copy all system files (and not have some blocked by running processes), the HOWTO recommended moving to single-user mode (runlevel 1):
telinit 1
Since my working Debian was located on a single partition on the old drive, I could use the easiest of the 3 methods listed in the HOWTO. (For others using 2 or more partitions, not including swap, for their working Linux, the HOWTO mentioned above gives 2 other methods to get your files transferred.) I used:
cp -ax / /mnt
The "-a" option preserves the attributes of your currently working system as much as possible, and the "-x" option keeps 'cp' from copying files located in other file systems (in this case /mnt and /proc).
On my system, an emtpy /proc directory was created (at /mnt/proc), but if this hadn't happened I would have had to create a /proc directory with "mkdir /mnt/proc".
The HOWTO suggested checking the new file systems before trying to boot the copied system. That meant unmounting the partitions first; the deeper directories in the structure have to be unmounted first):
umount /mnt/home
umount /mnt/var
umount /mnt/tmp
umount /mnt/usr
umount /mnt/boot
umount /mnt
Then the file system checker can be run on each partition:
fsck.ext2 /dev/hdg5 (and hdg2, for me)
fsck.ext3 /dev/hdg6 (and 7,8,9)
No problems on any of them for me.
The HOWTO also suggested it might be possible to see if the contents of regular files copied correctly. (This takes a long time, and is merely optional.) First, remount the partitions (same steps as above), then run (all one long command):
find / -path /proc -prune -o -path /mnt -prune -o -xtype f -exec cmp {} /mnt{} \;
With the new partitions mounted, you can then edit the 'fstab' file to make the new copy of Linux use the new partitions instead of the old one(s):
cd /mnt/etc
nano fstab
I had to add entries for hdg5,2,6,7,8, and 9, and remove my entry for hda7 (see my partition scheme listed above). I left the swappartition on the other drive, since it was located where I wanted it to be from the beginning.
I then had to edit 'menu.lst' so that I could boot to the new copy of Debian using 'grub'. For me, the necessary changes were not obvious because I hadn't dealt with 'grub' configurations before. As an oversimplified example, my original working Debian was configured this way in /boot/grub/menu.lst:
title Debian GNU/Linux
Re: How to move debian from one drive to another and keep it working?
Matias Rollan [EMAIL PROTECTED] wrote: bash# mount /dev/hdg5 /mnt; mount /dev/hdg2 /mnt/boot/ and so on then.. bash# tar cvf - / | (cd /mnt/; tar xvf -) Change the root of the system. chroot /mnt And then modify grub config files in order to boot from your new hdg drive [ don't use grub so I can't help you ]. And execute grub? [ ok I would execute lilo to save the changes in the MBR of your new /dev/hdg drive ] p.s: Be sure of having a swap partition in your new drive. Thanks for the help! I feel better now, seeing that it really is as easy as I hoped it would be. Dave W.
Re: How to move debian from one drive to another and keep it working?
Alvin Oga [EMAIL PROTECTED] wrote: differences between the (cd/net) install kernel and the installed systenm kernel nibbled your butt eh Ya, big time. some mb system bios will NOT let you boot from PCI controllers you can keep your grub info on /dev/hda ... and boot into / which is on /dev/hdg5 The BIOS on the controller card hijacks the boot process; I can boot from drives attached to it. My old drive may be approaching the end of its life, though I'm not having any problems yet. I am installing old OSes to the old drive (FreeDOS, OS/2, WinME) so that, if it dies, I haven't lost anything important. The new drive will be holding Debian and WinXP. My main reason for wanting 'grub' to boot from the new drive is in case the old one dies suddenly. only need to change /etc/fstab That's a relief! Seems to easy... ;-) be sure you have a way to boot the system if your "transfer failed" ( boot from floppy, boot from network, boot from cd, .. ) I have a grub floppy, and I have an old Knoppix CD. Hopefully they will cover me if something bad happens. Thanks for the helpful info! Dave W.
How to move debian from one drive to another and keep it working?
I just installed Debian for the first time. I have two hard drives, one on the motherboard IDE controller and a bigger, better one on a PCI controller card. I wanted to install Debian to the drive attached to the PCI controller, but the installer didn't recognize the card, so I was forced to install Debian to the old drive. Then, the installer installed a kernel that _did_ recognize the PCI controller, so now that Debian is installed to the wrong place I am able to partition and use the drive where I wanted Debian to be in the first place! I need advice from experiencedusers on how to move a working Debian from here: / /dev/hda7 swap /dev/hda5 to here: /dev/hdg5 / /dev/hdg2 /boot /dev/hdg6 /usr /dev/hdg7 /tmp /dev/hdg8 /var /dev/hdg9 /home As a newbie, I'm in danger of doing some real stupid things. My first guess at a solution would involve the following steps: 1. Copy (recursive) each corresponding directory to the appropriate partitions 2. Modify certain config files to point at the new partitions 3. Modify grub settings, especially 'menu.lst' and use grub-install to write the MBR on the new drive. (I am going to alter the BIOS settings so that the new drive boots first -- the controller card has its own BIOS and supports this feature -- but that means the original install of grub to the old drive's MBR will no longer operate.) Help, either in the form of recommended steps or references to the appropriate documents, would be much appreciated! Thanks, Dave Witbrodt
Thanks to S.O'Rear, R.Sanchez, P.Condon, G.L.Fairless, K.vanWyk, and Laurabelle!
Last fall (Sep. 25) I posted a message: "Newbie first-time install advice: Highpoint Rocket 133SB" (http://lists.debian.org/debian-user/2004/09/msg02943.html) and received plenty of information, advice, tips, hints, and encouragement. I am sorry to say that, due to circumstances beyond my control, I was unable to install Debian during the fall or the winter. Instead of merely backing up my hard drive, I decided instead to perform a thorough inspections of it's contents --sorting, reorganizing, deleting, renaming, and otherwise manipulating before I actually burned backup CDs. I never really understood what a "gigabyte" was until I started looking at 27 GB of files one at a time! (My first computer, a 386, had a 128 MB hard drive; my second, a 486, had a 212 MB hard drive; this machine, my third, has a 40 GB drive... and I never gave much thought to organizing myself as I created or downloaded files. Big mistake!) I want to particularly thank those who appear in the subject line to this message. I faced a situation that I thought was unusual -- my machine can't handle LBA48, but I had bought a 160 GB drive thinking I could just attach the thing and use it. When I realized there was a problem, I bought a PCI HD controller card that would 1) support a drive 128 GiB and 2) provide BIOS support for "legacy" OSes. So, I picked up an inexpensive controller card: a Highpoint Rocket 133SB. After ordering it, I wondered whether Debian would recognize it when I installed (which I hoped would be in October, then November, then December, ...). So I posted a message to debian-user, making it clear that I hadn't installed yet but planned to soon, and was wondering whether anyone had any experience with this card. Only one responder (K. van Wyk)indicated success with a similar (but not identical) card, but only after compiling a kernel with a driver-source package from Highpoint. Others encouraged me to just try a debian-installer CD, then post the results if I had problems. I only got around to it last week, 7 or 8 months later! My installingexperience was complicated by the fact that I wanted to install 5 operating systems on two drives, and I have no previous experience with Linux. I began last Friday. Due to a combination of bad luck, hardware unsupported by the debian-installer CD, and gross incompetence on my part, I had exactly ZERO operating systems booting by Sunday night. (I even torqued the WinMe partition on my old drive by accident, which I wanted to keep running so I could access email and browsers "in case something happened." I lost that partition almost immediately, thinking I was formatting a different partition.) On Saturday I tried to install Debian, but the netinst CD failed to recognize the controller card (needing a HPT302 driver). That forced me to install, temporarily, to a partition on the old drive. The funny thing was that, once installed, Debian could recognize the HPT302 controller; that allowed me to partition the new drive and get ready to install some of the other OSes. Unfortunately, playing around with a Knoppix CD, trying to get some of the other OSes to install, Ilost that original Debian install. So, by Sunday night, I had nothing working at all. My luck improved on Monday and Tuesday: I was able to get a fresh install of WinME working, and was able to get a WinXP upgrade to install over top of a second WinME on the new drive, and I was able to get FreeDOS to install after installing Debian a second time and using 'dd' to zero out the boot sector of the FreeDOS partition. It has been aggravating, but I've learned a lot! Being a complete Debian newb, I have a lot of reading to do over my 4 day weekend coming up! I just wanted to thank those who helped and encouraged me last fall, and apologize for not getting around to it until now. I have 3 out of 5 OSes booting from the partitions I made for them, and I have Debian running from the wrong partition. I definitely need more help and advice, but I will start specific threads for those questions. I still haven't submitted my installation "bug report," so I want to do that first. It's really strange that the installer kernel couldn't recognize my HD controller, but it installed a kernel that could! Thanks again, Dave Witbrodt
Re: Recommended Debian book?
Deboo ^ [EMAIL PROTECTED] wrote: What is a good book on debian for and intermediate users? I'm a newbie to Linux, but I have found several titles useful (you should definitely get used to using 'man' pages, 'info', listservs, wikis, etc., though!): 1. Debian GNU/Linux Bible (new version soon to be released, maybe in June) 2. Essential System Administration (by Frisch) [Thanks Laurabelle!] 3. any number of books published by O'Reilly -- you can search by publisher at places like amazon.com, or just head over to the O'Reilly website. If you're interested in learning some low-level programming, Linux Programming by Example (by Robbins) is excellent. Dave W.
Re: Newbie first-time install advice: Highpoint Rocket 133SB
Paul E Condon wrote: I joined this thread late. Now I have a better idea of what you need. You want to preserve Windows on the old smaller drive. To do this remove the old drive while you work at gettind Debian up and running on new drive. Pretend everything is going to work, it probably will. Don't worry about special drivers. Maybe the special drivers are already in place. I have a few days yet before I can even attempt my Debian install. (Still backing up old drive.) Last night, another helpful responder showed me some source code from kernel 2.6.0b5 that looks like there is support for my IDE controller after all. Since I have some time, I emailed the manufacturer and I am going to do a bit more looking into it myself. In short, it looks like you are right about it probably being in place... as long as I use a kernel that is new enough. Connect you big new drive as 'master'. Your old small drive was 'master', but you have removed it. Your computer won't boot without a 'master' drive even if it is empty. The big drive requires some special installation steps and utils, which I have obtained from that manufacturer. Another user, with a similar drive, responded last night and confirmed that following those steps works without a hitch. Performing that part of the process is pretty clear for me. Use the Sarge net-install CD. You should be able to boot from it, since boot from CD does not access HD. Read intro carefully. There is an 'expert' mode. You are not an expert but you should know that it is there. If you ask for help, you may be told the answer to give to a question that you have no recollection of ever having seen. This is because the person giving help assumes that you are using expert mode, and surely saw the screen to which he refers. First time through, you should just go with whatever the install program suggests. Don't worry about HD partitioning, etc. Just see if it works. Use grub. It is what the install prefers. Don't try to pick up bits and pieces of code from outside Debian. Just see what happens. If it works, you know you have no serious problems with a 'real' install in which you partition HD as you want, reconnect the old HD, dual boot Windows, etc. And if it doesn't work, you have really specific questions to ask and error messages to report here. I agree. None of us knows how it will work for me until I actually try it. Your advice about just trying a simple install to see if it works, skipping expert mode, is well-taken. I posted the original thread hoping to hear from one or more folks who faced a similar situation -- using the same IDE controller, or having used Sarge netinst over an SBC DSL connection. Those folks would have first-hand knowledge about issues they faced (if there even were any problems at all) in trying to install Debian. Thanks for your advice and responses just the same! Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Newbie first-time install advice: Highpoint Rocket 133SB
I am about to install Linux for the first time in the next week or two, as soon as I finish backing up my old hard drive. I received a WD 160 GB hard drive as a gift earlier this year, but have not found a chance to install it until now. I assumed I could just plug it in, but when I began reading about it I realized that my old PC (circa 2000) cannot handle IDE drives larger than 137 GB. Further reading helped me understand that buying a newer IDE controller would allow me to use the big drive. I plan a multiboot system with Windows XP (and maybe a couple of other OSes), and I have on-hand all of the drivers and docs I need to make that work. Unfortunately, I am still unclear about how to allow Debian to support the IDE controller. First, several retailers listed Debian as a distro for which there is Rocket 133SB support. But the Highpoint website itself provides no such support, except for source code for the drivers (which hopefully compiles and functions for Debian). Unfortunately, I am a newbie and have no idea (at this time) how to take advantage of those sources. Even if I did, I don't have an installed Linux with which to compile them. Second, when reading about stable Debian I seemed to find that the kernel doesn't quite support large LBA48 hard drives, an issue quite aside from support for the controller card. Unfortunately, I had already downloaded and burned 3.0r2 CDs of disk 1 and disk 5 (bf2.4), thinking those would be all I needed. Being a newbie, I thought sticking with stable would be a better idea until I become more familiar with how Linux works. After discovering the LBA48 road block, I searched around a little and found the HILUX website -- an update for stable with a kernel (2.4.26) which should support LBA48. It was just after I downloaded and burned that mini-CD that it occurred to me that the Rocket 133SB controller might not be supported. When I went looking for info about that, I arrived at my current state of confusion. I would rather install from CD, since I am a total newbie (with Linux) and doubt I could make my DSL connection work if it did not autodetect. But just in case, I downloaded a Sarge netinst CD a couple of weeks ago. (Since then, I have simply been finishing the backup job on the old drive before I start playing around inside the case -- I have other new hardware to install besides the Rocket controller.) If any Debian users out there have comments or advice before I begin my big experiment (I look forward to it, even if I do have lots of problems!), please speak up. I will be beginning in the next week or two -- as soon as I have a couple of days off from work after I finish backing up -- so there is still time for me to learn the right way before I learn the HARD way! TIA, Dave Witbrodt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Newbie first-time install advice: Highpoint Rocket 133SB
Stefan O'Rear wrote:
Linux autodetects nearly anything. Non-hardware things like PPPoE (IIRC
this is used by DSL) can be trickier. Also, there are Linux-hostile
hardware vendors out there; be very careful near wireless LAN cards,
modems, and 3D-accelerated graphics cards. (ATI refuses to support
Linux, NVidia officially supports Linux but the drivers aren't open
source.)
I am glad to hear about the autodetect, but I am a bit worried about
autodetection of my NIC (HP EN1207D-TX) and my video (NVidia Vanta on
motherboard).
I have a SpeedStream 5100b, which has a built-in router, for DSL.
That is supposed to make things easier, since it handles PPPoE itself.
On the other hand, if I have the slightest problem I will be
stonewalled, since I'm a total newbie. That's my main reason for
preferring CDs over netinst. I kept a forum article where someone
explained that I only need something called DHCP to be able to use
Linux; unfortunately, I don't even know what that is (yet).
Don't usually bother with the manufacturor's website. Almost everyone
seems to have been brainwashed into thinking Red Hat is Linux; Debian
doesn't exist.
Almost all DSFG-free GPL-compatible drivers come with the kernel;
non-kernel drivers are contraversial, obscure, proprietary, non (beer)
free, very new, or some combination of the above.
I will be able to ignore the Highpoint website only if I can find a
kernel with built-in support for the Rocket 133SB controller.
Otherwise, I will have to use their open source driver code, and then
learn how to compile my own kernel, or use the driver as a kernel
module, from what I've read. The website has binary packages for 3
other distros, but at least provides source code for the drivers you can
compile yourself. I was hoping to hear from someone already using a
Rocket 133SB, so that I would know which kernels already support it, or
whether I will be forced to compile the drivers myself... which will be
a bit over my head for a while!
Not having a kernel with Rocket 133SB support would mean installing
Debian to the old hard drive until I can get a kernel working which can
handle the controller and hard drive. It's THOSE things that I wish
would autodetect! And maybe they will, but I won't be able to try for
several more days.
Sarge will be stable Real Soon Now.
I did download a Sarge netinst CD, as I mentioned before. I saw the
announcement in August that it would become the new stable by 9/15,
but that appears to have been wishful thinking. If netinst can't figure
out how to use my DSL connection, that CD is useless anyway -- unless
someone can tell me how to finesse it to work with my DSL modem.
Woody was frozen in 2001/2. Still gets security updates, but no new
programs.
Yes, and when I noticed it couldn't handle the big HD, that's when I
searched and found HILUX. The only problem is that I don't know if it
supports the Rocket. I will give it a try, since I don't know how else
to find out whether it will work.
Do use sarge though. The Woody installer ('boot-floppies') is nearly
impossible to use.
I was under the impression that boot floppies are no longer necessary
with boot CDs. Isn't that so?
Thanks for the response,
Dave W.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Newbie first-time install advice: Highpoint Rocket 133SB
Stefan O'Rear wrote: If you have a local network (if you have a router you have a local network) than you don't need to worry about DSL. If you have a working router and a working NIC you have working internet. It's not a real router, and I do not have a LAN. It's a router built-in to the 5100b modem. A real router allows attachment of external devices, but this router is actually built into the DSL modem case, making for a different sort of connection to the NIC. I think it is the standard SBC (phone company) choice for DSL modems in order to make their automated Windows installer more trouble-free. So, no LAN. DHCP means that you don't need to enter your IP address. Dynamic Host Configuration Protocol makes things MUCH easier. Even a total newbie should know how to turn the computer off when the install doesn't work :) Yes, this newbie knows that much. What I don't know is how to alter the installation configuration if it can't figure out how to handle my DSL connection. If the HILUX update CDs don't work, I will give the Sarge netinst CD a try. If you know something about using DSL with this particular modem (SpeedStream 5100b), and can warn me about problems I will face if I try to use the netinst CD, then that info would be very helpful. Otherwise, I can't ask for anything more specific until I try it... assuming I have problems, that is! My understanding of DHCP is that it is a networking protocol supported by some specific Linux package(s). As a newbie, I know about power buttons, but not technical alterations to configuration files in the event that the installer cannot figure out what to do. Linux doesn't usually support devices. It supports chipsets. Often, multiple device brands use the same chipset type. For instance, I have Creative Labs integrated sound, but I use the Ensoniq ES1371 driver. I opened up the case and looked at the sound ports with a flashlight, but hotplug and discover (two programs used by debian-installer to detect hardware) are supposed to make that unnecessary. Chances are VERY good the Rocket 133SB uses a standard controller. There is one driver that supports all standard IDE/ATA/SATA controllers. It is not a standard IDE controller, in the sense of the usual controller chipsets on the motherboards. We can know this because the manufacturer provides binary driver packages on their websites for several Linux distributions. (If the standard one driver provided with Linux for IDE support worked, those extra packages would be unnecessary, I presume.) This controller is a PCI card that supports drives larger than 137 GB, with its own BIOS so that other OSes which rely on the BIOS for disk support can use these larger drives as well. (I also know that Linux does not rely on BIOS support for drive access, but it looks like I need a special driver for Linux to use the controller card.) My hope in posting to debian-user was to hear from someone using a Rocket 133SB, so they could tell me about their experiences. Does Debian have built-in support? (I doubt it, but I thought I would ask here in case someone who knows would see my message.) If not, what steps should I take to get myself a Debian kernel that can use the Rocket controller? Don't worry about it unless the install doesn't work. OK. I was only hoping to hear from someone with this equipment before I make the attempt, since I have reason to believe it won't work... I did download a Sarge netinst CD, as I mentioned before. I saw the announcement in August that it would become the new stable by 9/15, but that appears to have been wishful thinking. If netinst can't figure out how to use my DSL connection, that CD is useless anyway -- unless someone can tell me how to finesse it to work with my DSL modem. 1. That is what debian-user is here for. And I am grateful for it! I was just looking for tips/hints/advice in advance... 2. Try it and see - it could work, and since you backed up your data it can't mess things up. Yep. I was under the impression that boot floppies are no longer necessary with boot CDs. Isn't that so? You are correct. boot-floppies is only a name. So, you meant the Woody installer CD, called boot-floppies, is almost impossible to use? Ouch! That would be what the HILUX CD has, since it an update to stable (Woody). I am going to try that first, but you don't make it sound too promising (Bummer.) Thanks again, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Newbie first-time install advice: Highpoint Rocket 133SB
Roberto Sanchez wrote: I just moved to an area w/ SBC DSL service. I had it set up a couple of weeks ago. The SpeedStream modem works no problem with Linux. Plug it into your NIC, get your IP address through DHCP and browse to http://192.168.0.1 to set up your connection and what not. Works like a champ. Thank you, sir! For reference when I get around to installing, and for the peace-of-mind of a newbie, what do you mean by get your IP address through DHCP? Is that a command, like this: dhcp It sort of sounds like you already had a running system, with the DHCP package already installed/configured. If my CDs don't work, and I will have try the Sarge netinst CD that I burned. You wouldn't happen to know anything about that, would you? (It sure would be nice to have that work well if the stable CDs can't get it done!) Sincere thanks, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Newbie first-time install advice: Highpoint Rocket 133SB
Stefan O'Rear wrote: My understanding of DHCP is that it is a networking protocol supported by some specific Linux package(s). As a newbie, I know about power buttons, but not technical alterations to configuration files in the event that the installer cannot figure out what to do. Yes. and that package comes with all versions of debian. It is automatically set up by debian-installer. Therefore, it should work OK. My point was only that I've never used it before, since I'm installing for the first time, so that if even a simple problem comes up I won't know how to fix it. This deb-user list can help me in that case, but I'll have to partition and install a Windows version to be able to access the list from home until I could get the Linux partition to work with the DSL connection. You mention (below) that the Woody installer comes with poor documentation, so that is another strike against it, I suppose? Is the Sarge documentation that much better? Are you assuming that netinst will work without needing extra help from me, so that documentation will be available from the net? (The netinst CD is quite small!) At any rate, we'll find out once I try it. Best way to learn is by doing. I enjoy troubleshooting, except when there is no solution at all Linux doesn't usually support devices. It supports chipsets. Often, multiple device brands use the same chipset type. For instance, I have Creative Labs integrated sound, but I use the Ensoniq ES1371 driver. [snip] Chances are VERY good the Rocket 133SB uses a standard controller. There is one driver that supports all standard IDE/ATA/SATA controllers. It is not a standard IDE controller, in the sense of the usual controller chipsets on the motherboards. We can know this because the manufacturer provides binary driver packages on their websites for several Linux distributions. (If the standard one driver provided with Linux for IDE support worked, those extra packages would be unnecessary, I presume.) One would think that. This controller is a PCI card that supports drives larger than 137 GB, with its own BIOS so that other OSes which rely on the BIOS for disk support can use these larger drives as well. (I also know that Linux does not rely on BIOS support for drive access, but it looks like I need a special driver for Linux to use the controller card.) My hope in posting to debian-user was to hear from someone using a Rocket 133SB, so they could tell me about their experiences. Does Debian have built-in support? (I doubt it, but I thought I would ask here in case someone who knows would see my message.) If not, what steps should I take to get myself a Debian kernel that can use the Rocket controller? Looking in the 2.6 tree, there are drivers supporting the Highpoint 343, 345, 366, 370, 370A, and 372. Now that is helpful information! (May I ask how and where you found this, so I will bother other folks less in the future? The sooner I can become self-sufficient, the sooner I can start helping other newbies on this list! ;) According to the manual for the Rocket 133SB in the retail box, the Windows drivers are called HPT302. The source code tarball provided by Highpoint is called hpt302-opensource-v1.2.tgz Looks bad for me, at first. Maybe I should start another thread asking for advice (i.e., What would you do?) about how to proceed. I have an older 37 GB drive that works as is, and a new 160 GB drive that will only work at maximum capacity if I use it with this Rocket133SB controller that I bought (like a big dummy, without checking into it first to see if Linux kernels already know about it). I had hoped to install all of the new hardware with my old OS first, just to make sure it works. Then I wanted to install Linux and XP directly to the new big drive (through the Rocket). Now the picture looks more complex. Maybe I should temporarily put my old WinME on half of the old drive (so I can use the net to get help if I have install problems with Debian), and install Debian on the other half. Then I need to compile the tarball above as a module (or should I compile a new kernel?) so that I can create a new setup that can use the Rocket. Then I can partition the big drive through the Rocket for Debian and XP, and install them over there. Or is/are there easier ways? Not impossible, just rather difficult. No useful documentation, you need to know the chipset used by most of your hardware, slow, encourages you too partition your disk but doesn't tell you how to do it right, chokes on ISA PNP, etc. YMMV, and probably won't be worse than mine. You make this sound pretty bad. I wonder if the HILUX CD is as bad as this. It's a lot smaller, and has a lot of updated (backported) packages for a minimal installation, which can then be finished by downloading anything else desired. I have a lot to learn in a hurry!
Re: Newbie first-time install advice: Highpoint Rocket 133SB
Gayle Lee Fairless wrote: I received a WD 160 GB hard drive as a gift earlier this year, but have not found a chance to install it until now. I assumed I could just plug it in, but when I began reading about it I realized that my old PC (circa 2000) cannot handle IDE drives larger than 137 GB. Further reading helped me understand that buying a newer IDE controller would allow me to use the big drive. I plan a multiboot system with Windows XP (and maybe a couple of other OSes), and I have on-hand all of the drivers and docs I need to make that work. Unfortunately, I am still unclear about how to allow Debian to support the IDE controller. Your configuration is somewhat similar to mine. I have a Gateway 500 with Windows 98SE with a 13 GB IBM hard drive as my primary drive. I installed a Western Digital 160 GB hard drive (slave) on my system. It was useful to download the Western Digital Data Lifeguard utility off Western Digital's website since the utility on Windows 98SE has a 64 GB limitation. I used Western Digital's utility to partition the new 160 GB hard drive into 6 partitions. I used the first for Linux root, a spare partition for a future root system, 2 swap partitions (one for Linux, maybe the second for Windows), and 2 large data partitions ( one for Linux, the second and last for Windows and/or Linux). I have downloaded the WD utils, even though I haven't tried to physically install the drive yet. Glad to hear that it works. If I may ask, I was a bit confused by the instruction I read (and printed) from the WD website explaining how to carry out the partitioning process. Those instructions list the following steps: 1) Connect the drive to the motherboard IDE controller (which can't handle 137 GB drives on old systems?). 2) Boot using the Data Lifeguard utils disk. 3) Install OS. 4) Power down; install LBA48 controller card, but leave big drive on legacy controller. (This is so that Windows can just recognize the controller w/o being confused by an attached drive, I guess.) 5) Boot, and load drivers. 6) Power down; move big drive to new controller. 7) Power up, and OS should boot from big drive. Did you follow these steps, or something similar? If not, what steps did you carry out. (I'm quite interested, since you obviously were successful! I have not made the attempt yet, but info about real experiences is most valuable.) I also have the 7 woody CDROM's. I was unable to use any of the 2.2 kernels in the first 4 choices off the installation CDROM (no. 1). bf2.4 had to be used. It was the only choice that saw the partitions on the 160 GB hard drive. I used cfdisk off the Linux installation CDROM to format (but not to partition) those partitions in ext2 for Linux ( partitions 1,2,3, and 5 out of six). When you come to the Xfree86 portion of the installation, choose simple or medium. Do NOT choose advanced! That option is for those people who know exactly what the hardware is on their system! BTW, be sure to prepare list of all your hardware, vendors, etc. to answer the installation questions. Thanks for the tip on Xfree86. Will do I didn't burn 7 CD's! I did some reading, and decided I needed disk 1 and 5 (bf2.4). Further reading made me think that the old Woody kernels wouldn't be able to handle my 160 GB drive, even if partitioned with the WD tool. Obviously, from your experience, I misunderstood and was wrong. Your advice about _only_ formatting (not partitioning) with cfdisk is also noted. I have burned a small CD, with an updated Woody, called HILUX. It has a more advanced kernel, which I thought was essential because of my misunderstanding about recognizing the big drive's capacity. I also hoped that it might have built-in support for my controller, but it looks now like I'm completely out of luck in that area. (Elsewhere in this thread I concluded that I will have to compile a source tarball from the manufacturer's site. Unfortunately, being an absolute beginner with Linux, that is going to pose a major hurdle for me.) I happened to choose gdm for my windows manager. Perhaps I should have chosen kdm instead since I now know that I like KDE. After that it was just a matter of learning to use apt-get update and apt-get upgrade to bring the installation up to the latest stuff. I used the package list off www.debian.org to shop for additional packages. apt-get install package works nicely. You have to run the apt-get commands as root. Be sure to create one or more user accounts for your routine use because it is not a good idea to run as root all the time. You'll have to add the user account(s) to one or more various groups to mount floppies, dial out, etc. If you have ZIP drives from Iomega, the iw utility for Linux off the Iomega website will be useful. Knowing how to setup the
Re: Newbie first-time install advice: Highpoint Rocket 133SB
Stefan O'Rear wrote: Looking in the 2.6 tree, there are drivers supporting the Highpoint 343, 345, 366, 370, 370A, and 372. Now that is helpful information! (May I ask how and where you found this, so I will bother other folks less in the future? The sooner I can become self-sufficient, the sooner I can start helping other newbies on this list! ;) According to the manual for the Rocket 133SB in the retail box, the Windows drivers are called HPT302. The source code tarball provided by Highpoint is called hpt302-opensource-v1.2.tgz I suspect the (34x,3[67]x) drivers will work backwards-compatibly. That's a very good idea! I'll email the folks at Highpoint and see what they say! You make this sound pretty bad. I wonder if the HILUX CD is as bad as this. It's a lot smaller, and has a lot of updated (backported) packages for a minimal installation, which can then be finished by downloading anything else desired. Probably not. The debian woody packages are dated, but still quite good. The HILUX people have probably substituted something else (like Red Hat's anaconda or the Sarge installer, both of which can be made to work with woody) for boot-floppies. We'll see how it goes, then. I'm scrambling as fast as I can to finish the backup so that I can get to work on it. I would still like to know how you looked up the info on which drivers were supported. Is that info from the net, or from your system? Which kernel does it refer to? Thanks again for your assistance, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Newbie first-time install advice: Highpoint Rocket 133SB
Paul E Condon wrote: I just Googled '5100b modem' and found: http://kbserver.netgear.com/kb_web_files/n101306.asp Reading these instructions, it seems to me that 5100b is a wanabe router, and that it seems to have all the functionality that you actually need. You can configure it by accessing it from your computer as if it were a web page at IP address 192.168.0.1 This is very standard behavior for a consumer oriented router box. I can't guarentee that it will work, but I would be very surprised if it didn't. Yes, when I received my DSL package from SBC in early August I did a bunch of researching myself. I found the manufacturer's website, which had some useful info. Even more useful was the FAQs and forums at dslreports.com. There I found explanations about how this modem works, including how it is different from previous DSL modems. Its onboard router is supposed to make it more convenient to use in general, especially when first setting up. I went to the IP address you referred to and copied all of the important info down, so that I would have it without having to look it up again later. The instructions that I'm reading concern turning off PPPoE, and really concern how to live with two 'routers' that both want to be addressed as 192.168.0.1 Your bigger issue is getting your ISP to actually turn on service. Don't get too tangled up in config issues until you have determined that they have started service. To do that, borrow a Windoze laptop and try to connect to internet. If they don't get you connected that way, they surely won't get you connected with Linux. At the moment, I'm still running the old WinME dinosaur. The SBC installation CD worked, but only after I turned the modem off and back on! (Somehow ME was not detecting that the modem was even attached to the NIC until I did that. I sent an email to SBC suggesting that they mention this as a troubleshooting tip, since I blew nearly an hour trying to figure out why all of the lights were good but the installer program still couldn't see it!) At any rate, my DSL account been activated and running very nicely for about 2 months. Thanks for the tips, though. Right now, I am most concerned about the Debian installer being able to figure out how to use the thing. If the installer can't figure it out itself, then I will have to come back here pestering people to find out what part of my configuration to change. I printed out a forum thread from somewhere in which some experienced user explained how to get it working. He fell short of providing details about what commands to run, so as a newbie I'm still a little bit in the dark about what commands to run and what configuration files to edit if I have trouble. For now all I can do is hope I don't have too much trouble, but I'm already in big trouble over the original subject of this thread: getting a device driver for my (unusual) hard drive controller! I think you may be able to have a LAN, if you want. Once you get things working with you 5100b and one computer, you get a 'hub' and install it between the 5100b and your first computer. For now, I don't have the need (or the physical room) for a LAN setup. I had to move the computer into a small bedroom near a phone jack for the DSL connection. The room is 8' x 10', and has 1500 - 2000 books -- my personal library... the ones that fit inside the house, that is! The desk and printer stand are maxed out, and I can't fit any more equipment in here even if I wanted to! I do have printouts on how to reconfigure my modem if I ever want to use a real router, though. But thanks for trying to help, anyway! (You wouldn't happen to know anyone who uses a Highpoint Rocket 133SB IDE controller with their big [137 GB] HD, would you? I need to talk to someone like that REALLY bad!!) Thanks, Dave W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Newbie first-time install advice: Highpoint Rocket 133SB
Stefan O'Rear wrote:
On Sat, Sep 25, 2004 at 10:57:23PM -0400, David Witbrodt wrote:
I would still like to know how you looked up the info on which drivers
were supported. Is that info from the net, or from your system? Which
kernel does it refer to?
It refers to kernel 2.6.0 beta 5.
I downloaded it, extracted it in ~/linux-2.6.0, and:
~ %% cd linux-2.6.0/
~/linux-2.6.0 %% grep -lri Highpoint .
} one minute and 41 seconds later (my system is slow)...
./drivers/ide/pci/hpt34x.c
./drivers/ide/pci/hpt366.c
./drivers/ide/pci/hpt366.h
~/linux-2.6.0 %%
Looking in drivers/ide/pci/hpt34x.c, I find this:
static char *chipset_names[] = {HPT343, HPT345};
and:
MODULE_DESCRIPTION(PCI driver module for Highpoint 34x IDE);
In drivers/ide/pci/hpt366.c:
char *chipset_nums[] = {366, 366, 368,
370, 370A, 372,
302, 371, 374 };
^
Looks like HPT302 support.
Beautiful!!
It looks same way to me, even though I am a newbie! ;-)
I sent a message to Highpoint asking about it. This info is quite
specific, and I can ask them directly whether the HPT366 driver is
backward compatible with HPT302 and will run the controller. If so,
that is going to save me a bunch of trouble. (Someday I'll be able to
actually DO the things I was worried I would have to do!)
If it is the kernels in the 3.6.x series that I need, then I may have
to use the Sarge netinst CD. The HILUX CD seems to have only 2.4.24,
and the Woody CDs are farther behind than that. I wonder if it is
possible, if the Sarge netinst CD gives me problems, to get an updated
kernel from backports.org and use it with one of these CD sets? I see
that kernels 2.6.6 and 2.6.7 are available there, but at this point
doing anything like that is probably way over my head
Thanks for everything,
Dave Witbrodt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I'm new to Debian and need advice
Hi, I'm in the process of backing up a decade's worth of old files I want to keep, burning to CD-R. Once finished, I plan to partition and install 4 OS's, including Debian. I have the CD from a book, Debian GNU/Linux 2.1 Unleased, but the kernel there is 2.0.36. From the reading I've done, especially the Large Disk HOWTO, this kernel won't work with my 40 Gb HD. It looks like I'll have to make boot floppies and download the rest, or have someone burn a CD for me. My first question is: will potato work with my 40 Gb HD, or do I need sid or woody? My second question is: even if potato would work, should I get sid or woody anyway? (It looks like most people are running the testing version even though it might crash more, right? Bear with me... I'm new to Debian... haven't even installed it yet!) Then, the computer that I just got was a gift, and it was packaged with a Riptide chameleon combo card with modem and sound on the same card. I've looked around and it looks like this card won't work with Linux, so I need to replace it. (It's crap anyway, so I'm going to replace it even if it is supported now.) So my third and fourth questions are: If you had to pick a new sound card, which would you pick? If you had to pick a new modem, which would you pick? Thanks, Dave W.
Re: I'm new to Debian and need advice
Kirk, Thanks for the response! I can't speak for most people, but I personally enjoy testing. It's not quite as stable as, well, stable, but I rarely encounter any significant errors. The benefit is that you get much newer versions of many of the packages. That helps. I will probably be installing the testing version, then. If you had to pick a new sound card, which would you pick? I've had great luck with Ensoniq PCI (ES1371 chipset) cards. They're very basic, but sound good and are well-supported by pretty much every OS in existence. By every OS, I wonder if you know whether DOS and OS/2 in particular are supported? If you had to pick a new modem, which would you pick? I have a Diamond Multimedia (was Supra when I bought it - before DiamondMM bought Supra) SupraExpress 56e external. It's truly an outstanding performer. Along those lines, pretty much all external modems will work without any special effort. Thanks. This has been a tough research project for me. I had hoped that an external USB modem would be an option, but apparently it isn't (at this time). This computer doesn't have a lot of room left inside the case, so I want an external modem, but there seems to be a lot of confusion about what will work and what won't work with Linux. I've noticed that the real modems (as opposed to Winmodems) cost significantly more. Hopefully the one I get will last for a while! Thanks again for your help, Dave W.
