** Changed in: debian-installer (Ubuntu)
Status: Confirmed = Fix Released
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because you are a member of Ubuntu
Server Team, which is a direct subscriber.
--
Who ever beleives that bugs go away by closing them on launchpad
I have a machine with two SATA drives and the following layout:
o sda1 100M /dos FAT16
o sda2 large RAID 1 for \ encrypted LVM
o sda3 small RAID 2 for \boot
o sdb1 100M /dos FAT16
o sdb2 large RAID 1 for \ encrypted LVM
If it aborts installation, then this is clearly not the same bug at all.
The original bug report is that the system fails to boot after install,
which is entirely different.
You need to open a separate bug report for the separate issue.
--
root raid installs have bad grub config
Iff Mr. Kirkland ever tried himself to install Intrepid on a pair of
REAL harddisks with mirrored /boot on both disks and encrypted
filesystem with LVM on another mirrored raid he would have found out
that ALL the problems are still present in Beta!
Colin, it's not only me beeing tired of how the
** Changed in: debian-installer (Ubuntu)
Status: Confirmed = Fix Released
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing
Please go back and read the original description of this bug.
The scenario you describe is completely different than the bug that
James Troup reported in March of 2006, which has been fixed. I'm
closing this bug as such.
This may well merit a new bug report, but it absolutely *does not
belong*
Who ever beleives that bugs go away by closing them on launchpad
I have a machine with two SATA drives and the following layout:
o sda1 100M /dos FAT16
o sda2 large RAID 1 for \ encrypted LVM
o sda3 small RAID 2 for \boot
o sdb1 100M /dos FAT16
o sdb2 large RAID 1 for \ encrypted LVM
If it aborts installation, then this is clearly not the same bug at all.
The original bug report is that the system fails to boot after install,
which is entirely different.
You need to open a separate bug report for the separate issue.
--
root raid installs have bad grub config
Please confirm whether this is still present in the beta, and if it is
then exactly what the current symptoms are. Since there have been quite
a lot of changes in this area, I don't expect that it's still behaving
the same way, and something more than bug still present would be
useful.
--
root
Please confirm whether this is still present in the beta, and if it is
then exactly what the current symptoms are. Since there have been quite
a lot of changes in this area, I don't expect that it's still behaving
the same way, and something more than bug still present would be
useful.
--
root
Bug still present in Alpha 4
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because you are a member of Ubuntu
Server Team, which is a direct subscriber.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Bug still present in Alpha 4
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
This bug was fixed in the package grub - 0.97-29ubuntu35
---
grub (0.97-29ubuntu35) intrepid; urgency=low
[ Dustin Kirkland ]
* debian/patches/00list: add grub-install_better_raid.diff.
* debian/patches/grub-install_better_raid.diff: add support for writing an
MBR on each
This bug was fixed in the package grub - 0.97-29ubuntu35
---
grub (0.97-29ubuntu35) intrepid; urgency=low
[ Dustin Kirkland ]
* debian/patches/00list: add grub-install_better_raid.diff.
* debian/patches/grub-install_better_raid.diff: add support for writing an
MBR on each
Per feedback from slangasek on IRC, I have another revision of the grub
patch.
This one does not assume/hard-code hd0, rather it uses the previously
existing logic to find the appropriate bios device.
And if the user passes a device for which we cannot determine the
appropriate bios device, we
Revision 841 in lp:~kirkland/grub/33649 adds some smarts (back) into the
handling of the multiple devices on a RAID providing /boot.
Rather than using the same (hd0,0) type string for each device,
independently calculate the partition number. This is problem is
similarly reported in bug #46223,
Per feedback from slangasek on IRC, I have another revision of the grub
patch.
This one does not assume/hard-code hd0, rather it uses the previously
existing logic to find the appropriate bios device.
And if the user passes a device for which we cannot determine the
appropriate bios device, we
Revision 841 in lp:~kirkland/grub/33649 adds some smarts (back) into the
handling of the multiple devices on a RAID providing /boot.
Rather than using the same (hd0,0) type string for each device,
independently calculate the partition number. This is problem is
similarly reported in bug #46223,
This is the second revision of patch 2/2 for bug #33649, based on feedback
from
slangasek. He questioned the previous revision, where I was installing GRUB
onto all devices of a RAID providing /boot, every time.
This revision will:
1) install to all devices, if the target on
This is the second revision of patch 2/2 for bug #33649, based on feedback
from
slangasek. He questioned the previous revision, where I was installing GRUB
onto all devices of a RAID providing /boot, every time.
This revision will:
1) install to all devices, if the target on
This bug was fixed in the package grub-installer - 1.32ubuntu2
---
grub-installer (1.32ubuntu2) intrepid; urgency=low
[ Colin Watson ]
* Add another guard against calling 'udevadm info' with an empty device
name (LP: #30772).
[ Dustin Kirkland ]
* grub-installer: add
I don't think this is a viable long-term solution, because grub-install
after installation won't do the same thing. Thus the task on grub should
definitely stay open. However, it may help in the short term.
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You
Colin-
I have a proposed patch in a bzr branch of grub:
* https://code.launchpad.net/~kirkland/grub/33649
The first patch handled grub-installer used in the debian-installer, and
this one handles grub-install (in the grub package), used in the
installed operating system thereafter.
The
Also, added to a bzr branch:
* https://code.launchpad.net/~kirkland/grub-installer/33649
:-Dustin
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
This bug was fixed in the package grub-installer - 1.32ubuntu2
---
grub-installer (1.32ubuntu2) intrepid; urgency=low
[ Colin Watson ]
* Add another guard against calling 'udevadm info' with an empty device
name (LP: #30772).
[ Dustin Kirkland ]
* grub-installer: add
I don't think this is a viable long-term solution, because grub-install
after installation won't do the same thing. Thus the task on grub should
definitely stay open. However, it may help in the short term.
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You
Colin-
I have a proposed patch in a bzr branch of grub:
* https://code.launchpad.net/~kirkland/grub/33649
The first patch handled grub-installer used in the debian-installer, and
this one handles grub-install (in the grub package), used in the
installed operating system thereafter.
The
** Also affects: grub (Ubuntu)
Importance: Undecided
Status: New
** Also affects: grub-installer (Ubuntu)
Importance: Undecided
Status: New
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because you are a
I'm attaching a patch to the grub-installer package which adds support
for iteratively installing GRUB to each disk in an mdadm-managed
software RAID providing /boot.
I'm not done testing it yet, but I'm posting it here in case anyone has
any productive comments on the patch.
:-Dustin
**
** Also affects: grub (Ubuntu)
Importance: Undecided
Status: New
** Also affects: grub-installer (Ubuntu)
Importance: Undecided
Status: New
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because you are a
@Dustin:
Do I err with my impression that your intension is to get some quick fix while
my concern is to make Ubuntu as simple and reliable as possible? It is now the
moment to make sure that the user interface while booting mirrored raids is
understandable and maneagable not only for experts
On Fri, Aug 1, 2008 at 9:25 AM, tricky1 [EMAIL PROTECTED] wrote:
@Dustin:
Do I err with my impression that your intension is to get some quick fix
My intention is to fix this multi-faceted bug in an incremental and
solvable manner.
That the bug has been around for 2.5 years is a testament to
@Dustin
My intention is to fix this multi-faceted bug in an incremental and
solvable manner.
My suggestions ARE along these lines :D
That the bug has been around for 2.5 years is a testament to the fact
that it is difficult to solve. Breaking it down into manageable bits
is a tried and true
@Dustin:
Do I err with my impression that your intension is to get some quick fix while
my concern is to make Ubuntu as simple and reliable as possible? It is now the
moment to make sure that the user interface while booting mirrored raids is
understandable and maneagable not only for experts
On Fri, Aug 1, 2008 at 9:25 AM, tricky1 [EMAIL PROTECTED] wrote:
@Dustin:
Do I err with my impression that your intension is to get some quick fix
My intention is to fix this multi-faceted bug in an incremental and
solvable manner.
That the bug has been around for 2.5 years is a testament to
@Dustin
My intention is to fix this multi-faceted bug in an incremental and
solvable manner.
My suggestions ARE along these lines :D
That the bug has been around for 2.5 years is a testament to the fact
that it is difficult to solve. Breaking it down into manageable bits
is a tried and true
@Dustin:
a) Even if smart status is not perfect it is a good idea to warn user
during boot in case of errors detected.
b) What I tried to suggest is not a visible timer (good idea but not
urgent), but the possibility that during _installation_ one can specify
if automatic degraded booting will
On Thu, Jul 31, 2008 at 7:58 AM, tricky1 [EMAIL PROTECTED] wrote:
a) Even if smart status is not perfect it is a good idea to warn user
during boot in case of errors detected.
I still don't see this as practical, as it would necessitate moving
smartctl (and dependent .so's) into the initramfs.
@Dustin:
a) Even if smart status is not perfect it is a good idea to warn user
during boot in case of errors detected.
b) What I tried to suggest is not a visible timer (good idea but not
urgent), but the possibility that during _installation_ one can specify
if automatic degraded booting will
On Thu, Jul 31, 2008 at 7:58 AM, tricky1 [EMAIL PROTECTED] wrote:
a) Even if smart status is not perfect it is a good idea to warn user
during boot in case of errors detected.
I still don't see this as practical, as it would necessitate moving
smartctl (and dependent .so's) into the initramfs.
Thx, good news from Dustin. Questions:
- When will your work be integrated into the daily iso?
- Did you read my additional comments added at the bottom of the wiki page?
I am convinced that a separate entry in grubs menu list is a short
sighted approach, please comment!
--
root raid installs
On Wed, Jul 30, 2008 at 9:10 AM, tricky1 [EMAIL PROTECTED] wrote:
- When will your work be integrated into the daily iso?
Ideally, sometime before FeatureFreeze, currently set for 28 Aug 2008.
* https://wiki.ubuntu.com/IntrepidReleaseSchedule
- Did you read my additional comments added at the
Thx, good news from Dustin. Questions:
- When will your work be integrated into the daily iso?
- Did you read my additional comments added at the bottom of the wiki page?
I am convinced that a separate entry in grubs menu list is a short
sighted approach, please comment!
--
root raid installs
On Wed, Jul 30, 2008 at 9:10 AM, tricky1 [EMAIL PROTECTED] wrote:
- When will your work be integrated into the daily iso?
Ideally, sometime before FeatureFreeze, currently set for 28 Aug 2008.
* https://wiki.ubuntu.com/IntrepidReleaseSchedule
- Did you read my additional comments added at the
It is very disappointing to see that all alfas of intrepid still have
that problem. I wonder how this deeply rooted bug shall be corrected in
the few weeks remaining if currently nothing seems to be done in that
direction?
--
root raid installs have bad grub config
I have linked this bug to the following Blueprint for Intrepid:
* https://blueprints.launchpad.net/ubuntu/+spec/boot-degraded-raid
And covered it briefly in the specification:
*
https://wiki.ubuntu.com/BootDegradedRaid#head-bad7ecb75ab9cd9fd207658b7aecf983f919e33a
I am working on this for
It is very disappointing to see that all alfas of intrepid still have
that problem. I wonder how this deeply rooted bug shall be corrected in
the few weeks remaining if currently nothing seems to be done in that
direction?
--
root raid installs have bad grub config
I have linked this bug to the following Blueprint for Intrepid:
* https://blueprints.launchpad.net/ubuntu/+spec/boot-degraded-raid
And covered it briefly in the specification:
*
https://wiki.ubuntu.com/BootDegradedRaid#head-bad7ecb75ab9cd9fd207658b7aecf983f919e33a
I am working on this for
The installer on alternate cd looks broken as soon as one intends to use
_any_ kind of raid.
Same problem on server edition. Who ever would want to install a real
world server without mirroring?
I wonder why the responsible manager seems not to recognize importance
of this bug??
--
root raid
Please wake up ;-)
** Changed in: debian-installer (Ubuntu)
Assignee: (unassigned) = Ubuntu Installer Team (ubuntu-installer)
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because you are a member of Ubuntu
Server Team,
The installer on alternate cd looks broken as soon as one intends to use
_any_ kind of raid.
Same problem on server edition. Who ever would want to install a real
world server without mirroring?
I wonder why the responsible manager seems not to recognize importance
of this bug??
--
root raid
Please wake up ;-)
** Changed in: debian-installer (Ubuntu)
Assignee: (unassigned) = Ubuntu Installer Team (ubuntu-installer)
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because you are a member of Ubuntu
Bugs, which
I think I just saw this problem when I installed gutsy from the
alternate cd.
I have an existing RAID5 array on /dev/hd[cegi] and /dev/[cbef] which is
/dev/md2, and installed to /dev/sd[ab]1, with swap on /dev/sd[ab]5.
The installation went pretty much as expected (considering I had a
previous
Still present in Gutsy
see: bug #152229
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Reproduced on Dapper and Edgy. Feisty works just fine. If the fix for
this can be cherrypicked, it would be great to be able to include it in
the upcoming point release.
--
root raid installs have bad grub config
https://bugs.launchpad.net/bugs/33649
You received this bug notification because
I have had problems with a new installation of Ubuntu server 6.10 with
the root partition on RAID1, and have identified two apparent errors:
1. In grub/menu.lst, the kernel parameter was root=/dev/hda1 instead of
root=/dev/md0
2. In /etc/fstab, the UUID of the root partition is incorrect.
56 matches
Mail list logo
