Updating the kernel

[toncho11]

Hi,

Can I update the kernel just by copy/paste?
Does it need to be in the first 8 files. Would it be a problem to boot it when I overwrite it?

[ghaerr]

Not sure what you mean by "copy/paste", but if you copy a new kernel (always named linux) to /linux, it should work, provided that /linux was already there. That is, the /linux directory entry must be the first directory entry for some boot sectors. This is ensured to be the case if you are updating a kernel that is already booting, or on a disk that was made from the ELKS build process. The actual location of the /linux kernel data on disk isn't important, but the location of the directory entry /linux will remain unchanged when copying.

Does that answer your question?

[toncho11]

Thanks. Yes. So I can just build the kernel and overwrite it. I think most recent changes are in the kernel, so I do not need to re-install.

[ghaerr]

I think most recent changes are in the kernel, so I do not need to re-install.

That is correct when the changes are only in the kernel, and no structure changes, or changes to the C library, which is many times the case. However, when libc changes or kernel structures change, rebuilding (and installing) the applications would be necessary. For my PRs, I try to indicate that by including [libc] on the top line of the PR.

[toncho11]

@ghaerr
I tried to update the kernel today and it did not work on my Amstrad.
It says #ELKS setup ... Bad system header!

Also it seems fm does not work with an old kernel. It gives some stack overflow messages.

[ghaerr]

I tried to update the kernel today and it did not work on my Amstrad.

That could be because /linux needs to be contiguous sectors. I suggest trying it on a fresh floppy, rather than just copying a new /linux to the floppy.

Also it seems fm does not work with an old kernel. It gives some stack overflow messages.

Not sure on this... does it work with a new kernel? There have been a lot of changes recently in the kernel and application to support various applications.

[toncho11]

I am trying to update my hdd installation.
Indeed just coping the /linux will save me a lot of effort. Currently to just update the kernel I need to:

• write new image to flash
• boot DOS
• write the image to a new floppy disk
• reboot into ELKS
• use sys

This is slow and tedious. Also the install process will overwrite my config options.
Maybe I can save the new kernel in /tmp for example and then use makeboot to update my installation by pointing the kernel I want to be installed (updated). What do you think @ghaerr ?

[toncho11]

-k kernel that just updates the kernel, nothing else. It should verify that the conditions for the /linux file are met.

makeboot /dev/hda1 -k /tmp/linux

[Mellvik]

Hi @toncho11, this scenario sounds very familiar. For quite some time had a similar setup (without DOS and sys involved though, I was creating new bootfloppies (1.44M) continuously from a linux system using a USB floppy drive). Anyway, if you have a serial line on the system, your best bet is to use SLIP and ftp. Obviously depending on the serial speed, but you'll have a new kernel ready to boot in something like 30 seconds. As long as there haven't been any changes to libraries or system header files, you can replace your /linux file and reboot any time without worrying about the rest of the system. Using sys every time sounds like a waste, just copy the kernel. BTW - it sounds like you would benefit from changing the ELKS config files on your development system, to avoid having to do that over and over again. Also, there is the setup command that does some og this, although oriented towards networking.

29. aug. 2022 kl. 09:17 skrev toncho11 ***@***.***>: I am trying to update my hdd installation. Indeed just coping the /linux will save me a lot of effort. Currently to just update the kernel I need to: write new image to flash boot DOS write the image to a new floppy disk reboot into ELKS use sys This is slow and tedious. Also the install process will overwrite my config options. Maybe I can save the new kernel in /tmp for example and then use makeboot to update my installation by pointing the kernel I want to be installed (updated). What do you think @ghaerr <https://github.com/ghaerr> ? -k kernel that just updates the kernel, nothing else. It should verify that the conditions for the /linux file are met.

This is easy to do (I have a PR with an updated makeboot coming up), but I don't see that it can be useful. Using cp or mv does what you want and there isn't much to check about the kernel file itself.

…

-M

[toncho11]

@Mellvik I noted in my previous message that just copying the file (on Windows) did not work, so I think it is not that simple.
@ghaerr says that there are two restrictions for the /linux file:

