Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #187691 > unrolled thread

Log files: location and description

Back to article view | Back to linux.debian.user

Contents

  Log files: location and description Richard Owlett <rowlett@cloud85.net> - 2017-10-07 16:40 +0200
    Re: Log files: location and description David Wright <deblis@lionunicorn.co.uk> - 2017-10-07 22:10 +0200
      Re: HD device name assignments (was: Log files: location and  description) Felix Miata <mrmazda@earthlink.net> - 2017-10-07 22:30 +0200
        Re: HD device name assignments Richard Owlett <rowlett@cloud85.net> - 2017-10-08 14:40 +0200
      Re: Log files: location and description <tomas@tuxteam.de> - 2017-10-08 14:40 +0200
        Re: Log files: location and description Richard Owlett <rowlett@cloud85.net> - 2017-10-08 16:00 +0200
          Re: Log files: location and description <tomas@tuxteam.de> - 2017-10-08 16:50 +0200
            Re: Log files: location and description Richard Owlett <rowlett@cloud85.net> - 2017-10-08 17:10 +0200
        Re: Log files: location and description Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-09 15:10 +0200
          Re: Log files: location and description <tomas@tuxteam.de> - 2017-10-09 18:10 +0200
      Re: Log files: location and description Richard Owlett <rowlett@cloud85.net> - 2017-10-08 14:40 +0200
        Re: Log files: location and description David Wright <deblis@lionunicorn.co.uk> - 2017-10-08 22:40 +0200
      Re: Log files: location and description Richard Owlett <rowlett@cloud85.net> - 2017-10-08 15:50 +0200
    Debian-installer writes /dev/ references in grub.cfg, was Re: Log  files: location and description David Wright <deblis@lionunicorn.co.uk> - 2017-10-09 02:10 +0200

#187691 — Log files: location and description

I'm looking for a comprehensive catalog of log files giving location, 
name, and one line description. I've Googled and found bits and pieces 
that are too narrowly focused. To paraphrase my situation, I'm not only 
not seeing the forest for the trees -- I'm also not seeing the forest 
for the leaves.

My current problem is finding the appropriate logs to document the 
details behind my addendum to Bug 852323.

The BIOS of the test machine can select whether to boot from the primary 
HDD or from a particular flash drive. There are multiple instances of 
Debian installed. Grub was installed to the MBR of that drive when 
Debian was installed to the drive's first partition.

I have a hypothesis, but I need to have facts to back it up.
Specifically:
1. During the installation process I need to inventory when and
    "as what" various USB devices are recognized. The installation
    target is a USB drive and Grub is being installed to its MBR.
2. Under particular circumstances it will fail to boot. I need
    to compare that log to that written when it successfully boots.
3. I need to know what happens during update-grub run from the HDD.
4. I need to repeat [2] but for the case that the the Grub menu is
    on the HDD.

TIA

[toc] | [next] | [standalone]

#187702

On Sat 07 Oct 2017 at 09:36:37 (-0500), Richard Owlett wrote:
> I'm looking for a comprehensive catalog of log files giving
> location, name, and one line description. I've Googled and found
> bits and pieces that are too narrowly focused. To paraphrase my
> situation, I'm not only not seeing the forest for the trees -- I'm
> also not seeing the forest for the leaves.
> 
> My current problem is finding the appropriate logs to document the
> details behind my addendum to Bug 852323.
> 
> The BIOS of the test machine can select whether to boot from the
> primary HDD or from a particular flash drive. There are multiple
> instances of Debian installed. Grub was installed to the MBR of that
> drive when Debian was installed to the drive's first partition.
> 
> I have a hypothesis, but I need to have facts to back it up.
> Specifically:
> 1. During the installation process I need to inventory when and
>    "as what" various USB devices are recognized. The installation
>    target is a USB drive and Grub is being installed to its MBR.

It's all in /var/log/installer, specifically syslog.
partman has the partitioning, and hardware-summary gives
both that and related software summaries. That's all after
the event, of course. While the d-i is running, syslog
is under /var/log as normal.

