2013/6/19 Henrik /KaarPoSoft <hen...@kaarposoft.dk>: > Dear all, hei,
> I am experiencing a strange problem with swap using systemd 204. > Any help in diagnosing this would be most appreciated. > > I have 64 GB of physical memory, > and two 64 GB swap partitions. Do these have the same partlabel? I think this might couse confusion for systemd/udev > My fstab is attached. > > When booting, I get a few errors related to swap; in particular: > Failed to reread /proc/swaps: File exists In my (untested) theory this is because your swap is mounted (by the initrd?) and while loading existing swaps from /proc/swaps systemd tries to create /dev/disk/by-partlabel/Linux\x20swap.swap twice, failing the second time. > swapon: /dev/sda3: swapon failed: Device or resource busy probably similar to above, when sda4 comes online systemd tries to activate all services belonging to it, blkid tells that partlabel is "Linux swap" so systemd tries to activate /dev/disk/by-partlabel/Linux\x20swap.swap but /dev/disk/by-partlabel/Linux\x20swap is a symlink to /dev/sda3 which is already activated. > A full > journalctl -b | grep -i swap > is atached as swap1.txt > > However, swapon seems to be happy: > > swapon -s > Filename Type Size Used Priority > /dev/sda4 partition 67108860 0 1 > /dev/sda3 partition 67108860 0 1 > > Every now and again, I get journal messages about swap; see > journalctl -b | grep -i swap > attached as swap2.txt > > When executing > systemctl poweroff > most of the time the machine just powers off as expeced. > > However, sometimes the poweroff gets stuck (hanging for at least 15 > minutes). > This happens very late in the poweroff, so there is nothing in the logs. > However, a screenshot is attached: swap.png even though i am not sure what is happening here, it also talks about /dev/disk/by-partlabel/Linux\x20swap so it is probably the same issue as above > Your insights into what I might be doing wrong would be most appreciated > > /Henrik If the above is the case and changing the partlabel of one of the swap devices solves the problem, then this is a bug in systemd since nothing obligates parlabel to be unique. I will probably try and reproduce this here later today. hilsen Simon _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
