I’ve been using OpenSUSE 13.1 for the pas few weeks, no big probs.
Today, I can’t access the login screen : I’m stuck with the splash screen.
I rebooted on emergency mode, and the boot sequence seems to be caught in a loop. At some point, it just says :
Welcome to emergency mode! After loggin in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot in default mode
systemd-journald [XXX]: Received request to flush runtime journal from PID 1
XXX being , 292 or 290, the 2 times I made the experiment.
This 3 or 4 times, then “welcome to ermergency mode!” again, then systemd-journald resquest, same numbers, again and again. No way I can get a working terminal.
Inability to enter emergency mode is bug https://bugzilla.novell.com/show_bug.cgi?id=852021. Almost the only reason for systemd to enter emergency mode is failure to mount filesystem defined in /etc/fstab; so you need to check what is there and probably comment out those you do not need, so you can boot and investigate it further.
Sounds like corrupted file system you may try running fsck on it but to be honest I’m not sure the BTRFS tool chain is really totally working yet so I’m not sure about a real recovery.
Use a live DVD or the recovery CD images to boot from and you maybe able to fix it. But history is not good on that point. If you don’t want to experment with cutting edge file systems you might want to reinstall with ext4
Ok. I’ll try that. Since the opensuse news said that “The btrfs file system has received a serious workout and while not default, is considered stable for everyday usage”, I thought it was no longer considered “cutting edge file system”. My bad
It is ok as long as all goes well the problem is recovery from corruption. Also it seems a little less able to resist problems like loss of power or improper shut downs then say ext4.
There was a push on to make btrfs the default for 13.1 and it may be for 13.2. IMHO that is a huge mistake. For one thing it ships with the snapshot function on and pretty aggressive so you need to double the size of a partition to allow for the snaps. This is not going to be obvious to the naive user. Also most of the bells and whistles it promises I don’t see much use for on the average desktop. And even so there are still a lot of those B&W are not actually ready yet. So currently it is not even feature complete.
You should probably report this problem on bugzilla. But we don’t really understand how you got to this state so I’m not sure if will help you directly but it may alert the developers to the real world problems .
So did you try fsck from a 13.1 live DVD or the 13.1 rescue CD? It might work maybe.
linux:/home/linux # btrfsck /dev/sdb6
Checking filesystem on /dev/sdb6
UUID: 9bcac83a-e18f-4f9d-b9f2-b65be34d6938
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 1526216793 bytes used err is 0
total csum bytes: 8499896
total tree bytes: 624365568
total fs tree bytes: 578822144
total extent tree bytes: 34439168b
tree space waste bytes: 175687504
file data blocks allocated: 112948105216
referenced 32351207424
Btrfs v0.20-rc1+20130701
linux:/home/linux # btrfsck /dev/sdb8
Checking filesystem on /dev/sdb8
UUID: e0a6c69b-b993-4003-808a-ec322cec911f
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 70818243917 bytes used err is 0
total csum bytes: 117383800
total tree bytes: 180862976
total fs tree bytes: 35999744
total extent tree bytes: 14737408b
tree space waste bytes: 17875899
file data blocks allocated: 245588201472
referenced 119927652352
Btrfs v0.20-rc1+20130701
sdb6 and 8 being my / and /home partitions. To no avail.
I haven’t tried commenting all lines on fstab except for the /boot, /, swap and /home partitions. I will, but I seriously doubt it’ll solve the problem. The first time I encountered this issue, I guessed it was partition-mounting related since I had just shut down Windows quite abruptely (dual boot, 2 hard drives). So I went back to windows, shut it down properly, and then OpenSUSE booted fine.
Here, I have started and stopped windows a dozen times since I can’t get OpenSUSE to work, it made no difference …
If I can’t solve my problem and go for the format option, I’ll certainly revert to ext4. But I don’t know if that’s relevant to fill a bug : I have no idea how the issue appeared. I believe the only thing I did before OpenSUSE broke down was to apply some common updates …
/boot, swap and /home are not needed to boot system.
The first time I encountered this issue, I guessed it was partition-mounting related since I had just shut down Windows quite abruptely (dual boot, 2 hard drives). So I went back to windows, shut it down properly, and then OpenSUSE booted fine.
I saw this same problem yesterday. I had applied the latest updates and my system would no longer boot. It failed at the time it would normally start KDE. When I attempted to boot into recovery mode to analyze or repair this problem, my recovery mode boot failed with the ‘system-journald [XXX] …’ message reported here.
I was able to restore my system by reinstalling (updating) SuSE 13.1 from DVD. After testing the latest updates that just came out I have determined that openSUSE-2013-957 is the one that caused my problem. Once restored with all updates except openSUSE-2013-957, my system now boots and also boots into recovery mode successfully.
I’m unsure as to what to do next. Since I’ve started and properly shutdown windows numerous times, how can I get my windows partition back in OpenSUSE ? Force a defrag and scandisk on it ?
Yes, I can boot from my HD on either OpenSUSE or Windows, no problem anymore lol!
But since I’ve commented the line corresponding to my windows partition in my fstab, this windows partition is no longer mounted during boot.
Anyway to fix this ?
To be a little more specific, when I try to manually mount the windows partition from OpenSUSE, I get the following message :
linux-q8lb:~ # mount /dev/sda2 /windows
Windows is hibernated, refused to mount.
Failed to mount '/dev/sda2': Operation not permitted
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.
I don’t understand, since I’ve stopped or rebooted windows numerous times, and performed a scandisk … Has windows 8 a new way of shutting down that would prevent the disk to be accessed by ntfs-3g ?
Yes, IIRC it is called Fast Boot where it actually hibernates under the hood. It can be disabled somewhere in system settings (search for Windows fast boot
It is actually called “Fast Startup”. I disabled it, then shut-downed, rebooted, restarted : I still can’t mount the partition in Linux …
linux-q8lb:~ # mount /dev/sda2 /windows
Windows is hibernated, refused to mount.
Failed to mount '/dev/sda2': Operation not permitted
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.
linux-q8lb:~ #
The problem is now partially solved by mounting the windows partition as read only : I edited my fstab, and replaced the dmask=XXX and fmask=XXX by the ro argument :