> 2. Under particular circumstances it will fail to boot. I need
>    to compare that log to that written when it successfully boots.

With expert install, the splash/menu screen goes away and boot
messages come out on the console in my experience.

> 3. I need to know what happens during update-grub run from the HDD.
> 4. I need to repeat [2] but for the case that the the Grub menu is
>    on the HDD.

update-grub runs grub-mkconfig which is a script, so I suppose
you could add set -x to make it print all its expanded commands
(as I do in .xsession).

Without getting into the specifics of that bug, ie UUID stuff,
it might be worth pointing out that it has been reported here that
a USB3 stick inserted at boot can demote the internal disk to
/dev/sdb. No idea if that's relevant here unless you're using
/dev/sdX without actually checking the by-id values that d-i
displays in the relevant places.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#187703 — Re: HD device name assignments (was: Log files: location and description)

David Wright composed on 2017-10-07 15:01 (UTC-0500):

> it might be worth pointing out that it has been reported here that
> a USB3 stick inserted at boot can demote the internal disk to
> /dev/sdb. 

It need not be v3 of USB, and it's one of the prime reasons alternatives to
booting by device name were developed in the first place. Assignments are
typically BIOS dependent at least to some extent. The push isn't always to sdb
either. I've seen sda moved to sdf, sdg and sdh at times with some kernels over
time. Ultimately, device names come down to kernel version and whether the ATA
bus(es) are enumerated and initialized prior to USB(s) or not.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#187726 — Re: HD device name assignments

On 10/07/2017 03:24 PM, Felix Miata wrote:
> David Wright composed on 2017-10-07 15:01 (UTC-0500):
>
>> it might be worth pointing out that it has been reported here that
>> a USB3 stick inserted at boot can demote the internal disk to
>> /dev/sdb.
>
> It need not be v3 of USB, and it's one of the prime reasons alternatives to
> booting by device name were developed in the first place. Assignments are
> typically BIOS dependent at least to some extent. The push isn't always to sdb
> either. I've seen sda moved to sdf, sdg and sdh at times with some kernels over
> time. Ultimately, device names come down to kernel version and whether the ATA
> bus(es) are enumerated and initialized prior to USB(s) or not.
>

I suspect that is much of the problem.

[toc] | [prev] | [next] | [standalone]

#187727

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Oct 08, 2017 at 07:31:23AM -0500, Richard Owlett wrote:
> On 10/07/2017 03:01 PM, David Wright wrote:
> >On Sat 07 Oct 2017 at 09:36:37 (-0500), Richard Owlett wrote:

[...]

No idea about the other things, but:

> I don't understand.
> According to the man page neither update-grub nor grub-mkconfig have
> an "-x" option.

It's a shell feature: if you do "set -x" in a shell script, all the
commands in the current shell get transcribed (to stdout, I think).

In a shell, type "help set" to learn a lot (better "help set | less").

So if you sneak a "set -x" into said shell scripts you get to see
what they are "thinking". Very useful for debugging purposes.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnaHD0ACgkQBcgs9XrR2kar0ACfcb50xtUhAVKSTFlDq8Z1NGUj
FHkAn11u+zbpcCiTZKIDNLPiV4QUBqYZ
=L9Ws
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#187733

On 10/08/2017 07:38 AM, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, Oct 08, 2017 at 07:31:23AM -0500, Richard Owlett wrote:
>> On 10/07/2017 03:01 PM, David Wright wrote:
>>> On Sat 07 Oct 2017 at 09:36:37 (-0500), Richard Owlett wrote:
>
> [...]
>
> No idea about the other things, but:
>
>> I don't understand.
>> According to the man page neither update-grub nor grub-mkconfig have
>> an "-x" option.
>
> It's a shell feature: if you do "set -x" in a shell script, all the
> commands in the current shell get transcribed (to stdout, I think).

It didn't provide any additional details when running update-grub.

>
> In a shell, type "help set" to learn a lot (better "help set | less").

