Henrik Carlqvist <
Henrik.C...@deadspam.com> wrote:
> On Sun, 25 Apr 2021 09:16:00 +0000, John Forkosh wrote:
>
>> I'm using
>> slackware64-current/usb-and-pxe-installers/usbimg2disk.sh
>> to create a boot/install thumb drive. Is there any way to modify either
>> the script or the resulting thumb drive or anything else so that when
>> you boot that drive all the boot messages get saved to a file similar to
>> /var/log/messages. Preferably all messages, as if *.*
>> -/var/log/messages were in /etc/syslog.conf .
>
> Anything is possible depending upon how much you are willing to customize
> your installation media. You could add syslogd with its configuration and
> startup files to initrd.img
Thanks for that suggestion, "You could add...". But that only works
for some values of "You", i.e., I've got no idea how to do that.
I'd assume everything needed (and then some) is in the /a/sysklogd-2...txz
package, particularly usr/sbin/syslogd and usr/lib64/libsyslog.so.0.0.0 .
But what do you do about etc/syslog.conf? And I've no idea how to
(re)build initrd.img with all that. But if I knew what I was doing,
then it doesn't sound too hard, at least not too hard to give it a try.
Is there a link to any slack howto, or similar, about all that?
>> Reason I'm asking is because the boot drive boots and installs fine on
>> two boxes, but hangs on a third, just at the last moment when it prints
>> that "Press 1 to select alternate keyboard" message.
>> And unforturnately, it blanks the screen just before printing that.
>> Retrying several thimes, I think I see a "kernel panic" message, but
>> can't make out any details before they all disappear.
>
> The sad thing with those log messages is that when you need them the most
> you will probably not get them. The problem is that any data written to a
> file will be cached, probably on several layers.
Yeah, I realize it's nowhere near guaranteed/foolproof to diagnose
the problem. But I wanted to give it a try and see what I get.
Won't be any worse off than I already am. So nothing to lose,
except the time and effort.
> First you have your program which calls fwrite which only writes to a
> buffer. If you are lucky that buffer might get flushed at every end of
> line, but if you are unlycky your program will need to call fflush to
> empty its buffer.
>
> Then we have your file system which your kernel probably uses some part
> of your RAM for caching data for a more responsive file system, to empty
> that cache you will need to call fsync or unmount the file system. Not
> until then will your OS think that data has been written to disk.
>
> However, even after your OS thinks that data has been written to disk it
> might still be in some cache on your raid controller or on your disk. If
> your disk is removable that cache should be emtied if you tell your disk
> that you are going to eject it.
>
> If you get a kernel panic, your logged data migth still be in the fwrite
> buffer, or in the OS cache. When you reboot you will most likely find
> that the file system where you stored your log has been corrupted and
> need to be fixed with some tool like fsck.
>
> Sometimes you might be able to save logs which would be lost on a local
> disk by logging to a log server on the network or by logging to a printer
> or a serial port.
>
> regards Henrik
Okay, I guess an easier solution is to modify that initrd.img in
some way so it doesn't blank the screen before printing that final
"Press 1 to select keyboard" message. If it does that by just
printing an ansi escape sequence, then maybe I could just vi the
file and change those hex instructions to no-op's. Seems like that
would be simple enough, if I just knew precisely where they were
and what to do about them. Then I could just read the messages
off the screen, without any logging/printing/etc.