FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 08-15-2012, 04:49 PM
Denis A. Altoé Falqueto
 
Default systemd

On Wed, Aug 15, 2012 at 11:12 AM, Mikael Eriksson
<mikael_eriksson@miffe.org> wrote:
> On Wed, Aug 15, 2012 at 01:50:01PM +0200, Fred Verschueren wrote:
>> My problem:
>> When booting with init=/bin/systemd I have the following phenomenon:
>>
>> Job dev-mapper-nvidia_cjjcaiiep1.device/start timed out and booting
>> stops and I'm in a rescue shell.
>> my /home partition is not mounted.
>>
>> /dev/mapper/nvidia_cjjcaiiep1 exists.
>>
>> Systemctl start dev-mapper-nvidia_cjjcaiiep1.device gives the same
>> result timeout.
>>
>> and my /home is not mounted
>>
>> When I do a manual mount of the /home partition
>> mount /dev/mapper/nvidia_cjjcaiiep1 /home
>> /home is mounted
>>
>> Systemctl default
>>
>> my system resumes booting and finally comes online.
>
> I have the exact same problem with systemd-188-2, downgrading back to
> systemd-187-4 makes it work again.

Be sure to report a bug in Arch's flyspray. Lots of developers don't
read arch-general anymore (we should all thank the polite
conversations of last days...)

--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?
For more information, please read: http://idallen.com/topposting.html

-------------------------------------------
Denis A. Altoe Falqueto
Linux user #524555
-------------------------------------------
 
Old 08-16-2012, 06:59 AM
Fred Verschueren
 
Default systemd

Op 15-08-12 18:49, Denis A. Altoé Falqueto schreef:

On Wed, Aug 15, 2012 at 11:12 AM, Mikael Eriksson
<mikael_eriksson@miffe.org> wrote:

On Wed, Aug 15, 2012 at 01:50:01PM +0200, Fred Verschueren wrote:

My problem:
When booting with init=/bin/systemd I have the following phenomenon:

Job dev-mapper-nvidia_cjjcaiiep1.device/start timed out and booting
stops and I'm in a rescue shell.
my /home partition is not mounted.

/dev/mapper/nvidia_cjjcaiiep1 exists.

Systemctl start dev-mapper-nvidia_cjjcaiiep1.device gives the same
result timeout.

and my /home is not mounted

When I do a manual mount of the /home partition
mount /dev/mapper/nvidia_cjjcaiiep1 /home
/home is mounted

Systemctl default

my system resumes booting and finally comes online.

I have the exact same problem with systemd-188-2, downgrading back to
systemd-187-4 makes it work again.

Be sure to report a bug in Arch's flyspray. Lots of developers don't
read arch-general anymore (we should all thank the polite
conversations of last days...)


I downgraded to systemd-187-4 but have still the same problem.

Any hints where to start searching?
Fred
 
Old 08-17-2012, 03:28 PM
Fred Verschueren
 
Default systemd

On 08/16/12 08:59, Fred Verschueren wrote:


Op 15-08-12 18:49, Denis A. Altoé Falqueto schreef:

On Wed, Aug 15, 2012 at 11:12 AM, Mikael Eriksson
<mikael_eriksson@miffe.org> wrote:

On Wed, Aug 15, 2012 at 01:50:01PM +0200, Fred Verschueren wrote:

My problem:
When booting with init=/bin/systemd I have the following phenomenon:

Job dev-mapper-nvidia_cjjcaiiep1.device/start timed out and booting
stops and I'm in a rescue shell.
my /home partition is not mounted.

/dev/mapper/nvidia_cjjcaiiep1 exists.

Systemctl start dev-mapper-nvidia_cjjcaiiep1.device gives the same
result timeout.

and my /home is not mounted

When I do a manual mount of the /home partition
mount /dev/mapper/nvidia_cjjcaiiep1 /home
/home is mounted

Systemctl default

my system resumes booting and finally comes online.

I have the exact same problem with systemd-188-2, downgrading back to
systemd-187-4 makes it work again.

Be sure to report a bug in Arch's flyspray. Lots of developers don't
read arch-general anymore (we should all thank the polite
conversations of last days...)


I downgraded to systemd-187-4 but have still the same problem.

Any hints where to start searching?
Fred


I found a work around:

if I replace in fstab
/dev/mapper/nvidia_cjjcaiiep1 /home ext3
defaults,acl 0 1

by
/dev/dm-7 /home ext3 defaults,acl 0 1

the system is booting without problem.

Kind regards,
Fred
 
Old 08-17-2012, 03:44 PM
Thomas Bächler
 
Default systemd

