https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1003309 and
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/251164 had the
info I needed to fix my problems with encrypted RAID1 not booting in
degraded mode.
--
You received this bug notification because you are a member of Ubuntu
My server was in 8.04 LTS, having a raid 1 setup with 2 mirrored harddisk.
I have tested, if I unplug one of the disk, the raid 1 was working fine.
Sadly, after upgraded my system to 10.04.1 LTS, if I unplug one of the
disk and boot, the raid 1 become inactive.
#mdadm --detail /dev/md0
mdadm: md
Thank you Emanuele, I really haven't tried what you're suggesting, will
definitely do it if I have time, or if my hard disk crashes for real.
I've a question, I subscribe to this bug, but when I look at my ACCOUNT
- BUGS - LIST SUBSCRIBED BUGS, it's not there, and I really want to be
updated on
Hosed wrote:
Hi, I have Ubuntu 9.04. I have Two (2) 36gb Seagate Cheetah with Raid 1
- Mirroring Setup. When I boot to Ubuntu 9.04 with One (1) of the hard
disks unplugged, it fails to boot, it drops me to a shell with
initramfs. What's the deal with that? Does it mean that Raid1 is NOT
Hi, I have Ubuntu 9.04. I have Two (2) 36gb Seagate Cheetah with Raid 1
- Mirroring Setup. When I boot to Ubuntu 9.04 with One (1) of the hard
disks unplugged, it fails to boot, it drops me to a shell with
initramfs. What's the deal with that? Does it mean that Raid1 is NOT
WORKING with Ubuntu
Is this bug still present? I've installed a fresh 8.04.2 amd64 in a
VirtualBox 2.1.2 with three SATA harddrives. When i switch off a drive,
kernel is loadding but at the end the raid arrays are stopped and the
system is unusable.
r...@ubuntu:~# dpkg-reconfigure mdadm
Do you want to boot your
Tapani-
I very much appreciate the detail with which you have constructed your
report, as well as your followup which provides a hint as to how one
might fix this issue. Thank you! But you are describing a different
issue, which is deeper, and more involved.
Please, please, please open a new
Degraded RAID 1 array with encryption, Bug #324997.
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Ubuntu
Server Team, which is a subscriber of a duplicate bug.
--
Ubuntu-server-bugs mailing list
Dustin, thank you for your quick answer and tips.
It took me a while to test it, as I have an encrypted RAID 1 array with
LVM, and things are not that straightforward with that setup.
So far I have been using one of the tricks described in this thread
earlier (ie. edit
Ok, I'm answering myself: there is a workaround for getting it to work
with LUKS encryption. You can run sudo dpkg-reconfigure mdadm and
enable automatic startup with degraded RAID array if you want, or watch
the screen and be quick enough to answer Yes when asked to start
degraded. Nevertheless,
It seems that the issue is now fixed in Intrepid, and also backported to
Hardy 8.04.2, which was released a few days ago. However, it is unclear
to me if I need to reinstall from 8.04.2 distribution media, or can I
fix an existing Hardy installation via software updates?
--
cannot boot raid1
You should not need to reinstall.
To solve this, you need to:
a) live upgrade all packages (specifically, you need to upgrade grub,
mdadm, and initramfs-tools)
b) install grub to the raid (for instance, if /dev/md0 provides your
/boot directory, you can do grub-install /dev/md0)
Cheers,
** Changed in: grub (Ubuntu Hardy)
Status: In Progress = Fix Released
** Changed in: initramfs-tools (Ubuntu Hardy)
Status: In Progress = Fix Released
** Changed in: mdadm (Ubuntu Hardy)
Status: In Progress = Fix Released
--
cannot boot raid1 with only one disk
Thanks, Nick.
Please respond with any test results in Bug #290885.
Bug #120375 is hereby reserved for wailing, moaning, fussing, cursing,
complaining, lamenting, murmuring, regretting, repining, bewailing,
deploring, weeping, mourning, protesting, charging, accusing,
disapproving, grumbling,
Now that the Intrepid development cycle has wound down, I was finally
able to circle back to this.
For those of you interested in seeing this backported to Hardy, see Bug
#290885.
I have test packages available in my PPA--standard PPA disclaimers
apply. Please refer to Bug #290885 for test
I'm un-subscribing from this bug as well.
Anyone who believes that berating the developer who has (finally)
fixed this bug in the current release of Ubuntu, and offered to fix it
in the LTS release, is constructive desperately needs to re-read the
Ubuntu Code of Conduct.
*
Dustin, Steve, thank you for your support.
I'll be waiting for the updates on my hardy, and pray to not get in a
situation where this bug will show up ugly on my servers.
I remain subscribed, as I believe guys will make their job done soon.
Good luck!
On Fri, 2008-10-10 at 06:01 +, Dustin
No one should be taking any of this personally or feel berated. People
should feel free to be honest about their experiences without fear that
doing so will drive away people that could be of help in resolving the
issues. I've been keeping my mouth shut on this bug for a couple of
months and I
Subscribing to what agent 8131 said.
Now there are two drinks to get for the guy who helps us!
On Fri, 2008-10-10 at 07:13 +, agent 8131 wrote:
agent 8131
--
() Campania Panglicii în ASCII
/\ http://stas.nerd.ro/ascii/
--
cannot boot raid1 with only one disk
Can somebody explain, is this bug fixed in hardy packages?
A lot of comments, and not a single clear report!!!
If it is not fixed... Is there a patch for local script in initramfs-
tools and mdadm or is there any rebuilt package with the fixes?
Currently in Hardy i got:
~$ apt-cache policy
On Thursday 09 October 2008, Stanislav Sushkov wrote:
Can somebody explain, is this bug fixed in hardy packages?
A lot of comments, and not a single clear report!!!
If it is not fixed... Is there a patch for local script in initramfs-
tools and mdadm or is there any rebuilt package with the
Can you point to a wiki page or a comment in this thread where I'll find
a solution for hardy?
Or I should install Intrepid packages?
Thank you.
On Thu, 2008-10-09 at 15:14 +, Dustin Kirkland wrote:
This is fixed in Intrepid, not in Hardy.
:-Dustin
--
() Campania Panglicii în ASCII
Dustin I love the work that you've put in to this but I need to stand by Ace
Suares and for a LTS version it should be fixed.
It prevents me to use ubuntu for my servers which uses software raid. The ones
with hardware raid could use ubuntu.
But sticking with debian for the moment because of
Just post a file with patch which works for hardy, and that's all folks
:)
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Ubuntu
Server Team, which is a subscriber of a duplicate bug.
--
On Thursday 09 October 2008, Stanislav Sushkov wrote:
Just post a file with patch which works for hardy, and that's all folks
:)
No it's not.
There is a procedure for that, so it will be updated automatically. That
procedure I followed but at some point in the procedure, powers
of 'normal'
You mean this procedure?
It didn't work for me.
I mean I patched my local manually, but it broke my init image
in /boot after update-initramfs...
Maybe I the patch really works, but no one from this thread reported it
as a solution...
On Thu, 2008-10-09 at 20:37 +, Ace Suares wrote:
On
Fixing Hardy would mean, at the very least:
1) porting the patches for:
* mdadm
* initramfs-tools
* grub
* grub-installer
2) Rebuilding the installation ISO's.
3) Obsessively regression testing the new install media.
After Intrepid releases on October 30, 2008, I will spend a few
Dustin,
what about those packages for ibex. If I update my hardy with those, so
I risk serious troubles?
Or it is not possible cause of difference between kernels?
Someone did this before?
On Thu, 2008-10-09 at 21:21 +, Dustin Kirkland wrote:
Dustin
--
() Campania Panglicii în ASCII
/\
Dustin,
I am glad you may be spending some time on this bug.
You mention rebuilding ISO's. But why can't it just be an upgrade to the
existing installations?
I mean, on an existing system, all we need to do is upgrade ?
Also, I am not being sarcastic at all, when I say that I can not
Dustin,
I've been doing sysadmin work for 15 years. I chose to try out Ubuntu
for a home RAID server project, and loaded up Hardy as it was an LTS
edition. In my first day working with Ubuntu, I ran into this bug, a bug
where the version of mdadm (pretty well out of date) on Hardy was
Unsubscribing ubuntu-sru. Please do not subscribe the SRU team to bugs
that don't actually include proposed fixes to previous releases. a)
this is not the documented procedure for SRU fixes, b) the SRU team has
other things to do that actually benefit Ubuntu users, instead of
following a bug
Another thing to mention: Which systems are using raid? Right! ...
Server! Such systems are usually maintained remotely and rebooted
through a ssh connection. This message an the question is very very
useful. :-(
If you abort now, you will be provided with a recovery shell.
Do you wish to
I've experimented this bug on a new system I sold.. After a few days
working, one of the disks just died for my bad luck. I lost a Lot of
hours trying to fix it, resulting downtime to our costumer.. I couldn't
believe when I saw the panic I went to was the result of a bug not fixed
on this so
Updates, and Backports to previous releases. Please follow the
procedures specified in:
* https://wiki.ubuntu.com/StableReleaseUpdates
* https://help.ubuntu.com/community/UbuntuBackports
This bug, [Bug 120375] Re: cannot boot raid1 with only one disk, is
solved, and I'm un-subscribing from
The attached patch adds a debconf question, prompting the user as to the
desired behavior on a newly degraded RAID...
To boot, or not to boot, that is the question.
The priority is currently set to medium, with the default being
BOOT_DEGRADED=false, which is the conservative/traditional
Updated patch. Only difference from the previous is that I added a line
to the change log about the debian/po/*.po files changed.
:-Dustin
** Attachment added: mdadm.boot_degraded_debconf.debdiff
http://launchpadlibrarian.net/16894112/mdadm.boot_degraded_debconf.debdiff
--
cannot boot
Dustin, you could have open a separate bug with your debconf patch to
track your work and at the same time keep the comunity updated and able
to give you feedback in a more organized manner.
the default being BOOT_DEGRADED=false, which is the
conservative/traditional behavior.
Only some may
This bug is considerably overloaded.
Thus, I have split the mdadm/debconf/boot_degrade bug/patch to:
* Bug #259127
:-Dustin
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Ubuntu
Server Team, which
Wow, Dustin we again wrote or comments almost simultaneously. Thank you for
separating the issue.
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Ubuntu
Server Team, which is a subscriber of a
Only some may consider this conservative behaviour a broken behavior,
when a system on a redundant array of independent disks will degrade
just fine when running, but won't even come up when booting.
Even the more when you have upgraded from dapper LTS to hardy LTS and you
*think* you are
I have separated out the issue of booting with degraded non-root arrays
into Bug# 259145.
As a user merely helping to gather info I can't say if updates to hardy
(ubuntu 8.04) will be made available. Dustin?
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You
One more comment on this; I can understand the conservative
behaviour, but when an array was degraded, the boot process halted with
NO MESSAGE indicating what was wrong. Please whatever you do, even in
the case of maintaining conservative behavior, emit a message telling
the user why you're not
On Monday 18 August 2008, Ross Becker wrote:
One more comment on this; I can understand the conservative
behaviour, but when an array was degraded, the boot process halted with
NO MESSAGE indicating what was wrong. Please whatever you do, even in
the case of maintaining conservative
Comment 91 (https://bugs.launchpad.net/ubuntu/+bug/120375/comments/91) worked
for me.
I didn't need the extra lvm stuff but it can't hurt.
I was booting from /dev/sdb1, which was the 'failed' drive from
/dev/md0.
In /etc/fstab, I had /dev/md0 als /, and it shows up as such in 'df'.
But
This is a reason why a lot of system administrators that I know went back to
debian which doesn't have this behavior.
For a LTS version it should be fixed.
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member
Michael-
Is there any chance you can test the functionality on Intrepid?
Also, would you please open a new bug, and reference this one? With 91+
comments, these bugs tend to spiral out of control and cover way too
many independent though possibly related problems.
:-Dustin
--
cannot boot
One additional comment on this; this bug will also prevent a system
from booting if the array is reshaping (as opposed to missing a disk)
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Ubuntu
Server
4 of the 5 bugs taged as duplicates use a separate home array,
the fix will not let such systems boot degraded.
WARNING:
The mdadm - 2.6.7-3ubuntu2fix uses mdadm --assemble --scan on a system based
on udev hotplugging.
It will start all partly attatched arrays in degraded mode.
When any
I just noticed that with slowly-appearing drives (with md devices on it) the md
device will not exist on the regular run of init-premount/mdadm. But since
introducing another waiting loop into the coldplug driven boot does not make
much sence it'll be preferable to just do degration with
This bug was fixed in the package initramfs-tools - 0.92bubuntu7
---
initramfs-tools (0.92bubuntu7) intrepid; urgency=low
* scripts/functions:
- add_mountroot_fail_hook(): set up symlinks to hooks in tmp directory
- try_failure_hooks(): new function that executes each fail
How can you install the solution.
Tried a sudo apt-get -y update sudo apt-get -y upgrade
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Ubuntu
Server Team, which is a subscriber of a duplicate bug.
On Mon, Jul 28, 2008 at 3:41 PM, RpR [EMAIL PROTECTED] wrote:
How can you install the solution.
Tried a sudo apt-get -y update sudo apt-get -y upgrade
This has been fixed in the development tree of Ubuntu Intrepid for
further testing. It's not available for Hardy (or anything prior to
I think it can be understood that using mdadm --assemble --scan instead of
doing selective mdadm --run device calls on all devices ${ROOT} depends on
could be a reasonable and quick fix, if the information is not available
somwhere allready. Full support here.
My interest lies in getting the
Thank you for your comments and I'm sorry me slowly commenting overlapped with
your updated patches. (Of course you just worked to fast ;-), and fixed things
beforehand, perfect. :)
It's good to see that happen, and I've seen the merrit of the while loop
in intrepid now. It looks much better
From my perspective, what needs to happen is that the issue of booting from a
degraded root on kernel software raid needs a simple, easy to implement fix
for those who run fixed configuration machines, I.E. servers and the like.
The provided patches seem to accomplish this goal with a boot
How can I apply them?
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Ubuntu
Server Team, which is a subscriber of a duplicate bug.
--
Ubuntu-server-bugs mailing list
And this mdadm patch supercedes the previous one. It uses the new
initramfs-tools interface for adding the fail hook.
Updated package in my PPA:
* https://launchpad.net/~kirkland/+archive
:-Dustin
** Attachment added: mdadm.120375.debdiff
** Changed in: initramfs-tools
Status: Confirmed = In Progress
** Changed in: mdadm (Ubuntu)
Status: Triaged = In Progress
** Also affects: initramfs-tools (Ubuntu)
Importance: Undecided
Status: New
** Changed in: initramfs-tools (Ubuntu)
Assignee: (unassigned) =
Testing instructions for Intrepid are available in a wiki page for a
specification covering this bug:
*
https://wiki.ubuntu.com/BootDegradedRaid#head-a5a91db34505d4a047fd7f30e44ac2020da369a6
:-Dustin
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received
Hi, some feedback about the patches.
Does it matter if call_failure_hooks is allways called?
mdadm --run --scan will start all arrays degraded not only the one needed for
the rootfs (and its lvm and crypt respectively).
It will start for example a partial array from a removable disk that was
After
# We've given up,
A while loop is calling panic. An if statement might look better.
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Ubuntu
Server Team, which is a subscriber of a duplicate bug.
On Sat, Jul 26, 2008 at 01:15:08AM -, ceg wrote:
# We've given up,
A while loop is calling panic. An if statement might look better.
No, the while loop is correct -- it lets the user attempt to fix the
system repeatedly and on failures, it will drop to a shell again.
--
cannot boot raid1
On Fri, Jul 25, 2008 at 8:08 PM, ceg [EMAIL PROTECTED] wrote:
Instead of fixed sleep 5 in init-premount/mdadm, you could introduce a check
timeout loop
after call_failure_hooks in the local script. (So we can resume booting
ASAP.) Maybe just copy
the slumber while loop from above the
On Fri, Jul 25, 2008 at 8:08 PM, ceg [EMAIL PROTECTED] wrote:
mdadm --run --scan will start all arrays degraded not only the one needed
for the rootfs (and
its lvm and crypt respectively).
It will start for example a partial array from a removable disk that was
attatched and hasn't been
initramfs-tools patch.
:-Dustin
** Attachment added: initramfs-tools.120375.debdiff
http://launchpadlibrarian.net/16293732/initramfs-tools.120375.debdiff
** Changed in: mdadm (Ubuntu)
Status: Confirmed = Triaged
--
cannot boot raid1 with only one disk
mdadm patch.
:-Dustin
** Attachment added: mdadm.120375.debdiff
http://launchpadlibrarian.net/16293729/mdadm.120375.debdiff
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Ubuntu
Server Team, which
I have a pair of debdiffs which will be posted in the following two
messages. One for mdadm, and a second for initramfs-tools.
The mdadm patch supports an optional kernel parameter, which can be any of:
* bootdegraded
* bootdegraded=true
* bootdegraded=yes
* bootdegrade=1
If a RAID device
I successfully installed raid 1 on an Ubuntu Desktop 8.04 64-bit machine
according to Martiis intructions:
http://users.piuha.net/martti/comp/ubuntu/en/raid.html
The only thing missing in Martiis instructions was
sudo update-initramfs -u (thx to Alexander)
after inserting Kens lines
# The
This also affects raid5 (seems logical) but the patch doesn't seem to
work for me when also using lvm. My test setup:
sda1 100Mb /boot
sda2 raid
sdb1 100Mb (manual copy of /boot)
sdb2 raid
sdc1 100Mb (manual copy of /boot)
sdc2 raid
/dev/md0 is a raid5 using sda2/sdb2/sdc2, on that
Correct my if I'm wrong, but it looks like the patch file is not
actually in /usr/share/initramfs-tools/scripts? If you downloaded the
file to any other location, you need to specify the full path when
executing patch.
--
cannot boot raid1 with only one disk
I have created a patch for the initramfs-tools script as suggested by
Ken in this comment:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/120375/comments/47
In order to apply it (as root), cd /usr/share/initramfs-tools/scripts,
patch initramfs-mdadm-assemble-scan.patch, then
I have been fighting installing a RAID setup with 8.04 + GRUB for about
20 hours. My old setup used a CF card mounted as /boot but I can't get
that to work with some newer hardware and with grub and 8.04. This
worked fine under 6.x and 7.x... So I give up and set up a md RAID 1
partition as ext2
I added notes on how to adjust the ubuntu hotplug setup to cope with raid
devices at:
https://wiki.ubuntu.com/BootDegradedRaid
See under Implementation.
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member
So, just to summarize, we are stuck to ubuntu 7.10?
I would like to upgrade to 8.04 for many reasons, but to risk to find
myself with the same problem as before is unacceptable.
Do you guys think situation will improve by the time of 8.10 ?
Do you also find the following procedure suitable:
1)
didn't a previous poster say that this works fine in the current Debian?
So maybe the place to start is to identify what was changed from the
'base' Debian scripts, and why.
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because
** Also affects: initramfs-tools
Importance: Undecided
Status: New
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
You received this bug notification because you are a member of Ubuntu
Server Team, which is a subscriber of a duplicate bug.
--
You are probably correct, that some changes may be needed to initramfs-
tools.
I will be working on this for Intrepid. See:
* Blueprint:
https://blueprints.edge.launchpad.net/ubuntu/+spec/boot-degraded-raid
* Specification: https://wiki.ubuntu.com/BootDegradedRaid
:-Dustin
** Changed in:
77 matches
Mail list logo
