To what i understand is:

Journalling helps u to recover corrupted data back to the previously synced to disk data from the buffer.

Any unclean reboot/reboot can cause this based on the runlevel scripts deployed by the Linux distro to make sure no data corruption. If we dont do that, there is a risk to the data integrity.

Also, it will always force a check, when ur ext3 is customized in such a way where after a period of time, u must do a force filesystem check.

Use tune2fs utility to check the ext3 filesystem for it's tuning info.

For ext3 to ext2, u dont have to do anything actually. U juz simply ignore the journal portion of data.

In other words, you juz need to mount your ext3 filesystem partitions as ext2 partition. Done.

But from ext2 to ext3, ur in big trouble......

You cant basically see this ext3 journal "files" as if it is a file.

It's not a file, but a metadata (stored in a defined data structure) in binary format which only the ext3 module itself can understand. Simply to say, if u want to know inside the meaning of it as equivalent to ur first 512bytes in the bootsector MBR, sorry to say that, it's quite tough, unless u have gone through the code and documentation of ext3 specs.

For 512bytes in MBR, we will need to refer to the documentation and specs right?

Same goes here for ext3 file system. I looked at the partimage.org sourced before which uses ext3 and other filesystems code and datastructure and how it is implemented. Probably u can take a look there too.

Hope that helps. Cheers.

Make sure u have a dedicated harddisk partition out of that disk space to install Ubuntu.

To hide ur password while u type, hide the command prompt input via:

# stty -echo

To turn back on the text input:
# stty echo

Hi, gaurav. We can't differentiate SAN disk using /dev/sdX device names as when the LUNs are provisioned. We will still see it as a /dev/sdX. Of course this is excluding the I-SCSI based storage luns. Which is obviously very straightforward to detect.

If you are using SAN storage. You will need to refer to your vendor documentation as it is very vendor specific. Some are even using their own device filenames. For example, an EMC san storage uses:

/dev/emcpowerX as their device file

However these device are accessible via their multipaths which can be /dev/sdX

Hope above explains if I answer u what u r looking for.

Also, if you dont have a vendor based software to detect your SAN disk (LUNs), or instead uses "multipath" tools which is open source utility. Then, u can see the device names via running:

# multipath -l

Alternatively, u can see these LUNs are detect and mapped using device mapper. (/dev/mapper/.... or /dev/disk/by-uuid or /dev/disk/by-name)

As for /proc/scsi/{your hba card type}, this is usable via kernel 2.4 (i.e RHEL3), but for kernel 2.6 (i.e SLES10) it will be in /sys/class/fc_host/{hba cards info here}

For Sendmail:
You should disable the masquerading in order to allow your domain sendmail specific host senders. And then, recompile the sendmail.mc file.

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch21_:_Configuring_Linux_Mail_Servers

Have you used uncompress command ?

--> uncompress your-file.Z

If *.Z is your extension in this case and it is using the LZ compression. If not, u can study using the file command.

# file your-file.Z

Remember, linux use extensions as an identifier for user only. In real linux, a file without a extension will still run accordingly by its application as those applications knows how to make full use of that file (be it a binary or a text file)

If the file is corrupted like Ricky mention, u can  verify by running "md5sum" on the original file and the copied file. To make sure the file did not get corrupted during transfer.
# md5sum original-file.z

# md5sum copied-file.z

I believe it is not that Linux have no proper or missing proper solution. It is just that we have a phenomena called "So Near Yet So Far"

The answer to using Linux/Unix commands is 1 simple principle that adheres to standards wisely is
--> Use the "man" and "info" tool.

Most of the times Linux tool developers will either document their sample commands in "man" page or "info" page.

# man find
or
# info find

You follow this principle, u dont need 2 waste effort googling around at all.

Ah a common problem when compiling a new kernel for a fresh start. Used to happen to me too on Red Hat based distros

1. What for is initrd.img?
Initial ramdisk  file is a binary file consists of a small kernel modules that you want to load before switching into your real root partition (ramdisk here as it runs on ur RAM). Red Hat always do this with for their filesystems (biasly referring to ext3 most of the time). So you will need 2 load kernel module (ext3) before VFS can use it mount that partition.

What for is bootspalsh. Can initrd.img be replace with bootsplash somehow?
Bootsplash is a new toy in your linux where when you boot your linux, you dont see those kernel log messages showing hardware detection but a nice splash screen with cool pictures and progress bar.

Bootsplash project tis here. I used to re-compile the kernel to support bootsplash on slackware.
--> http://bootsplash.org/Welcome_to_the_graphical_world_of_Linux

Why Command “make dep” answered that this is not necessary?
Depends on which kernel version you compile. And when u run it.
1. I presume u r compiling a kernel 2.6.x

2. If not you have just recompiled and ran once "make dep". So if you do so again without any change to existing binaries, you will get this message.

If you do not wish to use FQDN or hostnames to access your server (for example: mysql) you can just do so simply by using that server's IP address rather than the hostname.

There could be other factors that hit the server performance such as hardware and  OS tuning itself other than the misconfiguration of DNS itself. However, that is left to your hand as a sys admin to decide.

Owez read the man page dude

# man find

FYI

[root@rhel4 /]# find /root -name foo*
/root/foo2
/root/foo1
/root/foo*
[root@rhel4 /]#
[root@rhel4 /]#
[root@rhel4 /]# find /root -name foo\*
/root/foo2
/root/foo1
/root/foo*
[root@rhel4 /]#
[root@rhel4 /]#
[root@rhel4 /]# find /root -name "foo\*"
/root/foo*
[root@rhel4 /]#

Guys, FYI http://docs.fedoraproject.org/release-notes/f8/en_US/sn-Installer.html

1. Always use Maximum RPM tutorial as your refrence.

2. Use "rpmbuild" utility. Also if that source tarball comes with the RPM specfile "application-file.spec". Then, you are very luck. Else, you need to write one.

Take note that, normally if you use source RPM packages (i.e. app-1.2.3.src.i386.rpm)  from the distro itself. You are 100% lucky that it has already the spce files.

   Recommend LS
   Linux User Around