Am 17.08.2012 17:28, schrieb Fred Verschueren:
>> I downgraded to systemd-187-4 but have still the same problem.
>>
>> Any hints where to start searching?
>> Fred
>>
> I found a work around:
>
> if I replace in fstab
> /dev/mapper/nvidia_cjjcaiiep1 /home ext3
> defaults,acl 0 1
> by
> /dev/dm-7 /home ext3 defaults,acl 0 1
>
> the system is booting without problem.

This is extremely dangerous! The name "dm-7" is not persistent at all,
it may change at will. What you describe here suggests a problem with
the device-mapper and its udev interaction.

Udev is supposed to create the symlink /dev/mapper/nvidia_cjjcaiiep1 ->
../dm-7, but it doesn't do so, or doesn't do so in time. This problem
lies somewhere in the device mapper library, or in the way the dmraid
tool uses it. To be more precise: When activating dmraid, the tool is
supposed to wait until udev successfully created the missing symlink. So
either dmraid is not configured to do that, or systemd doesn't wait
until dmraid finishes, or systemd doesn't know to call dmraid at all.

I don't understand enough about systemd to fix this right now, sorry.


I am forwarding this to Tom and Dave, who probably don't follow
arch-general anymore, but can surely shed some light on the situation.
 
Old 09-06-2012, 03:09 PM
francis picabia
 
Default systemd

On Wed, Jul 25, 2012 at 12:47 PM, Ralf Mardorf
<ralf.mardorf@alice-dsl.net> wrote:
> On Wed, 2012-07-25 at 17:32 +0200, Ralf Mardorf wrote:
>> On Wed, 2012-07-25 at 17:29 +0200, Ralf Mardorf wrote:
>> > PS: Even the Wiki shows him taking a photo from himself:
>> > http://en.wikipedia.org/wiki/Lennart_Poettering
>>
>> You think somebody else made a photo from him? Perhaps, but there's a
>> bad reflection that lead to a snapshot in front of a mirror and some
>> other photos, see the google link with no doubt are snapshots in front
>> of a mirror.
>
> Serious, I'm willing to test systemd, but many audio users already
> experienced that he does no self-reflection and he isn't open for bug
> reports. If PA breaks anything he claims is, that it's a borked ALSA
> driver, while the ALSA drivers for ALSA and Jack and any other
> soundservers do work. I'm doubtfully. He suggested sound card test that
> are insane, even people who hate me, agree with me on that, just
> regarding to audio engineering facts.
>
> "Mirror, mirror on the wall, tell me tell me what is wrong?"
>
> I'll wait. I wonder how rolling releases will do the switch .
> On Arch the discussion about another issue, became a discussion about
> systemd and than about Windows .
>
> In cases of doubt, I'm against using anythin coming from Lennart
> Poettering.
>
> 2 Cents,
> Ralf

These are good reasons to be cautious. Who is developing and controlling
the future of this is very important. Just because he is brave (or
foolish) enough
to take on something this big regardless of the long standing tradition of init
and writing POSIX compliant code, doesn't mean he is the best person for
the task.

Personally, I've seen young smart developers come and go. There were
a bunch at Gentoo. None of them had a hint of facial hair. Some
moved on to Ubuntu. Lots of smarts and short on wholistic view.

Those older bearded Unix guys are missing from the scene!

There are sometimes brilliant developers who come out
with the next best thing since __________ and turn out to be a mess.

Look at Reiser and the file system named after him.
Some distros were starting to adopt it as the default,
despite the horrible odds when there was any kind
of file system problem to repair. Then look at what he does in his
personal life. Then, what do you know, this file system
has no future once a single developer goes to jail.

I wrote off reiserfs the first time I saw the goofy tu-cows like
error message about a corrupted file system which told me
to send $20 to Reiser's company for support. It reminded me
so much of tu-cows nagware, but in this case perhaps ransomware?

systemd has 2 authors so far. I'd like to see 4 or more before
this goes ahead into production.

Like many projects, there is no pressing need to make this change,
so rather than think like the Gentoo ricer, think, what problem does this
solve? If very little, proceed with caution and grace.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CA+AKB6Eevs6U7qMbmB7f-UOMSTACogy+_hc-5YPksW2Qcxy1YQ@mail.gmail.com">http://lists.debian.org/CA+AKB6Eevs6U7qMbmB7f-UOMSTACogy+_hc-5YPksW2Qcxy1YQ@mail.gmail.com
 
Old 09-07-2012, 12:47 PM
Jon Dowland
 
Default systemd

