as the topic says, my booting process hangs after systemd-fsck with no errors or anything. i use opensuse 13.1 x86_64 KDE. Before systemd-fsck messages i get this: OK ] Stopped target Reboot. OK ] Stopped Reboot. OK ] Stopped target Shutdown. Don’t know why i get messages about shutdown and reboot during the boot process. Before this happened i looked around in system services in yast, but only disabled bluetooth, nothing else. Booting in recovery mode or into another kernel, gives the same result. I looked at the thread here: https://forums.opensuse.org/showthread.php/472262-Opensuse-12-1-hangs-at-bootup-for-5-minutes-after-systemd-fsck but in my case it doesn’t load the desktop after 5 minutes, and i don’t use samba like in the starter of the thread above. I’m starting to think this might be a bug in systemd. any advice appreciated, edit: don’t know why the forum won’t let me start a new paragraph and instead forces everything into one line of text
Do you have an install DVD or live CD? After the fsck the root filesystem should mount.
With a DVD you should be able to coose the rescue/recovery (I can’t remember what its current name is) and login as root (no password). Then *fdisk -l *and mount the root partition on /mnt. This will at least let you know whether the root filesystem will mount.
With a Live CD you should be able to mount and browse the filesystems.
When your system is starting is the main console output obscured with a splash screen? Can you discard the splash screen with the [Esc] key?
Hi!
I wonder why you write about ‘systemd-fsck’.
There is no such tool.
Yes, fsck (for ext4, or ext3, or whatever file system) is run at boot.
Maybe that your hard disk is failing - just like mine, recently.
Make backups of your data.
Then enter a terminal (running openSUSE).
There say
smartctl -x /dev/sda
if /dev/sda is your hard disk.
Please post the result here.
You can find out by looking at the output of
df
or
fdisk -l
Good luck
Mike
so i tried to boot using the fsck.mode=skip kernel command line attribute and it still hangs, but this time without the fsck messages the last messages are: OK ] Stopped target Reboot. OK ] Stopped Reboot. OK ] Stopped target Shutdown. are these messages normal during boot? i also noticed a warning earlier: Job systemd-readahead-done.timer/start deleted to break ordering cycle starting with reboot.target/stop
yes, i can see the console output, but cannot type anything into it. I’ll try to mount the root partition later, since the disk is a luks/lvm, and i didn’t have the instructions how to unlock it from the console handy
it’s just fsck but done by systemd http://www.freedesktop.org/software/systemd/man/systemd-fsck.html
I can mount the root filesystem, so it’s not the drive. But the last time the system booted, i opened both the services and runlevel settings windows in yast many times, maybe it didn’t save some config files correctly and that’s the reason… Could accidently changing the runlevel in the dropdown menu, in Services (Runlevel), in yast cause the rest of the services, except for the selected runlevel, not to start?
Do you have an install DVD? If so you can use the rescue/recovery system to mount the root partiition, /proc, /dev, /sys, then chroot, and attempt a repair. Or you you could attempt a re-install, and “upgrade” to 13.1.
But the last time the system booted, i opened both the services and runlevel settings windows in yast many times, maybe it didn’t save some config files correctly and that’s the reason… Could accidently changing the runlevel in the dropdown menu, in Services (Runlevel), in yast cause the rest of the services, except for the selected runlevel, not to start?
Was this a clean install of the production 13.1 plus updates?
The concept of run-level is part of the init system and does not exist with systemd.
You should be using the yast2-service-manager module , not yast2-runlevel.
i have the 13.1 Rescue CD, and i didn’t see an option to repair a system in the boot menu, i must be missing something… is the repairing automated or do i have to do it from the command line?
It was 12.3 upgraded to 13.1 some time ago. Why should i use the service-manager instead of runlevel module?
From the command line (CLI).
I usually just do it from the install DVD. Boot with the install DVD, choose Rescue from the initial menu.
I suppose the Rescue CD gives you a CLI?
Probably the same procedure. At the login prompt, enter the following:
root
from there I run
fdisk -l
to confirm my HD partitition order.
We need to mount root (For me that’s sda3, so I will use that as the example. You use the correct one for your root partition wherever I use sda3.).
Now mount root (/) with:
mount /dev/sda3 /mnt
To mount the other devices Next do:
mount --bind /dev /mnt/dev
Then chroot:
chroot /mnt
For 13.1, (different than 12.3), do:
mount -t proc proc /proc
mount -t sysfs sysfs /sys
Your prompt changes to:
Rescue:/>
You can now do rescue work to the installed openSUSE.
For example, to fix Grub, you would now do:
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sd???
the latter being sda if you want Grub in the MBR of disk “a”, or if you want to boot from the root partition instead of MBR, in my case it would be sda3.
If booting from the root partition, you will want to set the root partition as the BOOT or ACTIVE partitition.
To do so, Do:
parted
You will now have a prompt
(parted)
Assuming that your root partition is sda3, as in my case (remember, change the sda3 to match your root partition), do:
select /dev/sda
You should get a confirmation message that the device is now selected.
Do:
set 3 boot
That is to set/reset the 3rd partition’s boot flag on the selected device (sda).
It will prompt you with the line New state?
Do:
on
When it is confirmed, do:
quit
You will be back at the Rescue:~# prompt.
Do:
reboot
The Rescue CD is a bit of a misnomer; it’s actually a Live XFCE
Because the yast2-services-manager actually works with systemd systems. The run-level module is a hang-over from init systems and is unreliable with systemd.
Unless you are confident in knowing what has befallen your system, and can understand the rationale of Fraser’s instructions, I recommend that you download a DVD image and use it to install/upgrade.
On 2014-04-21 13:36, eng-int wrote:
>
> Fraser_Bell;2637820 Wrote:
>>
>> I suppose the Rescue CD gives you a CLI?
>
> The Rescue CD is a bit of a misnomer; it’s actually a Live XFCE
It is named a “rescue system” because it is not installable, like the
Gnome/KDE lives are; applications that are not needed for rescue have
been removed (no office, no firefox or thunderbird, for instance), and
some applications specifically used for rescue work have been added.
For instance, it has gparted, testdisk, ddrescue, smartctl, rsync…
even midnight commander!
It is not installable, but if you run it off an USB stick it gets a
writable partition and you can even “install” extra packages on it (with
some limitations: don’t try to upgrade the kernel, for instance).
> Unless you are confident in knowing what has befallen your system, and
> can understand the rationale of Fraser’s instructions, I recommend that
> you download a DVD image and use it to install/upgrade.
(clarification: the full DVD, a bit over 4 GB).
Yes, I agree, booting that DVD and choosing “upgrade” often can be used
to solve some big problems. However, the partitions have to be
“correct”, no fsck pending.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Thanks guys for the suggestions. I will have to backup my data before i do the rescue system from the installation dvd (to avoid any potential data loss), which will take a few days, as i have to buy a new drive to do that. In the meantime i will continue to mess with config files and systemd. I’ll report back after i do the system rescue, or if i manage to get it right another way earlier. Cheers!
I managed to get the system bootable again 
It turned out that while i looked through the services in the yast runlevel applet, i accidentally changed the default runlevel to boot into to runlevel 6. Which is reboot, that’s why there were messages about rebooting.
Changing the symlink in */etc/systemd/system/default.target *to /usr/lib/systemd/system/runlevel5.target fixed the problem.
On a side note, i think the yast services applets should be consolidated into one, and overhauled. I thought that the runlevel dropdown menu was to just to let you see the services for the selected level, but didn’t change the default one. So maybe changing the option name would be good.
Anyway, thanks for all the help.
Cheers!
On 2014-04-24 15:26, ambusher wrote:
>
> I managed to get the system bootable again
> It turned out that while i looked through the services in the yast
> runlevel applet, i accidentally changed the default runlevel to boot
> into to runlevel 6. Which is reboot, that’s why there were messages
> about rebooting.
> Changing the symlink in -/etc/systemd/system/default.target -to
> -/usr/lib/systemd/system/runlevel5.target- fixed the problem.
Gosh…!
> On a side note, i think the yast services applets should be consolidated
> into one, and overhauled. I thought that the runlevel dropdown menu was
> to just to let you see the services for the selected level, but didn’t
> change the default one. So maybe changing the option name would be good.
YaST was overhauled for 13.1: they translated the entire thing to
another language. They first created an automated translator, then they
translated everything. If there were errors, they corrected the
translator, not the translation, and tried again the translation. Over
and over till it was “all green”.
They had no time for improvements.
In fact, they removed some YaST modules. There is a list somewhere.
The yast systemd services thing was an exception, added in some haste
(my educated guess).
Hopefully there will be improvements for 13.2… but that release is
undergoing another type of overhaul.
Volunteers are wanted
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
The name of that menu is “Default System Target”, which I think is fairly indicaive of its function.
The “run level” entries are symbolic links to their approximate systemd taget equivalents, e.g.
runlevel2.target -> multi-user.target
runlevel5.target -> graphical.target
and I would expect them to be deprecated in the future.