• the /linux directory entry must be the first directory entry for some boot sectors
• the file must be on continuous sectors

If I replace the file on Windows, I do not understand why /linux will still be the first directory entry? Replace means to delete and then copy again, most-likely as a new entry at a new location, right?
And of course there is nothing that guarantees that a file will be continuous when copying on Linux or Windows, right?

I think the file should be copied continuously after the last used block. And the old directory entry should be redirected to the new location. Can this be done with direct access to inodes? I am really not into that low level disk access.

[Mellvik]

OK; I keep forgetting that you're using FAT file systems, presumably on the floppy too. I have no experience with that. If you want to optimize your development setting (and save a lot of time) I'd suggest you use Minix file systems instead - ON the floppy and on the HD. A small partition - it may be as small as 4M - for ELKS root and you're done with all these problems. And the remainder of your HD is still FAT and evenly visible from Windows and ELKS. —M

…

29. aug. 2022 kl. 11:14 skrev toncho11 ***@***.***>: @Mellvik <https://github.com/Mellvik> I noted in previous message that just copying the file (on Windows) did not work, so I think it is not that simple. @ghaerr <https://github.com/ghaerr> says that there are two restrictions for the /linux file: the /linux directory entry must be the first directory entry for some boot sectors the file must be continuous If I replace the file on Windows, I do not understand why /linux will still be the first directory entry? Replace means to delete and then copy again, most-likely as a new entry at a new location, right? And of course there is nothing that guarantees that a file will be continuous when copying on Linux or Windows, right? I think the file should be copied continuously after the last used block. And the old directory entry should be redirected to the new location. Can this be done with direct access to inodes? I am really not into that low level disk access. — Reply to this email directly, view it on GitHub <#1380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WGOADHJ2DAHPQMFN3NX3V3R5N7ANCNFSM545V35WA>. You are receiving this because you were mentioned.

[ghaerr]

In general, I agree with a lot of @Mellvik's suggestions.

There isn't a need for a special makeboot -k option, since cp will work fine. When a directory entry is deleted, if it's the first one, it will always be used (again) for a subsequent copy and create. There is no guarantee about contiguous files, but on FAT filesystems, blocks are allocated from lowest-to-highest, so /linux would remain contiguous if it were just previously deleted, unless the /linux file is larger than its number of blocks than the first one, in which case the additional blocks may not be contiguous.

Switching to a MINIX filesystem may solve some of the hassle of upgrading, but it is kind of nice to have @toncho11's FAT filesystem tests occurring and to hear about issues. We really need to solve the bigger problem of upgrading using possible solutions discussed in #1390.

[toncho11]

Yes, I was thinking about an automatic update.

I still think that people that are on FAT will always need a tool that needs to assure that the /linux file is correctly written. Now we are counting on the way directory entries are re-used and there is no solution if the file is bigger.

[ghaerr]

I still think that people that are on FAT will always need a tool that needs to assure that the /linux file is correctly written.

MSDOS has exactly the same problem, requiring contiguous entries for the two hidden system files - what does it do, isn't MSDOS sys required to be run directly after formatting a drive? The MSDOS sys tool doesn't ensure contiguous blocks either, unless run on an empty floppy.

[Mellvik]

Incidentally I just ran into this on Minix too. It happens rarely but it does happen - the root directory exceeds one block, and even if most files in the root directory are deleted, the chance is good that a new kernel ends up in the 2nd block, in which case ELKS will not boot. I'm not suggesting we do anything about it, just an observation (I had more than 40 different kernel copies around from the rabbit hunt that ended up being a virus). It is interesting though (or at least useful to know) that ELKS does not automatically reuse 'early' directory slots when they become available. —M

…

29. aug. 2022 kl. 17:27 skrev Gregory Haerr ***@***.***>: I still think that people that are on FAT will always need a tool that needs to assure that the /linux file is correctly written. MSDOS has exactly the same problem, requiring contiguous entries for the two hidden system files - what does it do, isn't MSDOS sys required to be run directly after formatting a drive? The MSDOS sys tool doesn't ensure contiguous blocks either, unless run on an empty floppy. — Reply to this email directly, view it on GitHub <#1380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WGOHS3QXH5SUD67NOMKLV3TJEPANCNFSM545V35WA>. You are receiving this because you were mentioned.

