It seems like Grub.cfg is also using proper drive by UUID.
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-amd64' --class debian
--class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set dec79ed9-b96a-47e4-81f0-7e32735b5057
echo 'Loading Linux 2.6.32-5-amd64 ...'
linux /vmlinuz-2.6.32-5-amd64 root=/dev/mapper/xxxxxxxx-root ro quiet
echo 'Loading initial ramdisk ...'
initrd /initrd.img-2.6.32-5-amd64
But somewhere in a boot process system shows:
FSCK from Util-Linux-ng 2.17.2
unable to resolve UUID=".....5b5057
(I'm not sure which log after start it would be in :)
It seems as the "after system is starting to load" the UUID is not
resolved and /dev/sda and /dev/sdb get loaded incorrectly ?
Thanks,
Lucas
On Fri, Oct 29, 2010 at 10:10 AM, Lukasz Szybalski <szybal...@gmail.com> wrote:
> What I don't understand is that in squezze the fstab shows:
>
> /etc/fstab
>
> # /boot was on /dev/sda5 during installation
> UUID=dec79ed9-b96a-47e4-81f0-7e32735b5057 /boot ext2
> defaults 0 2
> # /boot2 was on /dev/sdb1 during installation
> UUID=bb0512c5-6de6-4164-a7af-4312a4718ce3 /boot2 ext2
> defaults 0 2
>
> Which means system figured out that the sda and sdb swapped, and used
> the UUID to mount the folders, but why am I still getting the "fsck"
> failed? Is that happening during boot, and fstab is not involved. If
> that's the case which file needs to be modified? I would figure that
> the same process that updated fstab would update the other file? (Is
> the other file a grub file or?)
>
> Thanks,
> Lucas
>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
