Core v16.0beta1

[GNUser]

Hi Rich. Thank you

[idk]

A couple of small tweaks to the tce-setup and tce-load scripts in the base initrd:

tce-setup diff:

Code: [Select]

63c63                                                                                             
<       [ -f "$MOUNTPOINT"/"$TCE_DIR"/"$TARGETLIST"] || touch "$MOUNTPOINT"/"$TCE_DIR"/"$TARGETLIST"
---                                                                                               
>       [ -f "$MOUNTPOINT"/"$TCE_DIR"/onboot.lst ] || touch "$MOUNTPOINT"/"$TCE_DIR"/onboot.lst   


tce-load diff:

Code: [Select]

99c99
<               [ "$THISAPP" != "$EXTENSION" ] || [ "$DOWNLOAD_ONLY" ] || [ "$LOAD_ONLY" ] || echo "$THISAPP" >> "$TCEDIR"/$ONBOOTNAME
---
>               [ "$THISAPP" != "$EXTENSION" ] || [ "$DOWNLOAD_ONLY" ] || [ "$LOAD_ONLY" ] || echo "$THISAPP" >> ../$ONBOOTNAME

I think I got the diff order right - it'll make sense to whoever applies the patches.

These both should correct some file/dir reference issues when a couple of the bootcode-based overrides are used. These have needed tweaking for years. Sorry it took me so long to contribute.

Thanks,
idk

[MikeLockmoore]

Maybe this is not the right place to discuss sound issues, but in the RC I have alsa and pulseaudio installed.  I have the same issue others have posted where I need to unmute my speakers each time I reboot.  I'd like my Flit sound applet be able to control sound without the PAVUcontrol needing to be installed, but as of now, PAVUcontrol is the only way to get sound working for me.  I don't see yet anything PAVUcontrol does when unmuting that is different than the amixer and pactl commands I've tried to unmute the speakers form the command line.  Any thoughts?  Should I repost this issue in another thread?

[Rich]

Hi MikeLockmoore

... I don't see yet anything PAVUcontrol does when unmuting that is different than the amixer and pactl commands I've tried to unmute the speakers form the command line.  Any thoughts?  Should I repost this issue in another thread?

Yes, start a new thread in  TCE Talk  please.

[CNK]

TC16 doesn't boot on my 486DX4-100 laptop. After "Decompressing kernel... Parsing ELF...", then someting else which flashes up too quick to see, it reboots. I can try to frame-through a video of it if it would be useful to know the rest of the message. Perhaps there's a chance the kernel just won't start in the laptop's 16MB RAM anymore (rootfs.gz and modules.gz are unpacked to a HDD partition used as root= so they're not in RAM like a normal TC installation), but probably an illegal instruction.

Sorry I'm late with my usual 486 test. On my first attempt I reconnected the HDD wrong and killed it, losing my TC boot configuration in the process. I tested TC15 again though and (eventually) got it booting again. Replacing the TC15 vmlinuz file with the TC16 one causes the above behaviour. The same HDD transplanted into a 1GHz Intel Celeron laptop with 256MB RAM boots TC16 OK.

[Rich]

Hi CNK

... but probably an illegal instruction. ...

An illegal instruction usually causes the system to halt.

... Replacing the TC15 vmlinuz file with the TC16 one causes the above behaviour. ...

That kernel can't load any of the drivers from that HDD.

There was a recent thread about insufficient RAM with newer kernels:
https://forum.tinycorelinux.net/index.php/topic,27458.0.html

[CNK]

... but probably an illegal instruction. ...

An illegal instruction usually causes the system to halt.

I'm not sure in this case because it's before the kernel has properly started up (before the dmesg messages start). The behaviour might be different at that stage. It's probably before or at the beginning of the start_kernel stage as described here.

... Replacing the TC15 vmlinuz file with the TC16 one causes the above behaviour. ...

That kernel can't load any of the drivers from that HDD.

Nah, it was booting to the TC16 rootfs.gz/modules.gz unpacked to a HDD, and the newer laptop runs off there fine. From earlier misadventures recreating my set-up after my HDD disaster I know that the kernel doesn't actually mount the root= partition (or fail to) until a good way later in the boot process than where the sudden reboot happens, so I just mentioned the vmlinuz file becuase loading things from the root filesystem isn't really relevant at that stage.

There was a recent thread about insufficient RAM with newer kernels:
https://forum.tinycorelinux.net/index.php/topic,27458.0.html

TC15 does boot in 16MB RAM with my HDD install configuration, it's not the same as running in the usual tmpfs. I'll see if I can catch the last boot message on video...

[Rich]

Hi CNK
You said that you unpacked rootfs.gz and modules.gz to the HDD.
The TC16 vmlinuz will accept the rootfs. But if needs any drivers
(kernel modules) for the 486, it won't load them because the
module version won't match the kernel version.

... TC15 does boot in 16MB RAM with my HDD install configuration, ...

Maybe TC16 needs more RAM.

[CNK]

Turns out the last messages that flash up are just normal before the kernel starts:



Specifically they come from misc.c in the kernel sources. Converting the hex in kernel_total_size/needed_size it says it only needs 12.9MB for the kernel. Once it jumps to that main kernel code the PC reboots before any other messages are shown. Well before loading modules (which are correct for kernel 6.12.11-tinycore anyway, I just didn't mention switching them as well as vmlinuz the first time).

I might try on a Pentium 1 PC with more RAM to see if there's trouble booting there as well.

[Rich]

Hi CNK
Does your BIOS reserve any RAM, such as for video for example?

[CNK]

Does your BIOS reserve any RAM, such as for video for example?

When booted to a working Linux distro, dmesg shows 16384k available (16MB). It also says 408k "reserved" though I'm not sure if that's by the kernel or the hardware (I'd guess the kernel). More than 12.9MB left anyway. The laptop's manual says it has separate video memory (1MB).

I'd expect the kernel to handle running out of memory at that stage more gracefully anyway, since routines (such as in misc.c) allocate it in advance. The reboot still suggests an instruction set issue to me (the kernel itself can't print "illegal instruction" if the code to do that doesn't run).

[Leee]

The "apps" browser...

Have I mentioned how much I like the new layout?  Having "Browse" hanging directly off of the "Apps" button instead of down one menu level doesn't sound like much of a change, but it's much easier to use.

[CNK]

TC16 does boot on my Pentium 1 PC with 80MB RAM. I'll see if I can install more RAM in the 486 laptop to see whether CPU or RAM is the problem there.

[Rich]

Hi CNK
See if this boot code eases memory pressure any:

Code: [Select]

udev.children-max=1

[CNK]

Thanks Rich, but yes I've got that already along with a bunch of other options I thought might reduce RAM (I've tried without these too). I think the problem happens before most of the options will take effect since they're typically associated with initialisation messages in dmesg and this happens before the dmesg output even starts.

Looks like udev.children−max=1 doesn't take effect until udevd is started by /etc/init.d/tc-config, which is way later in the boot process.

I'll see what I can do towards upgrading RAM. The manual says 36MB max. but doesn't say how many RAM slots there are in the laptop or if they're standard 72pin SIMM type.