grub edited just the sdc to sdb to boot, no other changes made.
Copied fstab and grub.cfg to desktop
sudo update-grub
The fstab was unchanged (OK), and the grub.cfg had the UUIDs used instead of
the sdc devices, and the hd2 s were changed to hd1 s., correcting all the
problems.
diff below from th
Could you try booting the system ( press e at the grub prompt to edit
the stanza and correct the root= part ) and then run sudo update-grub
and see if that corrects it to use the UUID?
--
Grub Installer gets devices wrong when running from live USB
https://bugs.launchpad.net/bugs/384633
You recei
Correct.
It just occurred to me that a significant difference between the two installs
is that the usb flash sticks only have one partition. I have always had at
least two partitions on a hard disk (one for swap, plus the install partition,
plus any others).
--
Grub Installer gets devices wro
Ok, just to confirm now, when you install on a usb flash stick, grub.cfg
does not use the uuid on the linux line, but when you install to a usb
hard disk, it does?
--
Grub Installer gets devices wrong when running from live USB
https://bugs.launchpad.net/bugs/384633
You received this bug notifica
Recreated the problem of the sdc appearing on the linux lines in grub.cfg on an
install to a 4G Patriot xmini usb stick.
fstab was OK with the UUID used for /, sdc1 only appearing in a comment.
I did copy the /var/log files off the install media in case they might be of
interest.
Install sequence
Yes, I can recreate it.
I'll run a couple of Maverick installs tonight to some 4G sticks.
I'll use a Maverick created installer, and capture the grub.cfg, and fstab.
If I can, I'll grab the log files off the install media too.
--
Grub Installer gets devices wrong when running from live USB
https:
> Installs to 4G sticks seem to get the device and will not boot without
> editing the grub commands.
> Installs to a USB hard disk seem to get the UUID and will work for the first
> linux boot.
Hrm... the system should not be able to tell the difference between a
usb flash stick and a usb hard
We both agree the second grub file will boot linux. I doubt it will boot
windows, but don't care.
Look at the LINUX line from first grub.cfg file from a 4G stick install, four
lines cut out below:
set root='(hd2,msdos1)'
search --no-floppy --fs-uuid --set 0ddfb60a-4791-45c9-85ec-c13c42c459af
That config looks like it should work perfectly fine, have you tried it?
Again, it does not matter that the set root= line has the wrong drive
because it is followed by the search command which sets it by locating
the drive by UUID.
--
Grub Installer gets devices wrong when running from live USB
I found the original grub.cfg file from a USB hard disk install. It does use
UUIDs on the linux line, just the hdx references are wrong. This probably
would have booted Maverick successfully, but maybe not Windows, which does the
search with UUID, but used the bad hd1 for the drvemap. The fst
No, I have never edited any default files to produce the sdc on the
linux line. The problem is created by a pretty standard install, just
doing a manual partition because I am afraid if I answer yes to "use the
whole disk" the windows internal disk would be wiped out.
--
Grub Installer gets devi
The set root line tells grub where to look, and can be wrong, since it
is followed by the search line which has grub locate the disk by uuid.
The root= parameter on the linux line tells the kernel where to look,
and it should also be UUID, unless you have edited /etc/default/grub and
uncommented:
I do agree that if the UUID is used on the linux line, the "set root=" line to
the wrong hd2 will not stop the boot.
I have just done 4 quick Maverick USB installs, and I think I recall that not
all have had the sdc1 on the linux line. The install to a USB hard disk seemed
to only have the set
Certainly not the case with me. The root=/dev/sdc1 on the linux line overrides
whatever the search UUID did. I just did a fresh install from a 2G usb stick
created on a Maverick system with the normal desktop iso, to a 4G new pqi
stick. I captured the grub.cfg (bad), fstab (OK), and the /var/
The next line after the root should be a search command with the correct
UUID, so it does not matter if the device specified on the root line is
wrong. Is this not the case for you?
Also the comments referring to the device in /etc/fstab are just that;
comments don't matter.
--
Grub Installer g
This problem goes back to grub1, and grub 2 did not fix it entirely. UUIDs
helped, but they are not used for every disk reference. I use the normal
desktop gui install, from a 2G "live" usb, to a 4G usb target on a standard
Windows laptop, The created grub.cfg still has wrong device reference
Lucid and maverick should be using grub2, which should be using UUIDs to
work this out. There should be no device.map. Are you using the
alternate install or is this a normal desktop gui install? Can you
attach your /boot/grub/grub.cfg and /etc/fstab?
** Changed in: grub-installer (Ubuntu)
Maverick usb install media, whether created from Lucid or Maverick will still
create a non-booting target usb device (thumbdrive or usb hdd) because the
wrong device (sdc instead of sdb) is used. To recap, at install time, the
Windows internal hard disk gets sda, the boot media gets sdb, and t
Lucid (10.04) has fixed the bad device.map (got rid of it), fixed the comments
mentioning devices on the other oses, and generally has rationalized the hd0 is
sda, hd1 is sdb. Unfortunately, the /etc/fstab file now puts / on
/dev/sdcx instead of /dev/sdbx (or UUID as in Karmic). Since there is
As of Karmic (9.10), grub's use of UUIDs fixed the problem of being
unable to boot the other operating systems. The devices are still
wrong, but will make no difference unless the install is to a portable
device like a usb stick which should be able to boot windows on any PC.
In that case, fix the
20 matches
Mail list logo