Difference between revisions of "Post-Install Hardware Changes"
| (14 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | {{ | + | {{NeedsUpdate}} |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | <b>Preliminary:</b> | + | =<b>Preliminary:</b>= |
| − | Swapping hardware in a Linux system such as Amahi/ | + | Swapping hardware in a Linux system such as Amahi (Fedora/Ubuntu) is very forgiving and simple for the most part. Amahi does depend, however, on having the eth0 network interface and your shares depend on having the right drives and SATA ports identified between hardware changes to avoid <i>lengthy</i> repair processes. Note that all of these apply mostly the same if you're running within a virtual machine. Some VM hypervisors abstract the parts enough that the OS will not notice new hardware and not rename it (eg: eth0 to eth1). |
| − | + | =Motherboard/ SATA-controller/ RAID-card= | |
| − | + | - you have no changes to make when booting back into Linux, which will just re-fit drivers to the new part. <br /> | |
| − | - you have no changes to make when booting back into | + | - It is VERY advisable though, to reconnect your drives in the same sequence they were before the swap of the motherboard/ sata-controller/ RAID-card..<br /> |
| − | - It is advisable though, to reconnect your drives in the same sequence they were before the swap of the motherboard/ sata-controller/ RAID-card..<br /> | ||
eg:<br /> | eg:<br /> | ||
before the part-swap<br /> | before the part-swap<br /> | ||
| Line 22: | Line 13: | ||
sata port 01 = sata drive sda<br /> | sata port 01 = sata drive sda<br /> | ||
..and so on.<br /> | ..and so on.<br /> | ||
| − | - In the BIOS/ UEFI, ensure that the boot sequence is also the same. <br /> | + | - In the BIOS/ UEFI, ensure that the boot sequence is also the same as before the upgrade or swap. <br /> |
| + | >> Finally, after replacing or even adding drives, run a 'greyhole -f' and a 'greyhole -l' as sudo in terminal to completely re-discover what you may have had in the greyhole storage pool. | ||
| − | + | <b></b><br /> | |
| − | + | =Network Card= | |
- you must ensure that the same ethernet device assignment stands as before the part swap. <br /> | - you must ensure that the same ethernet device assignment stands as before the part swap. <br /> | ||
| − | - If anything eth0 may become eth1 afterwards, so you will need to rename it to eth0 via the Network Manager in the | + | - If anything eth0 may become eth1 afterwards, so you will need to rename it to eth0 via the Network Manager in the desktop. You'll want to reboot to finalize changes. <br /> |
| + | - use your favourite command line editor and edit with sudo/su.. | ||
| + | $/etc/udev/rules.d/70-persistent-net.rules | ||
| − | + | which may look like this | |
| − | |||
| − | |||
| + | <pre># This file was automatically generated by the /lib/udev/write_net_rules | ||
| + | # program, run by the persistent-net-generator.rules rules file. | ||
| + | # | ||
| + | # You can modify it, as long as you keep each rule on a single | ||
| + | # line, and change only the value of the NAME= key. | ||
| + | # net device () (custom name provided by external tool) | ||
| + | SUBSYSTEM=="net", ACTION=="add", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" | ||
| + | </pre> | ||
| + | And notice the "eth0". If it is something else, make it eth0 and save the file and reboot. | ||
| + | <br /> | ||
| − | + | =CPU / RAM / video card= | |
| − | + | - no changes need to be done after boot. These drivers and modules should automatically load on a reboot of Linux VMs.<br /> | |
| − | < | + | - this is because the hypervisor is abstracting the CPU to the VM regardless. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | < | + | <b></b><br /> |
| − | |||
| − | </ | ||
Latest revision as of 00:52, 24 May 2016
|
Update Needed |
|---|---|
| The contents of this page have become outdated or irrelevant. Please consider updating it. |
Contents
Preliminary:
Swapping hardware in a Linux system such as Amahi (Fedora/Ubuntu) is very forgiving and simple for the most part. Amahi does depend, however, on having the eth0 network interface and your shares depend on having the right drives and SATA ports identified between hardware changes to avoid lengthy repair processes. Note that all of these apply mostly the same if you're running within a virtual machine. Some VM hypervisors abstract the parts enough that the OS will not notice new hardware and not rename it (eg: eth0 to eth1).
Motherboard/ SATA-controller/ RAID-card
- you have no changes to make when booting back into Linux, which will just re-fit drivers to the new part.
- It is VERY advisable though, to reconnect your drives in the same sequence they were before the swap of the motherboard/ sata-controller/ RAID-card..
eg:
before the part-swap
sata port 01 = sata drive sda
after the part-swap
sata port 01 = sata drive sda
..and so on.
- In the BIOS/ UEFI, ensure that the boot sequence is also the same as before the upgrade or swap.
>> Finally, after replacing or even adding drives, run a 'greyhole -f' and a 'greyhole -l' as sudo in terminal to completely re-discover what you may have had in the greyhole storage pool.
Network Card
- you must ensure that the same ethernet device assignment stands as before the part swap.
- If anything eth0 may become eth1 afterwards, so you will need to rename it to eth0 via the Network Manager in the desktop. You'll want to reboot to finalize changes.
- use your favourite command line editor and edit with sudo/su..
$/etc/udev/rules.d/70-persistent-net.rules
which may look like this
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# net device () (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
And notice the "eth0". If it is something else, make it eth0 and save the file and reboot.
CPU / RAM / video card
- no changes need to be done after boot. These drivers and modules should automatically load on a reboot of Linux VMs.
- this is because the hypervisor is abstracting the CPU to the VM regardless.