I learned I need to study more ;/
It appears to be a summary of a more complete document.
What would it be? Is it on the web?
Thanks

>
> So if you sneak a "set -x" into said shell scripts you get to see
> what they are "thinking". Very useful for debugging purposes.
>
> Cheers
> - -- tomás
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlnaHD0ACgkQBcgs9XrR2kar0ACfcb50xtUhAVKSTFlDq8Z1NGUj
> FHkAn11u+zbpcCiTZKIDNLPiV4QUBqYZ
> =L9Ws
> -----END PGP SIGNATURE-----
>
>

[toc] | [prev] | [next] | [standalone]

#187740

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Oct 08, 2017 at 08:58:11AM -0500, Richard Owlett wrote:
> On 10/08/2017 07:38 AM, tomas@tuxteam.de wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On Sun, Oct 08, 2017 at 07:31:23AM -0500, Richard Owlett wrote:

[...]

> >In a shell, type "help set" to learn a lot (better "help set | less").
> 
> I learned I need to study more ;/
> It appears to be a summary of a more complete document.
> What would it be? Is it on the web?

It's on your computer ;-)

Basically (not literally, though) it's an extract of "man bash" (careful:
that one is over 3k lines long). Happy reading ;^)

Each shell builtin has a little help blurb: sometimes that's easier to
find than the spot in the big man page (which is really worth perusing,
nevertheless!)

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnaONAACgkQBcgs9XrR2kbl/wCbBdgZDA2bQ6FMjIR5HqkSYckw
9GoAn2YJtrkgqv6WqUyHDW7SFAQqdgeX
=zMBV
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#187742

On 10/08/2017 09:40 AM, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, Oct 08, 2017 at 08:58:11AM -0500, Richard Owlett wrote:
>> On 10/08/2017 07:38 AM, tomas@tuxteam.de wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Sun, Oct 08, 2017 at 07:31:23AM -0500, Richard Owlett wrote:
>
> [...]
>
>>> In a shell, type "help set" to learn a lot (better "help set | less").
>>
>> I learned I need to study more ;/
>> It appears to be a summary of a more complete document.
>> What would it be? Is it on the web?
>
> It's on your computer ;-)

There's lots of things on my computer ;/!
I often don't know what to look for.

>
> Basically (not literally, though) it's an extract of "man bash" (careful:
> that one is over 3k lines long). Happy reading ;^)

I DID ask for a reading assignment.
Who knows what I might learn ;)



>
> Each shell builtin has a little help blurb: sometimes that's easier to
> find than the spot in the big man page (which is really worth perusing,
> nevertheless!)
>

[toc] | [prev] | [next] | [standalone]

#187775

On Sun, Oct 08, 2017 at 02:38:21PM +0200, tomas@tuxteam.de wrote:
> It's a shell feature: if you do "set -x" in a shell script, all the
> commands in the current shell get transcribed (to stdout, I think).

To stderr by default, but bash lets you set the BASH_XTRACEFD variable
to send it elsewhere.

[toc] | [prev] | [next] | [standalone]

#187779

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Oct 09, 2017 at 09:02:12AM -0400, Greg Wooledge wrote:
> On Sun, Oct 08, 2017 at 02:38:21PM +0200, tomas@tuxteam.de wrote:
> > It's a shell feature: if you do "set -x" in a shell script, all the
> > commands in the current shell get transcribed (to stdout, I think).
> 
> To stderr by default, but bash lets you set the BASH_XTRACEFD variable
> to send it elsewhere.

OK, thanks :-)

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnbnc8ACgkQBcgs9XrR2kZObACfbK08VjCnvvFX4AulEm8N0PZx
SgsAnA7vizD46cgXM0FbE5+rT4hIXm6H
=AN0V
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#187728

