dcore-101

[sm8ps]

Huh?! I am sorry but I do not know where to put your statement, both intellectually as well as editorially -- nor can I grasp its importance. Could you please provide some more background information or give a use case? That would probably help determine how/where to include this in the wiki.

Exploring unknown territory is fun past-time and I am learning a lot, albeit on a somewhat slow pace. I wish I knew some more of the technical technicalities like, well, drivers and firmware for example.
Thank you for making this excellent plattform for tinkering and learning available!

[Jason W]

Probably anyone building kernel modules will already know that with the shared kernel that was built on Core, modules will have to be built there as well.

The main kernel image needs to be built with the same version of GCC as the modules.  Preferably, just build with the same system. 

So probably not a need for that to be in the wiki.

[sm8ps]

About the video driver page, you could add the fact that some driver needs firmware.

I happened to encountered the opportunity/necessity of diving more deeply into matters of drivers and firmware. So I could make sense of your comment and added it to the wiki.

So probably not a need for that to be in the wiki.

Amen! 

[sm8ps]

Sorry to revive a dormant thread but it seems to be the appropriate one. 
The boot-codes "opt" and "home" do create their respective directories in the specified partition if they did not exist already.
However, "tce" does not so; furthermore it takes a directory instead of a partition.
Is this expected behavior or am I over-looking something obvious?

[sm8ps]

I have investigated a bit on this and found out that the described behavior happens when specifying partitions by device files ('/dev/sdXn'); i.e. '/home/' and '/opt/' do get properly set up whereas 'tce/' does not.

This behavior changes if the boot-code is specified as "tce=LABEL=<LABEL>". In this case, 'tce/' does get properly set up.

I do not think that this is expected behavior.

[Jason W]

The protocol is to specify tce=sda2 not tce=/dev/sda2.  But if home and opt work when doing that, I can use that same logic for tce.

[sm8ps]

Aha, I did not know about this.
IMHO it would make sense to have the same behavior for all three boot-codes. I shall add the information to the wiki.

[nitram]

Not sure if this helps, but if dCore is based on Core then for consistency here's what the Core book says:

10.1. tce - extensions directory
The tce bootcode specifies where to locate and store the extensions
and backup. If it’s not given, the system will scan all drives for a
first-level directory called /tce. Thus it may improve boot time to
specify where it is.
It needs to be given when there are multiple such directories (for
example to use your USB installation even on machines with Core
on the hard disk), or if the directory is not named tce.

The bootcode supports both labels and UUIDs (universal
identifiers), which are a necessity with USB drives, as you can’t tell
beforehand how the USB stick might get named.
Examples:
• tce=sda1
• tce=sda1/mydir
• tce=LABEL=mydisk
• tce=LABEL=mydisk/mydir
• tce=UUID=fho4-3436t
• tce=UUID=fho4-3436t/mydir

10.5. home and opt - persistence
The home and opt bootcodes let you keep the respective directories
on a persistent disk. Each bootcode takes either a drive name, a
label, or an UUID.
These options are covered in more detail in the persistence chapter.

Examples:
• home=sda1
• home=LABEL=mydisk
• home=UUID=fho4-3436t

[sm8ps]

Right on the spot, nitram. Thanks!

[Jason W]

Yeah, best to be expected to follow the longstanding boot code convention.  The home and opt persistence was coded long ago, and has the /dev stripped from the entries if they exist evidently.  The TCE directory setup was more recently (recent years) changed to call on tce-setup, and that stripping of /dev apparently was not added in.  That is the reason they behave differently if the /dev is mistakenly added to the boot option line. 

[sm8ps]

Agreed! I had neglected the CoreBook as reference. I have corrected the wiki.

[jls]

Hi
I've added this to the wiki:
http://wiki.tinycorelinux.net/dcore:keyboard_layout_in_console#keyboard_layout_-_tinycore_way
kmaps could be added to the dCore repo.

[sm8ps]

Great, thanks a lot! I went over the structure and now your addition is better visible. I was wondering about what codes for the layout to use. Is there a list available from TC? A quick Google-search did not turn up much.

I did not know that regular TC-extensions can be used in dCore. Is there no substantial difference between the two?

I agree that adding kmaps to the dCore-repo would be very valuable for international users.
@JasonW: hope you see this! What do you say?

[jls]

Great, thanks a lot! I went over the structure and now your addition is better visible. I was wondering about what codes for the layout to use. Is there a list available from TC? A quick Google-search did not turn up much.

look at the content of the tcz:
http://tinycorelinux.net/6.x/x86/tcz/kmaps.tcz.list

I did not know that regular TC-extensions can be used in dCore. Is there no substantial difference between the two?

no differences

[sm8ps]

OK. Have added link to this list to the wiki.