MiNT - init interrupted by error -13 (media change)

[sety]

Hi. Sorry to bother you with this. I've tried to figure it out but I can't work out what's going on. Ever since I MiNT 1.16 I've been finding that my init process is being interrupted by error -13, which I believe means a media change. I've been able to live with it because I can just start init from the shell and it continues to boot, but it's starting to drive me nuts because I can't do an unattended boot.

Please ignore the error -33. I'm not worried about that. I don't have that fallback shell installed. Any idea on what I'm doing wrong? Image attached.

Thanks,
Stuart

[joska]

EasyMiNT? If so, it does not start up XaAES directly but via the init-scripts. The "shell" (xaloader.prg in this case) is defined in /etc/ttytab (IIRC, it's been a long time!), this probably still points to the old xaloader from the MiNT-version you upgraded from.

[sety]

Hi Joska. This is a clean install. It's not EasyMiNT. It's the manual version. It will start XaAES instantly if I put it in MINT.CNF but I prefer UNIX init. I just don't know where this media change error is coming from.

[ThorstenOtto]

I just don't know where this media change error is coming from.

The ENXIO error reported earlier by nfs_init seems to indicate something else. Maybe device drivers missing? At least you try to boot without nfs.

[mikro]

Isn't that actually Error -14 on that screenshot? And yes, disable NFS.XFS, it will clean up the boot screen at least.

[joska]

Yes, that's -14 which is "Media changed". Maybe that's triggered by the NFS failure? As suggested by ThorstenOtto and mikro already - try to boot without NFS and see what happens.

[sety]

Sorry, I was half asleep. I meant error -14 media change.

Here is a screenshot with NFS disabled.

Thanks again for all your help,
Stuart

[joska]

Can you post your configuration-files and init-scripts? Where does the init-binary come from? Do you still have a pre-1-16 kernel installed you can test with? What kind of hardware are you running this on?

[wongck]

Hi. Sorry to bother you with this. I've tried to figure it out but I can't work out what's going on. Ever since I MiNT 1.16 I've been finding that my init process is being interrupted by error -13, which I believe means a media change. I've been able to live with it because I can just start init from the shell and it continues to boot, but it's starting to drive me nuts because I can't do an unattended boot.

Been sometime now since I updated my Mint, but I think I had the same issue with you. Just that i do not remember the error code but it just drops to the builtin command line.

Can't remember what I did, but looking for clues on what I did on AF here, it seems to be something to do with folders structure.
http://www.atari-forum.com/viewtopic.ph ... 25#p337812

So Joska seems to be on the right track, and sety need to modify /etc/ttytab so the init can execute the correct xaaes.

[sety]

Hi! Sorry about the late reply. 12 Hour time difference, I'm normally going to bed when you guys get up.

I've attached my mint.cnf and /etc/ttytab as requested (with comments stripped) I've also put in some more info; the absolute path to my MiNT kernel loader and a list of running processes.

The processes are interesting. init is supposed to be PID 1. I understand why "shell" is PID 1, because I started init from the shell, so I'd expect init to be PID 2, but PID 2 is something called "update". What on Earth is that??

Thanks again

[joska]

I've attached my mint.cnf and /etc/ttytab as requested (with comments stripped) I've also put in some more info; the absolute path to my MiNT kernel loader and a list of running processes.

Since this error does not happen when you boot directly too XaAES but only when running init, there's most likely something in your init scripts that triggers the problem. Maybe you should try to disable stuff one by one and see if you can isolate where in your init scripts things go wrong.

The processes are interesting. init is supposed to be PID 1. I understand why "shell" is PID 1, because I started init from the shell, so I'd expect init to be PID 2, but PID 2 is something called "update". What on Earth is that??

Take a look at process sizes, both shell and update are kernel threads/processes. Shell is the internal shell you've started init from, update is the update daemon that flushes the writeback cache to disk. Both processes are forked before any external programs are executed, although the shell process will not be created when things are working correcly.

[wongck]

looks like gluestik PID is lower than xaloader.... but i do not see where it is started from mint.cnf.

[Faucon2001]

Add the full path in your ttytab : u:/c/mint .... instead of /c/mint and check that you have tabs and not spaces before and after vt52
If it doesn't fix it, it would be interesting to see the full mint.cnf and your xaaes.cnf

[wongck]

never mind
i think you started gluestik on the shell manually
as Joska mentioned just look at the services that are started by init

[sety]

Add the full path in your ttytab : u:/c/mint .... instead of /c/mint and check that you have tabs and not spaces before and after vt52
If it doesn't fix it, it would be interesting to see the full mint.cnf and your xaaes.cnf

Done. It didn't make much difference.

Some more weirdness is attached.

But honestly, I'm really happy with this machine, so I won't lose too much sleep if I can't solve the init problem.

[helmut]

Does it still happen if you remove the fsck from mint.cnf?

Is there a log-file from init (e.g. /var/log/...)?

Is there something in xa_boot.log?

[sety]

I have managed to find a work around. I'd hardly call it a solution, because it's pretty ugly.

If I execute an app from mint.cfg before starting init, then the app invariably crashes first, and leaves init to start up okay. Ugly but it's working. :/

[joska]

No, it's not working. You're just crashing something else. It may appear to be working, but it will get you into trouble.

[sety]

No, it's not working. You're just crashing something else. It may appear to be working, but it will get you into trouble.

I think it was actually Taskbar that I used to do this

But I'm starting to think this is some sort of weird hardware problem. A similar thing happened when I tried to use a prebuilt Debian image - worked for everyone else, but crashed for me right on starting the rootfs. Of course there is no fallback shell so all I got was a kernel panic. I got it to boot only once by holding the hard disk up in the air, tried a different drive, still the same. I've ordered a new IDE cable. I really hope it makes a difference, otherwise I'm out of ideas for now.

Thanks,
Stuart

[joska]

While I don't doubt that Taskbar would be able to do this, it seems to be innocent this time

Your problem starts with init. I've asked before - where does this init binary come from? Do you know that it works correctly? What about the shell it spawns, where does it come from and do you know it works? Have you tried to debug your init scripts to determine exactly where init crashes? Is memory protection enabled - that should give you some clues. The ps output from the fallback shell indicates corrupted kernel memory.