Re: Log files: location and description
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.
Reply to: