Hi , this is a very important fix and I really appreciate the community
for this.
I have a question though ; is it possible to use 'dpkg-reconfigure
mdadm' non interactively ?
I saw the man pages , but i would like to Enable Bootdegraded as an
option through the command line , without any user
Thanks for answering Dustin, very fast as usual!
Just to make sure I get it correctly:
1) back-up data (of course...)
2) boot normally my 7.10 amd64 desktop with both disks in Raid1
3) do a live distribution update from Update Manager New dist rel 8.04 LTS
is available button
4) reboot after
You got it ;-)
:-Dustin
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
https://bugs.launchpad.net/bugs/290885
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Thank you very much for your help!
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
https://bugs.launchpad.net/bugs/290885
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Dustin, I have been following this from the beginning, but I'm still
puzzled on the way to upgrade my 7.10 AMD64 desktop, working OK with the
patch on 2 sata HD.
I would like to:
1) disconnect 1 HD boot degraded
2) update to 8.04 via network
3) update to 8,10
4) connect the second HD and sync
On Mon, Jan 19, 2009 at 12:07 PM, Davias dav...@egroup.it wrote:
Dustin, I have been following this from the beginning, but I'm still
puzzled on the way to upgrade my 7.10 AMD64 desktop, working OK with the
patch on 2 sata HD.
I would like to:
1) disconnect 1 HD boot degraded
2) update to
There is no appropriate place to solve this in the Hardy server guide.
Instead, we have provided instructions at:
* https://help.ubuntu.com/community/DegradedRAID
I'm open to the idea of adding a reference to this in the grub postinst,
if it's believed that will help.
:-Dustin
** Changed in:
FOLLOW NOTES
- I compared the 'local' script on my 1st (successful) machine and this 2nd
machine; they're identical, same file-date, same lack of 'mdadm' reference. So
that's not the problem here.
- I sat and waited to see if the new Boot degraded? prompt appeared; it did
not.
- I tried
I've just tried this on my other Ubuntu system and it did not work.
ORIGINAL SETUP
- initially installed with Ubuntu 7.10 with manual fix to initramfs
- two SATA drives in RAID-1 mirror
- confirmed that I could boot from 1 drive
- updated to 8.04.1
- GRUB is still installed to both drives but the
This bug was fixed in the package grub - 0.97-29ubuntu21.1
---
grub (0.97-29ubuntu21.1) hardy-proposed; urgency=low
* debian/patches/grub-install_better_raid.diff: backported from Intrepid;
install grub on multiple disks in a RAID. (LP: #290885)
* debian/patches/00list:
This bug was fixed in the package grub-installer - 1.27ubuntu8.1
---
grub-installer (1.27ubuntu8.1) hardy-proposed; urgency=low
* Backport fixes for booting degraded software RAID (LP: #290885).
* grub-installer: determine if installing to a /dev/md RAID device, and
This bug was fixed in the package initramfs-tools - 0.85eubuntu39.3
---
initramfs-tools (0.85eubuntu39.3) hardy-proposed; urgency=low
* Functionality backported from Intrepid to Hardy to support booting
degraded RAID, LP: #290885.
* scripts/functions: Adjust the mountroot
This bug was fixed in the package mdadm -
2.6.3+200709292116+4450e59-3ubuntu3.1
---
mdadm (2.6.3+200709292116+4450e59-3ubuntu3.1) hardy-proposed; urgency=low
* Fixes for LP: #290885, backported from Intrepid to Hardy
* Backport functionality to enable booting degraded RAID from
** Tags added: verification-done
** Tags removed: verification-needed
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
https://bugs.launchpad.net/bugs/290885
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Martin-
I consciously did *not* edit the postinst to do the grub install, in
order to keep with the rule of least surprise.
I agree with Steve's comments that it would be quite nice if this
could be done automatically, but I don't think messing with every RAID
user's MBR is something that we
Dustin Kirkland wrote:
Beyond that, code-wise, perhaps we could emit a warning in the
grub-install postinst, that detects if /boot is on a RAID, and
recommend that the user investigate the situation and perhaps run
grub-install on the device. Steve mentioned update-notifier, which
might be
I've walked through the steps at http://wiki.ubuntu.com/BootDegradedRaid
and can confirm that the degraded raid boot options work (modulo the
issue I raised around grub/MBR). The dpkg-reconfigure steps, the kernel
command line options, and the /etc/initramfs/conf.d/mdadm settings all
seem to work
I'm working through verification of this fix, and one thing that I've
come across is that if the raid was setup using the older version of
grub/grub-installer (e.g. off of 8.04.1 media), grub-install is not re-
invoked and so the second disk still does not have a grub stage 1 in its
MBR. Thus, if
Martin-
Would would you think of adding a bit to the grub postinst that
detected if you were upgrading from a certain version, and if you have
root (or /boot) on a RAID device, and if so, run grub-install on that
device?
:-Dustin
--
SRU: Backport of Boot Degraded RAID functionality from
Dustin Kirkland [2008-12-04 12:51 -]:
Would would you think of adding a bit to the grub postinst that
detected if you were upgrading from a certain version, and if you have
root (or /boot) on a RAID device, and if so, run grub-install on that
device?
That doesn't seem to be a problem
On Thu, Dec 04, 2008 at 08:22:32PM -, Martin Pitt wrote:
Dustin Kirkland [2008-12-04 12:51 -]:
Would would you think of adding a bit to the grub postinst that
detected if you were upgrading from a certain version, and if you have
root (or /boot) on a RAID device, and if so, run
Should this fix work also for degraded raid not on boot partition?
I have a machine with non-raid root partition (indeed it's hw raid) and
some extra software raid space which is in fstab to be mounted on pass
2. I'm doing some tests with this setup in a VM.
I tried with stock 8.04.1 and if I
Stefano-
No, this is only intended to solve the situation where you need to
boot your system from a degraded RAID.
:-Dustin
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
https://bugs.launchpad.net/bugs/290885
You received this bug notification because you are a
Dustin-
I think the problem is anyway quite related to what this is fixing. If a
server refuses to boot if a single disk in a raid1 array fails, the
perceived problem from the user is quite the same, even if that array is
not the one the system is booting from but just another filesystem. The
On Thu, Nov 20, 2008 at 11:33 AM, Stefano Garavaglia
[EMAIL PROTECTED] wrote:
I have a machine with non-raid root partition (indeed it's hw raid) and
some extra software raid space which is in fstab to be mounted on pass
2.
See http://manpages.ubuntu.com/manpages/hardy/en/man5/fstab.html
Dustin Kirkland wrote:
Right, or you can set the fs_passno 0, which would remove passing the
filesystem check as a boot requirement, if this is what you want.
No, that's not what I want to do, I'd just want the system to boot (or
be configured to boot) with the array in degraded mode,
Ah, okay. Yes, you're exactly right, you're speaking of Bug #259145.
The current stack of SRU's is not claiming to solve that bug, while
that bug is valid, confirmed and important. It will be addressed
separately.
:-Dustin
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to
The 3 minute delay is to handle older configurations (generally
clusters), which we needed to support for the LTS. As a result, the 3
minute delay needs to stay. It was reduced in Intrepid to 30 seconds.
For people that want to reduce it, they can add it to the grub config
with e.g.
Here's my findings after testing the packages (grub, grub-installer,
initramfs-tools and mdadm) from hardy-proposed.
My testing was carried out on both virtual and physical hardware. The
testing on a virtual machine was under VMware using two SCSI disks
connected to a LSI Logic controller. The
Actually, I can replicate :-)
I've just recreated the test case noted in my comment above in a VMware
virtual machine with the same results. It appears the debconf DB is
correct the change doesn't make it through to the initramfs although it
does get rebuilt:
[EMAIL PROTECTED]:/home/pre500#
A RAID admin should understand (or come to understand) this workflow.
Please don't say that. Is there some formal course of study that's
required before implementing sw RAID? No, of course not. Personally, I
am an experienced network manager with decades of experience and various
certs but
My most sincere apologies are offered for any offense taken...
This should absolutely be handled in the official documentation, most
likely in the Ubuntu Server Guide.
:-Dustin
** Also affects: ubuntu-docs (Ubuntu)
Importance: Undecided
Status: New
--
SRU: Backport of Boot Degraded
Paul-
I think I understand the wrinkle you're seeing here...
mdadm will only fail to construct a newly degraded array.
So the *first* time you boot with a missing disk, mdadm expects the
RAID to be fully operational, notices it's missing a disk, and the new
code we have in the initramfs takes
I appear to have found a small issue. On my test machine (a physical x86
server), once I've configured mdadm to boot degraded arrays
automatically, it seems impossible to change it back. These are the
steps I took:
1. Installed 8.04.1 x86 to a physical box with 2 SCSI disks in a Raid-1 mirror.
2.
Adding a task to update the Ubuntu Server Guide for Hardy/Intrepid to
clearly explain the new degraded RAID behavior. Specifically, we need
to clearly explain that there's a significant difference to mdadm
between a newly degraded RAID event, and subsequent boots on a RAID
that is known to be
How is your system partitioned? What is your RAID setup? What is
your LVM setup? I can test in a kvm.
Thanks! here are the info:
# fdisk -l /dev/sda
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk
JHR:
Thanks, good stuff.
Also, did you install this from the Ubuntu Hardy alternate/server iso,
or some other mechanism?
:-Dustin
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
https://bugs.launchpad.net/bugs/290885
You received this bug notification because you
Also, did you install this from the Ubuntu Hardy alternate/server iso,
or some other mechanism?
I used 8.04LTS server 32bit iso.
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
https://bugs.launchpad.net/bugs/290885
You received this bug notification because you are
Hi,
I use RAID1 + LVM, hardy uses LILO to boot and not GRUB if you have this
configuration.
Can you confirm me that this patch you're working on will also work in
this configuration ?
Thanks.
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
JHR wrote:
I use RAID1 + LVM, hardy uses LILO to boot and not GRUB if you have this
configuration.
Can you confirm me that this patch you're working on will also work in
this configuration ?
LiLo was unaffected by these changes -- it already contained the
functionality I added to GRUB.
How
initramfs-tools uploaded.
For mdadm:
-add_mountroot_fail_hook
+add_mountroot_fail_hook_d 10-mdadm
Where does 10-mdadm come from? I don't see it anywhere in mdadm, the
patch, or initramfs-tools.
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
Ah, nevermind. That's the target file name. Uploaded mdadm.
** Changed in: grub (Ubuntu Hardy)
Status: In Progress = Fix Committed
Target: ubuntu-8.04.2 = None
** Changed in: grub-installer (Ubuntu Hardy)
Status: In Progress = Fix Committed
Target: ubuntu-8.04.2 =
Synaptic is still showing me the same 2 updates (ppa4). Should the
version numbers have changed with these latest changes? Also, I'm still
waiting for feedback on my testing and posted questions.
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
I bumped the build priority for those packages, they should get
available at archive.ubuntu.com in a few hours.
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
https://bugs.launchpad.net/bugs/290885
You received this bug notification because you are a member of Ubuntu
On Fri, Nov 7, 2008 at 6:21 PM, Bill Smith [EMAIL PROTECTED] wrote:
Synaptic is still showing me the same 2 updates (ppa4). Should the
version numbers have changed with these latest changes? Also, I'm still
waiting for feedback on my testing and posted questions.
Hey Bill-
Sorry that I
On Thu, Nov 6, 2008 at 1:07 AM, Bill Smith [EMAIL PROTECTED] wrote:
OK, so the test seemed to go ok (aside from my BIOS trying to boot from
my 'data' drives).
Great, your efforts here, Bill, are greatly appreciated, and were
instrumental in helping us get these patches from my PPA and into
Updated patch attached for initramfs-tools.
initramfs-tools:
- patch changes previous changelog, and misses bug number
Fixed.
- add_mountroot_fail_hook(): Changes behaviour of function. Please keep
original function and add
add_mountroot_fail_hook_d() or so.
Done, fixed.
- panic():
Updated patch attached for mdadm.
mdadm:
- changelog missing bug number
Fixed.
- debian/initramfs/init-premount: needs new name for
add_mountroot_fail_hook_d() (see above)
Adjusted accordingly.
- OK otherwise, although large patch which needs thorough testing
Agreed.
Verification
grub: I fixed the changelog to say backported from intrepid (not
hardy), and removed the spurious manpage header diffs. The patch itself
looks good and reasonably isolated to me.
It only affects grub-install, so regression potential is low enough to
not suddenly break existing installations. It
grub fix backported from intrepid, closing jaunty task.
** Changed in: grub (Ubuntu)
Status: In Progress = Fix Released
Target: ubuntu-8.04.2 = None
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
https://bugs.launchpad.net/bugs/290885
You received this
Reuploaded grub with bug number in changelog, rejected previous upload.
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
https://bugs.launchpad.net/bugs/290885
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
grub-installer looks fine, too, uploaded to queue.
** Changed in: grub-installer (Ubuntu Hardy)
Assignee: (unassigned) = Dustin Kirkland (kirkland)
Status: New = In Progress
Target: None = ubuntu-8.04.2
** Changed in: grub-installer (Ubuntu)
Assignee: Dustin Kirkland
initramfs-tools:
- patch changes previous changelog, and misses bug number
- add_mountroot_fail_hook(): Changes behaviour of function. Please keep
original function and add a add_mountroot_fail_hook_d() or so.
- panic(): Why the chvt 1? Boot messages are usually on VT8, and this changes
mdadm:
- changelog missing bug number
- debian/initramfs/init-premount: needs new name for
add_mountroot_fail_hook_d() (see above)
- OK otherwise, although large patch which needs thorough testing
Verification should include dpkg-reconfigure, booting in both modes with
degraded and
Attaching the grub patch.
Requesting sponsorship to hardy-proposed.
:-Dustin
** Attachment added: grub.290885.debdiff
http://launchpadlibrarian.net/19395824/grub.290885.debdiff
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
Attaching the grub-installer patch.
Requesting sponsorship to hardy-proposed.
:-Dustin
** Attachment added: grub-installer.290885.debdiff
http://launchpadlibrarian.net/19395838/grub-installer.290885.debdiff
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
Attaching the initramfs-tools patch.
Requesting sponsorship to hardy-proposed.
:-Dustin
** Attachment added: initramfs-tools.290885.debdiff
http://launchpadlibrarian.net/19395848/initramfs-tools.290885.debdiff
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
Attaching the mdadm patch.
Requesting sponsorship to hardy-proposed.
:-Dustin
** Attachment added: mdadm.290885.debdiff
http://launchpadlibrarian.net/19395867/mdadm.290885.debdiff
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
OK, so the test seemed to go ok (aside from my BIOS trying to boot from
my 'data' drives).
OBSERVATIONS
- As you suggested I ran the update command on just the boot array,
sudo grub-install /dev/md0
It correctly identified the two physical drives and updated them both
- The initial boot
On Thu, Oct 30, 2008 at 3:56 PM, Bill Smith [EMAIL PROTECTED] wrote:
I'm trying to test it on my Ubuntu 8.04.1 setup but I'm not sure what's
the appropriate method for updating GRUB. You mention running 'grub-
install' against the RAID device (e.g. 'md0') but I had previously run
it against
Uploaded updated grub-installer package to my PPA, containing the
backported fixes for installing grub to each disk in an array providing
/.
* https://launchpad.net/~kirkland/+archive
:-Dustin
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
Stable Release Update requested for:
* grub-installer
* grub
* mdadm
* initramfs-tools
Per:
* https://wiki.ubuntu.com/StableReleaseUpdates
1) This set of bugs affects any Ubuntu 8.04 LTS user with / or /boot on
a RAID1 device. RAID is intended to provide both redundancy of the data
on
Per comments from Kees, I will upload each of the 4 patches
independently.
Also, I will need to update the version of each package to use a dot.
More patches coming.
:-Dustin
--
SRU: Backport of Boot Degraded RAID functionality from Intrepid to Hardy
https://bugs.launchpad.net/bugs/290885
You
Dustin,
Thanks for working on back-porting this. (P.S. Congratulations on your
interview in the Ubuntu newsletter!)
I'm trying to test it on my Ubuntu 8.04.1 setup but I'm not sure what's
the appropriate method for updating GRUB. You mention running 'grub-
install' against the RAID device
I have some very preliminary, working packages in my PPA, available for
testing. See:
* https://launchpad.net/~kirkland/+archive
o grub
o initramfs-tools
o mdadm
If you have some spare hardware or virtualization at your disposal, and
you're willing and able to
65 matches
Mail list logo
