13.1 x64 hangs after installation -- Dependency failed for Local File Systems

I just installed OpenSUSE 13.1 x64 in a machine with the followimng specs:

ASUS P5K-Deluxe motherboard
Intel Q6600 quad-core CPU
8 GB RAM
2 Seagate ST3500320AS 500 GB hd’s forming an INTEL ICH9R RAID0 BIOS array that contains Windows 7 Ultimate x64 NTFS installation.
1 Seagate ST31000333AS 1 TB hd containing OpenSUSE 12.3 i586 ext4 installation.
2 WD WDC-WD2500AAJB-0 250 GB hd’s forming an OpenSUSE software RAID0 array that contains OpenSUSE 13.1 x64 ext4 installation.

The 13.1 system boots itself and the other two systems using GRUB2. The 12.3 dualboots itself and Windows 7, also through GRUB2. The Windows 7 bootloader just boots itself.

OpenSUSE 12.3 has no problems whatsoever in mounting/reading/writing the Windows 7 ICH9R RAID0 partition.

OpenSUSE 13.1 once installed, however, refuses to load and hangs every time at the following part of the startup procedure, comments in parentheses are mine:


‘Started Apply Kernel Variables’ (a very long wait)
[DEPEND] 'Dependency failed for /win7c
[DEPEND] ‘Dependency failed for Local File Systems’
‘Welcome to Emergency Mode!’ (etc, etc.)

Once it shows the Emergency Mode warning, OpenSUSE 13.1 hangs. It will not let you log in and it will not accept any other command except a Ctrl-Alt-Del reboot.

I have reinstalled 13.1 five times, and have tried specifying fstab mount points for the Windows 7 ICH9R array by id, by UUID, by name, etc. to no avail.

Obviously, 13.1 sees and and is fully aware of the Windows 7 ICH9R RAID0 BIOS array. The problem lies in 13.1’s inability to mount it at boot. It seems 13.1 is lacking a certain kernel module or an arcane configuration (systemd perhaps?) that would permit the array to be mounted.

I have spent several days researching this problem everywhere in the 'net to no useful answers. I would GREATLY appreciate any help to solve this problem. My interest in 13.1 is due to its ‘Evergreen’ designation, as it would allow me to use and fully maintain the system for a few years longer than 12.3.

Thanks!

You should enter your root password there to get into emergency mode, where you could then fix your fstab or whatever needs fixing.

That said, try to add the “nofail” option to your entries (or only the offending entry if you know which one) in the fstab. openSUSE should at least bootup then without mounting it.
See here: nofail option in /et/fstab | eazynet.de

Then try to run “systemctl status /win7c” to maybe find out why it cannot be mounted.

Thanks for your reply, wolfi. When 13.1 hangs it will not accept any kind of further input, no username, no password, nothing. Therefore, I cannot run systemctl.

I have manually mounted the system to init 3 through the repair console in the 13.1 DVD and have experimented through YAST2 redoing mount points, etc. No solutions. I will try mounting the system with the nofail option you describe and see if I can run systemctl then.

It is essential for me to be able to mount/read/write my Win 7 partition through 13.1.

But it would be easier to investigate what’s the problem if the system boots up and runs…

I do share your suspicion that there’s some kernel module missing, so it cannot see the RAID.

On 2013-11-24 13:46, rgutierrezg wrote:

> Obviously, 13.1 sees and and is fully aware of the Windows 7 ICH9R RAID0
> BIOS array. The problem lies in 13.1’s inability to mount it at boot. It
> seems 13.1 is lacking a certain kernel module or an arcane configuration
> (systemd perhaps?) that would permit the array to be mounted.

Then don’t mount it. Add “noauto,nofail” to it.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Here again, wolfi.

I manually booted into the system through the repair console of the DVD. I added the ‘nofail’ argument to the /win7c fstab entry like you said and I then was able to successfully reboot and login to 13.1. Once into 13.1 I ran systemctl as you suggested, and here are the results:

*systemctl status /win7c -l
*
win7c.mount - /win7c

  • Loaded: loaded (/etc/fstab)*

  • Active: inactive (dead)*

  • Where: /win7c*

  • What: /dev/disk/by-id/raid-isw_gjbidegbe_RVolume-part2*
    

Nov 24 09:39:54 linux systemd[1]: Dependency failed for /win7c.
Nov 24 09:41:44 linux-jpqp systemd[1]: Dependency failed for /win7c.
Nov 24 09:45:52 linux-jpqp systemd[1]: Dependency failed for /win7c.

