As I wrote later in the same thread, I had to disable some stuff (that I
don't particularly need at the moment) in the kernel config, to make the
kernel smaller. Otherwise you'd see link-time error like this.
Cheers,
Paul
On Sat, 22 Feb 2020, Derek Johansen wrote:
> Same result. still get the errors with sudo ./build.sh clean
>
> On Sat, Feb 22, 2020 at 9:38 AM Jody Bruchon <jody@xxxxxxxxxxxxxxx> wrote:
> >
> > 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.
>
