Prevent Debian from auto-assembling RAID at boot
I set up a Debian wheezy (7.6), installed openmediavault, and created a software raid 5 with that. It is listed at /dev/md127
.
Now I want to move that to a virtual XEN VM. To do so, I have to stop Debian to automatically assemble the raid at startup, so I can put it through to the VM via xm block-attach
, and I don't get that to work. No matter what I try, there is still md127
listed under /dev/
, and after every boot I can manually end it via mdadm --stop /dev/md127
. But even after that, it is still listed under /dev/
.
What I already tried:
/etc/mdadm/mdadm.conf: commented out array line:
#ARRAY /dev/md0 metadata=1.2 name=masterbox:MainRaid UUID=3f620e6d:4e655d66:b931eb71:baf7cf3a
ARRAY /dev/md0 name=Null
moved
/libs/udev/rules.d/64-md-raid.rules
to/root/
update-initramfs u
- commented out the line in
/etc/fstab
- disassembled raid manually via
mdadm --stop /dev/md127
set kernel parameter
raid=noautodetect
in/etc/default/grub
:
GRUB_CMDLINE_LINUX_DEFAULT="quiet raid=noautodetect"
rebooted
- disabled mdadm services at boot
Here's also the log from dmesg:
[ 3.448121] md: md127 stopped.
[ 3.452518] md: bind<sda>
[ 3.452747] md: bind<sdc>
[ 3.452933] md: bind<sdb>
[ 3.954794] md: raid6 personality registered for level 6
[ 3.954797] md: raid5 personality registered for level 5
[ 3.954799] md: raid4 personality registered for level 4
[ 3.955417] bio: create slab <bio-1> at 1
[ 3.955436] md/raid:md127: device sdb operational as raid disk 0
[ 3.955439] md/raid:md127: device sdc operational as raid disk 2
[ 3.955442] md/raid:md127: device sda operational as raid disk 1
[ 3.955740] md/raid:md127: allocated 3228kB
[ 3.955988] md/raid:md127: raid level 5 active with 3 out of 3 devices, algorithm 2
[ 3.955991] RAID conf printout:
[ 3.955993] --- level:5 rd:3 wd:3
[ 3.955996] disk 0, o:1, dev:sdb
[ 3.955999] disk 1, o:1, dev:sda
[ 3.956000] disk 2, o:1, dev:sdc
[ 3.956044] md127: detected capacity change from 0 to 6000916561920
... How can I bring Debian to not touch the raid drives at all, so I cann pass them to my VM?
debian startup raid initramfs
add a comment |
I set up a Debian wheezy (7.6), installed openmediavault, and created a software raid 5 with that. It is listed at /dev/md127
.
Now I want to move that to a virtual XEN VM. To do so, I have to stop Debian to automatically assemble the raid at startup, so I can put it through to the VM via xm block-attach
, and I don't get that to work. No matter what I try, there is still md127
listed under /dev/
, and after every boot I can manually end it via mdadm --stop /dev/md127
. But even after that, it is still listed under /dev/
.
What I already tried:
/etc/mdadm/mdadm.conf: commented out array line:
#ARRAY /dev/md0 metadata=1.2 name=masterbox:MainRaid UUID=3f620e6d:4e655d66:b931eb71:baf7cf3a
ARRAY /dev/md0 name=Null
moved
/libs/udev/rules.d/64-md-raid.rules
to/root/
update-initramfs u
- commented out the line in
/etc/fstab
- disassembled raid manually via
mdadm --stop /dev/md127
set kernel parameter
raid=noautodetect
in/etc/default/grub
:
GRUB_CMDLINE_LINUX_DEFAULT="quiet raid=noautodetect"
rebooted
- disabled mdadm services at boot
Here's also the log from dmesg:
[ 3.448121] md: md127 stopped.
[ 3.452518] md: bind<sda>
[ 3.452747] md: bind<sdc>
[ 3.452933] md: bind<sdb>
[ 3.954794] md: raid6 personality registered for level 6
[ 3.954797] md: raid5 personality registered for level 5
[ 3.954799] md: raid4 personality registered for level 4
[ 3.955417] bio: create slab <bio-1> at 1
[ 3.955436] md/raid:md127: device sdb operational as raid disk 0
[ 3.955439] md/raid:md127: device sdc operational as raid disk 2
[ 3.955442] md/raid:md127: device sda operational as raid disk 1
[ 3.955740] md/raid:md127: allocated 3228kB
[ 3.955988] md/raid:md127: raid level 5 active with 3 out of 3 devices, algorithm 2
[ 3.955991] RAID conf printout:
[ 3.955993] --- level:5 rd:3 wd:3
[ 3.955996] disk 0, o:1, dev:sdb
[ 3.955999] disk 1, o:1, dev:sda
[ 3.956000] disk 2, o:1, dev:sdc
[ 3.956044] md127: detected capacity change from 0 to 6000916561920
... How can I bring Debian to not touch the raid drives at all, so I cann pass them to my VM?
debian startup raid initramfs
Uninstallmdadm
from dom0? Unfortunately that assumes dom0 doesn't need any other RAID devices though.
– Celada
Nov 9 '14 at 22:01
@Celada: Yeah, I did this now and it solves my problem. Though it is of course not the best solution :p
– Droids
Nov 12 '14 at 9:04
Why don't you just pass the already assembled raid array to the domU instead of the individual disks?
– psusi
Oct 4 '15 at 19:29
Well, I wanted to let the NAS-Software in the VM to manage everything - from assembling drives to a raid, to assigning and sharing filesystems. The root-OS was supposed to really only host the VMs, and nothing more. Of course that would have been at least a simple solution. Sadly I cannot try it anymore, as I have re-installed my entire homeserver to a no-virtualization-solution.
– Droids
Oct 6 '15 at 10:20
add a comment |
I set up a Debian wheezy (7.6), installed openmediavault, and created a software raid 5 with that. It is listed at /dev/md127
.
Now I want to move that to a virtual XEN VM. To do so, I have to stop Debian to automatically assemble the raid at startup, so I can put it through to the VM via xm block-attach
, and I don't get that to work. No matter what I try, there is still md127
listed under /dev/
, and after every boot I can manually end it via mdadm --stop /dev/md127
. But even after that, it is still listed under /dev/
.
What I already tried:
/etc/mdadm/mdadm.conf: commented out array line:
#ARRAY /dev/md0 metadata=1.2 name=masterbox:MainRaid UUID=3f620e6d:4e655d66:b931eb71:baf7cf3a
ARRAY /dev/md0 name=Null
moved
/libs/udev/rules.d/64-md-raid.rules
to/root/
update-initramfs u
- commented out the line in
/etc/fstab
- disassembled raid manually via
mdadm --stop /dev/md127
set kernel parameter
raid=noautodetect
in/etc/default/grub
:
GRUB_CMDLINE_LINUX_DEFAULT="quiet raid=noautodetect"
rebooted
- disabled mdadm services at boot
Here's also the log from dmesg:
[ 3.448121] md: md127 stopped.
[ 3.452518] md: bind<sda>
[ 3.452747] md: bind<sdc>
[ 3.452933] md: bind<sdb>
[ 3.954794] md: raid6 personality registered for level 6
[ 3.954797] md: raid5 personality registered for level 5
[ 3.954799] md: raid4 personality registered for level 4
[ 3.955417] bio: create slab <bio-1> at 1
[ 3.955436] md/raid:md127: device sdb operational as raid disk 0
[ 3.955439] md/raid:md127: device sdc operational as raid disk 2
[ 3.955442] md/raid:md127: device sda operational as raid disk 1
[ 3.955740] md/raid:md127: allocated 3228kB
[ 3.955988] md/raid:md127: raid level 5 active with 3 out of 3 devices, algorithm 2
[ 3.955991] RAID conf printout:
[ 3.955993] --- level:5 rd:3 wd:3
[ 3.955996] disk 0, o:1, dev:sdb
[ 3.955999] disk 1, o:1, dev:sda
[ 3.956000] disk 2, o:1, dev:sdc
[ 3.956044] md127: detected capacity change from 0 to 6000916561920
... How can I bring Debian to not touch the raid drives at all, so I cann pass them to my VM?
debian startup raid initramfs
I set up a Debian wheezy (7.6), installed openmediavault, and created a software raid 5 with that. It is listed at /dev/md127
.
Now I want to move that to a virtual XEN VM. To do so, I have to stop Debian to automatically assemble the raid at startup, so I can put it through to the VM via xm block-attach
, and I don't get that to work. No matter what I try, there is still md127
listed under /dev/
, and after every boot I can manually end it via mdadm --stop /dev/md127
. But even after that, it is still listed under /dev/
.
What I already tried:
/etc/mdadm/mdadm.conf: commented out array line:
#ARRAY /dev/md0 metadata=1.2 name=masterbox:MainRaid UUID=3f620e6d:4e655d66:b931eb71:baf7cf3a
ARRAY /dev/md0 name=Null
moved
/libs/udev/rules.d/64-md-raid.rules
to/root/
update-initramfs u
- commented out the line in
/etc/fstab
- disassembled raid manually via
mdadm --stop /dev/md127
set kernel parameter
raid=noautodetect
in/etc/default/grub
:
GRUB_CMDLINE_LINUX_DEFAULT="quiet raid=noautodetect"
rebooted
- disabled mdadm services at boot
Here's also the log from dmesg:
[ 3.448121] md: md127 stopped.
[ 3.452518] md: bind<sda>
[ 3.452747] md: bind<sdc>
[ 3.452933] md: bind<sdb>
[ 3.954794] md: raid6 personality registered for level 6
[ 3.954797] md: raid5 personality registered for level 5
[ 3.954799] md: raid4 personality registered for level 4
[ 3.955417] bio: create slab <bio-1> at 1
[ 3.955436] md/raid:md127: device sdb operational as raid disk 0
[ 3.955439] md/raid:md127: device sdc operational as raid disk 2
[ 3.955442] md/raid:md127: device sda operational as raid disk 1
[ 3.955740] md/raid:md127: allocated 3228kB
[ 3.955988] md/raid:md127: raid level 5 active with 3 out of 3 devices, algorithm 2
[ 3.955991] RAID conf printout:
[ 3.955993] --- level:5 rd:3 wd:3
[ 3.955996] disk 0, o:1, dev:sdb
[ 3.955999] disk 1, o:1, dev:sda
[ 3.956000] disk 2, o:1, dev:sdc
[ 3.956044] md127: detected capacity change from 0 to 6000916561920
... How can I bring Debian to not touch the raid drives at all, so I cann pass them to my VM?
debian startup raid initramfs
debian startup raid initramfs
edited Oct 4 '15 at 18:07
Josip Rodin
931512
931512
asked Nov 7 '14 at 17:41
DroidsDroids
3615
3615
Uninstallmdadm
from dom0? Unfortunately that assumes dom0 doesn't need any other RAID devices though.
– Celada
Nov 9 '14 at 22:01
@Celada: Yeah, I did this now and it solves my problem. Though it is of course not the best solution :p
– Droids
Nov 12 '14 at 9:04
Why don't you just pass the already assembled raid array to the domU instead of the individual disks?
– psusi
Oct 4 '15 at 19:29
Well, I wanted to let the NAS-Software in the VM to manage everything - from assembling drives to a raid, to assigning and sharing filesystems. The root-OS was supposed to really only host the VMs, and nothing more. Of course that would have been at least a simple solution. Sadly I cannot try it anymore, as I have re-installed my entire homeserver to a no-virtualization-solution.
– Droids
Oct 6 '15 at 10:20
add a comment |
Uninstallmdadm
from dom0? Unfortunately that assumes dom0 doesn't need any other RAID devices though.
– Celada
Nov 9 '14 at 22:01
@Celada: Yeah, I did this now and it solves my problem. Though it is of course not the best solution :p
– Droids
Nov 12 '14 at 9:04
Why don't you just pass the already assembled raid array to the domU instead of the individual disks?
– psusi
Oct 4 '15 at 19:29
Well, I wanted to let the NAS-Software in the VM to manage everything - from assembling drives to a raid, to assigning and sharing filesystems. The root-OS was supposed to really only host the VMs, and nothing more. Of course that would have been at least a simple solution. Sadly I cannot try it anymore, as I have re-installed my entire homeserver to a no-virtualization-solution.
– Droids
Oct 6 '15 at 10:20
Uninstall
mdadm
from dom0? Unfortunately that assumes dom0 doesn't need any other RAID devices though.– Celada
Nov 9 '14 at 22:01
Uninstall
mdadm
from dom0? Unfortunately that assumes dom0 doesn't need any other RAID devices though.– Celada
Nov 9 '14 at 22:01
@Celada: Yeah, I did this now and it solves my problem. Though it is of course not the best solution :p
– Droids
Nov 12 '14 at 9:04
@Celada: Yeah, I did this now and it solves my problem. Though it is of course not the best solution :p
– Droids
Nov 12 '14 at 9:04
Why don't you just pass the already assembled raid array to the domU instead of the individual disks?
– psusi
Oct 4 '15 at 19:29
Why don't you just pass the already assembled raid array to the domU instead of the individual disks?
– psusi
Oct 4 '15 at 19:29
Well, I wanted to let the NAS-Software in the VM to manage everything - from assembling drives to a raid, to assigning and sharing filesystems. The root-OS was supposed to really only host the VMs, and nothing more. Of course that would have been at least a simple solution. Sadly I cannot try it anymore, as I have re-installed my entire homeserver to a no-virtualization-solution.
– Droids
Oct 6 '15 at 10:20
Well, I wanted to let the NAS-Software in the VM to manage everything - from assembling drives to a raid, to assigning and sharing filesystems. The root-OS was supposed to really only host the VMs, and nothing more. Of course that would have been at least a simple solution. Sadly I cannot try it anymore, as I have re-installed my entire homeserver to a no-virtualization-solution.
– Droids
Oct 6 '15 at 10:20
add a comment |
3 Answers
3
active
oldest
votes
You said you disabled the mdadm
service, but that service runs the monitoring deamon; there's a separate mdadm-raid
service that starts all md arrays in userland based on the configuration file. And, you can also run dpkg-reconfigure mdadm
to disable auto-starting arrays.
add a comment |
This is an old question, but since I searched quite long for a solution, I want to share my result:
# /etc/mdadm/mdadm.conf
ARRAY <ignore> UUID=3f620e6d:4e655d66:b931eb71:baf7cf3a
From man mdadm.conf
:
ARRAY The ARRAY lines identify actual arrays. The second word on the line may be the name of the device where the array
is normally assembled, such as /dev/md1 or /dev/md/backup. If the name does not start with a slash ('/'), it is
treated as being in /dev/md/. Alternately the word <ignore> (complete with angle brackets) can be given in which
case any array which matches the rest of the line will never be automatically assembled. If no device name is
given, mdadm will use various heuristics to determine an appropriate name.
Thx! I am using my installation without virtualization since then, but maybe I find the time to try the XEN approach again with your tip. Will update this post then.
– Droids
Nov 9 '17 at 11:04
Also I read somewhere here thatAUTO -all
inmdadm.conf
stops auto-assembling, but the whole file will be ignored, if it does not include anARRAY
line. So in order to ignore all arrays addARRAY <ignore> UUID=00000000:00000000:00000000:00000000
andAUTO -all
tomdadm.conf
(not tested).
– Toxiro
Nov 9 '17 at 15:26
add a comment |
On Ubuntu 18.04, this worked:
AUTO -all
ARRAY <ignore> UUID=00000000:00000000:00000000:00000000
Nothing was auto-assembled after that point.
New contributor
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f166688%2fprevent-debian-from-auto-assembling-raid-at-boot%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
You said you disabled the mdadm
service, but that service runs the monitoring deamon; there's a separate mdadm-raid
service that starts all md arrays in userland based on the configuration file. And, you can also run dpkg-reconfigure mdadm
to disable auto-starting arrays.
add a comment |
You said you disabled the mdadm
service, but that service runs the monitoring deamon; there's a separate mdadm-raid
service that starts all md arrays in userland based on the configuration file. And, you can also run dpkg-reconfigure mdadm
to disable auto-starting arrays.
add a comment |
You said you disabled the mdadm
service, but that service runs the monitoring deamon; there's a separate mdadm-raid
service that starts all md arrays in userland based on the configuration file. And, you can also run dpkg-reconfigure mdadm
to disable auto-starting arrays.
You said you disabled the mdadm
service, but that service runs the monitoring deamon; there's a separate mdadm-raid
service that starts all md arrays in userland based on the configuration file. And, you can also run dpkg-reconfigure mdadm
to disable auto-starting arrays.
answered Mar 5 '15 at 19:37
Josip RodinJosip Rodin
931512
931512
add a comment |
add a comment |
This is an old question, but since I searched quite long for a solution, I want to share my result:
# /etc/mdadm/mdadm.conf
ARRAY <ignore> UUID=3f620e6d:4e655d66:b931eb71:baf7cf3a
From man mdadm.conf
:
ARRAY The ARRAY lines identify actual arrays. The second word on the line may be the name of the device where the array
is normally assembled, such as /dev/md1 or /dev/md/backup. If the name does not start with a slash ('/'), it is
treated as being in /dev/md/. Alternately the word <ignore> (complete with angle brackets) can be given in which
case any array which matches the rest of the line will never be automatically assembled. If no device name is
given, mdadm will use various heuristics to determine an appropriate name.
Thx! I am using my installation without virtualization since then, but maybe I find the time to try the XEN approach again with your tip. Will update this post then.
– Droids
Nov 9 '17 at 11:04
Also I read somewhere here thatAUTO -all
inmdadm.conf
stops auto-assembling, but the whole file will be ignored, if it does not include anARRAY
line. So in order to ignore all arrays addARRAY <ignore> UUID=00000000:00000000:00000000:00000000
andAUTO -all
tomdadm.conf
(not tested).
– Toxiro
Nov 9 '17 at 15:26
add a comment |
This is an old question, but since I searched quite long for a solution, I want to share my result:
# /etc/mdadm/mdadm.conf
ARRAY <ignore> UUID=3f620e6d:4e655d66:b931eb71:baf7cf3a
From man mdadm.conf
:
ARRAY The ARRAY lines identify actual arrays. The second word on the line may be the name of the device where the array
is normally assembled, such as /dev/md1 or /dev/md/backup. If the name does not start with a slash ('/'), it is
treated as being in /dev/md/. Alternately the word <ignore> (complete with angle brackets) can be given in which
case any array which matches the rest of the line will never be automatically assembled. If no device name is
given, mdadm will use various heuristics to determine an appropriate name.
Thx! I am using my installation without virtualization since then, but maybe I find the time to try the XEN approach again with your tip. Will update this post then.
– Droids
Nov 9 '17 at 11:04
Also I read somewhere here thatAUTO -all
inmdadm.conf
stops auto-assembling, but the whole file will be ignored, if it does not include anARRAY
line. So in order to ignore all arrays addARRAY <ignore> UUID=00000000:00000000:00000000:00000000
andAUTO -all
tomdadm.conf
(not tested).
– Toxiro
Nov 9 '17 at 15:26
add a comment |
This is an old question, but since I searched quite long for a solution, I want to share my result:
# /etc/mdadm/mdadm.conf
ARRAY <ignore> UUID=3f620e6d:4e655d66:b931eb71:baf7cf3a
From man mdadm.conf
:
ARRAY The ARRAY lines identify actual arrays. The second word on the line may be the name of the device where the array
is normally assembled, such as /dev/md1 or /dev/md/backup. If the name does not start with a slash ('/'), it is
treated as being in /dev/md/. Alternately the word <ignore> (complete with angle brackets) can be given in which
case any array which matches the rest of the line will never be automatically assembled. If no device name is
given, mdadm will use various heuristics to determine an appropriate name.
This is an old question, but since I searched quite long for a solution, I want to share my result:
# /etc/mdadm/mdadm.conf
ARRAY <ignore> UUID=3f620e6d:4e655d66:b931eb71:baf7cf3a
From man mdadm.conf
:
ARRAY The ARRAY lines identify actual arrays. The second word on the line may be the name of the device where the array
is normally assembled, such as /dev/md1 or /dev/md/backup. If the name does not start with a slash ('/'), it is
treated as being in /dev/md/. Alternately the word <ignore> (complete with angle brackets) can be given in which
case any array which matches the rest of the line will never be automatically assembled. If no device name is
given, mdadm will use various heuristics to determine an appropriate name.
answered Nov 9 '17 at 10:54
ToxiroToxiro
211
211
Thx! I am using my installation without virtualization since then, but maybe I find the time to try the XEN approach again with your tip. Will update this post then.
– Droids
Nov 9 '17 at 11:04
Also I read somewhere here thatAUTO -all
inmdadm.conf
stops auto-assembling, but the whole file will be ignored, if it does not include anARRAY
line. So in order to ignore all arrays addARRAY <ignore> UUID=00000000:00000000:00000000:00000000
andAUTO -all
tomdadm.conf
(not tested).
– Toxiro
Nov 9 '17 at 15:26
add a comment |
Thx! I am using my installation without virtualization since then, but maybe I find the time to try the XEN approach again with your tip. Will update this post then.
– Droids
Nov 9 '17 at 11:04
Also I read somewhere here thatAUTO -all
inmdadm.conf
stops auto-assembling, but the whole file will be ignored, if it does not include anARRAY
line. So in order to ignore all arrays addARRAY <ignore> UUID=00000000:00000000:00000000:00000000
andAUTO -all
tomdadm.conf
(not tested).
– Toxiro
Nov 9 '17 at 15:26
Thx! I am using my installation without virtualization since then, but maybe I find the time to try the XEN approach again with your tip. Will update this post then.
– Droids
Nov 9 '17 at 11:04
Thx! I am using my installation without virtualization since then, but maybe I find the time to try the XEN approach again with your tip. Will update this post then.
– Droids
Nov 9 '17 at 11:04
Also I read somewhere here that
AUTO -all
in mdadm.conf
stops auto-assembling, but the whole file will be ignored, if it does not include an ARRAY
line. So in order to ignore all arrays add ARRAY <ignore> UUID=00000000:00000000:00000000:00000000
and AUTO -all
to mdadm.conf
(not tested).– Toxiro
Nov 9 '17 at 15:26
Also I read somewhere here that
AUTO -all
in mdadm.conf
stops auto-assembling, but the whole file will be ignored, if it does not include an ARRAY
line. So in order to ignore all arrays add ARRAY <ignore> UUID=00000000:00000000:00000000:00000000
and AUTO -all
to mdadm.conf
(not tested).– Toxiro
Nov 9 '17 at 15:26
add a comment |
On Ubuntu 18.04, this worked:
AUTO -all
ARRAY <ignore> UUID=00000000:00000000:00000000:00000000
Nothing was auto-assembled after that point.
New contributor
add a comment |
On Ubuntu 18.04, this worked:
AUTO -all
ARRAY <ignore> UUID=00000000:00000000:00000000:00000000
Nothing was auto-assembled after that point.
New contributor
add a comment |
On Ubuntu 18.04, this worked:
AUTO -all
ARRAY <ignore> UUID=00000000:00000000:00000000:00000000
Nothing was auto-assembled after that point.
New contributor
On Ubuntu 18.04, this worked:
AUTO -all
ARRAY <ignore> UUID=00000000:00000000:00000000:00000000
Nothing was auto-assembled after that point.
New contributor
New contributor
answered 1 hour ago
SlawomirSlawomir
1011
1011
New contributor
New contributor
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f166688%2fprevent-debian-from-auto-assembling-raid-at-boot%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Uninstall
mdadm
from dom0? Unfortunately that assumes dom0 doesn't need any other RAID devices though.– Celada
Nov 9 '14 at 22:01
@Celada: Yeah, I did this now and it solves my problem. Though it is of course not the best solution :p
– Droids
Nov 12 '14 at 9:04
Why don't you just pass the already assembled raid array to the domU instead of the individual disks?
– psusi
Oct 4 '15 at 19:29
Well, I wanted to let the NAS-Software in the VM to manage everything - from assembling drives to a raid, to assigning and sharing filesystems. The root-OS was supposed to really only host the VMs, and nothing more. Of course that would have been at least a simple solution. Sadly I cannot try it anymore, as I have re-installed my entire homeserver to a no-virtualization-solution.
– Droids
Oct 6 '15 at 10:20