As you can see, it indicates that /win7c is loaded in fstab, but it is inactive (dead).

But you know what? Despite the systemctl report as to /win7c being inactive/dead, 13.1 DID mount my Windows 7 RAID0 partition, but under its Windows name RVolC, not win7c as I intended for its 13.1 mount.

I was able to read/write and in general transfer documents back-and-forth from 13.1 to Win 7 and viceversa, apparently with no problems, In addition, I was able to do the same (as expected) with 13.1 to 12.3; as a matter of fact, the above report quote came from 13.1 into my 12.3 installatio from where I am writing this reply.

So everything seems to be working as desired. However, I am concerned about running 13.1 in this sort of ‘mount limbo’ which obviously is due to some missing or incorrect system kernel or other configuration. I would like to be able to correct this completely, if possible before actually starting to migrate my 12.3 platform to 13.1. Can you shed any further insights?

At any rate I truly, truly thank you, wolfi, because you gave me the key I needed to be able to make 13.1 bootable. Now, with it working (along with my old 12.3), I can research and implement with your and the forum’s kind help any permanent fixes that might solve for good this conundrum.

Again, many thanks!

Hi, Carlos! Thank you for your reply. Please refer to my comments to wolfi, above or below this reply to you.

Basically I added the nofail argument to fstab and then I was able to boot unimpeded into 13.1, and despite systemctl advising that the /win7c mount was inactive/dead, 13.1 had mounted it anyway but under its Windows partition name RVolC, not win7c as I intended for 13.1.

Two question for you: In view of the above, wouldn’t adding the ‘noauto’ argument you suggest to fstab be unnecessary since 13.1 is reading and writing the Win 7 partition apparently correctly despite systemctl reporting it dead? Can you please add any further insight to fix permanently this quandary? I appreciate your help.

On 2013-11-24 16:36, rgutierrezg wrote:

> Hi, Carlos! Thank you for your reply. Please refer to my comments to
> wolfi, above or below this reply to you.

I did.

> Basically I added the nofail argument to fstab and then I was able to
> boot unimpeded into 13.1, and despite systemctl advising that the /win7c
> mount was inactive/dead, 13.1 had mounted it anyway but under its
> Windows partition name RVolC, not win7c as I intended for 13.1.
>
> Two question for you: In view of the above, wouldn’t adding the ‘noauto’
> argument you suggest to fstab be unnecessary since 13.1 is reading and
> writing the Win 7 partition apparently correctly despite systemctl
> reporting it dead? Can you please add any further insight to fix
> permanently this quandary? I appreciate your help.

I think it is being automatically mounted by the desktop with perhaps
different options, that work, or mounted later, at some other instant in
the boot sequence. maybe initrd tries to mount it and fail, needs some
module.

The output of “mount” will tell you what options it is using.

Maybe the device node has changed.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Is boot.dmraid active?

systemctl status dmraid.service
chkconfig --list boot.dmraid

Do you have rsyslog installed? Or probably other syslog implementation?

Loaded just means, that systemd knows about it.
Unfortunately there’s no information why it failed.

But you know what? Despite the systemctl report as to /win7c being inactive/dead, 13.1 DID mount my Windows 7 RAID0 partition, but under its Windows name RVolC, not win7c as I intended for its 13.1 mount.

It gets mounted to /RVolC, or do I misunderstand you?
Hm.
You’ll get “RVolC” if you take “win7c” and overwrite the first 4 characters with the ones from “RVolume-part2*”. *:wink:

Could you maybe post the fstab?

Maybe you’ll find more information why it fails in journalctl…

Hi, Carlos!

There is NO mention whatsoever of /win7c or RVolC in themount dialog results. All other systems /dev/md0 (13.1), /dev/sdb2 (12.3) are mentioned as expected:

*/dev/md0 on / type ext4 (rw,relatime,stripe=16,data=ordered)
/dev/sdb2 on /os123 type ext4 (rw,relatime,data=ordered)

*All other 13.1 partitions are mentioned properly as well. Any other thoughts? Thanks!

Still like to actually see your /etc/fstab

Hi, Arvid! Thank you for your kind help.

systemctl showed the following information (I highlighted **bold **sections) :

*dmraid.service - LSB: start dmraid
Loaded: loaded (/etc/init.d/boot.dmraid)
Active: active (exited) since Sun 2013-11-24 15:11:19 AST; 23min ago
Process: 356 ExecStart=/etc/init.d/boot.dmraid start (code=exited, status=0/SUCCESS)

