I'm about to change the m/board/CPU/RAM on my PC, while everything else will stay the same.

Is it possible to reboot aptosid without needing to re-install? If so, what steps are needed for a successful reboot?

I will not use the on-board sound nor any form of RAID, nor on-board graphics.

The obvious thing I can think of is the need to re-generate the persistent udev rule entries for the onboard network interface, i.e just comment out the old ones. The other thing I can think of is the possible need to re-generate the initramfs. Something like:

I think the persistent udev data is the only think you normally have to deal with (and even that isn't vital if you don't mind having say eth1 and no eth0).

In general, but not in your case by the sound of it, the only other common concern might be any custom xorg configuration if you were changing graphics card or monitor(s), though that can usually be easily be fixed by booting straight into run-level 3 and then just moving any xorg.conf or xorg.conf.d snippets out of the way before continuing to run-level 5.

You don't seem to do that, but in case another one stumbles upon this thread: If you change harddrives, keep in mind to change the UUID(s) in /etc/fstab! Grub needs to be updated, too, so it knows which harddisk/partition root is on.

Regarding xserver: By default xserver-xorg-video-all and xserver-xorg-input-all are installed on your system, but they might be removed in the meantime by you. Just make sure you have at least the needed video-driver installed.

Just think about this: If it would be hard to move a linux system from one hardware piece to another, how would a livecd work?

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor

I have successfully moved a Linux install to a new mobo in the past and the same cannot be said about Windows

snvv

Post subject:Posted: 30.11.2011, 15:36

Joined: 2010-09-13
Posts: 331

Status: Offline

I did that a few days ago.

I moved a HD with aptosid from a PC with burned motherboard to a new and totally different PC and it runs happily

Regards
snvv

krisbee

Post subject:Posted: 03.12.2011, 09:32

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

Thanks for everyone's input. Point taken about LiveCDs, and of course Linux is superior to Windows in so many ways.

Anyway, the job is done without a hitch and just the udev net rules to fix. The comment about /etc/fstab reminded me the simplest way to do this was to use an aptosid LiveCD and copy the udev net rules from there.

I have just to opitmise the BIOS settings now, particularly the system voltages as the Phenom II x4 960T is not behaving as expected and it looks like I might have to use K10stat to get as I want. For now, it is undervolted and idles at 1.12Vcore 800MHz and can run at 3000MHz with a Vcore of 1.25V. It seems to run cool and quiet.

If you rename /etc/udev/rules.d/70-persistent-cd.rules it gets regenerated, but how would you do the same for 70-persistent-net.rules, instead of just editing the interface names in the file and commenting old hardware, or copying it from the liveCD generated version?

krisbee

Post subject:Posted: 04.12.2011, 08:34

Joined: 2011-04-25
Posts: 49
Location: London
Status: Offline

alexk wrote:

If you rename /etc/udev/rules.d/70-persistent-cd.rules it gets regenerated, but how would you do the same for 70-persistent-net.rules, instead of just editing the interface names in the file and commenting old hardware, or copying it from the liveCD generated version?

A good question, and since you asked I found some answers on the web, but cannot say if they work or which is the best approach.

slh

Post subject:Posted: 04.12.2011, 15:00

Joined: 2010-08-25
Posts: 954

Status: Offline

Don't rename these files (they stay in the way and may interfere seriously), delete them (they'll be regenerated anyways).

DeepDayze

Post subject:Posted: 04.12.2011, 15:30

Joined: 2010-09-11
Posts: 616
Location: USA
Status: Offline

slh wrote:

Don't rename these files (they stay in the way and may interfere seriously), delete them (they'll be regenerated anyways).

What about *moving* the files to your home directory if you just want to have the security of a backup in case something goes awry?

DonKult

Post subject:Posted: 04.12.2011, 20:31

Team Member

Joined: 2010-09-02
Posts: 485

Status: Offline

DeepDayze wrote:

slh wrote:

Don't rename these files (they stay in the way and may interfere seriously), delete them (they'll be regenerated anyways).

What about *moving* the files to your home directory if you just want to have the security of a backup in case something goes awry?

Obviously you can do that - it's your machine, do what you want -, the sense behind a backup of non-working files is just not that obvious, at least for me, but as you please…

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor

alexk

Post subject:Posted: 04.12.2011, 22:19

Joined: 2010-10-01
Posts: 288

Status: Offline

DonKult wrote:

DeepDayze wrote:

What about *moving* the files to your home directory if you just want to have the security of a backup in case something goes awry?

Obviously you can do that - it's your machine, do what you want -, the sense behind a backup of non-working files is just not that obvious, at least for me, but as you please…

I deleted my old persistent-cd.rules file and edited the persistent-net.rules file. Never a problem keeping a backup in a non-system folder, of course. May also come in handy if you put removed hardware back in a machine. I still don't know how to generate a persistent-net.rules file automagically.

dpt

Post subject:Posted: 11.12.2011, 09:16

Joined: 2010-09-11
Posts: 281
Location: New Delhi
Status: Offline

I would reinstall.
To have fresh & clean OS and save time.

Have a nice day.

dpt

_________________In a lunatic asylum, everyone thinks that he is the doctor.