(04-28-2015, 08:35 AM)m654321 link Wrote: [ -> ]Thanks Goldfinger, thanks Rob...
I tried what you both suggested, but with no luck.
If you are stuck too, I may just go for a single OS (LL2.4) install and have windows in a VM for when I need it
Don't give up yet. I actually didn't expect those things to solve the problem -- I just wanted to eliminate various
possibilities to narrow it down.
Main thing I saw missing in the fstab file was that there is no entry for the "EFI System Partition". Assuming that your conversion to UEFI mode actually did work, (and from what you have answered, it did), there should be an entry for that partition in
fstab. Why it's not there now is a mystery? Anyway, I'm pretty sure that once you add an entry for it the boot problem will be solved.
-- Boot with live LL again and open a terminal.
-- Open
fstab as root with following command:
Code:
gksu leafpad /etc/fstab
--
Widen the size of the text editor window so that no lines wrap. Do that to
double-check that all lines beginning with "UUID=" are in fact one continuous line. Only reason I want you to check that is because when I copy/pasted your original one here, the "UUID=" line for the DATA partition entry had a carriage return after "ntfs-3g" forcing the rest of that entry onto a new line. That very well could just have been a quirk caused by the forum when you pasted it here and not something that is actually in your file on the computer. I just want you to check to be sure.
-- Add this missing 2-line entry for the EFI partition to the end of the file:
Code:
# EFI System Partition
UUID=6E57-A726 /boot/efi vfat defaults 0 1
-- Save file, close everything out and reboot. See if you can boot into installed LL now? (This time, I am expecting it to work.)
Assuming you can now boot into LL, take ownership of the mount point for DATA partition with this command in a terminal (substitute your real username):
Code:
sudo chown -R username: /mnt/DATA
If that command spits out an error message saying it can't set permissions right, redo it without the "-R" part of command. NTFS formatting doesn't set permissions like Linux formats (Ext4, Ext3, etc.), so it's possible the "-R" to recursively chown the subdirectories and files won't work. (I haven't toyed with NTFS in quite a while, so not sure whether you'll see any errors or not. Just covering bases.) In any event, once you change ownership of the mount point itself, you shouldn't have any problems accessing things.
(04-28-2015, 12:48 PM)m654321 link Wrote: [ -> ]... I should add to reply#11 above that I did not delete the folders in /home before attempting binding. I can't see from my notes whether I should have done this or not, or is that something one only does with sym-linking, the alternative to binding?
Deleting pre-existing Home folders is only necessary when using symlinks. If you didn't, then the symlink command would essentially be trying to create a second directory using the identical name as one that already exists -- and the command will fail.
When "binding", you're essentially re-mounting specific directories within the DATA partition to specific other locations within the file system -- in this case, to your Home directory. So, just like you needed a mount point (/mnt/DATA) for the DATA partition; you need mount points for the bound directories. Your current Home directories serve as those mount points. Eg.
/home/username/Documents becomes the mount point for
/mnt/DATA/Documents.
If you decided later that you want to add another folder (eg. "Miscellaneous") to the DATA partition and also have it show-up in Home, you'd need to make a folder named "Miscellaneous" in both
/mnt/DATA and
/home/username. Then remember to add an entry for the binding of it to your
bind-home.conf file in
/etc/init.