Friday, October 1, 2010
ubuntu Desktop live CD and fakeRAID-1
FakeRAID howto
RAID-1
![/!\](https://help.ubuntu.com/htdocs/ubuntunew/img/alert.png "/!\"){kind=small}
You should be aware that dmraid (especially the dm-raid1 target of the device mapper) currently (including kernel version 2.6.17) supports the mirroring with RAID-1, but it has no error handling. When a block on one disk fails a failure reaches up to the application level, currently it doesn't try to read from the second disk. It only mirrors all data to the second disk.So it secures the system from data loss, but the system can nonetheless crash. There exists patches for the 2.6.17 kernel series which enables a higher read speed and error handling in failure case, but until now they are not incorporated.
External links regarding RAID-1: Running Ubuntu On a Fakeraid/1 array described how to adapt the original HOWTO to a RAID-1 (mirroring) array.
Ubuntu 9.10 ( Karmic Koala)
The automatic installer may or may not work out of the box. When I tried it, it didn't work the first time and I had to manually install dmraid. But it did work the second time on the same machine, (with disks that had been wiped) The problem appears to be installing grub2
Use the LiveCD method
* Boot the system with the Live CD
* Run the partitioner program gpartd (System->Gpart)
9.10 loads dmraid automatically so you should see for a disk device
/dev/mapper/pdc_feddabdf or some suchlike
if dmraid detected and can use a fakeraid partition
* Setup an extended partition using whatever space your going to allocate for Ubuntu or the entire drive. Setup a minimum of 2 logical partitions in the extended partition, the first will be formatted ext4 and the last swap. Set the type on the swap partition to swap. Format the first partition. Exit gpart
* Run the installer. When it gets to it's partitioner, change the mount point on the first partition to / DO NOT format it! Do NOT make any partition changes! The installer partitioner does not understand dmraid partitions properly
* In the installer summary screen right before the copy process starts, click the Advanced button. Change the boot partition (this is the MSDOS-style "parent" partition not the Linux partitions) to /dev/mapper/pdc_feddabdf (or whatever dmraid lists as your fakeraid partition) Make sure the checkbox is clicked to boot from this disk. note that the installer will modify grub2 to point to the correct logical partition /dev/mapper/pdc_feddabdf1 or whatever / is on.
* When the installer finishes DO NOT REBOOT, the new system will be mounted on /target. If you rebooted then run the terminal screen and mount the /dev/mapper/pdc_feddabddf4 (root) partition (this is the target the installer put the root on) on some convenient directory (/tmp/tmp or some such) chroot that directory (/target or whatever it's mounted on)
* Run the command "apt-get install dmraid" If your lucky you will get a message back saying that the system didn't need to do anything as the installer will have correctly built initrd for grub to include dmraid. Otherwise this will update dmraid and rebuild the grub init to load dmraid. Exit the terminal and click reboot, or type "shutdown -r now" at the terminal window
* When the system comes back up login and verify that /dev/mapper/pdc_feddabdf (or whatever dmraid names your fakeraid) exists, and use df to verify that the system is mounted on it. (it will say it at the top)
tecnicambalandia ...dmraid-on-ubuntu
use Clonezilla, a software especially made to copy partitions and entire drives.
GParted and RAID
Source
RAID stands for Redundant Array of Inexpensive Disks. This is a solution where several physical hard disks (two or more) are governed by a unit called RAID controller, which turns them into a single, cohesive data storage block.
An example of a RAID configuration would be to take two hard disks, each 80GB in size, and RAID them into a single unit 160GB in size. Another example of RAID would be to take these two disks and write data to each, creating two identical copies of everything.
RAID controllers can be implemented in hardware, which makes the RAID completely transparent to the operating systems running on top of these disks, or it can be implemented in software, which is the case we are interested in.
There are quite a few RAID schemes, known by numbers and names, such as RAID 0, RAID 1, RAID 5, and others. You may also have heard of RAID striping and mirroring, which are names for RAID 0 and RAID 1, respectively.
If you're interested, Wikipedia has a very nice article on the subject.
RAID is interesting, because we can no longer use physical disks and partitions as units of measure. Instead, we have a higher level of hierarchy instead, defining how the devices should be called. If you remember this important fact when setting up RAID, it will be much easier for you to understand the concept.
RAID devices in Linux are denoted by letters md followed by a single letter. For instance, md0, md1, md6, these are valid examples for RAID devices. There is no strict relation whatsoever between md devices and physical hard disks and their partitions.
For example, md0 could be a RAID 0 device, spanning physical sda1 and sdb1 partitions. It could also be a RAID 1 device, spanning physical sda1 and sdb2 partitions. In both cases, the device name would remain the same, while the physical topography underneath would be different.
Here's an example:
We can see that GParted does not display RAID (md) devices, but it does identify them. The RAID partitions are marked with the raid flag (more about those later).
One thing worth noting is that on sda6, GParted is unable to recognize the filesystem. This is because the RAID configured on that partition is such that sda6 does not provide all the information on the filesystem used, preventing GParted from properly classifying the partition. We're using RAID 0, known as striping on sda6 (and sdb6), which converts these two partitions into a single device. Therefore, each partition contains only half the information, hence deciding on what data is contained cannot be deducted from just looking at a single partition in the pair.
This should not bother you, as it's perfectly all right. However, you should remember that this can happen - and know what it means. We will talk about this in great detail in a dedicated tutorial.
Another example, this time using the command-line utility fdisk, here's what a RAID layout might look like:
Notice the Linux raid autodetect filesystem. This means that partitions sda1 and sdb1might be used in a RAID configuration. What and how exactly, we will focus on that in a separate article.
Another useful command for checking the status/presence of RAID devices on the system is the /proc/mdstat command:
For example, on the system above, we have three RAID devices, md0-2, each containing a pair of devices in a Mirror configuration, also known as RAID 1. Again, do not get flustered if you find this short sub-section too technical. A separate tutorial will explain RAID in detail.
While GParted can identify RAID devices, it cannot create or fail them. To this end, you will have to use other utilities. For now, though, it is important that you understand what RAID is what it looks like, so you can properly identify the layout and change it accordingly if needed.
This has caused quite a stir among the Acronis True Image users who happen to dual boot Windows and Linux and like to use their product to create system backups of both their operating systems.
The solution to the problem is very simple.
First, we need to check what our filesystem currently uses. This is done using the tune2fssystem utility.
Let's see what we get on our Ext3 filesystem formatted by GParted (our sdb5 from earlier):
We have the Inode size: 256. Not good. We won't be able to use Acronis. So we need to change the size. This can be done using the mke2fs formatting utility for Ext2-based filesystems.
Indeed, if we check again:
Our Inode size is good now. In general, I recommend all dual-boot users, especially those fond of imaging, to perform these steps manually on all partitions they intend to use for Linux and image from Windows and/or using a Windows-based program like Acronis.
That's about it.
We now know the ins and outs of partitioning and working with GParted. Congratulations!
Now, for some extras ...
Advanced tasks
This section is not strictly related to GParted. It's more of a bonus appendix, showing you a number of useful tricks that can enhance your partitioning skills. Here, though, we will have to leave the GUI behind and work with command line tools.Change the Inode size
Inodes are data structure units that regulate how the filesystem will treat directories and files residing on it. A filesystem with small inodes will be able to house a very large number of files, but it won't have the best read/write performance. A filesystem will large inodes will be more suited for I/O throughput, but it won't be able to store too many files on it. Whatever the need, changing inodes cannot be done through the GParted GUI.Why should you care?
That's a good question. Why would anyone be interested in changing the defaults set by the filesystem. Well, it turns out that some imaging software, like Acronis True Image, can only work with Linux filesystems that use inodes of the 128-byte size. However, some modern distributions, like Ubuntu 8.10 Intrepid Ibex, use 256-byte inodes, thus making the software unusable with this Ubuntu release.This has caused quite a stir among the Acronis True Image users who happen to dual boot Windows and Linux and like to use their product to create system backups of both their operating systems.
The solution to the problem is very simple.
First, we need to check what our filesystem currently uses. This is done using the tune2fssystem utility.
(sudo) tune2fs -l /dev/ | grep "Inode size"
The above command polls the filesystems on the relevant /dev/ device for information. The grep command merely extracts the specific bit we need.Let's see what we get on our Ext3 filesystem formatted by GParted (our sdb5 from earlier):
We have the Inode size: 256. Not good. We won't be able to use Acronis. So we need to change the size. This can be done using the mke2fs formatting utility for Ext2-based filesystems.
(sudo) mke2fs -j -I 128 /dev/sdb5
This will format the sd5 device as Ext3 filesystem (-j flag) with Inode size 128 (-I flag).Indeed, if we check again:
Our Inode size is good now. In general, I recommend all dual-boot users, especially those fond of imaging, to perform these steps manually on all partitions they intend to use for Linux and image from Windows and/or using a Windows-based program like Acronis.
That's about it.
We now know the ins and outs of partitioning and working with GParted. Congratulations!
Now, for some extras ...
Linux: zeroing the MBR
Source
My bootloader of choice is always grub, however some installations use lilo and the method I often use to remove lilo is to zero the MBR. Now I have read on LQ that if I use the following command the boot code will be zero'd but the partition table remains intact :
Whereas
will zero everything including the partition table record.
That second command erases the partition table and fdisk will report that the disk has no partitions.
When trying to install GRUB to re-write over LILO I was getting L99 99 99 99 99 errors on boot up. When I done a hexdump to view my MBR it showed that fragments of LILO were still installed. The way I eventually got grub to install properly was to zero 446 bytes and then re-install it. I was installing SLAX on a spare partiton and it uses LILO as the bootloader and gives you no alternative but to load it into the MBR of hda and not in any specified partition.
With all 512 bytes to 0, it must show the entire disk as unallocated space. Data aren't erased, so you could perhaps restore the deleted partitions using "testdisk".
But, if you put all the MBR to 0, then the disk label is deleted too.
On my system, I just made a label using "e2label". Using dd, I found this in the 3rd sector of the partition**---nowhere near the 1st sector / MBR.
**specifically, at an offset of OX478 from the start of the partition. This is in the 63-sector zone that precedes the start of the real partition data.
That’s because labeling a partition has nothing to do with the MBR. It is filesystem-specific (in this case ext2/3) and will undoubtedly affect whatever partition in which your filesystem resides.
As for masterclassic’s suggestion of using testdisk, you might instead backup and restore the partition table (and only the partition table).
It is this last that I mean, the last 2 bytes, that make the system to understand that the disk is formatted for an intel architecture, or for spark architecture, or for power-pc, & so on. This is the "msdos signature", usually needed for Linux/x86. This means that the partition table has this specific structure of 4 primary partition entries.
I think that most manufacturers now sale their disks with this signature already written. Obviously, if we install Linux or another system on an empty disk, it writes this signature in order to proceed to the disk partitioning and format.
Of course, I always prefer to backup the MBR before any partitioning work, rather than recovering
Testdisk is a tool we can use if something goes wrong. It is contained in several live cds, as in Gparted livecd (from the terminal), and I think in the Ultimate Boot cd.fdisk -l
My bootloader of choice is always grub, however some installations use lilo and the method I often use to remove lilo is to zero the MBR. Now I have read on LQ that if I use the following command the boot code will be zero'd but the partition table remains intact :
Code:
# dd if=/dev/zero of=/dev/sda bs=446 count=1
Code:
# dd if=/dev/zero of=/dev/sda bs=512 count=1
That second command erases the partition table and fdisk will report that the disk has no partitions.
When trying to install GRUB to re-write over LILO I was getting L99 99 99 99 99 errors on boot up. When I done a hexdump to view my MBR it showed that fragments of LILO were still installed. The way I eventually got grub to install properly was to zero 446 bytes and then re-install it. I was installing SLAX on a spare partiton and it uses LILO as the bootloader and gives you no alternative but to load it into the MBR of hda and not in any specified partition.
With all 512 bytes to 0, it must show the entire disk as unallocated space. Data aren't erased, so you could perhaps restore the deleted partitions using "testdisk".
But, if you put all the MBR to 0, then the disk label is deleted too.
On my system, I just made a label using "e2label". Using dd, I found this in the 3rd sector of the partition**---nowhere near the 1st sector / MBR.
**specifically, at an offset of OX478 from the start of the partition. This is in the 63-sector zone that precedes the start of the real partition data.
That’s because labeling a partition has nothing to do with the MBR. It is filesystem-specific (in this case ext2/3) and will undoubtedly affect whatever partition in which your filesystem resides.
As for masterclassic’s suggestion of using testdisk, you might instead backup and restore the partition table (and only the partition table).
| "disk label" i) The id bytes that Windoze stuffs in there (and the rest of the world ignores), or ii) the "signature" bytes at the end (last 2 bytes) of the first sector. |
I think that most manufacturers now sale their disks with this signature already written. Obviously, if we install Linux or another system on an empty disk, it writes this signature in order to proceed to the disk partitioning and format.
Of course, I always prefer to backup the MBR before any partitioning work, rather than recovering
Testdisk is a tool we can use if something goes wrong. It is contained in several live cds, as in Gparted livecd (from the terminal), and I think in the Ultimate Boot cd.fdisk -l
Update from MS
For Windows 2k3 spanish
update.microsoft.com/windowsupdate/v6/default.aspx?ln=es
The Microsoft Baseline Security Analyzer provides a streamlined method to identify missing security updates and common security misconfigurations. MBSA 2.1.1 is a minor upgrade to add support for Windows 7 and Windows Server 2008 R2.
update.microsoft.com/windowsupdate/v6/default.aspx?ln=es
The Microsoft Baseline Security Analyzer provides a streamlined method to identify missing security updates and common security misconfigurations. MBSA 2.1.1 is a minor upgrade to add support for Windows 7 and Windows Server 2008 R2.
Subscribe to:
Posts (Atom)
LibreOffice
Firefox
OpenSUSE
