From: Jody Bruchon <jody@jodybruchon.com>
To: Derek Johansen <djohanse678@gmail.com>, linux-8086@vger.kernel.org
Subject: Re: Cannot boot the real thing from HDD
Date: Sat, 22 Feb 2020 11:38:03 -0500 [thread overview]
Message-ID: <A5612F29-0CC2-4902-8E35-F14DD5D4334A@jodybruchon.com> (raw)
In-Reply-To: <CAOv0vdmeYKc9p_Wb61Yb2EzoFnYn+ZJLYpYaVZHWZYOE9VU3+g@mail.gmail.com>
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@gmail.com> 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@king.net.pl>
>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@king.net.pl> 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.
next prev parent reply other threads:[~2020-02-22 16:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LNX.2.21.1904141943280.11933@localhost.localdomain>
[not found] ` <alpine.LNX.2.21.1904151809190.25824@localhost.localdomain>
[not found] ` <e10535c1-4751-7e9a-5f76-9cc631e4eb3c@gmail.com>
[not found] ` <alpine.LNX.2.21.1904162210400.4944@localhost.localdomain>
[not found] ` <6e26eeeb-c80a-c42b-f2af-91b8df146a5e@gmail.com>
[not found] ` <alpine.LNX.2.21.1904172300570.28634@localhost.localdomain>
[not found] ` <cf48f070-f306-4afa-8afa-3e5b338114e7@gmail.com>
[not found] ` <alpine.LNX.2.21.1904181343510.11093@localhost.localdomain>
[not found] ` <1c3b5526-66ae-5ed3-ecc2-b6e7f14b53ca@gmail.com>
[not found] ` <alpine.LNX.2.21.1.1912161352140.19666@localhost.localdomain>
[not found] ` <alpine.LNX.2.21.1.1912171117001.25658@localhost.localdomain>
[not found] ` <f62d11b1-8e42-cbd9-d466-b4b60c5c18ea@gmail.com>
[not found] ` <alpine.LNX.2.21.1.1912172310001.28757@localhost.localdomain>
[not found] ` <CACpuWUnxxZr=8i0srFGkSPPLzrhMxMVBF1xXbh6ZXaG2ORS8Tw@mail.gmail.com>
[not found] ` <alpine.LNX.2.21.1.1912182337240.24813@localhost.localdomain>
[not found] ` <alpine.LNX.2.21.1.1912182347540.24813@localhost.localdomain>
[not found] ` <3c988b36-6f34-b903-6a80-e54b56c1c950@gmail.com>
2020-01-24 21:05 ` Cannot boot the real thing from HDD Marc-F. Lucca-Daniau
2020-01-30 19:51 ` Paul Osmialowski
2020-01-30 21:43 ` Marc-F. Lucca-Daniau
2020-02-01 10:28 ` Marc-F. Lucca-Daniau
2020-02-03 16:59 ` Paul Osmialowski
2020-02-03 18:52 ` Marc-F. Lucca-Daniau
2020-02-03 22:05 ` Paul Osmialowski
2020-02-03 22:09 ` Paul Osmialowski
2020-02-05 15:37 ` Paul Osmialowski
2020-02-08 9:35 ` Marc-F. Lucca-Daniau
2020-02-08 12:58 ` Paul Osmialowski
2020-02-05 19:26 ` Marc-F. Lucca-Daniau
2020-02-05 23:45 ` Paul Osmialowski
2020-02-06 10:07 ` Paul Osmialowski
2020-02-08 13:08 ` Paul Osmialowski
2020-02-10 23:38 ` Paul Osmialowski
2020-02-11 20:38 ` Marc-F. Lucca-Daniau
2020-02-12 19:39 ` Marc-F. Lucca-Daniau
[not found] ` <alpine.LNX.2.21.1.2002122207100.31423@localhost.localdomain>
[not found] ` <CACpuWU=DhqB93KxhmD2jpueOUrAkSPVeMPmLnRq4_j=zLjfm5g@mail.gmail.com>
[not found] ` <alpine.LNX.2.21.1.2002122326370.561@localhost.localdomain>
2020-02-17 21:24 ` Marc-F. Lucca-Daniau
2020-02-17 21:27 ` Paul Osmialowski
2020-02-17 21:34 ` Paul Osmialowski
2020-02-20 23:21 ` Paul Osmialowski
2020-02-22 16:24 ` Derek Johansen
2020-02-22 16:38 ` Jody Bruchon [this message]
2020-02-22 17:19 ` Derek Johansen
2020-02-22 21:27 ` Paul Osmialowski
2020-02-21 9:11 ` Marc-F. Lucca-Daniau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A5612F29-0CC2-4902-8E35-F14DD5D4334A@jodybruchon.com \
--to=jody@jodybruchon.com \
--cc=djohanse678@gmail.com \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).