On Thu, Sep 06, 2012 at 12:09:52PM -0300, francis picabia wrote:
> On Wed, Jul 25, 2012 at 12:47 PM, Ralf Mardorf
> <ralf.mardorf@alice-dsl.net> wrote:
> > In cases of doubt, I'm against using anythin coming from Lennart
> > Poettering.

Odd, I can't find Ralph's mail in my d-u archive, was it a private one?
Anyway, replying here rather than there since I can't find it.

If you are determined to avoid Lennart's code, you're going to have to
stop running the Linux kernel:

> commit ebec18a6d3aa1e7d84aab16225e87fd25170ec2b
> Author: Lennart Poettering <lennart@poettering.net>
> Date: Fri Mar 23 15:01:54 2012 -0700
>
> prctl: add PR_{SET,GET}_CHILD_SUBREAPER to allow simple process supervision

and

> commit 52a85e17091d2fe9ade6a5d94063e70c5d2a9d5b
> Author: Lennart Poettering <mzxreary@0pointer.de>
> Date: Thu Jun 4 16:18:13 2009 -0300
>
> V4L/DVB (11993): V4L/pwc - use usb_interface as parent, not usb_device

and don't worry, there are more, across many of the core kernel subsystems.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120907124732.GA29671@debian
 
Old 09-07-2012, 05:02 PM
Andrei POPESCU
 
Default systemd

On Jo, 06 sep 12, 12:09:52, francis picabia wrote:
>
> Like many projects, there is no pressing need to make this change,
> so rather than think like the Gentoo ricer, think, what problem does this
> solve? If very little, proceed with caution and grace.

Ironically, OpenRC is developed by Gentoo.

Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 09-07-2012, 07:06 PM
Henrique de Moraes Holschuh
 
Default systemd

On Fri, 07 Sep 2012, Jon Dowland wrote:
> If you are determined to avoid Lennart's code, you're going to have to
> stop running the Linux kernel:

...

Kernel patches from Lennart were properly reviewed, and accepted only after
the maintainers and subsystem maintainers approved them as an acceptable
solution for the general problem they were supposed to be addressing.

Lennart would not be able to easily push random crap to the kernel upstream
even if he tried to. It is a very different situation from userland.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120907190608.GE5847@khazad-dum.debian.net">http://lists.debian.org/20120907190608.GE5847@khazad-dum.debian.net
 
Old 09-08-2012, 09:34 AM
Jon Dowland
 
Default systemd

On Fri, Sep 07, 2012 at 04:06:08PM -0300, Henrique de Moraes Holschuh wrote:
> Kernel patches from Lennart were properly reviewed, and accepted only after
> the maintainers and subsystem maintainers approved them as an acceptable
> solution for the general problem they were supposed to be addressing.
>
> Lennart would not be able to easily push random crap to the kernel upstream
> even if he tried to. It is a very different situation from userland.

How so? Do you believe Redhat, Fedora etc. ship anything Lennart writes without
any kind of review? Do you think he has carte blanche as part of his employment
to do whatever he wants?

He is a convenient scapegoat. It's absurd to avoid code he's written, and
reductio ad absurdum, it would be absurd to avoid the kernel.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120908093440.GA1917@debian
 
Old 09-08-2012, 03:38 PM
Martin Steigerwald
 
Default systemd

Am Freitag, 7. September 2012 schrieb Henrique de Moraes Holschuh:
> On Fri, 07 Sep 2012, Jon Dowland wrote:
> > If you are determined to avoid Lennart's code, you're going to have
> > to
>
> > stop running the Linux kernel:
> ...
>
> Kernel patches from Lennart were properly reviewed, and accepted only
> after the maintainers and subsystem maintainers approved them as an
> acceptable solution for the general problem they were supposed to be
> addressing.
>
> Lennart would not be able to easily push random crap to the kernel
> upstream even if he tried to. It is a very different situation from
> userland.

Just a short look at

http://cgit.freedesktop.org/systemd/systemd/

and

http://cgit.freedesktop.org/systemd/systemd/log/


shows that Lennart is not the only one committing stuff to systemd.

Kay Sievers AFAIK does udev stuff. Tollef Fog Heen contributes to the
systemd debian package.

And there are quite some others.

Granted, it seems that Lennart does most of the commits, so thats still a
different situation than with the Linux kernel, but still it does not seem
to be a one man show. Especially when going a bit back August this year in
the log.

That written just from a quick glimpse. There are visualizition and
statistic tools available to further verify or falsify my current thesis
that systemd has quite some contributors.

--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201209081738.45598.Martin@lichtvoll.de">http://lists.debian.org/201209081738.45598.Martin@lichtvoll.de
 

Thread Tools




All times are GMT. The time now is 12:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org