Originally Posted by kainosnous
The only two places that your boot process should be looking for a UUID (that I can think of) is from fstab or grub. Until I had the system working correctly, I would try to just use /dev/sda2. Actually, I would suspect that the old grub file isn't even accessed, but instead the grub config file from your primary OS on sda1, and so it shouldn't have your old information in it?
I suspect fstab. Could you show us your fstab? Also, at which part of the boot process does it hang?
Don't try to change the links in /dev as they should be recreated at boot anyway.
So ... I first tried your suggestion of using /dev/sda2 in the fstab. Not sure if that's the /exact/ thing that fixed it, but it's going now! I still have no idea where it was getting the old uuid (I didn't change the old uuid to a new one anywhere else), but it's OBE now. Thanks for the suggestion!
New weird issue is with Grub2. I've had this issue before and am simply not sure what causes it. (it's not related to this thread, but I'll mention it anyway)
When Grub2 detects the other linux partition, it likes to try and use the linux root from the first partition (sets the root uuid to sda1 when booting to sda2), which has the unhappy side effect of simply booting to sda1. So I went in and manually changed it in grub.cfg (I know you're not supposed to really do that). Now grub no longer writes to that file during grub-install. I have to do a grub-mkconfig and copy those contents over grub.cfg (after editing the uuid).
Weird, but workable.