From: jerry@example.invalid
David Chmelik 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...
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
