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 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 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 > > >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 > > > 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. >