From: dchmelik@gmail.com   
      
   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...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)