I need to change the System Mainboard in an operational Athlon based SUSE LINUX 9.1 system. The new board used the same CPU but a different chipset. I'm wondering how I would be sure the replacement Mainboard is correctly adapted to the SUSE LINUX 9.1. I've not made such a hardware switch previously except to completely reinstall SUSE LINUX. I imagine this issue will arise the next time a system Mainboard fails. The SUSE install has an update option but it is not clear from the administrator's manual if that is intended to cover a Mainboard replacement situation. Thanks ahead of time for any light you may shed on this issue. John S. Wolter mailto:johnswolter@wolterworks.com
johnswolter@provide.net writes:
I need to change the System Mainboard in an operational Athlon based SUSE LINUX 9.1 system. The new board used the same CPU but a different chipset. I'm wondering how I would be sure the replacement Mainboard is correctly adapted to the SUSE LINUX 9.1.
I've not made such a hardware switch previously except to completely reinstall SUSE LINUX. I imagine this issue will arise the next time a system Mainboard fails. The SUSE install has an update option but it is not clear from the administrator's manual if that is intended to cover a Mainboard replacement situation.
I haven't actually done this sort of thing so treat the following as just a blather... :) I think the main issues, if any, are going to be in I/O area. Different motherboards may have different VGA controller chips, sound chips, ethernet chips, etc., and these may need to be reconfigured. If you normally boot to a KDE login screen, a different video chip may cause the screen to become invisible. So, you may need to boot into single-user mode (possibly also giving kernel parameters at the bootloader prompt to remove boot splash/reduce screen resolution) first and reconfigure XFree86 for the new chipset immediately after the board swap. You can then also at the same time run Yast (in text mode) to reconfigure all the other devices as needed. -Ti
On Tuesday 10 August 2004 11:54 pm, johnswolter@provide.net wrote:
need to change the System Mainboard in an operational Athlon based SUSE LINUX 9.1 system. The new board used the same CPU but a different chipset. I'm wondering how I would be sure the replacement Mainboard is correctly adapted to the SUSE LINUX 9.1.
Some time ago I had to switch out an ABIT board for an ELITE board to replace caps in the ABIT. With Suseplugger going I ripped out the old, put in the new and booted it up. Suse found all the stuff there and reconfigured what was needed, like the video etc. Later when I finished the board I did the switch again with no problems at all. My video is from a card so there was no need to make any changes there, If your video is on the mobo, you may have to run sax from INIT3 to configure the controller. I wouldnt hesitate to do it again. It's hard to screw up SuSE from my point of view. RA
I need to change the System Mainboard in an operational Athlon based SUSE LINUX 9.1 system. The new board used the same CPU but a different chipset. I'm wondering how I would be sure the replacement Mainboard is correctly adapted to the SUSE LINUX 9.1.
I've not made such a hardware switch previously except to completely reinstall SUSE LINUX. I imagine this issue will arise the next time a system Mainboard fails. The SUSE install has an update option but it is not clear from the administrator's manual if that is intended to cover a Mainboard replacement situation.
Thanks ahead of time for any light you may shed on this issue.
John S. Wolter mailto:johnswolter@wolterworks.com
On Wednesday 11 Aug 2004 05:54, johnswolter@provide.net wrote: the main rule for this is just do it Suse Linux will handle things for you without a problem unless you are planning to use extreemly strange or rarefied hardware that does not include modern MoBo's they all got no problem ,, like i say just do it . Pete. -- Linux user No: 256242 Machine No: 139931 G6NJR Pete also MSA registered "Quinton 11" A Linux Only area Happy bug hunting M$ clan PGN
Does anybody have experience with pam_mkhomedir? I want to mount home directories with NFS under /home/username, but I don't want to create home directories myself for all users in all machines (it is necessary in order to login using kde). I got mkhomedir to work with ssh - it created home, but ended the session (this is probably somekind ssh issue, it isn't important). But when logging in using kde, it does not find home... Any suggestions? There were some bugs with this if I remember correctly. /etc/pam.d/login: #%PAM-1.0 #auth requisite pam_unix2.so nullok #set_secrpc auth required pam_securetty.so auth required pam_nologin.so #auth required pam_homecheck.so #auth required pam_env.so #auth required pam_mail.so account required pam_unix2.so password required pam_pwcheck.so nullok password required pam_unix2.so nullok use_first_pass use_authtok session required pam_mkhomedir.so skel=/etc/skel umask=0022 session required pam_unix2.so none # debug or trace session required pam_limits.so
I read from smbmount manual pages: -- password=<arg> - specifies the SMB password. If this option is not given then the environment variable PASSWD is used. If it can find no password smbmount will prompt for a passeword, unless the guest option is given. -- How can I use this passwd variable? I login with user xxx and password yyy. Now I want to mount smth so that I don't have to enter username (possible) and password anymore... Is it possible?
On Wednesday 11 Aug 2004 10:24, Taavi Dovnar wrote:
Does anybody have experience with pam_mkhomedir?
I want to mount home directories with NFS under /home/username, but I don't want to create home directories myself for all users in all machines (it is necessary in order to login using kde). I got mkhomedir to work with ssh - it created home, but ended the session (this is probably somekind ssh issue, it isn't important). But when logging in using kde, it does not find home... Any suggestions? There were some bugs with this if I remember correctly.
/etc/pam.d/login: #%PAM-1.0 #auth requisite pam_unix2.so nullok #set_secrpc auth required pam_securetty.so auth required pam_nologin.so #auth required pam_homecheck.so #auth required pam_env.so #auth required pam_mail.so account required pam_unix2.so password required pam_pwcheck.so nullok password required pam_unix2.so nullok use_first_pass use_authtok session required pam_mkhomedir.so skel=/etc/skel umask=0022 session required pam_unix2.so none # debug or trace session required pam_limits.so
Whats with this hijacking of the thread again .. do it right start a new thread. -- Linux user No: 256242 Machine No: 139931 G6NJR Pete also MSA registered "Quinton 11" A Linux Only area Happy bug hunting M$ clan PGN
Peter, On Wednesday 11 August 2004 04:37, peter Nikolic wrote:
On Wednesday 11 Aug 2004 10:24, Taavi Dovnar wrote:
Does anybody have experience with pam_mkhomedir?
...
Whats with this hijacking of the thread again .. do it right start a new thread.
The usual excuse I'd get when I asked people about this is that hitting reply is the easiest way they know to get the proper "To" address in the new message. Those people surely do not use mailers that track topic threads. One of the things I like about KMail is filter-driven header deletion. I have a filter (configured for manual activation only, of course, and assigned to the main KMail window's Message menu) that removes the "In-Reply-To" and "References" headers. This severs the thread links in the inappropriate reply, moving it to the top of the thread hierarchy. Replies to that message follow it just as you want. Randall Schulz
* Randall R Schulz
One of the things I like about KMail is filter-driven header deletion. I have a filter (configured for manual activation only, of course, and assigned to the main KMail window's Message menu) that removes the "In-Reply-To" and "References" headers. This severs the thread links in the inappropriate reply, moving it to the top of the thread hierarchy. Replies to that message follow it just as you want.
Fine for your *personal* use and for posts following yours, but does not help someone trying to solve their own problems utilizing the list archives :-( ... -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos
Patrick, On Wednesday 11 August 2004 08:56, Patrick Shanahan wrote:
* Randall R Schulz
[08-11-04 09:08]: One of the things I like about KMail is filter-driven header deletion. I have a filter (configured for manual activation only, of course, and assigned to the main KMail window's Message menu) that removes the "In-Reply-To" and "References" headers. This severs the thread links in the inappropriate reply, moving it to the top of the thread hierarchy. Replies to that message follow it just as you want.
Fine for your *personal* use and for posts following yours, but does not help someone trying to solve their own problems utilizing the list archives :-( ...
Nope. Clumsy users hamper utility of public resources for all. I've always been fond of keeping my own archives of lists to which I subscribe, since on-line searching tends to be pretty limited. Even Google is not ideally suited to mailing lists--it's never (or rarely) totally up-to-date, and given the narrowness of the topics on mailing lists, it can be hard to pin-point what you're looking for without something like regular expressions and successively refined searches. Randall Schulz
-- Patrick Shanahan
I want to mount home directories with NFS under /home/username, but I don't want to create home directories myself for all users in all machines (it is necessary in order to login using kde). I got mkhomedir to work with ssh - it created home, but ended the session (this is probably somekind ssh issue, it isn't important). But when logging in using kde, it does not find home... Any suggestions? There were some bugs with this if I remember correctly.
/etc/pam.d/login:
It was necessary to modify /etc/pam.d/xdm, now it works nicely.
On Wednesday 11 August 2004 10:13, peter Nikolic wrote:
On Wednesday 11 Aug 2004 05:54, johnswolter@provide.net wrote: the main rule for this is just do it Suse Linux will handle things
Actually, the main rule here is backup anything you couldn't handle losing. It's that one in a million chance that bites you in the ass one in ten times.
for you without a problem unless you are planning to use extreemly strange or rarefied hardware that does not include modern MoBo's they all got no problem ,,
like i say just do it .
Pete.
-- Steve Boddy
John, On Tuesday 10 August 2004 21:54, johnswolter@provide.net wrote:
I need to change the System Mainboard in an operational Athlon based SUSE LINUX 9.1 system. The new board used the same CPU but a different chipset. I'm wondering how I would be sure the replacement Mainboard is correctly adapted to the SUSE LINUX 9.1.
I've not made such a hardware switch previously except to completely reinstall SUSE LINUX. I imagine this issue will arise the next time a system Mainboard fails. The SUSE install has an update option but it is not clear from the administrator's manual if that is intended to cover a Mainboard replacement situation.
Thanks ahead of time for any light you may shed on this issue.
I recently did just this: New motherboard, new CPU everything else unchanged. As others have stated, Linux just adapts. The first time you log in, you'll be notified that new hardware was detected and asked if you want it to be configured. Say "yes," of course. There can be several such notifications (USB, Ethernet, sound, on-board disk controllers, etc.) There is one exception to this, that I'm aware of: If you've created a custom kernel that is not as generic as the ones included in the distribution, you may not be able to use it to boot the new system. This is most likely to happen if what you customized in the kernel and then changed in the system is the CPU type. Also, as someone else mentioned, if the graphics / video hardware changed, then you'll likely see a stock-sized (is that 640x480 or 600x400?) screen resolution until you can configure the video parameters for the new card or chip. If you're using the "lm_sensors" package, you'll need to re-run "sensors-detect" and allow it to create a new sensor configuration. This is an interactive process (but not a GUI), so just answer the questions to the best of your ability. Defaults are probably fine. Good luck. You probably won't even need much!
John S. Wolter mailto:johnswolter@wolterworks.com
Randall Schulz
participants (8)
-
johnswolter@provide.net
-
Patrick Shanahan
-
peter Nikolic
-
Randall R Schulz
-
Richard
-
Stephen Boddy
-
Taavi Dovnar
-
ti@amb.org