On 10/07/2017 03:01 PM, David Wright wrote:
> On Sat 07 Oct 2017 at 09:36:37 (-0500), Richard Owlett wrote:
>> [snip]
>>
>> I have a hypothesis, but I need to have facts to back it up.
>> Specifically:
>> 1. During the installation process I need to inventory when and
>>    "as what" various USB devices are recognized. The installation
>>    target is a USB drive and Grub is being installed to its MBR.
>
> It's all in /var/log/installer, specifically syslog.
> partman has the partitioning, and hardware-summary gives
> both that and related software summaries. That's all after
> the event, of course. While the d-i is running, syslog
> is under /var/log as normal.

My basic problem is not knowing what is "normal" ;)
This information should remedy my immediate problem.

>
>> 2. Under particular circumstances it will fail to boot. I need
>>    to compare that log to that written when it successfully boots.
>
> With expert install, the splash/menu screen goes away and boot
> messages come out on the console in my experience.

The messages are clear enough as to what it sees as the problem. My 
intention was to explain why.

>
>> 3. I need to know what happens during update-grub run from the HDD.
>> 4. I need to repeat [2] but for the case that the the Grub menu is
>>    on the HDD.
>
> update-grub runs grub-mkconfig which is a script, so I suppose
> you could add set -x to make it print all its expanded commands
> (as I do in .xsession).

I don't understand.
According to the man page neither update-grub nor grub-mkconfig have an 
"-x" option.
The man page for xsession only mentions ".xsession" in passing. One 
reference refers reader to man page for xinit which I did not find 
informative.

Obviously I'm missing some background. What should I be reading?

>
> Without getting into the specifics of that bug, ie UUID stuff,
> it might be worth pointing out that it has been reported here that
> a USB3 stick inserted at boot can demote the internal disk to
> /dev/sdb. No idea if that's relevant here unless you're using
> /dev/sdX without actually checking the by-id values that d-i
> displays in the relevant places.

I was suspecting something similar but instead of vainly attempting to 
describe it on my own I wanted to quote log files.
My USB3 device is a WiFi Hotspot. IIRC it can initially be recognized as 
a memory device before it initializes.

I wanted to establish that if the installer used UUIDs my symptom would 
disappear. I don't know if there would be unwanted side-effects.

As a side note I'm investigating a possible problem with os-prober. But 
I need information from logfiles to determine if there is an actual 
problem or just confused operator.

>
> Cheers,
> David.
>

[toc] | [prev] | [next] | [standalone]

#187753

On Sun 08 Oct 2017 at 07:31:23 (-0500), Richard Owlett wrote:
> On 10/07/2017 03:01 PM, David Wright wrote:
> >On Sat 07 Oct 2017 at 09:36:37 (-0500), Richard Owlett wrote:
> >>[snip]
> >>
> >>I have a hypothesis, but I need to have facts to back it up.
> >>Specifically:
> >>1. During the installation process I need to inventory when and
> >>   "as what" various USB devices are recognized. The installation
> >>   target is a USB drive and Grub is being installed to its MBR.
> >
> >It's all in /var/log/installer, specifically syslog.
> >partman has the partitioning, and hardware-summary gives
> >both that and related software summaries. That's all after
> >the event, of course. While the d-i is running, syslog
> >is under /var/log as normal.
> 
> My basic problem is not knowing what is "normal" ;)
> This information should remedy my immediate problem.

