Have you run './build.sh clean' yet? That should reset any stale files. If something changed in the code, you may have some object files that are incompatible.
On February 22, 2020 11:24:02 AM EST, Derek Johansen <djohanse678@xxxxxxxxx> wrote:
>i did a git pull last night and then sudp ./build.sh and got these
>errors. This is the same process i have been using to build forever.
>Did not modify any settings in menuconfig. How do i get back to a
>working build?
>
>On Mon, Feb 17, 2020 at 2:38 PM Paul Osmialowski <pawelo@xxxxxxxxxxx>
>wrote:
>>
>>
>>
>> On Mon, 17 Feb 2020, Paul Osmialowski wrote:
>>
>> > Yes, I failed to express how worried I am by (ab)using ageing DD
>floppy
>> > drive (the only thing on-board floppy disk controller is able to
>> > recognize) when doing my tests. I'm mounting the on-card rootfs in
>/mnt to
>> > start as many of the commands as possible (chroot would help).
>> >
>> > Setting "Extra external buffer cache" would probably help, but it
>fails to
>> > compile...
>>
>> Turning this option on causes ELKS building proces to fail at linking
>like
>> this:
>>
>> arch/i86/boot/crt0.o arch/i86/boot/crt1.o \
>> init/main.o '-(' fs/fs.a kernel/kernel.a lib/lib.a net/net.a
>> fs/minix/minixfs.a fs/msdos/msdos.a arch/i86/kernel/akernel.a
>> arch/i86/lib/lib86.a arch/i86/mm/mm.a
>arch/i86/drivers/char/chr_drv.a
>> arch/i86/drivers/block/blk_drv.a arch/i86/drivers/net/net_drv.a '-)'
>\
>> -o arch/i86/boot/system > arch/i86/boot/system.map)
>> kernel/kernel.a(sleepwake.o): in function `_wake_up':
>> (.text+0xf4): relocation truncated to fit: R_386_16 against
>`select_queue'
>> net/net.a(af_inet.o): in function `inet_create':
>> (.text+0xb): relocation truncated to fit: R_386_16 against
>`tcpdev_inuse'
>> arch/i86/drivers/char/chr_drv.a(tcpdev.o): in function `tcpdev_open':
>> (.text+0xc): relocation truncated to fit: R_386_16 against
>`tcpdev_inuse'
>> (.text+0x19): relocation truncated to fit: R_386_16 against
>`tcpdev_inuse'
>> arch/i86/drivers/char/chr_drv.a(tcpdev.o): in function
>`tcpdev_release':
>> (.text+0x2b): relocation truncated to fit: R_386_16 against
>`tcpdev_inuse'
>> arch/i86/drivers/char/chr_drv.a(tcpdev.o): in function `tcpdev_init':
>> (.text+0x174): relocation truncated to fit: R_386_16 against
>> `tcpdev_inuse'
>> arch/i86/drivers/block/blk_drv.a(ll_rw_blk.o): in function
>`make_request':
>> (.text+0x179): relocation truncated to fit: R_386_16 against
>`blk_dev'
>> arch/i86/drivers/block/blk_drv.a(ll_rw_blk.o): in function
>`ll_rw_blk':
>> (.text+0x1ba): relocation truncated to fit: R_386_16 against
>`blk_dev'
>> arch/i86/drivers/block/blk_drv.a(ll_rw_blk.o): in function
>`blk_dev_init':
>> (.text+0x1ef): relocation truncated to fit: R_386_16 against
>`blk_dev'
>> (.text+0x1ff): relocation truncated to fit: R_386_16 against
>`blk_dev'
>> arch/i86/drivers/block/blk_drv.a(doshd.o): in function `end_request':
>> (.text+0xa0): additional relocation overflows omitted from the output
>>
>>
>> >
>> > Cheers,
>> > Paul
>> >
>> > On Mon, 17 Feb 2020, Marc-F. Lucca-Daniau wrote:
>> >
>> > > Got the same problem as you while trying to use the HD image,
>with wrong
>> > > partition detection when no MBR. Working on it...
>> > >
>> > > I am just wondering why you try to mount the rootfs partition as
>you booted on
>> > > it and it should be mounted. Did I miss something in your
>statement ?
>> > >
>> > > MFLD
>> > >
>> > >
>> > > Le 12/02/2020 ? 23:31, Paul Osmialowski a écrit :
>> > > > Yeah, it is described there indeed.
>> > > >
>> > > > I tried todays master. It does boot from CF card (MINIX HD
>image), so the
>> > > > original issue is now fixed. Yet still problem with lack of
>ability to
>> > > > mount rootfs from the same CF card and wrong listing of
>partitions on a
>> > > > card that contains no partitions (just a boot sector and a
>MINIX rootfs
>> > > > filesystem) remains and I guess deserved new (critical?) ticket
>as it
>> > > > limits usability of ELKS severely.
>> > > >
>> > > > Thanks,
>> > > > Paul
>> > > >
>> > > > On Wed, 12 Feb 2020, Marc-François Lucca-Daniau wrote:
>> > > >
>> > > > > Please read the updated 'README.md' :-)
>> > > > > MFLD
>> > > > >
>> > > > > Le mer. 12 févr. 2020 22:10, Paul Osmialowski
><pawelo@xxxxxxxxxxx> a
>> > > > > écrit :
>> > > > > Just a quick question. If there's no tools/env.sh, how
>one does
>> > > > > 'make
>> > > > > clean' now?
>> > > > >
>> > > > > On Wed, 12 Feb 2020, Marc-F. Lucca-Daniau wrote:
>> > > > >
>> > > > > > Hello Paul,
>> > > > > >
>> > > > > > Regression should be fixed now by latest commits.
>> > > > > >
>> > > > > > I selected CONFIG_IMG_HD, set CHS to 80/2/18 and
>size to 1440
>> > > > > blocks (to mimic
>> > > > > > a floppy).
>> > > > > >
>> > > > > > After modifying 'qemu.sh' to boot on 'image/hd.bin',
>got the ELKS
>> > > > > login
>> > > > > > prompt.
>> > > > > >
>> > > > > > So closing the issue, unless you still have the
>problem.
>> > > > > >
>> > > > > > Thanks,
>> > > > > >
>> > > > > > MFLD
>> > > > > >
>> > > > > >
>> > > > > > Le 11/02/2020 ? 21:38, Marc-F. Lucca-Daniau a écrit
>:
>> > > > > > > Hello Paul,
>> > > > > > >
>> > > > > > > Yes, confirmed, a recent commit on the boot sector
>missed the
>> > > > > CONFIG_IMG_HD
>> > > > > > > case.
>> > > > > > >
>> > > > > > > Tracked by :
>https://github.com/elks-org/elks/issues/323
>> > > > > > >
>> > > > > > > It again shows that we REALLY need more automatic
>testing in
>> > > > > the CI !
>> > > > > > >
>> > > > > > > MFLD
>> > > > > > >
>> > > > > > >
>> > > > > > > Le 11/02/2020 ? 00:38, Paul Osmialowski a écrit :
>> > > > > > > > Hi Marc,
>> > > > > > > >
>> > > > > > > > I'm observing some regression with today's
>changes on git
>> > > > > master. Despite
>> > > > > > > > selecting MINIX boot image, -DBOOT_FAT is still
>present in
>> > > > > build log
>> > > > > > > > (seems -UBOOT_FAT is not propagated properly):
>> > > > > > > >
>> > > > > > > > make[2]: Entering directory
>> > > > > '/home/pawelo/elks.git/elkscmd/bootblocks'
>> > > > > > > > ia16-elf-gcc -I /home/pawelo/elks.git/include -E
>-o
>> > > > > boot_sect.tmp
>> > > > > > > > boot_sect.S
>> > > > > > > > ia16-elf-gcc -I /home/pawelo/elks.git/include -E
>-UBOOT_FAT
>> > > > > -o
>> > > > > > > > boot_sect.tmp boot_sect.S
>> > > > > > > > ia16-elf-as -o boot_sect.o boot_sect.tmp
>> > > > > > > > rm -f boot_sect.tmp
>> > > > > > > > ia16-elf-gcc -Wall -Os -mregparmcall
>-fno-toplevel-reorder
>> > > > > -fno-inline
>> > > > > > > > -mcmodel=tiny -mno-segment-relocation-stuff
>-ffreestanding
>> > > > > -mtune=i8086 -I
>> > > > > > > > /home/pawelo/elks.git/include -c -o
>boot_minix.o
>> > > > > boot_minix.c
>> > > > > > > > ia16-elf-ld -T
>/home/pawelo/elks.git/elks/elks-raw.ld -M -o
>> > > > > minix.bin
>> > > > > > > > boot_sect.o boot_minix.o > minix.map
>> > > > > > > > ia16-elf-gcc -I /home/pawelo/elks.git/include -E
>-o
>> > > > > boot_probe.tmp
>> > > > > > > > boot_probe.S
>> > > > > > > > ia16-elf-as -oboot_probe.o boot_probe.tmp
>> > > > > > > > rm -f boot_probe.tmp
>> > > > > > > > ia16-elf-ld -T
>/home/pawelo/elks.git/elks/elks-raw.ld -M -o
>> > > > > probe.bin
>> > > > > > > > boot_sect.o boot_probe.o > probe.map
>> > > > > > > > ia16-elf-gcc -I /home/pawelo/elks.git/include -E
>-DBOOT_FAT
>> > > > > -o
>> > > > > > > > boot_sect_fat.tmp boot_sect.S
>> > > > > > > > ia16-elf-as -o boot_sect_fat.o
>boot_sect_fat.tmp
>> > > > > > > > boot_sect.S: Assembler messages:
>> > > > > > > > boot_sect.S:41: Error: Unknown disk medium!
>> > > > > > > > make[2]: *** [Makefile:42: boot_sect_fat.o]
>Error 1
>> > > > > > > > make[2]: Leaving directory
>> > > > > '/home/pawelo/elks.git/elkscmd/bootblocks'
>> > > > > > > > make[1]: *** [Makefile:126: all] Error 1
>> > > > > > > > make[1]: Leaving directory
>'/home/pawelo/elks.git/elkscmd'
>> > > > > > > > make: *** [Makefile:37: all] Error 2
>> > > > > > > > Build script has terminated with error 5
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On Sat, 8 Feb 2020, Paul Osmialowski wrote:
>> > > > > > > >
>> > > > > > > > > Things changed overnight on the ELKS repo and
>now my
>> > > > > Amstrad PC 2086
>> > > > > > > > > boots
>> > > > > > > > > ELKS from 32MB CF card!
>> > > > > > > > >
>> > > > > > > > > There are some shortcomings though:
>> > > > > > > > >
>> > > > > > > > > 1. Bootable MINIX image does not contain
>partition table.
>> > > > > There's
>> > > > > > > > > nothing
>> > > > > > > > > wrong about that, yet it makes ELKS's
>Partition Check
>> > > > > routine lost a
>> > > > > > > > > bit.
>> > > > > > > > > Contrary to this, the Desktop tools for
>managing external
>> > > > > storage in my
>> > > > > > > > > Desktop Linux environment somehow are able to
>spot that and
>> > > > > do mount
>> > > > > > > > > MINIX
>> > > > > > > > > fs on /dev/sdc when asked, not on /dev/sdc1 or
>anything
>> > > > > else (note that
>> > > > > > > > > fdisk /dev/sdc shows rubbish like non-existing
>/dev/sdc4
>> > > > > partition of
>> > > > > > > > > exotic type and size). ELKS's Partition Check
>also shows
>> > > > > rubbush bda4
>> > > > > > > > > partition of a very wrong size.
>> > > > > > > > >
>> > > > > > > > > 2. Root fs mount fails asking me to insert
>rootfs floppy:
>> > > > > > > > >
>> > > > > > > > > FAT: can't read super
>> > > > > > > > > VFS: Insert root floppy and press ENTER
>> > > > > > > > >
>> > > > > > > > > Fortunately, I still have one. Yet during
>that, good old
>> > > > > problem with
>> > > > > > > > > mounting on-card fs appeared again:
>> > > > > > > > >
>> > > > > > > > > minix: unable to read sb
>> > > > > > > > > mount failed: Invalid argument
>> > > > > > > > >
>> > > > > > > > > I suspect it tried to mount non-existing
>/dev/bda1 or wrong
>> > > > > /dev/bda4
>> > > > > > > > > partition as suggested by misleading Partition
>Check
>> > > > > > > > >
>> > > > > > > > > When I finally reached the shell, I managed to
>mount MINIX
>> > > > > fs anyway,
>> > > > > > > > > just
>> > > > > > > > > by doing:
>> > > > > > > > >
>> > > > > > > > > mount /dev/bda /mnt
>> > > > > > > > >
>> > > > > > > > > and it just worked, all the files and
>directories were
>> > > > > there!
>> > > > > > > > >
>> > > > > > > > > Cheers,
>> > > > > > > > > Paul
>> > > > > > > > >
>> > > > > > > > > On Thu, 6 Feb 2020, Paul Osmialowski wrote:
>> > > > > > > > >
>> > > > > > > > > > Some more update:
>> > > > > > > > > >
>> > > > > > > > > > I've compiled FAT support into kernel. Then
>I've also
>> > > > > built HD image
>> > > > > > > > > > with
>> > > > > > > > > > FAT filesystem (non-bootable), in facts,
>what have been
>> > > > > built was not
>> > > > > > > > > > binary image, it was rather rootfs in the
>'target'
>> > > > > directory. I've
>> > > > > > > > > > created
>> > > > > > > > > > partition table on the 32MB CF card with DOS
>partition
>> > > > > and formated
>> > > > > > > > > > the
>> > > > > > > > > > partition with FAT16 filesystem (all using
>FreeDOS booted
>> > > > > from
>> > > > > > > > > > floppy).
>> > > > > > > > > > Then I've rebooted the machine with ELKS
>bootable floppy
>> > > > > and this
>> > > > > > > > > > time...
>> > > > > > > > > > the rootfs was mounted by init into '/mnt'
>mountpoint. So
>> > > > > the HDD
>> > > > > > > > > > support
>> > > > > > > > > > isn't that entirely bad in ELKS and we're
>nearly there!
>> > > > > What I also
>> > > > > > > > > > immediately noticed is that this system
>lacks 'chroot'
>> > > > > command...
>> > > > > > > > > >
>> > > > > > > > > > Cheers,
>> > > > > > > > > > Paul
>> > > > > > > > > >
>> > > > > > > > > > On Thu, 6 Feb 2020, Paul Osmialowski wrote:
>> > > > > > > > > >
>> > > > > > > > > > > Hi Marc,
>> > > > > > > > > > >
>> > > > > > > > > > > Now it prints:
>> > > > > > > > > > >
>> > > > > > > > > > > C=0x3C H=0x10 S=0x3F
>> > > > > > > > > > >
>> > > > > > > > > > > Following this, I've tried to build HD
>boot image with
>> > > > > 63 sectors,
>> > > > > > > > > > > 16
>> > > > > > > > > > > heads and 60 tracks (cylinders), but it
>still dies at
>> > > > > '....4!'.
>> > > > > > > > > > >
>> > > > > > > > > > > Also, when I booted ELKS from floppy
>again, I noticed
>> > > > > it tried to
>> > > > > > > > > > > mount
>> > > > > > > > > > > filesystem on the card with the image
>mentioned above
>> > > > > that I left in
>> > > > > > > > > > > the
>> > > > > > > > > > > CF adapter. It failed eventually as such:
>> > > > > > > > > > >
>> > > > > > > > > > > Mounting FAT filesystem: hd: error:
>AX=0x04
>> > > > > > > > > > > BIOSHD: I/O error
>> > > > > > > > > > > dev 301, sector 2
>> > > > > > > > > > > minix: unable to read sb
>> > > > > > > > > > > mount failed: Invalid argument
>> > > > > > > > > > >
>> > > > > > > > > > > This 'Mounting FAT filesystem' message is
>kinda
>> > > > > misleading: I didn't
>> > > > > > > > > > > compile FAT support into the system, and
>the image on
>> > > > > CF card has
>> > > > > > > > > > > MINIX
>> > > > > > > > > > > filesystem installed.
>> > > > > > > > > > >
>> > > > > > > > > > > Cheers,
>> > > > > > > > > > > Paul
>> > > > > > > > > > >
>> > > > > > > > > > > On Wed, 5 Feb 2020, Marc-F. Lucca-Daniau
>wrote:
>> > > > > > > > > > >
>> > > > > > > > > > > > Yep, hex error fixed in latest commit:
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > >
>https://github.com/elks-org/elks/commit/6332929104591ecbd62f18757a76506938cf96ce
>> > > > > > > > > > > >
>> > > > > > > > > > > > MFLD
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > Le 03/02/2020 ? 23:05, Paul Osmialowski
>a écrit :
>> > > > > > > > > > > > > probe.bin prints:
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > Boot sector
>> > > > > > > > > > > > > C=0x3D H=0x10 S=0x3G
>> > > > > > > > > > > > > Press key
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > 0x3G is a rather strange hex value...
>I assume
>> > > > > off-by-one error
>> > > > > > > > > > > > > while
>> > > > > > > > > > > > > doing 'A' + h.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > I looked at what fdisk on different
>systems prints
>> > > > > about this
>> > > > > > > > > > > > > 32MB CF
>> > > > > > > > > > > > > card.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > On Linux (fdisk -c=dos /dev/sdX):
>cyls: 1024,
>> > > > > heads: 1, sects:
>> > > > > > > > > > > > > 61
>> > > > > > > > > > > > > On Linux (fdisk -c=dos on FreeDOS
>image): cyls: 3,
>> > > > > heads: 16,
>> > > > > > > > > > > > > sects: 63
>> > > > > > > > > > > > > On FreeDOS (fdisk /info /tech): TC: 61
> TH: 15 TS:
>> > > > > 63
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > I've tried all of those values, with
>the same
>> > > > > effect (....4!).
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > Also I think the name of config option
>in kernel
>> > > > > configuration
>> > > > > > > > > > > > > is
>> > > > > > > > > > > > > misleading. Tracks refers to number of
>tracks per
>> > > > > cylinder which
>> > > > > > >
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
