I know this person who I gave a laptop too far far away so I cannot do this with that laptop in my view. It had a 60GB 1.8" HDD, the size aprox of a zippo lighter. HP 2730p Elightbook, I could not get Linux on it to save my life with what I had to work with. So I gave/mailed it to him with Windows on it, then got me another LapTop HP 6930p Elightbook.

I've seen in an online buy stuff web page a conveter that is able to make a 1.8" into a 2.5" hdd.

if I was to stick that 1.8" into this laptop install Linux, then unplug it, then send it to him, and he plugs it into his LapTop will Linux still work as if it was installed in that laptop?

thanks...

It should work. I've done it before. Usually wlan0 for wireless is all that needs changing.

Keeeeeuuuuullllll Thanks ---

Usually the only time there is a problem is if the disk had a custom video driver added, and that interface doesn't exist on the laptop the disk is being installed in.

GOOD POINT: Thanks.

I know slackware has the big kernel that has, from what I understand, just about everything that is needed stuffed into it, so that it will start up on just about everything known to mankind that has a cpu.

if I could use that, or set it up to somehow to load the video driver that the other laptop has , as it is not that hard to find out what it is given we have the internet google search project in full swing.

then somehow have a work around so that it will work something like how slackware has it with different video drivers within it so that when it boots up the kernel will recognize the chip set then load the proper one needed.

got an idea on how to do that, seeings how you brought it up?

this way even though Slackware is not that hard to operate, I could look to maybe installing a different one, like Void perhaps - faster install of programs.

If the hard drive interface is the same, I don't see why it wouldn't, given that they're the same series notebook. As a precaution, I would set the fstab options to mount by UUID's, if you don't already. Far more robust than something like /dev/sda1...

Even if it doesn't work, it's definitely worth a try. I'd like to know how this plays out.

I'll think about it..

The only time I've seen problems with disks (this is on Fedora) it is due to the initrd containing UUIDs (usually for swap) that has to be modified. Now, cloning a disk will work, but that is because it also duplicates all the partitioning, UUIDs, filesystems, labels... everything.

Assuming this will be the only hard drive in the system, given that it's a notebook, the UUID's won't be a problem since the installer will make the initrd that goes on that drive. I doubt moving the drive to another computer will change a UUID.

I think I'd stay with the /dev/sda1 to play it safe, their is not that much of an performance hit as a result of it.

I was actually having problems with my own laptop and a second internal hdd I have in it. using UUID it kept losing the mount every time I booted it, so I changed it to /dev/sdb1 and never have problems with it mounting.

That sounds more like the fstab, since it is the second disk.

The problem occurs when you have another disk installed... It then depends on which disk responds to the controller first, and in the case where both respond identically (I have a pair), it then randomly switches between the two.

The only guarantee of identity is the UUID, or an assigned label to the filesystem. Neither of these work if the UUID or label happens to be duplicated.

In my experience, the position of a drive in the list is consistent and predictable, (sda, sdb, etc). I think it depends on what order the BIOS reports the drives to the bootloader (and subsequently the kernel). When I migrated the OS to my new SSD, I noticed that the drives were referenced by their model and serial numbers in the fstab. Same with the initrd IIRC.

There are several of ways to identify a filesystem and they all have their own pros and cons. GParted (and probably some similar programs) can generate a new random UUID without formatting the partition.

Nope. The Linux kernel scans the controllers in parallel. Whatever disk spins up first is given the first name. Since USUALLY this is the boot drive (it is already spun up) it gets /dev/sda. However, the second disk on the same controller can then start spinning up... but the first disk on the next controller starts spinning up first.. Thus, /dev/sdb gets used by that drive, unless for some reason it is a bit slow in which case the second drive on the first controller gets /dev/sdb.

In my case, I have 5 SATA connections... and two SAS (I would have had more, but the SAS controller is limited to 2TB drives, and I have 4 3TB drives). When I plug in the third disk, it becomes sdb, and the original sdb becomes sdc. Same thing happens doing the other SATA connections... The order is not exactly random - as it tends to repeat. But if I change manufacturing or have slightly different characteristics of a disk - they DO come up in a different order.

Quite. But that is also why using a UUID becomes reliable. You CAN force it, but it will get a unique ID by default.

That is what I have read on this other sight /dev/sda vs UUID - how using the old way can confuse the entire system and user if he has the system partitioned out spaning over seperate patrtitions. but I am only using one hard drive, with at the most 3 partitions.
all on the same hard drive. what chance would it be for the UUID to change itself if set up with UUID's on one computer, then removed and put into a different computer.

will that new (other) computer still understand what fstab is telling it ?

or would it be a better, and safer to change that to. seeings how this other person has no idea of what to do if something goes wrong in fstab. (or any of it actually)

I once swapped a harddrive that had a working LM install from a Samsung laptop to a Dell Inspiron, I think was the model, and the only thing that didnt work was the broadcom wireless card. I could have made it work by installing drivers for it, but I just bought a $15 Intel wireless-n card and put it in the Dell and was back to work in no time. Worked for me. Doing this in Windows will prompt you to re-enter your Windows activation key.