When a linux system is running, the system log is in
/var/log/syslog. The d-i is a linux system.
When the d-i completes, it copies the logs into
/var/log/installer/ so that (a) the d-i logs aren't
confused with the installed systems logs (as,
technically, they aren't the same system) and
(b) they don't get rotated away after a week
because they naturally were the oldset.

> >>2. Under particular circumstances it will fail to boot. I need
> >>   to compare that log to that written when it successfully boots.
> >
> >With expert install, the splash/menu screen goes away and boot
> >messages come out on the console in my experience.
> 
> The messages are clear enough as to what it sees as the problem. My
> intention was to explain why.

Well, if it fails to boot, you've got a problen to preserve the logs.
One way would be to use a serial console which is actually another
PC that's running script to capture the output. Can the d-i do that?

> >>3. I need to know what happens during update-grub run from the HDD.
> >>4. I need to repeat [2] but for the case that the the Grub menu is
> >>   on the HDD.
> >
> >update-grub runs grub-mkconfig which is a script, so I suppose
> >you could add set -x to make it print all its expanded commands
> >(as I do in .xsession).
> 
> I don't understand.
> According to the man page neither update-grub nor grub-mkconfig have
> an "-x" option.

No, that's why I wrote "set -x". Look at the top of grub-mkconfig
and you will see that it has set -e to make it bottle out after any
error. Edit a copy adding set -x and run that.

> The man page for xsession only mentions ".xsession" in passing. One
> reference refers reader to man page for xinit which I did not find
> informative.

That was an aside. My .xsession digs stuff out of   xrdb -symbols
and I want to see in .xsession-errors the consequent parameter
substitutions it made in the .xsession commands, rather than try
to guess what they were.

> Obviously I'm missing some background. What should I be reading?
> 
> >
> >Without getting into the specifics of that bug, ie UUID stuff,
> >it might be worth pointing out that it has been reported here that
> >a USB3 stick inserted at boot can demote the internal disk to
> >/dev/sdb. No idea if that's relevant here unless you're using
> >/dev/sdX without actually checking the by-id values that d-i
> >displays in the relevant places.
> 
> I was suspecting something similar but instead of vainly attempting
> to describe it on my own I wanted to quote log files.
> My USB3 device is a WiFi Hotspot. IIRC it can initially be
> recognized as a memory device before it initializes.

My guess would be that demotion is more likely then.

> I wanted to establish that if the installer used UUIDs my symptom
> would disappear. I don't know if there would be unwanted
> side-effects.

It might be better to put "writes" rather than "uses" as it's
less ambigous. I'll address your symptom separately.

> As a side note I'm investigating a possible problem with os-prober.
> But I need information from logfiles to determine if there is an
> actual problem or just confused operator.

AFAIK the os-prober is hostage to what the other OSes have
already written in their grub.cfg files, so it might be worth
concentrating on your first problem which, if actual and then
fixed, could take care of os-prober.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#187729

On 10/07/2017 03:01 PM, David Wright wrote:
> On Sat 07 Oct 2017 at 09:36:37 (-0500), Richard Owlett wrote:
>> [snip]
>>
>> I have a hypothesis, but I need to have facts to back it up.
>> Specifically:
>> 1. During the installation process I need to inventory when and
>>    "as what" various USB devices are recognized. The installation
>>    target is a USB drive and Grub is being installed to its MBR.
>
> It's all in /var/log/installer, specifically syslog.
> partman has the partitioning, and hardware-summary gives
> both that and related software summaries. That's all after
> the event, of course. While the d-i is running, syslog
> is under /var/log as normal.

I didn't find what I wanted.
It is very possible I just didn't recognize it.
Is there a guide for reading them?

[toc] | [prev] | [next] | [standalone]

#187764 — Debian-installer writes /dev/ references in grub.cfg, was Re: Log files: location and description

On Sat 07 Oct 2017 at 09:36:37 (-0500), Richard Owlett wrote:

> My current problem is finding the appropriate logs to document the
> details behind my addendum to Bug 852323.

Looking at the grub.cfg written by stretch's d-i RC3, it
appears to write

        linux   /boot/vmlinuz-4.9.0-2-686 root=/dev/sda2 ro  quiet

where one might expect

        linux   /boot/vmlinuz-4.9.0-2-686 root=UUID=7ccc1c1c-a690-418b-96c0-edcce6ebd3c1 ro  quiet

AFAICT the problem goes away when the installed system's own Grub
updates grub.cfg for whatever reason.

Most people won't notice this as a problem because their /dev/sdX
labelling is stable, but this stability seems to be evaporating
somewhat with the ?new USB3 interfaces that win the race to be
so labelled.

My knowledge of Grub's inner workings is too rudimentary to know
whether the search commands beforehand, which do refer to UUIDs,
have any bearing on the matter.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web