Removing the old udev rules did indeed resolve the precipitating error and allow
a smooth boot.
I kept the files so I could recreate the boot dependency failure, so if anyone
has an idea as to what output would be useful for me to collect to diagnose the
strange emergency shell behavior, I can ta
It took a while to grep the vol_id culprit. It's probably this:
/usr/share/initramfs-tools/scripts/functions: elif [ "$FSTYPE" = "unknown" ]
&& [ -x /lib/udev/vol_id ]; then
/usr/share/initramfs-tools/scripts/functions:
FSTYPE=$(/lib/udev/vol_id -t "${FS}" 2> /dev/null)
__
Am 27.07.2014 04:04, schrieb Brian Julin:
>
> Michael Biebl wrote:
>
>> You have a broken/outdated 60-persistent-storage.rules in
>> /etc/udev/rules.d. Why?
>
> I don't know why. I pasted my package history for udev|systemd at the end of
> the email.
>
>> You have a device listed in /etc/fsta
Michael Biebl wrote:
> You have a broken/outdated 60-persistent-storage.rules in
> /etc/udev/rules.d. Why?
I don't know why. I pasted my package history for udev|systemd at the end of
the email.
> You have a device listed in /etc/fstab which doesn't exist during boot,
> Please double check if
Elimar Riesebieter wrote:
> Now that systemd-shim 6-4 is out sysvinit-core can't be installed
> together with libpam-systemd?
Elimar, on debian-devel, Michael Biebl reported:
"Just a quick followup: After testing cgmanager a bit I stumbled over
various issues which should be fixed first before I'
On Sun, 27 Jul 2014, Michael Biebl wrote:
> Am 26.07.2014 23:59, schrieb Henrique de Moraes Holschuh:
> > On Sat, 26 Jul 2014, Michael Biebl wrote:
> >> If invoke-rc.d by default stops both .socket and .service, the package
> >> maintainer no longer has this option.
> >
> > This is incorrect.
> >
Am 27.07.2014 00:11, schrieb Corcodel Marian:
> Package: systemd
> Version: 208-6
> Followup-For: Bug #756044
>
> Hi
> For solve this issue i modified an lot of files from /lib/systemd/system
> poweroff.target start before systemd-poweroff.service and systemd-
> poweroff.service start before umoun
Am 26.07.2014 23:59, schrieb Henrique de Moraes Holschuh:
> On Sat, 26 Jul 2014, Michael Biebl wrote:
>> If invoke-rc.d by default stops both .socket and .service, the package
>> maintainer no longer has this option.
>
> This is incorrect.
>
> You can extend "invoke-rc.d stop" with a --option tha
On Sat, 26 Jul 2014, Michael Biebl wrote:
> Am 26.07.2014 22:15, schrieb Henrique de Moraes Holschuh:
> >> Up until now, we do not generate explicit maintainer scripts code to
> >> stop the socket during upgrades. The underlying idea was, that keeping
> >> the socket open would allow to not lose an
Am 10.07.2014 17:05, schrieb Stefano Zacchiroli:
> On Wed, Jul 09, 2014 at 05:31:57PM +0200, Michael Biebl wrote:
>> So, try to guard your restarts like this:
>>
>> ===
>> if [ -d /run/systemd/system ]; then
>>systemctl list-jobs | grep -q network.target && exit 0
>> fi
>> service shorewall
Am 26.07.2014 22:15, schrieb Henrique de Moraes Holschuh:
>> Up until now, we do not generate explicit maintainer scripts code to
>> stop the socket during upgrades. The underlying idea was, that keeping
>> the socket open would allow to not lose any incoming message.
>
> This is, unfortunately, e
Processing commands for cont...@bugs.debian.org:
> reassign 736258 dh-systemd
Bug #736258 {Done: Michael Meskes } [acpid] acpid fails to
upgrade on amd64
Bug reassigned from package 'acpid' to 'dh-systemd'.
No longer marked as found in versions acpid/1:2.0.20-1 and acpid/1:2.0.21-1.
Ignoring requ
reassign 736258 dh-systemd
forcemerge 751741 736258
thanks
We already have 736258 to track this issue.
We will decide there what to do about this and re-assign (if necessary)
to sysv-rc (which ships invoke-rc.d).
--
Why is it that all of the instruments seeking intelligent life in the
univers
On Sat, Jul 26, 2014 at 3:47 PM, Michael Biebl wrote:
> Control: tags -1 + pending
>
> Am 26.07.2014 20:36, schrieb Michael Biebl:
>> Am 26.07.2014 20:28, schrieb Felipe Sateler:
>
>>> As mentioned earlier in the bug report, the zsh maintainer's blessed
>>> way is to install to /usr/share/zsh/vend
reopen 736258
severity 736258 grave
retitle 736258 invoke-rc.d: stop action fails to disable socket activation
reassign 736258 systemd
thanks
Bug severity raised and reassignment to systemd done in response to Michael
Biebl's analysis of the bug. If this is incorrect, I apologise.
On Sat, 26 Jul
Am 26.07.2014 21:33, schrieb Brian Julin:
>
> Michael Biebl wrote:
>> Am 26.07.2014 20:10, schrieb Brian Julin:
>>> 3) If you enable "quiet" and run the recovery mode, you will get login
>>> prompts
>>> within a minute or two. You will get two login prompts running
>>> simultaneously.
>>> Once
Control: tags -1 + pending
Am 26.07.2014 20:36, schrieb Michael Biebl:
> Am 26.07.2014 20:28, schrieb Felipe Sateler:
>> As mentioned earlier in the bug report, the zsh maintainer's blessed
>> way is to install to /usr/share/zsh/vendor-completions. Please find
>> attached a patch that installs to
Processing control commands:
> tags -1 + pending
Bug #717540 [systemd] systemd: install zsh completion to the correct place
Added tag(s) pending.
--
717540: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717540
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
___
Michael Biebl wrote:
>Am 26.07.2014 20:10, schrieb Brian Julin:
>> 3) If you enable "quiet" and run the recovery mode, you will get login
>> prompts
>> within a minute or two. You will get two login prompts running
>> simultaneously.
>> Once you have provided a password to one of the prompts, t
Am 26.07.2014 21:12, schrieb Michael Biebl:
> I completely forgot that we defer the actual start/stop/restart to
> invoke-rc.d in most cases (i.e. if there is a matching .service and SysV
> init script).
>
> So, yeah, we'd actually need to special case .socket units here or we
> change invoke-rc.d
Am 26.07.2014 20:33, schrieb Michael Biebl:
> As for .socket units: they should be treated like .service units and
> started and stopped at the same time.
> You just need to keep the ordering in mind.
> If a package contains foo.service and foo.socket unit, you need to make
> sure foo.socket is sto
Am 26.07.2014 20:10, schrieb Brian Julin:
>
> I just went through this ordeal myself. Here are some observations.
>
> 1) The problem causing the OP to enter emergency mode in the first place
> is likely because systemd does not seem to (with current packages) want
> to do anything with swap or n
Am 26.07.2014 20:28, schrieb Felipe Sateler:
> Control: reopen -1
> Control: found -1 systemd/208-6
> Control: retitle -1 systemd: install zsh completion to the correct place
>
> Hi systemd maintainers,
>
> On Sun, Apr 27, 2014 at 7:21 PM, Debian Bug Tracking System
> wrote:
>
>> Changes:
>> s
Hi,
Am 23.07.2014 09:28, schrieb Michael Stapelberg:
> Hi Paul, Michael,
>
> sorry for the late reply. I finally looked into this, and I realized
> that I’m missing context/time to test and investigate deeper.
>
> My vague idea is that we should mask sockets before the upgrade and
> unmask them
I just went through this ordeal myself. Here are some observations.
1) The problem causing the OP to enter emergency mode in the first place
is likely because systemd does not seem to (with current packages) want
to do anything with swap or non-root partitions that are referenced by
UUID in /etc
Processing control commands:
> reopen -1
Bug #717540 {Done: Michael Biebl } [systemd] systemd: Please
install zsh completion
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked
Control: reopen -1
Control: found -1 systemd/208-6
Control: retitle -1 systemd: install zsh completion to the correct place
Hi systemd maintainers,
On Sun, Apr 27, 2014 at 7:21 PM, Debian Bug Tracking System
wrote:
> Changes:
> systemd (208-1) experimental; urgency=medium
> .
>[ Michael B
Am 26.07.2014 18:52, schrieb Martin Pitt:
> Hello Michael,
>
> Michael Biebl [2014-07-26 13:25 +0200]:
>> Hm, that seems to be a recent change in the linux kernel headers afaics.
>
> It seems to be an incompatibility between recent glibc and libattr.
My guess was linux-libc-dev, since that was t
Hello Michael,
Michael Biebl [2014-07-26 13:25 +0200]:
> Hm, that seems to be a recent change in the linux kernel headers afaics.
It seems to be an incompatibility between recent glibc and libattr.
> Can you try with the attached patch?
FTR, while that's not yet upstream, this is much simpler f
On Sb, 26 iul 14, 17:29:21, Michael Biebl wrote:
>
> You simply have a typo here :-P
>
> "udf,iso9660,user,noauto" should be
> "udf,iso9660 user,noauto"
>
> note the space vs ','
>
> Closing the bug as a misconfiguration issue.
Oh, this is embarrassing, I just "fixed" that yesterday, because I
Processing commands for cont...@bugs.debian.org:
> retitle 756097 FTBFS: sys/xattr.h:32:3: error: expected identifier before
> numeric constant
Bug #756097 [systemd] systemd: Can't build systemd in a chroot environment
Changed Bug title to 'FTBFS: sys/xattr.h:32:3: error: expected identifier
bef
Am 16.07.2014 17:25, schrieb Michael Biebl:
> Am 16.07.2014 17:22, schrieb Michael Biebl:
>
>> See
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752428
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752430
>
> sorry, meant
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752425
>
Am 26.07.2014 11:28, schrieb Andrei POPESCU:
> Package: systemd
> Version: 208-6
> Severity: important
>
> Hi,
>
> Booting fails if the fstab entry for /dev/cdrom is activated, even
> though it has 'noauto'. I get (written down by hand):
>
> A start job is running for dev-cdrom.device
>
>
On Tue, Jul 22, 2014 at 03:03:02PM +0200, Michael Biebl wrote:
> Am 22.07.2014 14:34, schrieb Gerrit Pape:
> > On Fri, Jul 18, 2014 at 12:03:41PM +, Gerrit Pape wrote:
> >> I'm really not keen to add a dependency to daemontools-run, esp. not to
> >> the runit package, just for (un)installing an
* Michael Biebl [2014-07-26 13:25 +0200]:
> Am 26.07.2014 10:08, schrieb Elimar Riesebieter:
> > Package: systemd
> > Version: 208-6
> > Severity: serious
> > Justification: fails to build from source (but built successfully in the
> > past)
> >
> > Using pbuilder updated today. Build stops at:
Am 26.07.2014 10:08, schrieb Elimar Riesebieter:
> Package: systemd
> Version: 208-6
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> Using pbuilder updated today. Build stops at:
> In file included from ../src/core/socket.c:32:0:
> /usr/incl
Hi gents,
* Martin Pitt [2014-07-20 19:41 +0200]:
> Matthias Klumpp [2014-07-20 16:12 +0200]:
> > I recommend helping
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752939 to make the
> > shim available again.
>
> For the record, the upload is ready, just waiting for cgmanager to get
> o
Package: systemd
Version: 208-6
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Using pbuilder updated today. Build stops at:
In file included from ../src/core/socket.c:32:0:
/usr/include/x86_64-linux-gnu/sys/xattr.h:32:3: error: expected identifier
38 matches
Mail list logo
