Yes, the grub-install should set partition boot flag so that it is capable of booting. You may need to confirm this using fdisk/parted/whatever to ensure it really did everything necessary. Running the same command a second time shouldn't do anything if it's already set properly.
I also personally never got the hang of UUID values for booting and might suggest that you archive the /etc/fstab and use partition names instead to see if that helps debug anything. Additionally, you may want to enable verbose boot with grub2 and see what that gives you when trying to boot from /dev/sdb1, and where it derails. Lastly, what does the BIOS/EFI say is the order of the two drives? If one is the master and the other the slave, that might also be stomping on you, but not knowing anything about the laptop, I can't help you beyond that. dafr NOTE: The brain has ceased functioning earlier this evening. Please exercise due diligence and research my statements before blindly acting on them. On 12/16/2013 07:41 PM, John Jason Jordan wrote: > People at yesterday's Clinic saw my new System76 Bonobo Extreme > computer. > > The computer has two 2.5 inch hard drive bays and two mSATA drive > slots. I ordered it with one 1 TB Seagate hybrid drive, on which I > installed Xubuntu 13.10 in a 100 GB partition (SDA1) and /home in a 300 > GB partition (SDA2). The remainder of the drive is unused free space. > > I also ordered a 480 GB mSATA SSD drive, which we installed at the > Clinic, which Linux recognizes as SDB. We created a 100 GB partition > (SDB1) and a 380 GB partition (SDB2), intending to use Clonezilla to > clone the partitions on SDA to the new partitions on SDB. > > Clonezilla did its thing and SDB1 and SDB2 are now identical to their > counterparts on SDA, that is, identical EXCEPT that I cannot boot to > SDB1. With Keith's help we determined that the initial part of SDA1 has > stuff that SDB1 lacks, which is no doubt the cause of the problem. > > The UUID numbers for the drives are the same: > > /dev/sda1: UUID="0c9621bb-ec81-43f3-85c5-16c3d12d500a" TYPE="ext4" > /dev/sda2: LABEL="Home" UUID="2cdd7cc1-03f6-4f98-87a4-cd11ac08c617" > TYPE="vfat" > /dev/sdb1: UUID="0c9621bb-ec81-43f3-85c5-16c3d12d500a" TYPE="ext4" > /dev/sdb2: LABEL="Home" UUID="2cdd7cc1-03f6-4f98-87a4-cd11ac08c617" > TYPE="ext4" > > ----------- > Note: I see that SDA2 is VFAT. I don't know how that happened. But the > entire SDA disk will ultimately be reformatted as one partition for > random storage, as soon as I get SDB working as the boot drive, so for > now it's irrelevant. > ----------- > > Also, /etc/fstab on SDA1 and SDB1 are identical, as > are /boot/grub/grub.cfg. > > Initially after using Clonezilla any attempt to boot to SDB would just > hang. However, on the Ubuntu forums I found a suggestion to use: > > sudo grub-install /dev/sdb > > And afterward it no longer hangs when I select SDB to boot to. > Unfortunately, the boot proceeds on SDA, not SDB. It would be > interesting to see what would happen if I physically removed SDA from > the computer, but I haven't tried that yet. > > I think the problem is somehow conglomerated with the UUID > numbers, /etc/fstab, and /boot/grub/grub.cfg, but I'm not sure how to > fix it. I do know that I can use tune2fs to generate a new random UUID > for a device. But I don't know if that is the solution, or which device > to give a new UUID to, or what changes to make to grub.cfg and fstab > after doing so. > > It would be helpful if someone with more brains than me would give me > some pointers here. > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