Nov 24 15:11:13 linux-jpqp boot.dmraid[356]: Waiting for udev to settle…
Nov 24 15:11:18 linux-jpqp boot.dmraid[356]: Activating dmraid…
Nov 24 15:11:19 linux-jpqp boot.dmraid[356]: RAID set “isw_gjbidegbe_RVolume” was not activated
Nov 24 15:11:19 linux-jpqp boot.dmraid[356]: ERROR: device “isw_gjbidegbe_RVolume” could not be found
Nov 24 15:11:19 linux-jpqp boot.dmraid[356]: …done
Nov 24 15:11:19 linux-jpqp systemd[1]: Started LSB: start dmraid.*

And yet, when I look it up in Dolphin, it is completely there… but, wait! when I went to open it the system opened a dialog stating

’Authentication is required to mount /dev/md/126p2’

it asks for the root password. Once this is entered, it is fully available. Now that I remember, since I started 13,1 for the first time it has asked for the root password to make the Win 7 partition available although according to the system it is nowhere to be found. Wow!

As for chkconfig --list boot.dmraid, it yields the following dialog:

*chkconfig --list boot.dmraid

Note: This output shows SysV services only and does not include native
systemd services. SysV configuration data might be overridden by native
systemd configuration.

boot.dmraid 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on* (B:on, the little smily face icon I cannot get rid of, sorry.)

So it is only running at boot level, and not at 3 or 5, according to the dialog. Any further ideas?

Again, many thanks!

Thanks, Gogal!

Here’s my /etc/fstab:

/dev/disk/by-id/ata-WDC_WD2500AAJB-00J3A0_WD-WCAV2H078403-part2 swap swap defaults 0 0
/dev/disk/by-id/md-uuid-fdcccfd4:a19ff6dc:b8135948:203855fb / ext4 acl,user_xattr 1 1
/dev/disk/by-id/ata-WDC_WD2500AAJB-00J3A0_WD-WCAV2H078403-part1 /boot ext4 acl,user_xattr 1 2
/dev/disk/by-id/ata-ST31000333AS_6TE0DSH9-part2 /os123 ext4 defaults 1 2
/dev/disk/by-id/raid-isw_gjbidegbe_RVolume-part2 /win7c ntfs-3g nofail,users,gid=users,fmask=133,dmask=022,locale=en_US.UTF-8 0 0

Ideas?

Thanks, wolfi!

To the left of every Dolphin dialog the Win 7 partition gets referred to as RVolC. But when you actually go into it, within the root folder it gets listed as win7c.

I checked journalctl as root and I do not see anything at all that could readily be linked to the problem, and there’s no mention whatsoever to the Win 7 array or partition.

Here’s the fstab:

/dev/disk/by-id/ata-WDC_WD2500AAJB-00J3A0_WD-WCAV2H078403-part2 swap swap defaults 0 0
/dev/disk/by-id/md-uuid-fdcccfd4:a19ff6dc:b8135948:203855fb / ext4 acl,user_xattr 1 1
/dev/disk/by-id/ata-WDC_WD2500AAJB-00J3A0_WD-WCAV2H078403-part1 /boot ext4 acl,user_xattr 1 2
/dev/disk/by-id/ata-ST31000333AS_6TE0DSH9-part2 /os123 ext4 defaults 1 2
/dev/disk/by-id/raid-isw_gjbidegbe_RVolume-part2 /win7c ntfs-3g nofail,users,gid=users,fmask=133,dmask=022,locale=en_US.UTF-8 0 0

I have to sign off for today. It is Sunday evening here and I need to attend to other matters. But I’ll be back tomorrow late afternoon, God willing. Many thanks to all you fine people for trying to help me !!!

So it is mounted to /win7c. Just the label in dolphin’s Places is RVolC? Maybe an abbreviation because there’s not enough visual space? :wink:

And btw, if you click on the drive in dolphin, it gets mounted before it is opened.

So most probably it is not mounted on boot (because of the error), but only by dolphin when you click on it.
That would suggest that you would have to add the needed kernel module to the initrd.
See /etc/sysconfig/kernel (“INITRD_MODULES”).
How to find out which one I don’t know. Maybe “lspci -nnk” would tell (to be sure the module is loaded, open it in dolphin before that). Or look in YaST->Hardware->Hardware Information, that should show the kernel module as well.

On 2013-11-24 20:36, rgutierrezg wrote:
> There is NO mention whatsoever of /win7c or RVolC in themount dialog
> results. All other systems /dev/md0 (13.1), /dev/sdb2 (12.3) are
> mentioned as expected:

Was that after that it was mounted? It must be listed somewhere. Has to.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)