Package: systemd
Version: 215-17+deb8u2
Severity: important
The following happened to me, as far as I can recollect after the fact:
- While booting I had an entry in /etc/fstab like
/dev/sdc1 /mnt ... noauto
- Later, I changed the entry to "/dev/sdb1 ..." and mounted it manually.
- Later
> > - Remembering what little I know about systemd, I did
> > "systemctl daemon-reload", and indeed this seemed to fix the
> > problem.
>
> Correct, you need to run daemon-reload after changes to /etc/fstab.
> Using inotify on configuration files was rejected upstream since you
> don't know,
Just saying me too (also to get informed about news on this front).
It happenes both on reboot and shutdown attempts.
I can also offer to help debugging it, if there's something specific
I can do (in jessie).
Also, I'd suggest to increase the severity, since, you know, not
shutting down the
I did some more debugging, and found out some things:
- In a debug shell after the failed shutdown, I did:
systemctl status `systemctl | grep failed | grep swap | awk '{print $2}'`
and found an error message like this:
swapoff: /dev/sdxx: swapoff failed: Cannot allocate memory
-
Bob B wrote:
> It's curious whether the problem can be resolved
>
> by updating the ODD's firmware
>
> to the latest version (currently "SB07"):
>
> http://www.tsstodd.com/eng/firmware/fwdownload/?functionvalue=view=733
I'd like to try it if there's some way to update the firmware.
The web site
> On 6 Jan 2016 02:45, "Frank Heckenbach" <f.heckenb...@fh-soft.de> wrote:
> >
> > I did some more debugging, and found out some things:
> >
> > - In a debug shell after the failed shutdown, I did:
> >
> > systemctl status
> What if instead of this service, you add an:
>
> After=swap.target
>
> To your tmp.mount ?
Doesn't work. Also, systemctl still lists tmp.mount before the swap
targets, which means (I suppose) it will be stopped after them.
I thought maybe swap.target is just a virtual target that depends on
> Due to the other bug I linked, this may not be sufficient. Please list
> all the swap units listed in
>
> % systemctl list-units '*.swap'
>
> You'll see that there are multiple units each of the different ways
> you can access the underlying partition (by uuid, did, wwm and sdX
> name).
>
> I
> > This seems to work. However, given that this single line is now >1
> > KB and more than 3 times as long as my work-around service, and
> > heavily depends on the system configuration, I doubt whether it's
> > actually less hackish. (I do occasionally change my swap partitions.
> > I also build
As a work around, I've put the following in
/etc/systemd/system/workaround-788303.service and activated it with
systemctl enable workaround-788303
This seems to work for me for now. Of course, I'd prefer a real
bugfix. (And so should the systemd author, seeing how much he hates
using the shell
> Nicht genügend Hauptspeicher verfügbar
>
> at shutdown time.
>
> Thanks for the reporting and analysis so far!
>
> @Frank Heckenbach: I would love to give the "workaround" a try, but I
> don't fully understand, what will be achieved by
>
> > ExecStop=/bin
Hi Jort,
> Great comment and recommendation. I was using SB04 and experienced the 90
> second boot delay. Workaround was functioning as described before, however
> udev rules might easily get overwritten so it's not an ideal solution.
>
> I have a dual boot OS.
> What I did:
> Booted to windows
> On 28 March 2016 at 12:18, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote:
> > Felipe Sateler wrote:
> >
> >> BTW, systemd has been uploaded to proposed-updates[1] fixing #805133.
> >> Could you please upgrade to that version and try usin
FYI, my drive that triggered this bug has now broken down, probably
just the optical/mechanical part (not worth investigating); it's
still seen by the computer and can probably be used to debug it if
someone's interested. (So far it doesn't seem so to me, and I won't
care about this bug now
14 matches
Mail list logo
