GOOD DAY
URGENT - HELP ME DISTRIBUTE MY $12 MILLION TO HUMANITARIAN.
This mail might come to you as a surprise and the temptation to ignore it as
unserious could come into your mind but please consider it a divine wish and
accept it with a deep sense of humility.
I am Mrs Helen George
Processing control commands:
> retitle -1 mkosi: works only on amd64 and arm64
Bug #860637 [src:mkosi] mkosi: arch:all, but builds only on amd64 and arm64
Changed Bug title to 'mkosi: works only on amd64 and arm64' from 'mkosi:
arch:all, but builds only on amd64 and arm64'.
> severity -1 importan
Control: retitle -1 mkosi: works only on amd64 and arm64
Control: severity -1 important
On Thu, Apr 20, 2017 at 3:20 AM, Lucas Nussbaum wrote:
>
> retitle 860637 mkosi: arch:all, but builds only on amd64 and arm64
> severity 860637 wishlist
> thanks
>
> On 20/04/17 at 07:36 +0200, Andreas Henriks
Processing commands for cont...@bugs.debian.org:
> retitle 860637 mkosi: arch:all, but builds only on amd64 and arm64
Bug #860637 [src:mkosi] mkosi: FTBFS on i386: help2man: can't get `--help' info
from ./mkosi
Changed Bug title to 'mkosi: arch:all, but builds only on amd
retitle 860637 mkosi: arch:all, but builds only on amd64 and arm64
severity 860637 wishlist
thanks
On 20/04/17 at 07:36 +0200, Andreas Henriksson wrote:
> Hello,
>
> On Wed, Apr 19, 2017 at 04:58:00PM +0200, Lucas Nussbaum wrote:
> [...]
> > Don't known the i686 architecture.
> [...]
>
> Thanks
Hello,
On Wed, Apr 19, 2017 at 04:58:00PM +0200, Lucas Nussbaum wrote:
[...]
> Don't known the i686 architecture.
[...]
Thanks.
While I'm not very familiar with mkosi I guess I should have understood
from the "legacy free" description that i386 "obviously" isn't supported:
if platform.machine()
n/rules binary.
> I've also tried to manually check return codes (0) and mkosi --help
> output (stdout). Nothing peculiar noticed.
Does it help to run "linux32 chroot.." or "linux32 mkosi --help" to set the
right (32 bit) personality
.
> >
> > Relevant part (hopefully):
> > > debian/rules build
> > > help2man --name "Create legacy-free OS images" \
> [...]
> > > help2man: can't get `--help' info from ./mkosi
> > > Try `--no-discard-stderr' if
help2man --name "Create legacy-free OS images" \
[...]
> > help2man: can't get `--help' info from ./mkosi
> > Try `--no-discard-stderr' if option outputs to stderr
> > debian/rules:17: recipe for target 'debian/mkosi.1' failed
> > make: *** [d
on i386.
Relevant part (hopefully):
> debian/rules build
> help2man --name "Create legacy-free OS images" \
> --version-string "mkosi 1" \
> --no-info \
> -o debian/mkosi.1 \
> ./mkosi
> help2man: can't get `--help' info
according to my
father, and I am the only child and heir apparent until the uncle was accused
of plotting with the people who killed him because of the family land property
which forced me to ran away.
See my personal e-mail: ericon...@yahoo.com for you to contact me if you want
to help and
Processing commands for cont...@bugs.debian.org:
> retitle 793416 dh-systemd: help making systemd drop-in overwrite files take
> effect
Bug #793416 [dh-systemd] help making systemd drop-in overwrite files take effect
Changed Bug title to 'dh-systemd: help making systemd drop-in over
h the values you suggested, but it still fails (and it
appears the timeout is still 90secs), attached the boot log
thanks for your help!!
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+Sandro
Before=remote-fs-pre.target
>
> and I've now set the test machine in a reboot loop until it detects an
> error, I'll let you know what happens
sadly it didnt take long to fail :( (that change still makes sense, so
I'm going to apply it to our systems anyway)
attached is th
On 4 March 2016 at 18:13, Sandro Tosi wrote:
>> Could you attach one? Or mail me privately if you prefer, and I can
>> take a look to see if there is anything else that may be fishy.
>
> we are extremely protective of what we do on our system, so i am not
> able to provide a pristine boot log. I a
t was indeed poor from my side (even though the changes were kinda
minor), apologize for that.
> Could you attach one? Or mail me privately if you prefer, and I can
> take a look to see if there is anything else that may be fishy.
we are extremely protective of what we do on our system, so i am
Thanks Felipe to assist me with this and sorry for the late reply!
On Thu, Feb 25, 2016 at 7:19 PM, Felipe Sateler wrote:
> On 24 February 2016 at 09:29, Sandro Tosi wrote:
> > Hey Felipe, thanks a lot for your help!
> >
> >
> > On Tue, Feb 23, 2016 at 10:16 PM
On 2 March 2016 at 11:46, Sandro Tosi wrote:
> Thanks Felipe to assist me with this and sorry for the late reply!
>
> On Thu, Feb 25, 2016 at 7:19 PM, Felipe Sateler wrote:
>> Maybe the timeout is just too short. Maybe adding
>> x-systemd.device-timeout=90s helps?
>
>
> i think that's already 90
On 24 February 2016 at 09:29, Sandro Tosi wrote:
> Hey Felipe, thanks a lot for your help!
>
>
> On Tue, Feb 23, 2016 at 10:16 PM, Felipe Sateler
> wrote:
>>
>> On 23 February 2016 at 12:12, Sandro Tosi wrote:
>> > On Tue, Feb 23, 2016 at 9:19 AM, Sandro Tos
Hey Felipe, thanks a lot for your help!
On Tue, Feb 23, 2016 at 10:16 PM, Felipe Sateler
wrote:
>
> On 23 February 2016 at 12:12, Sandro Tosi wrote:
> > On Tue, Feb 23, 2016 at 9:19 AM, Sandro Tosi wrote:
> >> quick update: we had a couple of (real) nfs issues and
> &
On 23 February 2016 at 12:12, Sandro Tosi wrote:
> On Tue, Feb 23, 2016 at 9:19 AM, Sandro Tosi wrote:
>> quick update: we had a couple of (real) nfs issues and
>> misconfiguration (meeh) that made the script fail even if it shouldnt
>> have, so no news yet; the reboot loop just restarted and wil
On Tue, Feb 23, 2016 at 9:19 AM, Sandro Tosi wrote:
> quick update: we had a couple of (real) nfs issues and
> misconfiguration (meeh) that made the script fail even if it shouldnt
> have, so no news yet; the reboot loop just restarted and will
> periodically check it and report back if something
quick update: we had a couple of (real) nfs issues and
misconfiguration (meeh) that made the script fail even if it shouldnt
have, so no news yet; the reboot loop just restarted and will
periodically check it and report back if something comes up.
On Fri, Feb 19, 2016 at 4:17 PM, Sandro Tosi wrot
> I now noticed this flag (bg). What happens if you remove it? This flag
> sounds like it could confuse systemd as to when the mounts are
> actually ready.
good catch! I've just setup another machine (so we still have the
original one) with the same setup as the other one, I'll report when a
failu
On 19 February 2016 at 09:11, Sandro Tosi wrote:
> Hey Felipe,
>
> On Thu, Feb 18, 2016 at 5:39 PM, Felipe Sateler wrote:
>> That mail has:
>> 1711:Feb 10 16:44:40 SERVER systemd[1]: mnt-NFSSERVER.mount changed
>> dead -> mounting
>> 1817:Feb 10 16:44:43 SERVER systemd[1]: mnt-NFSSERVER.mount cha
Hey Felipe,
On Thu, Feb 18, 2016 at 5:39 PM, Felipe Sateler wrote:
> That mail has:
> 1711:Feb 10 16:44:40 SERVER systemd[1]: mnt-NFSSERVER.mount changed
> dead -> mounting
> 1817:Feb 10 16:44:43 SERVER systemd[1]: mnt-NFSSERVER.mount changed
> mounting -> mounted
> 1818:Feb 10 16:44:43 SERVER sy
On 18 February 2016 at 14:05, Sandro Tosi wrote:
> On Thu, Feb 18, 2016 at 4:49 PM, Felipe Sateler wrote:
>> On 18 February 2016 at 13:41, Sandro Tosi wrote:
>>> On Thu, Feb 18, 2016 at 4:11 PM, Felipe Sateler wrote:
Could the networking script be exiting too early?
>>>
>>> at which networ
situation, and there are still missing
>>>> mount points
>>>>
>>>>
>>>> On Tue, Feb 9, 2016 at 9:21 PM, Michael Biebl wrote:
>>>>> Am 09.02.2016 um 22:11 schrieb Sandro Tosi:
>>>>>>> Another idea: maybe
t;>>
>>> On Tue, Feb 9, 2016 at 9:21 PM, Michael Biebl wrote:
>>>> Am 09.02.2016 um 22:11 schrieb Sandro Tosi:
>>>>>> Another idea: maybe it's related to name resolution. How is that
>>>>>> configured? Does it help if you use
gt;>> Am 09.02.2016 um 22:11 schrieb Sandro Tosi:
>>>>> Another idea: maybe it's related to name resolution. How is that
>>>>> configured? Does it help if you use IP adresses in /etc/fstab?
>>>>
>>>> # cat /etc/resolv.conf
>>>
idea: maybe it's related to name resolution. How is that
>>>> configured? Does it help if you use IP adresses in /etc/fstab?
>>>
>>> # cat /etc/resolv.conf
>>> search OUR-DOMAIN.com
>>> nameserver 127.0.0.1
>>> nameserver XXX.YYY.32.33
&g
any thoughts on the above results? are they manifesting a
configuration issue or something else is going on? thanks for your
help!
On Fri, Feb 12, 2016 at 5:32 PM, Sandro Tosi wrote:
> sorry the tests are going slowly, but another interesting thing i found is
> this: i have an @reboot c
here are still missing
> > mount points
> >
> > On Tue, Feb 9, 2016 at 9:21 PM, Michael Biebl wrote:
> >> Am 09.02.2016 um 22:11 schrieb Sandro Tosi:
> >>>> Another idea: maybe it's related to name resolution. How is that
> >>>> configure
t's related to name resolution. How is that
>>>> configured? Does it help if you use IP adresses in /etc/fstab?
>>>
>>> # cat /etc/resolv.conf
>>> search OUR-DOMAIN.com
>>> nameserver 127.0.0.1
>>> nameserver XXX.YYY.32.33
>>> nam
Disabling ifplugd didnt change the situation, and there are still missing
mount points
On Tue, Feb 9, 2016 at 9:21 PM, Michael Biebl wrote:
> Am 09.02.2016 um 22:11 schrieb Sandro Tosi:
>>> Another idea: maybe it's related to name resolution. How is that
>>> configure
Am 09.02.2016 um 22:11 schrieb Sandro Tosi:
>> Another idea: maybe it's related to name resolution. How is that
>> configured? Does it help if you use IP adresses in /etc/fstab?
>
> # cat /etc/resolv.conf
> search OUR-DOMAIN.com
> nameserver 127.0.0.1
> names
idea of what is going on on these machines?
>>>> can you help us fixing it? can we provide more information to pinpoint
>>>> the origin of the issue? thanks!!
>>>
>>> Can you post more details about your network configuration (like your
>>> /etc/
Am 09.02.2016 um 19:14 schrieb Sandro Tosi:
> Hey Michael!
>
> On Tue, Feb 9, 2016 at 5:07 PM, Michael Biebl wrote:
>> Am 09.02.2016 um 16:40 schrieb Sandro Tosi:
>>> Hi guys! do you have any idea of what is going on on these machines?
>>> can you help
Hey Michael!
On Tue, Feb 9, 2016 at 5:07 PM, Michael Biebl wrote:
> Am 09.02.2016 um 16:40 schrieb Sandro Tosi:
>> Hi guys! do you have any idea of what is going on on these machines?
>> can you help us fixing it? can we provide more information to pinpoint
>> the origin
Am 09.02.2016 um 16:40 schrieb Sandro Tosi:
> Hi guys! do you have any idea of what is going on on these machines?
> can you help us fixing it? can we provide more information to pinpoint
> the origin of the issue? thanks!!
Can you post more details about your network configuration (
Am 09.02.2016 um 16:40 schrieb Sandro Tosi:
> Hi guys! do you have any idea of what is going on on these machines?
> can you help us fixing it? can we provide more information to pinpoint
> the origin of the issue? thanks!!
>
According to your logs, you are using ifplugd, which seems
Hi guys! do you have any idea of what is going on on these machines?
can you help us fixing it? can we provide more information to pinpoint
the origin of the issue? thanks!!
On Fri, Jan 29, 2016 at 4:23 PM, Sandro Tosi wrote:
> Hey Felipe,
> thanks for your reply and sorry for getting b
evd.service @142ms +2ms
└─systemd-tmpfiles-setup-dev.service @118ms +23ms
└─kmod-static-nodes.service
@109ms +6ms
└─system.slice @106ms
└─-.slice @106ms
>
> Without more information on how thi
ful (`journalctl -axb` would get you the current boot's logs).
Also, what are you using for networking? Ifupdown? Does `systemctl
status` print failed units?
Without more information on how this is failing (ie, logs), it is very
hard to help.
BTW, be sure to order cron.service after remote-fs.tar
nded, i guess to speedup
boot) they just do nothing.
We havent found a lot of information on-line regarding this problems,
and while #739721 seems related it is now closed and all the proposed
solutions are already applied (or not applicable) and we still see
this issue.
Could you help us unders
Hi All,
The systemd 227-2 update now boots into debian correctly and Lightdm loads
at its normal speed, as well I am seeing that the user@105.service is not
taking a long time to load. However I am still seeing that the
systemd-rfkill.service is failing to start.
systemctl status systemd-rfkill.
Felipe Sateler:
> On 23 July 2015 at 17:28, Patrick Schleizer wrote:
>> Package: dh-systemd
>> Severity: wishlist
>>
>> Could you please add a feature, so debhelper (dh-systemd) could help
>> making systemd drop-in overwrite files
>> (/lib/systemd/system/un
On 23 July 2015 at 17:28, Patrick Schleizer wrote:
> Package: dh-systemd
> Severity: wishlist
>
> Could you please add a feature, so debhelper (dh-systemd) could help
> making systemd drop-in overwrite files
> (/lib/systemd/system/unit.service.d/override.conf) take effect?
>
Package: dh-systemd
Severity: wishlist
Could you please add a feature, so debhelper (dh-systemd) could help
making systemd drop-in overwrite files
(/lib/systemd/system/unit.service.d/override.conf) take effect?
(systemctl daemon-reload + service restart)
(guarded by [ -d /run/systemd/system
Hey Patrick,
Patrick Schleizer [2015-07-06 15:35 +]:
> Can debhelper (dh-systemd) help making override files
> (/lib/systemd/system/unit.service.d/override.conf) take effect?
> (systemctl daemon-reload + service restart)
>
> (Override files shipped by different packages.)
No
Hi!
Can debhelper (dh-systemd) help making override files
(/lib/systemd/system/unit.service.d/override.conf) take effect?
(systemctl daemon-reload + service restart)
(Override files shipped by different packages.)
Cheers,
Patrick
___
Pkg-systemd
Your message dated Fri, 05 Dec 2014 10:04:48 +
with message-id
and subject line Bug#766598: fixed in systemd 215-8
has caused the Debian Bug report #766598,
regarding systemd: help for journalctl --until option is misleading
to be marked as done.
This means that you claim that the problem
Control: notfound -1 217-1
Control: tag -1 pending
Hello,
Santiago Vila [2014-10-24 11:46 +0200]:
> --since=DATE Start showing entries on or newer than the specified
> date
> --until=DATE Stop showing entries on or older than the specified
> date
>
> This is a little bit co
Processing control commands:
> notfound -1 217-1
Bug #766598 [systemd] systemd: help for journalctl --until option is misleading
Ignoring request to alter found versions of bug #766598 to the same values
previously set
> tag -1 pending
Bug #766598 [systemd] systemd: help for journalctl -
Nikolaus Rath writes:
> On 11/06/2014 07:15 PM, Michael Biebl wrote:
>> Am 07.11.2014 um 02:32 schrieb Nikolaus Rath:
>>> Michael Biebl
>>>
>>> writes:
>>
>>
Try running "systemctl stop networking.service" before you
shutdown/reboot. This service seems to be hanging in "ifdown -a".
On 11/06/2014 07:15 PM, Michael Biebl wrote:
> Am 07.11.2014 um 02:32 schrieb Nikolaus Rath:
>> Michael Biebl writes:
>
>
>>> Try running "systemctl stop networking.service" before you
>>> shutdown/reboot. This service seems to be hanging in "ifdown -a".
>>> Might be dhclient or ifdown.d hook sc
Am 07.11.2014 um 02:32 schrieb Nikolaus Rath:
> Michael Biebl writes:
>> Try running "systemctl stop networking.service" before you
>> shutdown/reboot. This service seems to be hanging in "ifdown -a".
>> Might be dhclient or ifdown.d hook script causing a dead lock.
>
> I tried that, but it stil
t; When I'm running "systemctl reboot" from a console, the system stays
> usable. I can see the status messages, switch to other consoles and use
> the debug shell. But this doesn't help much, because the system shuts
> down just fine.
I confirmed this in a slightly differ
Michael Biebl writes:
> Am 05.11.2014 um 11:51 schrieb Michael Biebl:
>
>>>
>>> to the kernel command line and created the
>>> /usr/lib/systemd/system-shutdown/debug.sh file. I noticed that the
>>> system-shutdown directory did not exist - does that mean this method is
>>> not applicable in Debian
pposed to
>>>> fix that issue.
>>>> Could you upgrade to that version and test again?
>>>
>>> I'm at 2:4.1.13+dfsg-2 now, problem is still the same unfortunately.
>>
>>
>> Ok, this probably sounds weird, but I confirmed it several t
Am 05.11.2014 um 11:51 schrieb Michael Biebl:
>>
>> to the kernel command line and created the
>> /usr/lib/systemd/system-shutdown/debug.sh file. I noticed that the
>> system-shutdown directory did not exist - does that mean this method is
>> not applicable in Debian?
The directory is /lib/system
ume, you're not running samba 2:4.1.13+dfsg-2, which is supposed to
>>> fix that issue.
>>> Could you upgrade to that version and test again?
>>
>> I'm at 2:4.1.13+dfsg-2 now, problem is still the same unfortunately.
>
>
> Ok, this probably soun
this probably sounds weird, but I confirmed it several times:
- when I run "systemctl reboot/poweroff" on a console, it works
- when I run "systemctl reboot/poweroff" on an X11 terminal, it
hangs
Additionally, when running "systemctl reboot" from X11 the system
bec
On 11/05/2014 02:51 AM, Michael Biebl wrote:
> Am 05.11.2014 um 03:35 schrieb Nikolaus Rath:
>> Hello,
>>
>> I'm using testing with systemd as pid 1, and my system does not shut
>> down (or reboot) properly.
>>
>> That's a lot better than not booting properly, but I'd nevertheless like
>> to fix it
Am 05.11.2014 um 03:35 schrieb Nikolaus Rath:
> Hello,
>
> I'm using testing with systemd as pid 1, and my system does not shut
> down (or reboot) properly.
>
> That's a lot better than not booting properly, but I'd nevertheless like
> to fix it :-).
>
> I tried following the instructions at
> h
Thanks, patch applied upstream as
http://cgit.freedesktop.org/systemd/systemd/commit/?id=7558251eef.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sys
Package: systemd
Version: 215-5+b1
Tags: patch
The output of journalctl --help says this:
--since=DATE Start showing entries on or newer than the specified date
--until=DATE Stop showing entries on or older than the specified date
This is a little bit confusing. In fact
Hello
I'm waiting for systemd-journal-gatewayd support in debian ... how can
i help you to have this patch integrated in debian ?
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
68 matches
Mail list logo