[Mellvik]

Correction - ELKS does indeed reuse directory space from the beginning, the problem I'm seeing is something else. I'm getting the 3! error, which I should not since /linux is present and OK and even the first entry in the dir. Then again I vaguely remember that there is an issue with the directory size for root. Am I right @ghaerr?

…

-M

29. aug. 2022 kl. 18:51 skrev Helge Skrivervik ***@***.***>: Incidentally I just ran into this on Minix too. It happens rarely but it does happen - the root directory exceeds one block, and even if most files in the root directory are deleted, the chance is good that a new kernel ends up in the 2nd block, in which case ELKS will not boot. I'm not suggesting we do anything about it, just an observation (I had more than 40 different kernel copies around from the rabbit hunt that ended up being a virus). It is interesting though (or at least useful to know) that ELKS does not automatically reuse 'early' directory slots when they become available. —M > 29. aug. 2022 kl. 17:27 skrev Gregory Haerr ***@***.*** ***@***.***>>: > > > I still think that people that are on FAT will always need a tool that needs to assure that the /linux file is correctly written. > > MSDOS has exactly the same problem, requiring contiguous entries for the two hidden system files - what does it do, isn't MSDOS sys required to be run directly after formatting a drive? The MSDOS sys tool doesn't ensure contiguous blocks either, unless run on an empty floppy. > > — > Reply to this email directly, view it on GitHub <#1380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WGOHS3QXH5SUD67NOMKLV3TJEPANCNFSM545V35WA>. > You are receiving this because you were mentioned. >

[Mellvik]

(there are no usb 360 kb floppies).

There is - or at least there was. unfortunately the guy who designed it never completed the software beyond reading, so it's read only. I've got one.

Using Linux, MINIX, 386 and 1.44kb is far more easier.

Indeed it is. What I've been using to create 360 and 1.2M floppies is a 386 with both drive types, running ELKS. Works great, but writing 5.25in floppies is an exercise in patience.

…

-M

[toncho11]

I was thinking - why not increase the size of the kernel to make sure that the next version will be shorter (or equal if also extended)?

Before calling sys I can do:
truncate -s 100K /linux

The current kernel is around 85kb, so 100kb should be enough.
Or the kernel is extended immediately after copying it to the target media.
But is there a truncate command in ELKS?

[ghaerr]

I was thinking - why not increase the size of the kernel to make sure that the next version will be shorter (or equal if also extended)?

I actually thought that myself for a bit, but I think that methodology might end up being kind of "circular" where the reserved space just becomes larger and larger, but still having the same problem.

The current kernel is around 85kb, so 100kb should be enough.
Or the kernel is extended immediately after copying it to the target media.
But is there a truncate command in ELKS?

These are potentially interesting ideas, but not sure whether we really need to waste 15K of space on a 360K floppy for kernel expansion. There isn't a truncate command on ELKS, either. Does this problem actually occur (much), or do we just need a more precise way to work around this particular issue? For instance, fsck could possibly be modified to show which files use which disk blocks, and/or some data about which files are contiguous, etc, allowing a manual rm and cp when the replacement /linux is too large.

[toncho11]

If truncate is applied on the target then it won't be a problem because I usually use sys on a hdd where there is enough space.

I am using FAT to be able to just copy the "extended /bin" to my XT-IDE from Windows and be able to test. But then I can not just replace the new kernel from Windows. Ultimately the best is:

• copy the kernel to /tmp on the XT-IDE from windows and complement the /bin with the extra commands
• boot the old kernel
• apply makeboot or fsck to install the new kernel from /tmp
• reboot

Currently I need to reinstall everything from floppy and then go back and put the the "extended /bin" to have the fm. And that's why I still haven't tested fm on real hardware. It is just too slow and tedious.

I will really appreciate some improvement in the process.

[Mellvik]

