ASA boot/console logs to file

[Galle]

I'm planning to update the ASA and ROMMON software on a ISA3000. I've tested it in our lab first and during the testing I've been connected through the console port. This is nice as I can see what is going on during the reload processes. 

However, when I'll perform the upgrade on the target system, I'll only have an SSH connection, no console. Is there a way to get the same messages that can be seen during a reboot with an active console session written to a file? Or how can I get the same info, either live, or downloaded afterwards, from an SSH session?

I've tried to enable syslogging to file, but I can't find any of the messages I'm interested in there. I wondering if the messages I'm interested in do not come from the syslog service?

These are the current log settings:

FW01/sec/NoFailover# show logg
Syslog logging: enabled
Facility: 20
Timestamp logging: enabled
Timezone: enabled
Logging Format: disabled
Hide Username logging: enabled
Standby logging: disabled
Debug-trace logging: enabled
Console logging: disabled
Monitor logging: disabled
Buffer logging: level informational, 922 messages logged
Trap logging: level informational, facility 20, 1714 messages logged
Global TCP syslog stats ::
NOT PUTABLE: 0, ALL CHANNEL DOWN: 0
CHANNEL FLAP CNT: 0, SYSLOG PKT LOSS: 0
PARTIAL REWRITE CNT: 0
Permit-hostdown logging: enabled
History logging: disabled
Device ID: disabled
Mail logging: disabled
ASDM logging: level informational, 922 messages logged

[Mark Elsen]

  - @Galle   >....Is there a way to get the same messages that can be seen during a reboot with
                        an active console session written to a file?
                             Cisco devices don't support that , well actually it probably involves a number of race conditions

                     What you can do is have the console connected to a PC with a serial interface, and define a log file
                     in PuTTY before connecting to the ASA, then reboot

  M.

[Aref Alsouqi]

You can't get the boot up messages via SSH because the network services that would allow you to SSH to the device won't start from the very begining. I think what @Mark Elsen suggested is the only way to work around that.