Tinycore's boot sequence.

VFAT is FAT.

You need to dd it to the raw device, not to partition 1.

and needs to be in block 0 of the raw device, not in block 0 of the first partition.

OK, so that's eg. ...of=/dev/sda

Of course I'm going to try your advice. But I just recently AGAIN read that rPi boots from the GPM's to be able to read-FAT from the SD. So the first code that accesses SD expects to find a mountable FAT partition 1. Perhaps the code is

.....snip ..

OK, Thanks! It boots fast. But you can't . Mounted USBs and the SD:1st-partition are read-only; so you can't get data out to .

I could `chroot mc`, so it seems strange that write

-permission was denied?

But the doco show quirky stuff like:-- ]Login, passwords ]================ ] ]Default user is tc. There are no user passwords, tc user is auto logged ]in on the terminal. In case of piCore-5.x-SSH password for tc user is ] ]piCore ] ]It is not possible to log in as root.

and the forum had got an absurd registration procedure.

OMG, the standard /boot partition of rPi starts with a dos MBR from the previous millenium, including "insert a bootable floppy". You can't escape M$!

But tc is useless if everything is locked-down to be read-only. I tried to uncomment a line in /etc/inittab to get an extra console; perhaps by `init` after the edit. I can't write to any files.

Why would inittab have all but the 1st tty disabled? It's starting to look like a scam.

The does not start with an MBR.

The starts with an MBR which contains a standard MS-DOS style , like the majority of disks and similar storage media.

The "insert bootable floppy" and stuff is possibly because the original was built on a card that had been partitioned on a windows system which put the legacy code there.

The few bytes that identify it as an MS-DOS MBR and the partition table itself are the only parts of that 512 bytes that are used on the Pi.

To cut down on the number of processes running and therefore save memory? I often disable 2 or 3 of the ttys on my older, slower PCs (yes, slower than a Pi by a long way and with much less memory).

Yes ! It's very important to not forget that the partition starts after the MBR & stuff. But there's still some confusion:- ==this is a USBstik Device Boot Start End Blocks Id System /dev/sdc1 * 32 4339843 2169906 c W95 FAT32 (LBA) /dev/sdc2 4339844 15384303 5522230 83 Linux == and this is hda Device Boot Start End Blocks Id System /dev/hda1 * 1 128 1028128+ b W95 FAT32 /dev/hda2 129 256 1028160 b W95 FAT32 /dev/hda3 257 384 1028160 83 Linux ... and `dd` shows the MBR. So then is NOT the beginning.

Sure, I guessed that, but expected them to 'clean it'.

This was the report/question that I REALLY wanted an answer to.

Yes OK; that's obvious ONCE you mention it.

But even if you COULD write to inittab, you can't update it for the next boot, because the 'original' inittab is buried and reborn for each boot. For debugging and tracebility, it may be usefull to leave to leave the original, but now bypassed info?

==Thanks.

Start=1 is the beginning of the partition.

The MBR is always in sector 0.

Soemtimes there is other stuff in the "unallocated" space between the MBR and the first partition.

The other thing is that partition editors tend to align partition start/end to a certain number of KB for efficiency/speed.

Why bother? It doesn't do any harm.

This one I don't know the answer to, as I've never looked at tinycore Linux. I suspect it uses something like a loop-mounted squashfs file system, which would be a pain to update, so is only available in ro mode.

It might be possible to extract the compressed filesystem on another Linux box, mount it r/w, edit files, unmount and compress the file again. I'm sure a quick search will give results.