On Fri, Jul 8, 2016 at 12:39 PM, Lennart Poettering
wrote:
> Well, personally I am not convinced that a policy of "automatic time-based
> degrading" is a good default policy, and that a policy of "require
> manual intervention to proceed with degrading" is a better default
> policy.
I think that
On Wed, 06.07.16 12:36, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> > I figure it would be OK to merge a patch that makes the udev rules
> > above set SYSTEMD_READY immediately if the device popped up in case
> > some new kernel command line option is set.
>
> That won't work. This will make
Am Wed, 6 Jul 2016 06:21:17 +0200
schrieb Lennart Poettering :
> On Mon, 04.07.16 12:32, Chris Murphy (li...@colorremedies.com) wrote:
>
> > I have a system where I get an indefinite
> >
> > "A start job is running for dev-vda2.device (xmin ys / no limit)"
> >
> > Is there a boot parameter to u
Am Wed, 6 Jul 2016 06:26:03 +0200
schrieb Lennart Poettering :
> On Tue, 05.07.16 14:00, Chris Murphy (li...@colorremedies.com) wrote:
>
> > On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy
> > wrote:
> > > OK it must be this.
> > >
> > > :/# cat /usr/lib/udev/rules.d/64-btrfs.rules
> > > # do no
On Wed, Jul 6, 2016 at 3:36 AM, Andrei Borzenkov wrote:
> On Wed, Jul 6, 2016 at 7:26 AM, Lennart Poettering
> wrote:
>> I figure it would be OK to merge a patch that makes the udev rules
>> above set SYSTEMD_READY immediately if the device popped up in case
>> some new kernel command line optio
On Wed, Jul 6, 2016 at 7:26 AM, Lennart Poettering
wrote:
> On Tue, 05.07.16 14:00, Chris Murphy (li...@colorremedies.com) wrote:
>
>> On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy
>> wrote:
>> > OK it must be this.
>> >
>> > :/# cat /usr/lib/udev/rules.d/64-btrfs.rules
>> > # do not edit this f
On Mon, 04.07.16 12:32, Chris Murphy (li...@colorremedies.com) wrote:
> I have a system where I get an indefinite
>
> "A start job is running for dev-vda2.device (xmin ys / no limit)"
>
> Is there a boot parameter to use to change the no limit to have a
> limit? rd.timeout does nothing. When I u
On Tue, 05.07.16 14:00, Chris Murphy (li...@colorremedies.com) wrote:
> On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy wrote:
> > OK it must be this.
> >
> > :/# cat /usr/lib/udev/rules.d/64-btrfs.rules
> > # do not edit this file, it will be overwritten on update
> >
> > SUBSYSTEM!="block", GOTO=
On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy wrote:
> OK it must be this.
>
> :/# cat /usr/lib/udev/rules.d/64-btrfs.rules
> # do not edit this file, it will be overwritten on update
>
> SUBSYSTEM!="block", GOTO="btrfs_end"
> ACTION=="remove", GOTO="btrfs_end"
> ENV{ID_FS_TYPE}!="btrfs", GOTO="bt
OK it must be this.
:/# cat /usr/lib/udev/rules.d/64-btrfs.rules
# do not edit this file, it will be overwritten on update
SUBSYSTEM!="block", GOTO="btrfs_end"
ACTION=="remove", GOTO="btrfs_end"
ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
# let the kernel know about this btrfs filesystem, and che
On Tue, Jul 5, 2016 at 10:53 AM, Chris Murphy wrote:
> It seems like this dracut doesn't understand rd.timeout.
OK now on Fedora Rawhide and rd.timeout=30 appears to work. The
failure is the same, systemd is waiting for /dev/vda2 for an unknown
reason, it doesn't even attempt to mount it so this
New console log.
Command line: BOOT_IMAGE=/vmlinuz-3.10.0-327.22.2.el7.x86_64
root=/dev/vda2 ro rootflags=subvol=root,degraded vconsole.keymap=us
crashkernel=auto vconsole.font=latarcyrheb-sun16 LANG=en_US.UTF-8
rd.timeout=30 rd.debug rd.udev.debug systemd.log_level=debug
systemd.log_target=console
pre-mount:/# cat /run/systemd/generator/dev-vda2.device.d/timeout.conf
[Unit]
JobTimeoutSec=0
This is virsh console output during boot:
https://drive.google.com/open?id=0B_2Asp8DGjJ9RlN1cGJTTEtHcjg
Here is journalctl -b -o short-monotonic output from the pre-mount
shell using Command line:
BOOT_
On Mon, Jul 4, 2016 at 9:24 PM, Andrei Borzenkov wrote:
> 04.07.2016 21:32, Chris Murphy пишет:
>> I have a system where I get an indefinite
>>
>> "A start job is running for dev-vda2.device (xmin ys / no limit)"
>>
>> Is there a boot parameter to use to change the no limit to have a
>> limit? rd.
04.07.2016 21:32, Chris Murphy пишет:
> I have a system where I get an indefinite
>
> "A start job is running for dev-vda2.device (xmin ys / no limit)"
>
> Is there a boot parameter to use to change the no limit to have a
> limit? rd.timeout does nothing.
It should. Use rd.break and examine unit
I have a system where I get an indefinite
"A start job is running for dev-vda2.device (xmin ys / no limit)"
Is there a boot parameter to use to change the no limit to have a
limit? rd.timeout does nothing. When I use rd.break=pre-mount and use
blkid, /dev/vda2 is there and can be mounted with the
16 matches
Mail list logo