I had this problem on Slackware 14.2+current and Slackware 15. After I ran
LILO and rebooted, LILO said 'timestamp mismatch' and didn't show any menu
(I have several OSs) and wouldn't boot. No matter what I tried, it
wouldn't fix it. I set the BIOS clock two days ahead (though my BIOS and
OS times are the same.) I zeroed the boot sector, rebuilt my partition
table, reinstalled LILO to the drive. After both these tries the same
happened.

The test for timestamp mismatch should probably be optional for LILO in
Slackware. The check serves no useful purpose. Desktop users don't care,
and for servers, they can use other tools after they booted, for
timestamps.

Meantime I installed GRUB2. (which works)

What do I need to do to use LILO again?

On Wed, 24 Aug 2022 04:22:57 +0000, David Chmelik wrote:

> I had this problem on Slackware 14.2+current and Slackware 15. After I
> ran LILO and rebooted, LILO said 'timestamp mismatch' and didn't show
> any menu (I have several OSs) and wouldn't boot. No matter what I tried,
> it wouldn't fix it. I set the BIOS clock two days ahead (though my BIOS
> and OS times are the same.) I zeroed the boot sector, rebuilt my
> partition table, reinstalled LILO to the drive. After both these tries
> the same happened.

A quick peek at the LILO loader source (the assembly modules) shows
that the "timestamp mismatch" error occurs when the loader compares
the timestamps of two files, not by checking the realtime clock.

Comments in the code, and posts online hint that this is a check between
the timestamp on the map file's FAT entry, and a timestamp associated with
the second stage loader. If the map file is newer than the loader, then
the loader issues the error.

> The test for timestamp mismatch should probably be optional for LILO in
> Slackware. The check serves no useful purpose. Desktop users don't care,
> and for servers, they can use other tools after they booted, for
> timestamps.

Not really. The timestamp check ensures that the LiLO boot loader has the
proper file location data for the kernel, as the lilo(8) command embeds
static file location data into the LiLO boot loader file, and that boot
loader file /must/ reflect the location of the /current/ kernel(s).

> Meantime I installed GRUB2. (which works)
>
> What do I need to do to use LILO again?

Apparently, make certain that you run lilo(8) against the exact kernel/map
file image that you intend to boot from. (Exact, as in both locations,
contents /and/ timestamps.)

Hope this helps
--
Lew Pitcher
"In Skills, We Trust"

On Wed, 24 Aug 2022 16:12:01 -0000 (UTC), Lew Pitcher wrote:
> On Wed, 24 Aug 2022 04:22:57 +0000, David Chmelik wrote:
>> I had this problem on Slackware 14.2+current and Slackware 15. After I
>> ran LILO and rebooted, LILO said 'timestamp mismatch' and didn't show
>> any menu (I have several OSs) and wouldn't boot. No matter what I
>> tried,
>> it wouldn't fix it. I set the BIOS clock two days ahead (though my BIOS
>> and OS times are the same.) I zeroed the boot sector, rebuilt my
>> partition table, reinstalled LILO to the drive. After both these tries
>> the same happened.
>
> A quick peek at the LILO loader source (the assembly modules) shows that
> the "timestamp mismatch" error occurs when the loader compares the
> timestamps of two files, not by checking the realtime clock.
>
> Comments in the code, and posts online hint that this is a check between
> the timestamp on the map file's FAT entry, and a timestamp associated
> with the second stage loader. If the map file is newer than the loader,
> then the loader issues the error.

