Page 1 of 8 123 ... LastLast
Results 1 to 10 of 76

Thread: Welcome to emergency mode!

  1. #1

    Default Welcome to emergency mode!

    Since upgrading to openSUSE 12.3 (Dartmouth) (x86_64) with Linux 3.7.10-1.1-desktop and KDE 4.10.00 "release1" on an AMD Athlon 64 Processor 3200+, I usually boot into emergency mode! I don't think systemctl has ever failed me, but would be glad to escape this diversion, so would be grateful to anybody who can understand the following system boot log and advise me what I have to do to return to normal:
    Apr 02 10:43:50 UsrFriendesktop.Lisheen systemd-journal[227]: Allowing runtime journal files to grow to 100.3M.
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Initializing cgroup subsys cpuset
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Initializing cgroup subsys cpu
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Linux version 3.7.10-1.1-desktop (geeko@buildhost) (gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1 SMP PREEMPT Thu Feb 28 15:06:29 UTC 2013 (82d3f21)
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-3.7.10-1.1-desktop root=UUID=7417c0e6-33e0-4f84-ad65-1a84ce56c0d7 resume=/dev/disk/by-id/ata-ST3160827AS_4MT0BNMF-part5 splash=silent quiet showopts
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: e820: BIOS-provided physical RAM map:
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: BIOS-e820: [mem 0x0000000000100000-0x000000007ff2ffff] usable
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: BIOS-e820: [mem 0x000000007ff30000-0x000000007ff3ffff] ACPI data
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: BIOS-e820: [mem 0x000000007ff40000-0x000000007ffeffff] ACPI NVS
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: BIOS-e820: [mem 0x000000007fff0000-0x000000007fffffff] reserved
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: BIOS-e820: [mem 0x00000000fff80000-0x00000000ffffffff] reserved
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: NX (Execute Disable) protection: active
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: SMBIOS 2.3 present.
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./K8V-X, BIOS 1012.003 09/12/2005
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: e820: remove [mem 0x000a0000-0x000fffff] usable
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: AGP bridge at 00:00:00
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Aperture from AGP @ f4000000 old size 32 MB
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Aperture from AGP @ f4000000 size 64 MB (APSIZE f30)
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: e820: last_pfn = 0x7ff30 max_arch_pfn = 0x400000000
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: MTRR default type: uncachable
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: MTRR fixed ranges enabled:
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: 00000-9FFFF write-back
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: A0000-EFFFF uncachable
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: F0000-FFFFF write-protect
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: MTRR variable ranges enabled:
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: 0 base 0000000000 mask FF80000000 write-back
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: 1 disabled
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: 2 disabled
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: 3 disabled
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: 4 disabled
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: 5 disabled
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: 6 disabled
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: 7 disabled
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [ffff8800000ff780]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: initial memory mapped: [mem 0x00000000-0x1fffffff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Base memory trampoline at [ffff880000099000] 99000 size 24576
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: init_memory_mapping: [mem 0x00000000-0x7ff2ffff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: [mem 0x00000000-0x7fdfffff] page 2M
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: [mem 0x7fe00000-0x7ff2ffff] page 4k
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: kernel direct mapping tables up to 0x7ff2ffff @ [mem 0x1fffc000-0x1fffffff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: RAMDISK: [mem 0x340e8000-0x3606bfff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: ACPI: RSDP 00000000000faa60 00014 (v00 ACPIAM)
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: ACPI: RSDT 000000007ff30000 00030 (v01 A M I OEMRSDT 09000512 MSFT 00000097)
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: ACPI: FACP 000000007ff30200 00081 (v01 A M I OEMFACP 09000512 MSFT 00000097)
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: ACPI: DSDT 000000007ff303e0 03632 (v01 A0091 A0091006 00000006 MSFT 0100000D)
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: ACPI: FACS 000000007ff40000 00040
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: ACPI: APIC 000000007ff30390 0004A (v01 A M I OEMAPIC 09000512 MSFT 00000097)
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: ACPI: OEMB 000000007ff40040 0003F (v01 A M I OEMBIOS 09000512 MSFT 00000097)
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: ACPI: Local APIC address 0xfee00000
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Scanning NUMA topology in Northbridge 24
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: No NUMA configuration found
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Faking a node at [mem 0x0000000000000000-0x000000007ff2ffff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Initmem setup node 0 [mem 0x00000000-0x7ff2ffff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: NODE_DATA [mem 0x7ff1c000-0x7ff2ffff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: [ffffea0000000000-ffffea0001bfffff] PMD -> [ffff88007d600000-ffff88007f1fffff] on node 0
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Zone ranges:
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: DMA [mem 0x00010000-0x00ffffff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: DMA32 [mem 0x01000000-0xffffffff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Normal empty
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Movable zone start for each node
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: Early memory node ranges
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: node 0: [mem 0x00010000-0x0009efff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: node 0: [mem 0x00100000-0x7ff2ffff]
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: On node 0 totalpages: 523967
    Apr 02 10:43:50 UsrFriendesktop.Lisheen kernel: DMA zone: 56 pages used for memmap

  2. #2
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Welcome to emergency mode!

    On 2013-04-02 12:06, peterichardavis wrote:

    > Since upgrading to openSUSE 12.3 (Dartmouth) (x86_64) with Linux
    > 3.7.10-1.1-desktop and KDE 4.10.00 "release1" on an AMD Athlon 64
    > Processor 3200+, I usually boot into emergency mode! I don't think
    > systemctl has ever failed me, but would be glad to escape this
    > diversion, so would be grateful to anybody who can understand the
    > following system boot log and advise me what I have to do to return to
    > normal:


    Please use code tags for printouts and commands. Advanced editor, '#'
    button.
    Posting in Code Tags - A Guide
    . Or upload to susepaste.

    Sorry, I don't see anything of interest in your log. According to the
    developers, you look in "systemd-journalctl" to find out what happened.

    This lack of information by systemd, by the way, is "Bug 782904".

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 12.1 x86_64 "Asparagus" at Telcontar)

  3. #3
    Join Date
    Sep 2012
    Posts
    4,528

    Default Re: Welcome to emergency mode!

    Quote Originally Posted by robin_listas View Post
    "systemd-journalctl"
    This is simply journalctl in 12.3. And in 12.3 it even says you to call it when entering emergency mode.

  4. #4
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Welcome to emergency mode!

    On 2013-04-02 16:36, arvidjaar wrote:
    >
    > robin_listas;2543748 Wrote:
    >> "systemd-journalctl"

    > This is simply journalctl in 12.3.


    Ah.

    > And in 12.3 it even says you to call
    > it when entering emergency mode.


    The problem is, as explained in that bugzilla, that log is useless to
    find what was the actual problem that provoked emergency mode to start.


    I may have to repeat the test in 12.3 and report again as/if necessary.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 12.1 x86_64 "Asparagus" at Telcontar)

  5. #5
    Join Date
    Sep 2012
    Posts
    4,528

    Default Re: Welcome to emergency mode!

    Quote Originally Posted by robin_listas View Post
    The problem is, as explained in that bugzilla, that log is useless to
    find what was the actual problem that provoked emergency mode to start.


    I may have to repeat the test in 12.3 and report again as/if necessary.
    Newer systemd became better in this respect, "journalctl -b" in emergency mode usually gives enough information which mandatory service failed to start. Of course, to find why it failed to start is more challenging.

    Upstream systemd now finally preserves current services state when going in emergency mode, and this patch is queued to be released as update for 12.3 as well. It means you also will be able to use standard systemctl to check services state, see error output etc.

  6. #6
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Welcome to emergency mode!

    On 2013-04-02 17:16, arvidjaar wrote:
    >
    > robin_listas;2543782 Wrote:
    >>
    >> The problem is, as explained in that bugzilla, that log is useless to
    >> find what was the actual problem that provoked emergency mode to start.
    >>
    >>
    >> I may have to repeat the test in 12.3 and report again as/if necessary.
    >>

    >
    > Newer systemd became better in this respect, "journalctl -b" in
    > emergency mode usually gives enough information which mandatory service
    > failed to start. Of course, to find *why* it failed to start is more
    > challenging.


    I'll try this when my time permits... I'm interested.

    What happens if the emergency mode fails badly and I have to use a
    separate rescue system, is the information still available :-?


    > Upstream systemd now finally preserves current services state when
    > going in emergency mode, and this patch is queued to be released as
    > update for 12.3 as well. It means you also will be able to use standard
    > systemctl to check services state, see error output etc.


    Mmm.... :-)

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 12.1 x86_64 "Asparagus" at Telcontar)

  7. #7
    Join Date
    Sep 2012
    Posts
    4,528

    Default Re: Welcome to emergency mode!

    Quote Originally Posted by robin_listas View Post

    > Upstream systemd now finally preserves current services state when
    > going in emergency mode, and this patch is queued to be released as
    > update for 12.3 as well. It means you also will be able to use standard
    > systemctl to check services state, see error output etc.


    Mmm.... :-)
    Is this a question?

    In addition to start and stop systemd supports "isolate" operation. Comparing to "start" in addition to starting all dependencies it also stops everything that is currently started but is not in list of dependencies. This is normally used to switch "run-levels" (doing "init 3" will stop X as example because X is not in list of services that would be started by multi-user.target).

    Historically systemd performed "isolate emergency.target" when fatal errors were encountered during system startup. The effect was, almost all services that had failed were stopped. So when you tried to see failed services with "systemctl --failed" no services were listed. Because they no more were "failed".

    This patch changes it into "start emergency.target" (or .service, do not remember), so all state is preserved. You see immediately what failed and to some extent why.

    What happens if the emergency mode fails badly and I have to use a
    separate rescue system, is the information still available :-?
    By default on openSUSE journal is volatile, so it is lost. You can make it non-volatile, but I'm not sure how often it is flushed to disk. Of course, if system is failed so badly that even emergency mode does not start, there is no guarantee journal could be started or it could write anything to disk.

  8. #8
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Welcome to emergency mode!

    On 2013-04-02 19:56, arvidjaar wrote:
    >
    > robin_listas;2543787 Wrote:
    >>
    >>
    >>> Upstream systemd now finally preserves current services state when
    >>> going in emergency mode, and this patch is queued to be released as
    >>> update for 12.3 as well. It means you also will be able to use

    >> standard
    >>> systemctl to check services state, see error output etc.

    >>
    >> Mmm.... :-)

    >
    > Is this a question?


    My neurones trying to digest some difficult information and grumbling a
    bit :-)

    > In addition to start and stop systemd supports "isolate" operation.
    > Comparing to "start" in addition to starting all dependencies it also
    > stops everything that is currently started but is *not* in list of
    > dependencies. This is normally used to switch "run-levels" (doing "init
    > 3" will stop X as example because X is not in list of services that
    > would be started by multi-user.target).
    >
    > Historically systemd performed "isolate emergency.target" when fatal
    > errors were encountered during system startup. The effect was, almost
    > all services that had failed were stopped. So when you tried to see
    > failed services with "systemctl --failed" no services were listed.
    > Because they no more were "failed".
    >
    > This patch changes it into "start emergency.target" (or .service, do
    > not remember), so all state is preserved. You see immediately what
    > failed and to some extent why.


    Ah! I understand now, that is very interesting. Thank you for the
    expanded explanation :-)


    >> What happens if the emergency mode fails badly and I have to use a
    >> separate rescue system, is the information still available :-?

    > By default on openSUSE journal is volatile, so it is lost. You can make
    > it non-volatile, but I'm not sure how often it is flushed to disk. Of
    > course, if system is failed so badly that even emergency mode does not
    > start, there is no guarantee journal could be started or it could write
    > anything to disk.


    Ah. I see, it is that journal.

    There is a package, not installed by default, that does the writing to
    file. There have been reports of people with that file growing to 200MB
    or so, with the side effect of making boot very slow. The maximum size
    is adjustable. I made notes of that somewhere :-)

    Someday I will have to collect all those dispersed notes in a single
    file, but as I'm still using systemv, I feel lazy about it :-)

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 12.1 x86_64 "Asparagus" at Telcontar)

  9. #9

    Default Re: Welcome to emergency mode!

    > My neurones trying to digest some difficult information and grumbling a
    > bit :-)

    It'sreassuring, in a way, to know that a Flux Capacitor Penguin can be so afflicted. I, as a Newcomer, feel a bit less inadequate.

    My printout was produced by journalctl -b.

    I take it that my current bottom line is that I have to live with the diversion and the consequent slow boot. I hope that I'll be made aware when the patch is released, in the hope that somebody will be able to help me back to normal.

    Peter Davis

  10. #10
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    9,099
    Blog Entries
    1

    Default Re: Welcome to emergency mode!

    Maybe I misunderstood what is volatile or not?

    AFAIK
    The journal is not volatile, and is historically searchable. But, if you want to inspect only what occurred during your current session, then apply the "-b" flag.

    Unit status is volatile, and currently I do not know of any way to preserve that information except by writing to file which is easy enough to do.

    "isolate" is merely the systemd syntax for specifying the init level, typically changing from default.

    So far, I have not yet found any limitation to running systemctl in emergency mode although listing failed/stopped services sounds interesting. I would expect that if I'm successfully booted into emergency mode (not rebooted) because of a failure, "status" and maybe grepping for "Failed" should return the relevant information if state has changed.

    AFAIK and still learning,
    TSU

Page 1 of 8 123 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •