Post by David ChmelikI 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).
Post by David ChmelikThe 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).
Post by David ChmelikMeantime 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...