I see. It's not something I did. I've been using LILO since 1997 and
rarely made mistakes... lost count how many times I tried to fix this
almost a year... doubt I made same mistake 10 or 20+ times in a row. Each
time I zeroed block device with dd or Slackware blkdiscard or UNIX/*BSD
trim (does same).

>> The test for timestamp mismatch should probably be optional for LILO in
>> Slackware. The check serves no useful purpose. Desktop users don't
>> care,
>> and for servers, they can use other tools after they booted, for
>> timestamps.
>
> Not really. The timestamp check ensures that the LiLO boot loader has
> the proper file location data for the kernel, as the lilo(8) command
> embeds static file location data into the LiLO boot loader file, and
> that boot loader file /must/ reflect the location of the /current/
> kernel(s).
>
>> Meantime I installed GRUB2. (which works)
>>
>> What do I need to do to use LILO again?
>
> Apparently, make certain that you run lilo(8) against the exact
> kernel/map file image that you intend to boot from. (Exact, as in both
> locations, contents /and/ timestamps.) [...]

Unsure I've ever done that nor what it entails. All I do is make sure
System.map, config, vmlinuz match and latter matches lilo.conf, and run
lilo.

I discussed this elsewhere... there are two theories. LILO was updated
2015, and by 2016, Linux kernel redefined SSD/M2/NVMEs which broke LILO in
some cases... but worked fine on my SSD/M2/NVME early-to-mid 2020 to mid-
to-late 2021.

Mine is a bit strange. When I was trying several UNIXes and some didn't
work in BIOS/DOS extended/logical partitions, I tried UEFI/GPT but dislike
UEFI so switched to BIOS. Later I switched back to UEFI then after
successful installation booted broken ELILO (IIRC looks like 'LILO O O O O
O O O O...'). I zeroed drive and tried again... same result, multiple
times... don't recall ELILO ever worked. Then DOS partition table worked
fine. It's like my NVME may treat DOS & GPT differently with different
boot areas and UEFI/GPT broke and even zeroing entire block device
starting from sector 0 (through partition table) never even erased (not dd
nor blkdiscard nor trim)... yet that happened in 2020 and ELILO breaking
may have nothing to do with LILO breaking... worked perfectly until a
Slackware64 14.2+current including kernel update by/in October 2021. I
called Samsung and said I prefer BIOS/DOS but want to try UEFI/GPT
(broken)... they said like it's made to be good for UEFI (but not can't be
BIOS/DOS) and said send for repair/replacement... I might, but would need
to switch back to early-to-mid-2010s PC or build a new... anwyay NVME
warranty is into 2026.

I'd rather just get two more UNIX/*BSD/OpenSolaris/IllumOS (Tribblix,
OmniOSCE) working in extended/logical partitions. My first three are
NetBSD (my desktop several years), FreeBSD (my first other OS in college
computer science (CS) laboratories), DragonFlyBSD (powerful FreeBSD fork),
and Slackware first extended/logical partition. All these UNIX projects
(genetic UNIX) said they should theoretically boot from extended
partitions and they think some people already do, or that they worked on
code that made that work... and that might even work with other
partitioning such as BIOS/GPT... but most didn't. They all now say try
UEFI... which takes one's first partition number (people said one can put
it at end which I tried on older PC but only worked at beginning).

Tribblix & OmniOSCE OpenSolaris IllumOS UNIXes actually were installable &
bootable in extended/logical partitions but were weird... I tried to
install Tribblix but maybe didn't take a partition (just drive) so
installed OmniOSCE then later tried Tribblix again... then its format
command no longer could read NVME partition table... even after zeroing
the drive more than once each time installing *BSDs & Slackware and
extended/logical partitions. It's like IllumOS did something weird to the
NVME or it's not responding right... may also have nothing to do with
broken ELILO, but it's a weird NVME.

LILO is the nicest bootloader even to boot UNIXes... *BSD bootloaders (I
use to use more) are similar so okay but a bit difficult. GRUB is a mess
maybe only its programmers can understand automated configuration files so
if such goes wrong, one may be lost...

Either Linux kernel broke LILO or Samsung made a design flaw or ELILO or a
UNIX did something they shouldn't... no idea what happened anymore.
IllumOS isn't doing much/anything about the format bug because was on
BIOS/DOS and also suggests UEFI/GPT... may have to switch eventually but
really want to avoid...

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> A quick peek at the LILO loader source (the assembly modules) shows
> that the "timestamp mismatch" error occurs when the loader compares
> the timestamps of two files, not by checking the realtime clock.

I haven't been following all the detail here, but might it be a clock
issue? Eg some sort of backwards ntp-inducced time-correction after
file creation making it look future-like? Or is there any copying
between computers with poorly synchronised clocks?

#Paul

David Chmelik <dchmelik@gmail.com> wrote:
> On Wed, 24 Aug 2022 16:12:01 -0000 (UTC), Lew Pitcher wrote:
>> On Wed, 24 Aug 2022 04:22:57 +0000, David Chmelik wrote:
>>> I had this problem on Slackware 14.2+current and Slackware 15. After I
>>> ran LILO and rebooted, LILO said 'timestamp mismatch' and didn't show
>>> any menu (I have several OSs) and wouldn't boot. No matter what I
>>> tried,
>>> it wouldn't fix it. I set the BIOS clock two days ahead (though my BIOS
>>> and OS times are the same.) I zeroed the boot sector, rebuilt my
>>> partition table, reinstalled LILO to the drive. After both these tries
>>> the same happened.
>>
>> A quick peek at the LILO loader source (the assembly modules) shows that
>> the "timestamp mismatch" error occurs when the loader compares the
>> timestamps of two files, not by checking the realtime clock.
>>
>> Comments in the code, and posts online hint that this is a check between
>> the timestamp on the map file's FAT entry, and a timestamp associated
>> with the second stage loader. If the map file is newer than the loader,
>> then the loader issues the error.
>
> I see. It's not something I did. I've been using LILO since 1997 and
> rarely made mistakes... lost count how many times I tried to fix this
> almost a year... doubt I made same mistake 10 or 20+ times in a row. Each
> time I zeroed block device with dd or Slackware blkdiscard or UNIX/*BSD
> trim (does same).
>
>>> The test for timestamp mismatch should probably be optional for LILO in
>>> Slackware. The check serves no useful purpose. Desktop users don't
>>> care,
>>> and for servers, they can use other tools after they booted, for
>>> timestamps.
>>
>> Not really. The timestamp check ensures that the LiLO boot loader has
>> the proper file location data for the kernel, as the lilo(8) command
>> embeds static file location data into the LiLO boot loader file, and
>> that boot loader file /must/ reflect the location of the /current/
>> kernel(s).
>>
>>> Meantime I installed GRUB2. (which works)
>>>
>>> What do I need to do to use LILO again?
>>
>> Apparently, make certain that you run lilo(8) against the exact
>> kernel/map file image that you intend to boot from. (Exact, as in both
>> locations, contents /and/ timestamps.) [...]
>
> Unsure I've ever done that nor what it entails. All I do is make sure
> System.map, config, vmlinuz match and latter matches lilo.conf, and run
> lilo.
>
> I discussed this elsewhere... there are two theories. LILO was updated
> 2015, and by 2016, Linux kernel redefined SSD/M2/NVMEs which broke LILO in
> some cases... but worked fine on my SSD/M2/NVME early-to-mid 2020 to mid-
> to-late 2021.
>
> Mine is a bit strange. When I was trying several UNIXes and some didn't
> work in BIOS/DOS extended/logical partitions, I tried UEFI/GPT but dislike
> UEFI so switched to BIOS. Later I switched back to UEFI then after
> successful installation booted broken ELILO (IIRC looks like 'LILO O O O O
> O O O O...'). I zeroed drive and tried again... same result, multiple
> times... don't recall ELILO ever worked. Then DOS partition table worked
> fine. It's like my NVME may treat DOS & GPT differently with different
> boot areas and UEFI/GPT broke and even zeroing entire block device
> starting from sector 0 (through partition table) never even erased (not dd
> nor blkdiscard nor trim)... yet that happened in 2020 and ELILO breaking
> may have nothing to do with LILO breaking... worked perfectly until a
> Slackware64 14.2+current including kernel update by/in October 2021. I
> called Samsung and said I prefer BIOS/DOS but want to try UEFI/GPT
> (broken)... they said like it's made to be good for UEFI (but not can't be
> BIOS/DOS) and said send for repair/replacement... I might, but would need
> to switch back to early-to-mid-2010s PC or build a new... anwyay NVME
> warranty is into 2026.
>
> I'd rather just get two more UNIX/*BSD/OpenSolaris/IllumOS (Tribblix,
> OmniOSCE) working in extended/logical partitions. My first three are
> NetBSD (my desktop several years), FreeBSD (my first other OS in college
> computer science (CS) laboratories), DragonFlyBSD (powerful FreeBSD fork),
> and Slackware first extended/logical partition. All these UNIX projects
> (genetic UNIX) said they should theoretically boot from extended
> partitions and they think some people already do, or that they worked on
> code that made that work... and that might even work with other
> partitioning such as BIOS/GPT... but most didn't. They all now say try
> UEFI... which takes one's first partition number (people said one can put
> it at end which I tried on older PC but only worked at beginning).
>
> Tribblix & OmniOSCE OpenSolaris IllumOS UNIXes actually were installable &
> bootable in extended/logical partitions but were weird... I tried to
> install Tribblix but maybe didn't take a partition (just drive) so
> installed OmniOSCE then later tried Tribblix again... then its format
> command no longer could read NVME partition table... even after zeroing
> the drive more than once each time installing *BSDs & Slackware and
> extended/logical partitions. It's like IllumOS did something weird to the
> NVME or it's not responding right... may also have nothing to do with
> broken ELILO, but it's a weird NVME.
>
> LILO is the nicest bootloader even to boot UNIXes... *BSD bootloaders (I
> use to use more) are similar so okay but a bit difficult. GRUB is a mess
> maybe only its programmers can understand automated configuration files so
> if such goes wrong, one may be lost...

So write your own grub config file. It's not any more difficult than a
lilo config file. And as a bonus, you just update the config file when
necessary, like adding a new kernel, nothing else needed. Just make
update-grub or whatever it's callled nx so it doesn't overwrite your
hand crafted file.

>
> Either Linux kernel broke LILO or Samsung made a design flaw or ELILO or a
> UNIX did something they shouldn't... no idea what happened anymore.
> IllumOS isn't doing much/anything about the format bug because was on
> BIOS/DOS and also suggests UEFI/GPT... may have to switch eventually but
> really want to avoid...