I was apparently missing something like the raid1 kernel module in the initramfs in my fedora 21 partition, but I disabled the mdmonitor service and removed the raid filesystem from the /etc/fstab, yet the system still could not boot. It spent several minutes trying to recognize the raided disks then went into the dracut shell.
Should it really be utterly impossible to boot a system that merely has raided disks connected to it which no one is trying to reference? Should I make a kernel bug for this?
On 03/25/2015 04:26 AM, Tom Horsley wrote:
I was apparently missing something like the raid1 kernel module in the initramfs in my fedora 21 partition, but I disabled the mdmonitor service and removed the raid filesystem from the /etc/fstab, yet the system still could not boot. It spent several minutes trying to recognize the raided disks then went into the dracut shell.
Should it really be utterly impossible to boot a system that merely has raided disks connected to it which no one is trying to reference? Should I make a kernel bug for this?
I believe grub* will ignore things in /etc/fstab marked as "noauto" as they aren't to be mounted at boot time so the lack of the md module wouldn't matter. Things that don't have "noauto" set will be mounted by "mount -a" at some early time in the multiuser boot sequence. Remember that fstab doesn't indicate it's a RAID, just a disk and/or partition, so the system doesn't know to have the RAID module loaded unless it's in the modprobe stuff.
I don't think the system was unbootable (at least to single-user mode). Single user mode just needs the kernel running and the root filesystem mounted. Other run levels will start mounting up things in /etc/fstab and if it doesn't have "noauto", the system is going to assume it's needed.
The last part of your question implies that you're asking grub to predict if some program started at boot time is going to reference that RAID or not. That's a big ask. So, tag it as "noauto" in fstab and manually mount it in the equivalent of "rc.local" or ensure that the md module is in your modprobe configs so grub picks it up on a update to the grub environment. Don't expect grub to figure out if the disk is actually being used. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - If you can't beat your computer at chess...try kickboxing! - ----------------------------------------------------------------------
On Wed, 25 Mar 2015 10:06:27 -0700 Rick Stevens wrote:
The last part of your question implies that you're asking grub to predict if some program started at boot time is going to reference that RAID or not.
It was well past grub, the kernel was booting up and enumerating all the disks in udev (I think), and it claimed it never recognized a device (how it knew there should have been a device to recognize, I don't know :-). The dracut shell said something like "exit to continue", and I tried exiting, but nothing ever really continued.
On 03/25/2015 07:26 AM, Tom Horsley wrote:
I was apparently missing something like the raid1 kernel module in the initramfs in my fedora 21 partition, but I disabled the mdmonitor service and removed the raid filesystem from the /etc/fstab, yet the system still could not boot. It spent several minutes trying to recognize the raided disks then went into the dracut shell.
Should it really be utterly impossible to boot a system that merely has raided disks connected to it which no one is trying to reference? Should I make a kernel bug for this?
If there is an entry in /etc/fstab for ANY UUID that it can't find, it won't boot... I have run into that problem MANY times... I have to go in & comment out all entries except / and /home ( assuming it can find them), then it boots..
On Wed, 25 Mar 2015 13:24:01 -0400 Paul Cartwright wrote:
If there is an entry in /etc/fstab for ANY UUID that it can't find, it won't boot... I have run into that problem MANY times... I have to go in & comment out all entries except / and /home ( assuming it can find them), then it boots..
I explicitly removed the fstab entries so there wouldn't be anyone referencing the disks, but it apparently gets upset simply because the disks are plugged in (I had some version of the Windows XP installer do that to me once - it wouldn't ever get as far as letting me install if there was any EXT3 disk partition visible on the system - it would just hang).
On Wed, 2015-03-25 at 14:05 -0400, Tom Horsley wrote:
On Wed, 25 Mar 2015 13:24:01 -0400 Paul Cartwright wrote:
If there is an entry in /etc/fstab for ANY UUID that it can't find, it won't boot... I have run into that problem MANY times... I have to go in & comment out all entries except / and /home ( assuming it can find them), then it boots..
I explicitly removed the fstab entries so there wouldn't be anyone referencing the disks, but it apparently gets upset simply because the disks are plugged in (I had some version of the Windows XP installer do that to me once - it wouldn't ever get as far as letting me install if there was any EXT3 disk partition visible on the system - it would just hang).
You might have to update dracut, too.
I'm not sure what the relationship between dracut and RAID configuration is. Are RAIDs entered into the initramfs?
RBM
On 03/25/2015 11:05 AM, Tom Horsley wrote:
On Wed, 25 Mar 2015 13:24:01 -0400 Paul Cartwright wrote:
If there is an entry in /etc/fstab for ANY UUID that it can't find, it won't boot... I have run into that problem MANY times... I have to go in & comment out all entries except / and /home ( assuming it can find them), then it boots..
Even if it's tagged "noauto" in the options field? I haven't tried it using UUIDs, but LABELs have no issue. To wit, I have these:
# 500GB USB drive via label... LABEL=500GB-Drive /media/500GB-Drive ext4 noauto 0 0 # External ESATA drive LABEL=500GB-ESATA /media/500GB-ESATA ext3 noauto,defaults 0 0
and the system boots just fine if the drives aren't connected. I'll have to try UUIDs just to see. Dammit, now you've got me curious! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Animal testing is futile. They always get nervous and give the - - wrong answers - ----------------------------------------------------------------------
On 03/25/2015 11:33 AM, Ronal B Morse wrote:
On Wed, 2015-03-25 at 14:05 -0400, Tom Horsley wrote:
On Wed, 25 Mar 2015 13:24:01 -0400 Paul Cartwright wrote:
If there is an entry in /etc/fstab for ANY UUID that it can't find, it won't boot... I have run into that problem MANY times... I have to go in & comment out all entries except / and /home ( assuming it can find them), then it boots..
I explicitly removed the fstab entries so there wouldn't be anyone referencing the disks, but it apparently gets upset simply because the disks are plugged in (I had some version of the Windows XP installer do that to me once - it wouldn't ever get as far as letting me install if there was any EXT3 disk partition visible on the system - it would just hang).
You might have to update dracut, too.
I'm not sure what the relationship between dracut and RAID configuration is. Are RAIDs entered into the initramfs?
That is the discussion. I rarely use software RAIDs (I much prefer to buy hardware RAID controllers), but I'd think a software RAID that is required by the fstab at the time of the dracut invocation (and by that I mean that the fstab says it's used when you run dracut--not that the drive is really needed at boot or even mounted whe dracut is run), dracut would have to include the appropriate md driver in the initramfs so the kernel can assemble the RAID at boot time. I think dracut scans the fstab, the fstab says it's supposed to be there, therefore the kernel has to assemble it and it needs the drivers to do it.
If you don't need the RAID at boot, then I think tagging the entry as "noauto" in fstab would obviate that need. Of course, that assumes dracut skips entries with that tag. If that's the case, you would have to mount it manually, however, once the system came up. However, someone else has said that so long as the fstab has it tagged via a UUID, e.g.
UUID=cc48bc1d-3c2e-477a-a276-9b9dbb896637
it's irrelevant whether "noauto" is specified and you'd need the drivers in the initramfs and the system will try to mount the beblistered thing. My systems boot fine with drives tagged "noauto" not being plugged in, but I identify them with LABELs, not UUIDs or device names:
LABEL=500GB_USB ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Always remember you're unique, just like everyone else. - ----------------------------------------------------------------------
On Wed, 25 Mar 2015 12:33:24 -0600 Ronal B Morse wrote:
You might have to update dracut, too.
I'm not sure what the relationship between dracut and RAID configuration is. Are RAIDs entered into the initramfs?
I don't know if any raid config info is in there, but it definitely needs additional drivers in the initramfs (that's how I eventually got the system to boot).
I'm suspecting it knows enough to recognize the some of the raid metadata then gets upset because there is no raid driver loaded. I just wonder if the response to that could be more useful than hanging forever :-).
you now need "nofail" as an option so the automatic systemd crap will not stop on a missing fs.
And I have also noticed that once systemd parses the fstab file changing it won't work, you have to reboot it to get it to figure out you removed it.
There is probably a way to cancel what systemd is doing, but rebooting after updating fstab is simpler.
Using nofail and/or updating fstab (removing entries) has allowed me to reboot the machine and get it up--but you have to fix the issue or make changes and reboot to get systemd to not keep trying.
On Wed, Mar 25, 2015 at 3:05 PM, Tom Horsley horsley1953@gmail.com wrote:
On Wed, 25 Mar 2015 12:33:24 -0600 Ronal B Morse wrote:
You might have to update dracut, too.
I'm not sure what the relationship between dracut and RAID configuration is. Are RAIDs entered into the initramfs?
I don't know if any raid config info is in there, but it definitely needs additional drivers in the initramfs (that's how I eventually got the system to boot).
I'm suspecting it knows enough to recognize the some of the raid metadata then gets upset because there is no raid driver loaded. I just wonder if the response to that could be more useful than hanging forever :-). -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On Wed, Mar 25, 2015 at 4:54 PM, Roger Heflin rogerheflin@gmail.com wrote:
On Wed, Mar 25, 2015 at 3:05 PM, Tom Horsley horsley1953@gmail.com wrote:
On Wed, 25 Mar 2015 12:33:24 -0600, Ronal B Morse wrote:
You might have to update dracut, too.
I'm not sure what the relationship between dracut and RAID configuration is. Are RAIDs entered into the initramfs?
I don't know if any raid config info is in there, but it definitely needs additional drivers in the initramfs (that's how I eventually got the system to boot).
I'm suspecting it knows enough to recognize the some of the raid metadata then gets upset because there is no raid driver loaded. I just wonder if the response to that could be more useful than hanging forever :-).
you now need "nofail" as an option so the automatic systemd crap will not stop on a missing fs.
And I have also noticed that once systemd parses the fstab file changing it won't work, you have to reboot it to get it to figure out you removed it.
There is probably a way to cancel what systemd is doing, but rebooting after updating fstab is simpler.
Using nofail and/or updating fstab (removing entries) has allowed me to reboot the machine and get it up--but you have to fix the issue or make changes and reboot to get systemd to not keep trying.
Please bottom post.
When systemd parses "/etc/fstab", it creates .mount units in "/run/systemd/generator{,.late}/", so don't necessarily need to reboot. You could edit "/etc/fstab", edit the .mount unit(s), run "systemctl daemon-reload", and restart the .mount unit(s).
On 25.03.2015 12:26, Tom Horsley wrote:
I was apparently missing something like the raid1 kernel module in the initramfs in my fedora 21 partition, but I disabled the mdmonitor service and removed the raid filesystem from the /etc/fstab, yet the system still could not boot. It spent several minutes trying to recognize the raided disks then went into the dracut shell.
Should it really be utterly impossible to boot a system that merely has raided disks connected to it which no one is trying to reference? Should I make a kernel bug for this?
See if this is relevant:
dracut, degraded md arrays, resume and systemd. http://www.spinics.net/lists/linux-initramfs/msg03979.html
dracut: fix various issues with newly degraded md arrays http://www.spinics.net/lists/linux-initramfs/msg03990.html
mdraid fixes #58 https://github.com/haraldh/dracut/pull/58/files
On Fri, 27 Mar 2015 18:06:15 +0100 poma wrote:
See if this is relevant:
I don't think so. It definitely wasn't a degraded array - it was brand new with both disks involved operating fine. It was also simply a data disk, the boot and swap partitions were not on the raid.
I suspect it just didn't have kernel modules it needed in the initramfs. It was never able to recognize the disks (at least that's what it seemed to be saying in the boot messages).
When I booted off an f21 live USB, it had no problems. I'm not sure how the heck the initramfs normally gets built on a kernel update. I didn't see anything automatically applying the hostonly option, but when I updated the kernel in the fedora 21 boot partition by chrooting into it from the live USB session, the newly installed kernel was able to boot just fine, so the new update apparently included whatever was missing previously.
On 27.03.2015 21:10, Tom Horsley wrote:
On Fri, 27 Mar 2015 18:06:15 +0100 poma wrote:
See if this is relevant:
I don't think so. It definitely wasn't a degraded array - it was brand new with both disks involved operating fine. It was also simply a data disk, the boot and swap partitions were not on the raid.
I suspect it just didn't have kernel modules it needed in the initramfs. It was never able to recognize the disks (at least that's what it seemed to be saying in the boot messages).
When I booted off an f21 live USB, it had no problems. I'm not sure how the heck the initramfs normally gets built on a kernel update. I didn't see anything automatically applying the hostonly option, but when I updated the kernel in the fedora 21 boot partition by chrooting into it from the live USB session, the newly installed kernel was able to boot just fine, so the new update apparently included whatever was missing previously.
This line should lead you to the end of the kernel installation road: http://pkgs.fedoraproject.org/cgit/kernel.git/tree/kernel.spec#n2030
On Wed, Mar 25, 2015 at 5:26 AM, Tom Horsley horsley1953@gmail.com wrote:
I was apparently missing something like the raid1 kernel module in the initramfs in my fedora 21 partition, but I disabled the mdmonitor service and removed the raid filesystem from the /etc/fstab, yet the system still could not boot. It spent several minutes trying to recognize the raided disks then went into the dracut shell.
There should be a reference to an automatically generated rdsosreport.txt for you to post.
If not, then post the output from journalctl -b -l -o short-monotonic
Should it really be utterly impossible to boot a system that merely has raided disks connected to it which no one is trying to reference? Should I make a kernel bug for this?
No. And no, seems premature. I didn't have to make a special initramfs or even create mdadm.conf in order for a post-install created raid1 to be picked up and activated automatically at boot. It's only activated, not mounted, and the boot didn't fail. So without more information it's difficult to help.
On Fri, Mar 27, 2015 at 2:10 PM, Tom Horsley horsley1953@gmail.com wrote:
but when I updated the kernel in the fedora 21 boot partition by chrooting into it from the live USB session, the newly installed kernel was able to boot just fine, so the new update apparently included whatever was missing previously.
Ahh. That sorta sounds like possibly a dracut bug affected the original initramfs you had. So then dracut gets updated, and kernel update causes a new initramfs to be generated with updated dracut, and so the problem seems magically fixed.
-
Chris Murphy -
Paul Cartwright -
poma -
Rick Stevens -
Roger Heflin -
Ronal B Morse -
Tom H -
Tom Horsley