Hi @toncho11, agreed, you should be able to simplify (speed up) this. It would be interesting to see what the directory structure looks like when you replace the kernel from Windows. Can you do that? Copy the kernel to the XT-IDE and post a hexdump of the directory structure? It should look somewhat like this: 025600: 49 4f 20 20 20 20 20 20 53 59 53 07 00 00 00 00 IO SYS..... 025610: 00 00 00 00 00 00 c0 32 bf 1c 02 00 46 9f 00 00 .......2....F... 025620: 4d 53 44 4f 53 20 20 20 53 59 53 07 00 00 00 00 MSDOS SYS..... 025630: 00 00 00 00 00 00 c0 32 bf 1c 07 00 fa 94 00 00 .......2........ 025640: 57 49 4e 41 32 30 20 20 33 38 36 20 00 00 00 00 WINA20 386 .... 025650: 00 00 00 00 00 00 c0 32 bf 1c 39 02 85 24 00 00 .......2..9..$.. 025660: 43 4f 4e 46 49 47 20 20 53 59 53 20 00 00 00 00 CONFIG SYS .... 025670: 00 00 00 00 00 00 6f 6d 72 53 3b 02 cb 00 00 00 ......omrS;..... 025680: 41 55 54 4f 45 58 45 43 42 41 54 20 00 00 00 00 AUTOEXECBAT .... 025690: 00 00 00 00 00 00 6e 6d 72 53 3c 02 e7 00 00 00 ......nmrS<..... 0256a0: 41 55 54 4f 45 58 45 43 4e 32 4b 20 00 00 00 00 AUTOEXECN2K .... 0256b0: 00 00 00 00 00 00 e5 4d 85 50 3d 02 ba 00 00 00 .......M.P=..... 0256c0: 43 50 51 44 4f 53 33 33 49 4d 47 20 00 00 00 00 CPQDOS33IMG .... 0256d0: 00 00 00 00 00 00 7b 79 57 54 3e 02 00 a0 05 00 ......{yWT>..... 0256e0: 4e 41 4e 53 49 20 20 20 53 59 53 20 00 00 00 00 NANSI SYS .... 0256f0: 00 00 00 00 00 00 00 00 54 0d 6b 02 c4 09 00 00 ........T.k..... 025700: 43 4f 4e 46 49 47 20 20 4f 4c 44 20 00 00 00 00 CONFIG OLD .... 025710: 00 00 00 00 00 00 89 75 96 4e 6c 02 d8 00 00 00 .......u.Nl..... 025720: 41 55 54 4f 45 58 45 43 4f 4c 44 20 00 00 00 00 AUTOEXECOLD .... 025730: 00 00 00 00 00 00 89 75 96 4e 6d 02 82 00 00 00 .......u.Nm..... 025740: 41 55 54 4f 45 58 45 43 50 45 33 20 00 00 00 00 AUTOEXECPE3 .... 025750: 00 00 00 00 00 00 26 47 85 50 6e 02 b2 00 00 00 ......&G.Pn..... 025760: 43 50 51 44 4f 53 33 32 49 4d 47 20 00 00 00 00 CPQDOS32IMG .... 025770: 00 00 00 00 00 00 72 7a 57 54 6f 02 00 c0 12 00 ......rzWTo..... 025780: 42 4f 4f 54 4f 50 54 53 20 20 20 20 00 00 00 00 BOOTOPTS .... 025790: 00 00 00 00 00 00 3d 65 94 53 05 03 c9 01 00 00 ......=e.S...... 0257a0: 46 44 31 32 30 30 20 20 49 4d 47 20 00 00 00 00 FD1200 IMG .... 0257b0: 00 00 00 00 00 00 4f 77 75 54 0c 00 00 c0 12 00 ......OwuT…… —M

…

1. sep. 2022 kl. 10:31 skrev toncho11 ***@***.***>: If truncate is applied on the target then it won't be a problem because I usually use sys on a hdd where there is enough space. I am using FAT to be able to just copy the "extended /bin" to my XT-IDE and be able to test. But then I can not just replace the new kernel from Windows. Ultimately the best is: copy the kernel to /tmp on the XT-IDE from windows and complementing the /bin with the extra commands boot the old kernel apply makeboot or fsck to install the new kernel from /tmp Currently I need to reinstall everything from floppy and then go back and put the the "extended /bin" to have the fm. And that's why I still haven't tested fm on real hardware. It is just too slow and tedious. — Reply to this email directly, view it on GitHub <#1380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WGOACNLEQORIDFZEO2BDV4BSUVANCNFSM545V35WA>. You are receiving this because you were mentioned.

[ghaerr]

It sounds like one big issue here is we need the ability to reliably and easily update the kernel on an HD, from a floppy.

The sys command, and its worker makeboot, were originally written to reliably create a new system image from scratch, from a working boot image. That doesn't seem to be what we need now. Instead, we need a program that can update /linux properly, and possibly other programs, from a mounted FAT or MINIX floppy to the existing boot hard drive. The program needs to work on a FAT or MINIX hard drive.

Updating /bin or other utilities from a floppy is pretty straightforward (from the standpoint of @toncho11's issue, different than @Mellvik's): just cp the files over. It seems the only problem then is we can't just cp /linux, because it needs to be contiguous? If this is the problem, then there are a couple of solutions:

1. @Mellvik's idea of having a small boot partition (FAT or MINIX) on the HD is one that could work, but requires more setup - the boot partition could contain a very few files (always /linux, /bootopts and some others) that could be mkfsd from scratch by booting off a new floppy, then copying over /linux and /bootopts, guaranteeing their being contiguous. This gets a bit complicated if /etc needs to remain constant across upgrades.

2. Write a program that can copy files contiguously, for the /linux and /bootopts copy. This gets complicated quickly when having to support MINIX and FAT, but a "cheap" version could possibly just try copying, and copying, until the file is in fact contiguous from the free space. It is still lots of work since both FAT and MINIX filesystem code needs to be moved from the kernel into the program. In other words, lots of work versus coming up with a precise better way of upgrading.

I would say we might be best off coming up with a list of the exact scenarios we are trying to solve, so that we fully understand what needs to be done with new programming, versus some possibly filesystem or other restructuring. I'm all for making it easy for all of us to more easily use ELKS.

[ghaerr]

@toncho11 and @Mellvik: I just looked further into the boot code and now realize that only the FAT filesystem requires /linux to be contiguous. The MINIX boot loader will load /linux from any location, thus allowing it to be freely copied via cp. (the requirement that /linux be in the first root directory block remains, but that entry will always be reused if previously present). The reason that the MINIX boot is different is that the MINIX boot block is a full 1K (two sectors), versus FAT, whose specification only allows for 512 bytes.

Thus, I think the solution for @toncho11 is fairly straightforward: use MINIX on the boot partition for ELKS. Other partitions can be FAT, and Windows can be used to copy files from FAT distribution disks to the HD FAT partition. Then, after booting off the HD MINIX partition, all the files can be merely copied using cp from the mounted FAT (or MINIX) partition (or floppy).

If we wanted to remove the requirement that /linux be contiguous on a FAT filesystem, we could create a multi-stage boot loader, where the FAT boot loader looks for an additional loader stored in /boot, which then loads /linux. ELKS used to use this method, but it was replaced with the much faster single boot block loader. This greatly sped up the floppy disk boots. @Mellvik has pointed out that MINIX is much faster than FAT on ELKS, so perhaps the best answer is just to use MINIX for ELKS on HD, and only use FAT for floppy and/or transferring files from Windows or ELKS distribution disks.

[Mellvik]

Thank you @ghaerr, I agree with this - now even more than before after having sys'd and makeboot'd hundreds of times these past few days. These tools are solid and very useful (as @toncho11 also points out). A MINIX partition as small as 3MB will do the trick. I'm no FAT fan but I always keep a big FAT partition on all disks (usually but not always a CF card) to be able to test - and transfer files back and forth. More often than not, ELKS is the vehicle to get DOS tools and files across - directly to the FAT partition. That said, the SLIP alternative has also worked well for me, but may possibly be more complicated on Windows. I'm using Linux and a $10 RaspberryPI for that.

…

-M

@toncho11 <https://github.com/toncho11> and @Mellvik <https://github.com/Mellvik>: I just looked further into the boot code and now realize that only the FAT filesystem requires /linux to be contiguous. The MINIX boot loader will load /linux from any location, thus allowing it to be freely copied via cp. (the requirement that /linux be in the first root directory block remains, but that entry will always be reused if previously present). The reason that the MINIX boot is different is that the MINIX boot block is a full 1K (two sectors), versus FAT, whose specification only allows for 512 bytes. Thus, I think the solution for @toncho11 <https://github.com/toncho11> is fairly straightforward: use MINIX on the boot partition for ELKS. Other partitions can be FAT, and Windows can be used to copy files from FAT distribution disks to the HD FAT partition. Then, after booting off the HD MINIX partition, all the files can be merely copied using cp from the mounted FAT (or MINIX) partition (or floppy). If we wanted to remove the requirement that /linux be contiguous on a FAT filesystem, we could create a multi-stage boot loader, where the FAT boot loader looks for an additional loader stored in /boot, which then loads /linux. ELKS used to use this method, but it was replaced with the much faster single boot block loader. This greatly sped up the floppy disk boots. @Mellvik <https://github.com/Mellvik> has pointed out that MINIX is much faster than FAT on ELKS, so perhaps the best answer is just to use MINIX for ELKS on HD, and only use FAT for floppy and/or transferring files from Windows or ELKS distribution disks. — Reply to this email directly, view it on GitHub <#1380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WGOB7EYK76UYH2APLVE3V4DJMXANCNFSM545V35WA>. You are receiving this because you were mentioned.

[toncho11]

SLIP alternative

How is this used?

[tyama501]

〉The reason that the MINIX boot is different is that the MINIX boot block is a full 1K (two sectors

Is this mean MINIX boot needs to load 1K initially when turning on the PC?
I haven't consider supporting MINIX boot for PC-98 yet but it only can be done for FD1232, 1K per sector. Only 512 Bytes are loaded initially for FD1440, 512B/sector.

[Mellvik]

〉The reason that the MINIX boot is different is that the MINIX boot block is a full 1K (two sectors Is this mean MINIX boot needs to load 1K initially when turning on the PC?

No - all pcs load one sector, then executes whatever was loaded. No problem. The minix bootblock loads its own second half.

…

-M

[tyama501]

I see. Thank you.

[ghaerr]

I haven't consider supporting MINIX boot for PC-98 yet but it only can be done for FD1232, 1K per sector. Only 512 Bytes are loaded initially for FD1440, 512B/sector.

As @Mellvik points out, on the IBM PC, the BIOS boot loads a single 512-byte sector. For FAT, the entire boot code must fit into that 512 bytes. For MINIX, the 512-byte sector itself loads the next sector at track 0, head 0, sector 2, (which is boot_minix.c) which contains the extra code to load a non-contiguous /linux. For PC-98 FD1232, the entire minix.bin boot sector will be loaded by the PC-98 BIOS as a single 1K sector read, which means that the code in boot_sect.S that loads the additional sector can be deleted (along with the DDPT code which is also not included). This may leave enough extra room for you to complete development of a MINIX boot for PC-98, and FAST_READ is not required.

Here is the MINIX boot code in boot_sect.S, which could be deleted:

#ifndef BOOT_FAT
        // Load the second sector of the boot block

        mov $1,%ax
        mov %ax,%dx
        mov $payload,%cx
        push %ss
        mov $ERR_PAYLOAD,%bl
        call _disk_read

        call payload
#else
        // Load the file /linux from the FAT12/16 filesystem's root directory

In this case, the payload is an address set to the boot load address + 512 bytes, which is the beginning of the second sector loaded. In the PC-98 case, you would just code a jmp payload.

If the PC-98 can boot from 1440K disk, then this method won't be able to be used, and the second sector will have to be loaded by the first boot sector, just like the IBM PC.

[tyama501]

Thank you for the explanation. I understand.

[Mellvik]

 SLIP alternative How is this used?

@toncho11, Slip is a tcp/ip connection to your development machine (or some other machine on your network) connected via a serial line instead of an ethernet interface. So a working serial line is required. It may also be a good idea to enable FAST SERIAL in the configuration, but you don't need that to get started. Practical usage is exactly like if it was via ethernet. The setup is described in the wiki and you may have to look up the particulars of running slip on windows, probably one or two commands (unless you have a Linux machine available). If you decide to check it out (strongly recommended) - I'll be more than happy to help you get going. Start by enabling a login on the serial line to ensure that it is working correctly. Then disable the login before testing slip.

…

--M

[floriangit]

I have a followup question on this. I saw poweroff command giving me an error message, so I wanted to see/debug what's going on:

1. find and modify elks/kernel/sys.c sys_reboot() to add an individual printk()
2. ./build.sh and wait
3. check image/fd1440-minix timestamp
4. cp target/linux to floppy
5. on 286: mount /dev/fd0 /mnt && cp /linux /linux.orig && cp /mnt/linux /linux ; sync; reboot

On the target I don't see the additional printk when calling poweroff despite I have used the first line in that sys_reboot() function. I assume that what I think I pick up is not really what is needed?

Any steps I did wrong or missed?

Thanks.

[ghaerr]

Hello @floriangit,

The basic process you've outlined seems correct. Glad to see you're already in the kernel playing with things. (If you find something you'd like to add, please go ahead :)

A couple things to consider: ensure that the kernel you're building is in fact the latest .img file in image by using ls -lt image. I don't usually use ./build.sh as its primary use is for GitHub CI, but instead just do make from the top level (after building the tool chain of course using tools/build.sh). make should produce a floppy image image/fd1440.img.

On line 5 above, the reboot command won't display the kernel printk until that kernel is booted, and reboot run again, of course.

Thank you!

[floriangit]

Hi @ghaerr,

thanks for the build.sh clarification.
I did some more digging and found that I always copied the correct linux image and when I changed behavior like just return -EPERM or anything (as mentioned I edited elks/kernel/sys.c) it worked just fine. However adding a printk("foobar") into that file where I'm sure the execution will hit did not show output. Since I deal with functions that aim to power off or reboot instead of ever returning to user-space, does it mean I would have to flush this somehow? Note: I did not see the output of printk despite there are sleeps, that would me allow to see them (a few seconds)!

[ghaerr]

Hello @floriangit,

However adding a printk("foobar") into that file where I'm sure the execution will hit did not show output.

I just tried it, and yes, it's a little tricky to see when running on emualtors like QEMU. I think the emulator don't actually outputs to the virtual emulated screen at the moment that ELKS writes the BIOS console memory.

I added the following which works, although to see the initial message I had to comment out the actual hardware reboot, since QEMU doesn't always seem to update its screen after ELKS asking for hardware reset:

diff --git a/elks/kernel/sys.c b/elks/kernel/sys.c
index 242d606a..b04beebe 100644
--- a/elks/kernel/sys.c
+++ b/elks/kernel/sys.c
@@ -37,6 +37,7 @@ extern int sys_kill(pid_t, sig_t);
 
 int sys_reboot(unsigned int magic, unsigned int magic_too, int flag)
 {
+    printk("FOOBAR\n");
     if (!suser())
        return -EPERM;
 
@@ -49,7 +50,7 @@ int sys_reboot(unsigned int magic, unsigned int magic_too, int flag)
                C_A_D = flag;
                return 0;
            case 0x0123:                /* reboot*/
-               hard_reset_now();
+               //hard_reset_now();
                printk("Reboot failed\n");
                /* fall through*/
            case 0x6789:                /* shutdown*/

Thank you!

[floriangit]

I chase the poweroff path, i.e. the case is OxDEAD. poweroff give's me a "poweroff: invalid argument", that's why.
shutdown and reboot seem to work, so I just do it for the learning and fun :-)

Anyhow, I did the printk() like you AND I do not use an emulator, but real VGA card as H/W on my 286 so this output never showing is a bit puzzling right now to me.

[ghaerr]

so this output never showing is a bit puzzling right now to me.

Well, if you comment out the actual call to the BIOS power off routine, like I did, the printk() shows. So I'm thinking its something particular with the way how quickly real and emulated systems a power off request?

In any case, if there's something you find that you'd like to add for your (or other compatible) systems, go ahead and submit a PR. We haven't had much use of the BIOS APM functions, so its nice your playing with them.