You are not logged in.
I have update lilo with pacman -Syu.
After run "lilo -v" have reboot and screen appear only
07 07 07 07 07 07 07 07 07 07 07 07 and more.
I have boot with rescue disk and install the lilo from Arch CD, run "lilo -v" and work fine.
Offline
perhaps your /etc/lilo.conf may have been replaced. you could check that.
AKA uknowme
I am not your friend
Offline
perhaps your /etc/lilo.conf may have been replaced. you could check that.
No. Not replace. The original is "lilo.conf.pacnew".
My personal "lilo.conf" is the same.
Offline
I had this problem as well, also posted in a similar thread in FTP install. I first had the problem after a pacman -Syu though I get L 0101010 . . . Reinstalled using FTP and get the same problem. I had started with a working 0.4 install. My lilo.conf is in the other thread.
Offline
Hey! I've got this problem too.... Lilo displays bunch of 010101010 at startup :cry:
It was working before I "pacman -Syu"ed yesterday.
I had to downgrade lilo to the package from the Arch install CD 0.4 to get a working boot loader.
My lilo.conf file is still the one I set 3 months ago, and it was not changed by the "sync".
I guess I have now 3 possibilities:
- found out why lilo 22.5 crashes at startup
- install grub
- change pacman so that it can skip the upgrade of some packages (and leave alone that old good working lilo package!)
=> I think I will study the last one: it will be much more interesting
More seriously, if someone has some hints about this problem...
Offline
don't reboot. check the lilo homepage for bug reports and patches. i upgraded lilo last night but have not rebooted so i think i may have to downgrade or just wait until judd solves this issue.
AKA uknowme
I am not your friend
Offline
=> I think I will study the last one: it will be much more interesting icon_wink.gif
More seriously, if someone has some hints about this problem...
In fact, I was not joking: I've made a patch to enable an "IgnorePkg" feature. I will submit this to Judd.
I know it is a dirty way to solve my lilo problem... but that works
Offline
i was being serious myself. if you don't need to reboot then don't. proactively seeking a solution before rebooting is far better than delving into pacman's source for a temporary fix. a fix for the package is far more critical than adding a feature (no matter how good the feature). perhaps it is not an arch-only problem instead it is a generic problem. seeking an answer at the lilo homepage could be far more beneficial to linux users in general. lilo is a very common bootloader after all.
AKA uknowme
I am not your friend
Offline
Closest thing I can find to a lilo homepage is freshmeat. There is a change log for the latest version, 22.5, dated the 4th or March. I couldn't find anything like a list of bugs or bug tracking but I have not spent a lot of time using freshmeat. I also don't know anything about maintaining packages so someone else should probably be looking at this. Looking around real quick though, debian unstable is using 22.4.1-1 and as near as I can tell, gentoo is using 22.3.3-1. Not sure if gentoo had anything like debian sid but that is what they had listed in their package DB as well as available from CVS. Not sure any of this helps anything but it's the best I could do so far.
Offline
FWIW, I updated to the current LILO and everything works fine.
I can't say why some have had problems and some haven't though. Other than specific kernel entries, the lilo is similar.
boot=/dev/discs/disc0/disc
#default=arch
lba32
timeout=50
prompt
menu-title=" Peanut with Arch Linux "
image=/boot/vmlinuz-2.4.20-w4l
label=2.4.20-w4l-fb
root=/dev/discs/disc0/part3
append="video=vesa:ywrap:mtrr:pmipal"
vga=0x318
read-only
image=/boot/vmlinuz-2.4.20-w4l
label=2.4.20-w4l-std
root=/dev/discs/disc0/part3
read-only
image=/boot/vmlinuz
label=arch
root=/dev/discs/disc0/part3
read-only
image=/boot/vmlinuz
label=arch-initrd
root=/dev/discs/disc0/part3
initrd=/boot/initrd.img
read-only
#other=/dev/discs/disc0/part1
# label=dos
# End of file
BluPhoenyx
Offline
Ditto - latest lilo working fine here....
Offline
well here it doesn't work.
maybe you guys/girls post your lilo.conf's and we might sort the problem out.
Freedom is what i love
Offline
if you don't need to reboot then don't.
IMHO, I think you should reboot in order to test if the latest lilo works for you, and to share the result with us. Not rebooting won't learn you if you have the problem or not.
To my understanding, this problem is not related to Arch itself and the package. There is for sure something different with lilo. Quite strange to have lilo not being backward compatible with its configuration file... (I didn't see a single warning about that in its changelog).
Thanks to BluPhoenyx for posting his lilo.conf file: I realized that I'm not using the "lba32" option, I will made a try with it.
sarah31: I tried to implement the "ignorepkg" feature because this problem made me realize the interest of this feature, and it was a good example for testing the feature. 'til yesterday, I never had a single problem when "sync"ing my box.
But this does not mean I am forgetting the problem exists. I am aware I have something not working on my box, and I really don't like that
Offline
from lilo changelog fyi:
Changes from version 22.4.1 to 22.5 (04-Mar-2003) John Coffman
.
.
.
- Create 32-bit volume labels on all hard disks.
i noticed this when i read the changelog last night and wondered if this has something to do with it. of course not being too lilo option savy i did ot know how to counter this i guess bluphoenyx has it.
AKA uknowme
I am not your friend
Offline
For what its worth - my lilo.conf is standard other than a custom arch splash screen 8)
#
# /etc/lilo.conf
#
boot=/dev/discs/disc0/disc
default=arch
timeout=50
install=/boot/boot-bmp.b
bitmap=/boot/bg.bmp
bmp-table=30p,100p,1,10
bmp-colors=15,,11,8,,15
prompt
image=/boot/vmlinuz
label=arch
root=/dev/discs/disc1/part2
read-only
image=/boot/vmlinuz
label=arch-initrd
root=/dev/discs/disc1/part2
initrd=/boot/initrd.img
read-only
other=/dev/discs/disc0/part1
label=windose
# End of file
Offline
The bitmap thing was something I was considering also. I just haven't decided on the bitmap image yet. I want something with the AL logo but otherwise fairly simple. This option makes lilo a lot prettier on bootup.
As for errors. I can't say. There is still the small possibility the pkg file is bad. Since it's small, a fresh download couldn't hurt, just to verify this is not the trouble.
It could also be a problem with specific hardware or hardware types. I'm simply guessing but maybe it doesn't like a particular drive size or geometry. In these cases there are some options. You can get more info with man lilo and man lilo.conf.
-f disk_tab (specify the disk geometry file default /etc/disk_tab {nonexistant})
-g generate cylinder/head/sector (geometric) address - limited to 1023 cyl's
forces compatability with older versions.
-l generate 24-bit linear sector address instead of cylinder/head/sector addresses
-L generate 32-bit Logical Block Addresses instead of cylinder/head/sector addresses
-T option (read man) print out system info - can display drive geom for all drives and more
BluPhoenyx
Offline
The bitmap thing was something I was considering also. I just haven't decided on the bitmap image yet. I want something with the AL logo but otherwise fairly simple. This option makes lilo a lot prettier on bootup.
Well I hope you dont mind but I took the background of your website (black with blue splash) and the black arch logo (got any bigger sizes ??).
Heres my 2 minute job Could be mucho better - but I'm slack ...
Converted to gif just to show...
http://bodgy.cjb.net//bg3.gif
Offline
Well, I don't mind but I'm still just a rookie developer. I doubt the others will either. Your method is similar to what I had planned on, IE using the current logo on a simple background. Maybe some of the other developers have some ideas for this.
Ok, so it doesn't make things run better but at least it improves the boot time screen.
BluPhoenyx
Offline
Sorry to interrupt the discussion about splash screens, but I still have a problem with lilo 22.5 :cry:
I've got "LI 01 01 01 01 01" at bootup.
According to the documentation, it means:
LI: The first stage boot loader was able to load the second stage boot loader, but has failed to execute it. This can either be caused by a geometry mismatch or by moving /boot/boot.b without running the map installer.
0x01: "Illegal command". This shouldn't happen, but if it does, it may indicate an attempt to access a disk which is not supported by the BIOS. See also "Warning: BIOS drive 0x<number> may not be accessible" in section "Warnings".
I'm always pleased when something that shouldn't happen happens
Has someone something more detailed about that?
I installed lilo 22.4.1 and ran "lilo -v 3". And then, I installed lilo 22.5, and ran "lilo -v 3". The /etc/lilo.conf file was the same for both tests.
Here is the sdiff output:
LILO version 22.4.1, Copyright (C) 1992-1998 Werner Alme | LILO version 22.5, Copyright (C) 1992-1998 Werner Almesb
Development beyond version 21 Copyright (C) 1999-2002 Jo | Development beyond version 21 Copyright (C) 1999-2003 Jo
Released 27-Jan-2003 and compiled at 15:07:37 on Jan 30 | Released 04-Mar-2003 and compiled at 16:53:29 on Mar 4
raid_setup returns offset = 00000000 ndisk = 0 raid_setup returns offset = 00000000 ndisk = 0
> BIOS Volume S/N Device
Reading boot sector from /dev/discs/disc0/part1 Reading boot sector from /dev/discs/disc0/part1
bios_dev: device 0300 <
Warning: Int 0x13 function 8 and function 0x48 return di Warning: Int 0x13 function 8 and function 0x48 return di
head/sector geometries for BIOS drive 0x80 head/sector geometries for BIOS drive 0x80
fn 08: 1024 cylinders, 255 heads, 63 sectors fn 08: 1024 cylinders, 255 heads, 63 sectors
fn 48: 19710 cylinders, 16 heads, 255 sectors fn 48: 19710 cylinders, 16 heads, 255 sectors
bios_dev: masked device 0300, which is /dev/hda | bios_dev: PT match found 1 match (0x80)
bios_dev: geometry check found 0 matches | Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder
> 63 sectors. Partition offset: 63 sectors.
> Using serial number 7EBF9BA9 on bios 80
bios_dev: PT match found 1 match (0x80) bios_dev: PT match found 1 match (0x80)
Device 0x0300: BIOS drive 0x80, 255 heads, 5005 cylinder Device 0x0300: BIOS drive 0x80, 255 heads, 5005 cylinder
63 sectors. Partition offset: 0 sectors. 63 sectors. Partition offset: 0 sectors.
bios_dev: device 0301 | Using serial number 7EBF9BA9 on bios 80
bios_dev: masked device 0300, which is /dev/hda <
bios_dev: geometry check found 0 matches <
bios_dev: PT match found 1 match (0x80) bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder
63 sectors. Partition offset: 63 sectors. 63 sectors. Partition offset: 63 sectors.
> Using serial number 7EBF9BA9 on bios 80
> get video mode
> determine adapter type
> get display combination
> check VESA present
> mode = 0x03, columns = 80, rows = 25, page = 0
Using MENU secondary loader Using MENU secondary loader
Calling map_insert_data Calling map_insert_data
Secondary loader: 16 sectors (0x3000 dataend). | Secondary loader: 17 sectors (0x3200 dataend).
> bios_boot = 0x80 bios_map = 0x80 map==boot = 1 map S/
Boot image: /boot/vmlinuz Boot image: /boot/vmlinuz
bios_dev: device 0301 <
bios_dev: masked device 0300, which is /dev/hda <
bios_dev: geometry check found 0 matches <
bios_dev: PT match found 1 match (0x80) bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder
63 sectors. Partition offset: 63 sectors. 63 sectors. Partition offset: 63 sectors.
> Using serial number 7EBF9BA9 on bios 80
Setup length is 10 sectors. Setup length is 10 sectors.
Mapped 2530 sectors. Mapped 2530 sectors.
Added arch * Added arch *
<dev=0xe0,hd=25,cyl=82,sct=159> | <dev=0xe0,hd=24,cyl=108,sct=56>
"ro root=301" "ro root=301"
Boot image: /boot/vmlinuz Boot image: /boot/vmlinuz
bios_dev: device 0301 <
bios_dev: masked device 0300, which is /dev/hda <
bios_dev: geometry check found 0 matches <
bios_dev: PT match found 1 match (0x80) bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder
63 sectors. Partition offset: 63 sectors. 63 sectors. Partition offset: 63 sectors.
> Using serial number 7EBF9BA9 on bios 80
Setup length is 10 sectors. Setup length is 10 sectors.
Mapped 2530 sectors. Mapped 2530 sectors.
Mapping RAM disk /boot/initrd.img Mapping RAM disk /boot/initrd.img
bios_dev: device 0301 <
bios_dev: masked device 0300, which is /dev/hda <
bios_dev: geometry check found 0 matches <
bios_dev: PT match found 1 match (0x80) bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder
63 sectors. Partition offset: 63 sectors. 63 sectors. Partition offset: 63 sectors.
> Using serial number 7EBF9BA9 on bios 80
RAM disk: 523 sectors. RAM disk: 523 sectors.
Added arch-initrd Added arch-initrd
<dev=0xe0,hd=25,cyl=82,sct=187> | <dev=0xe0,hd=24,cyl=108,sct=84>
"ro root=301" "ro root=301"
Boot image: /boot/vmlinuz-org Boot image: /boot/vmlinuz-org
bios_dev: device 0301 <
bios_dev: masked device 0300, which is /dev/hda <
bios_dev: geometry check found 0 matches <
bios_dev: PT match found 1 match (0x80) bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder Device 0x0301: BIOS drive 0x80, 255 heads, 5005 cylinder
63 sectors. Partition offset: 63 sectors. 63 sectors. Partition offset: 63 sectors.
> Using serial number 7EBF9BA9 on bios 80
Setup length is 10 sectors. Setup length is 10 sectors.
Mapped 2985 sectors. Mapped 2985 sectors.
Added arch-org Added arch-org
<dev=0xe0,hd=25,cyl=82,sct=221> | <dev=0xe0,hd=24,cyl=108,sct=118>
"ro root=301" "ro root=301"
Backup copy of boot sector in /boot/boot.0301 | BIOS Volume S/N Device
Map file size: 59392 bytes. | 80 7EBF9BA9 0300
Writing boot sector. Writing boot sector.
> Backup copy of boot sector in /boot/boot.0301
> Map file size: 59904 bytes.
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID offset entry 0 0x00000000
> RAID device mask 0x0000
Failsafe check: boot_dev_nr = 0x0301 0xffc0 Failsafe check: boot_dev_nr = 0x0301 0xffc0
There are some strange diffs:
Secondary loader: 16 sectors (0x3000 dataend) | Secondary loader: 17 sectors (0x3200 dataend)
...
Added arch * Added arch *
<dev=0xe0,hd=25,cyl=82,sct=159> | <dev=0xe0,hd=24,cyl=108,sct=56>
...
Added arch-initrd Added arch-initrd
<dev=0xe0,hd=25,cyl=82,sct=187> | <dev=0xe0,hd=24,cyl=108,sct=84>
...
Added arch-initrd Added arch-initrd
<dev=0xe0,hd=25,cyl=82,sct=187> | <dev=0xe0,hd=24,cyl=108,sct=84>
...
Backup copy of boot sector in /boot/boot.0301 | BIOS Volume S/N Device
Map file size: 59392 bytes. | 80 7EBF9BA9 0300
Writing boot sector. Writing boot sector.
> Backup copy of boot sector in /boot/boot.0301
> Map file size: 59904 bytes.
Images are not using the same heads/cyl/sectors??? And the map file size is also different???
Any idea?
BTW, if you feel I didn't give enough details, I can post the "lilo -v 5" sdiff output
Offline
Here's a copy of the lilo output from my laptop. It's a 10gb drive with the following partitions.
hda0,0 = /boot
hda0,1 = swap
hda0,2 = /
One difference I noted is the 'Reading boot sector from' line. Mine is;
/dev/discs/disc0/disc
and yours is;
/dev/discs/disc0/disc/part1
It shouldn't matter whether you boot from the MBR or a partition so this may not affect anything.
FWIW, you could try using the absolute devfs entry (although this may not matter either);
/dev/ide/host0/bus0/target0/lun0(/disc or /part#)
I noticed that I don't get the warning about the difference in reported geometries. I don't know if this is related but I've seen this on another system which has a large (30 gb) ide. It could be possible that this lilo has problems with huge drives. I am working on a 20 gb system and will return any useful results shortly. (currently upgrading software)
LILO version 22.5, Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2003 John Coffman
Released 04-Mar-2003 and compiled at 16:53:29 on Mar 4 2003.
raid_setup returns offset = 00000000 ndisk = 0
BIOS Volume S/N Device
Reading boot sector from /dev/discs/disc0/disc
bios_dev: PT match found 1 match (0x80)
Device 0x0300: BIOS drive 0x80, 255 heads, 1222 cylinders,
63 sectors. Partition offset: 0 sectors.
Using serial number 00A1F819 on bios 80
bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 1222 cylinders,
63 sectors. Partition offset: 63 sectors.
Using serial number 00A1F819 on bios 80
get video mode
determine adapter type
get display combination
check VESA present
mode = 0x03, columns = 80, rows = 25, page = 0
Using MENU secondary loader
Calling map_insert_data
Secondary loader: 17 sectors (0x3200 dataend).
bios_boot = 0x80 bios_map = 0x80 map==boot = 1 map S/N: 00A1F819
Boot image: /boot/vmlinuz-2.4.20-w4l
bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 1222 cylinders,
63 sectors. Partition offset: 63 sectors.
Using serial number 00A1F819 on bios 80
Setup length is 10 sectors.
Mapped 1633 sectors.
Added 2.4.20-w4l-fb *
<dev=0xe0,hd=0,cyl=78,sct=162>
"ro root=303 video=vesa:ywrap:mtrr:pmipal"
Boot image: /boot/vmlinuz-2.4.20-w4l
bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 1222 cylinders,
63 sectors. Partition offset: 63 sectors.
Using serial number 00A1F819 on bios 80
Setup length is 10 sectors.
Mapped 1633 sectors.
Added 2.4.20-w4l-std
<dev=0xe0,hd=0,cyl=78,sct=181>
"ro root=303"
Boot image: /boot/vmlinuz-2.4.19-std-w4l
bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 1222 cylinders,
63 sectors. Partition offset: 63 sectors.
Using serial number 00A1F819 on bios 80
Setup length is 10 sectors.
Mapped 1634 sectors.
Added 2.4.19-w4l-fb
<dev=0xe0,hd=0,cyl=78,sct=200>
"ro root=303 video=vesa:ywrap:mtrr:pmipal"
Boot image: /boot/vmlinuz-2.4.19-std-w4l
bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 1222 cylinders,
63 sectors. Partition offset: 63 sectors.
Using serial number 00A1F819 on bios 80
Setup length is 10 sectors.
Mapped 1634 sectors.
Added 2.4.19-w4l-std
<dev=0xe0,hd=0,cyl=78,sct=219>
"ro root=303"
Boot image: /boot/vmlinuz
bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 1222 cylinders,
63 sectors. Partition offset: 63 sectors.
Using serial number 00A1F819 on bios 80
Setup length is 10 sectors.
Mapped 2985 sectors.
Added arch
<dev=0xe0,hd=0,cyl=78,sct=238>
"ro root=303"
Boot image: /boot/vmlinuz
bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 1222 cylinders,
63 sectors. Partition offset: 63 sectors.
Using serial number 00A1F819 on bios 80
Setup length is 10 sectors.
Mapped 2985 sectors.
Mapping RAM disk /boot/initrd.img
bios_dev: PT match found 1 match (0x80)
Device 0x0301: BIOS drive 0x80, 255 heads, 1222 cylinders,
63 sectors. Partition offset: 63 sectors.
Using serial number 00A1F819 on bios 80
RAM disk: 540 sectors.
Added arch-initrd
<dev=0xe0,hd=0,cyl=79,sct=14>
"ro root=303"
BIOS Volume S/N Device
80 00A1F819 0300
Writing boot sector.
/boot/boot.0300 exists - no boot sector backup copy made.
Map file size: 86528 bytes.
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID offset entry 0 0x00000000
RAID device mask 0x0000
Failsafe check: boot_dev_nr = 0x0300 0xffc0
BluPhoenyx
Offline
Here's my limited results from this simple test box. The system is an Athlon 950 with 256 mb ram, one 20 gb ide and also tested with an 8 gb ide.
After upgrading, rerunning lilo et.al the system booted just fine. Running lilo again resulted in a difference of sector numbers. Running lilo again returned the original sector values. Running lilo several more times simply switched between the two sets of sector values. Note that the system booted either way and I simply don't recall if this is normal or not. This happens on both the 8 or 20 gb drives.
Now, attempting to set to boot from a partition fails. In my case, the name LILO displays and I get an error 'Timestamp mismatch' I only tried this on the 20 gb drive as it was a 'throw away' Arch install anyhow.
As for why this happens, I don't know but IMHO your options are to boot from the MBR or try grub.
BluPhoenyx
Offline
i noticed this when i read the changelog last night and wondered if this has something to do with it. of course not being too lilo option savy i did ot know how to counter this i guess bluphoenyx has it.
The lba32 option is strictly a hardware setting. LBA (Large Block Access) is a method for accessing huge disks which was created to get around earlier hardware limitations. If the option is not used in the config, lilo should use it by default.
As for the 32 bit names, I wouldn't think this would be a problem. From what I can tell it's more of a compatibility problem with particular hardware. To be sure, we need to know the hardware it's failed on to compare against the hardware it works on. It's still possible there is a problem with large drives or particular oem drives. It might also be a problem related to difference in geometries such as the warning shown in orelien's output. On the few systems I have to check this with, this error doesn't show. As mentioned previously, I have seen it before but I can't check that system to verify the possible problem.
BluPhoenyx
Offline
# $Id: PKGBUILD,v 1.17 2003/03/05 01:00:58 judd Exp $
pkgname=lilo
pkgver=22.5
pkgrel=2
pkgdesc="A bootloader for Linux"
backup=(etc/lilo.conf)
depends=('glibc' 'bash')
install=lilo.install
source=(http://home.san.rr.com/johninsd/pub/linux/lilo/lilo-$pkgver.tar.gz http://home.san.rr.com/johninsd/pub/linux/lilo/updates/lilo-22.5.READONLY.patch http://home.san.rr.com/johninsd/pub/linux/lilo/updates/lilo-22.5.protectDX.patch lilo.conf)
build() {
cd $startdir/src/$pkgname-$pkgver
patch -Np1 -i ../lilo-22.5.READONLY.patch
patch -Np0 -i ../lilo-22.5.protectDX.patch
make || return 1
make ROOT=$startdir/pkg MAN_DIR=/usr/man install
mkdir -p $startdir/pkg/etc
cp $startdir/$pkgname.conf $startdir/pkg/etc/
}
AKA uknowme
I am not your friend
Offline
Thanks for your feedbacks, it gave me some new axes of investigation
- rebuild lilo 22.5 without the patches.
- install lilo 22.5 in the mbr.
So, this time, you have avoided the "lilo -v 5" post
In fact, I didn't mentionned it, but I'm using xosl as my "main" boot loader. It is installed in the mbr (www.xosl.org) .
Lilo loaders are installed in their own partitions, and each one is dedicated to its linux distro.
So, I will also try to reconfigure xosl after having installed lilo 22.5.
He may need to, since lilo 22.5 seems to not put things in the same place as lilo 22.4.1 and prior.
I will also check for know problems with xosl too.
If I still can get it boot, I will make a try with grub...
Offline
actually the patches fixed lilo for me they were not in the original build. lilo 22.5 puts thing exactly where 22.3.4 put them only 22.4.1 had bot boot/ files. the READONLY patch is likely the fix because by the sounds of it that is busted.
AKA uknowme
I am not your friend
Offline