[Expired for grub2 (Ubuntu) because there has been no activity for 60
days.]
** Changed in: grub2 (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/414184
Ti
This release of Ubuntu is no longer receiving maintenance updates. If
this is still an issue on a maintained version of Ubuntu please let us
know.
** Changed in: grub2 (Ubuntu)
Status: Triaged => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
As I've explained elsewhere, in general it's impossible to determine
BIOS ordering from outside the BIOS (or at least once you get into a
non-real-mode operating system). Our intent is to search and destroy all
places where GRUB relies on BIOS ordering.
I'm fairly sure you disagree with me here. T
The problem is the nearly random choice for the first SATA drive in your list.
If you identified the drives the same way the BIOS (or DOS for that matter) (or
Linux prior to this kernel) did, the first boot drive would be the same first
boot drive as mapped by the BIOS. All would be right with
Looks to me as if we're trying to map a partition to a drive, which
doesn't seem likely to work very well.
** Changed in: grub2 (Ubuntu)
Status: Incomplete => Triaged
** Changed in: grub2 (Ubuntu)
Importance: Undecided => Medium
--
[Karmic] update-grub creates incorrect entry for Free
I tried it yesterday, after applying all updates, still an issue.
SATA drives are not identified in correct order.
On Sunday 27 September 2009 12:26:54 pm Steven Harms wrote:
> Thank you for taking the time to report this bug. Can you try this out
> on Karmic Alpha 6 and see if it is still an is
Thank you for taking the time to report this bug. Can you try this out
on Karmic Alpha 6 and see if it is still an issue?
** Changed in: grub2 (Ubuntu)
Status: New => Incomplete
--
[Karmic] update-grub creates incorrect entry for FreeDOS
https://bugs.launchpad.net/bugs/414184
You received
