WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Recent Posts

Pages: 1 ... 8 9 [10]
91
TCB Q&A Forum / Re: How to boot TC5 on mdadm RAID1 correctly?
« Last post by curaga on April 11, 2014, 01:40:59 AM »
You can easily do it all in bootsync.sh, as there's nothing special about the boot script. You can call tce-setup any time to load extensions.

So in bootsync you would assemble, call tce-setup, and perhaps other things. You would also add the "base" bootcode for a small speedup, avoiding the tce scan.
92
Corepure64 / Re: No modules loaded
« Last post by curaga on April 11, 2014, 01:37:46 AM »
Your USB stick is likely slow, play with the waitusb param.
93
Corepure64 / No modules loaded
« Last post by AlexMartin on April 11, 2014, 01:13:26 AM »
No modules are loading after boot.

Corepure64 boot from usb.

I will need network running for additional tcz installs

Regards.
94
Raspberry Pi / Heartbleed - openssl-1.0.0.0 - UPDATE - NOT AFFECTED
« Last post by spence91 on April 11, 2014, 12:58:18 AM »
Hi - I don't know too much about this Heartbleed business - I know it's to do with the openssl library though.

I'm just wondering if it's worth rebuilding this with whatever patch fixes this issue?

***EDIT***

Opensssl 1.0.0.0 isn't affected. So we're safe.

https://www.openssl.org/news/secadv_20140407.txt

False alarm, apologies.
95
TCB Q&A Forum / How to boot TC5 on mdadm RAID1 correctly?
« Last post by virtualbox on April 11, 2014, 12:30:58 AM »
Hi,

I have installed TC5 on software RAID1 with XFS filesystem (and Grub2).

Kernel and initrd boots fine but TCE folder does not get mapped, because it sits on RAID1. The RAID1 array doesn't get assembled. So this is my question: How to assemble mdadm RAID before home TCE folder gets mapped in boot process.

I have compiled kernel with software RAID support and remastered initrd to contain mdadm and raid-dm. So I want to have somewhere in boot process (way before bootsync for example) a possibility to add "mdadm --assemble /dev/md0 /dev/sda4 /dev/sdb4" for example.

I thougth that maybe the pretce bootcode is a way to go (and use the onpre.sh script to assemble nessesary RAID arrays), but I need to give the path as UUID not with /dev/sda4 or something like this.. But I checked the tc-config source and I don't think it would work with UUID as path.

Grub2 entry:
Code: [Select]
menuentry 'Tinycore Linux' {
load_video
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos msdos
insmod diskfilter mdraid1x
insmod ext2
set root='mduuid/eea3afa37c26fba30153695473cb6fc7'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='mduuid/eea3afa37c26fba30153695473cb6fc7'  c390bd7b-1490-41fb-aa7a-760046c06258
else
  search --no-floppy --fs-uuid --set=root c390bd7b-1490-41fb-aa7a-760046c06258
fi
linux /tce/boot/vmlinuz_reiser4_xfs_mdraid quiet noicons noswap syslog waitusb=0:UUID="c390bd7b-1490-41fb-aa7a-760046c06258" tce=UUID="c390bd7b-1490-41fb-aa7a-760046c06258" xvesa=1400x900x32
initrd /tce/boot/core_mdadm.gz
}

Code: [Select]
$ uname -a
Linux 3.8.13-tinycore #8 SMP Tue Mar 4 11:54:42 UTC 2014 i686 GNU/Linux

Code: [Select]
$ version
5.1
96
Raspberry Pi / Re: Building landing wheels while in flight
« Last post by sbp on April 10, 2014, 10:46:12 PM »
@Paul and Steen-
I agree with moving forward with some mechanism for upgrading without having to remove the SD card.  I do think that given the unique case that is piCorePlayer there is a way to accommodate upgrades with current session running shell script logic.  If there are serious architecture shifts for Tiny Core (or any dependent packages), then the upgrade process would become more disruptive (up to the point of full SD card rewrite).  There may need to be some deliberate change for the approach of someone starting new versus someone upgrading from prior start.  I would also anticipate a challenge in enabling/supporting the wide range of DAC cards.  Eventually there will be conflicts that prevent providing protocol stacks for all known DACs.  This would almost trigger a "TCE-like" environment where there are unique "packages" to load for the different DACs.  In any regard, I would be willing to volunteer efforts along the line of providing upgrades to the degree that we can control it.

I agree that this will be a constant struggle to support all the new DACs that will be developed. However, for the near future I can't see that it will be possible to build "DAC packages". As it is now these new DACs require changes in the kernel and support for new DACs are added from time to time via a new kernel and modules.
For each major update of piCorePlayer I have build a new kernel and modules (in order to support more hardware and improve stability), so for piCorePlayer I think we often still need to supply our own kernel.img and module.gz. From time to time we are in sync with the official piCore development of bmarkus and sometime we are in front.
So we need to be able to download our own kernel.img and module.gz.
Therefore, we also need to be able to create and download the Kernel specific tcz packages (Alsa and wifi).   


I am also (quite selfishly) thinking of other embedded projects that would benefit from a remote upgrade approach.  The benefit of Tiny Core is that it is efficient, frugal and very embedded-friendly.  The downside is that it rapidly evolves and the upgrade method is now targeted to providing a new system image on a vanilla startup.  Thinking back to my process control days on Modcomp and Honeywell trigger a desire for a more robust deployment approach..

I'm not sure I completely understand.
But maybe piCorePlayer is not a good model for developing a generic in situ update system for piCore. The problem with piCorePlayer is that it often use its own kernel and module, therefore, the update system will be different compared to a system build on vanilla piCore and its modules.



Do you think it possible to include at least the "boot once" logic?  The goal being that a new image can be booted once, and if there is no way to confirm a positive execution (through user confirmation or script logic), then on power cycle the last "known good" image will be reconstituted and provide a recovery avenue?  The most elegant approach would provide the means at bootload (maybe like the berryboot VNC - and all it's hairy dependencies).  Perhaps there is something less elegant that will get most of the functionality.

In any event, I am willing to invest time in whatever approach is considered most viable and desired.

This sound good. However, I have no idea how to make it work.


Steen - this is really your creation.  Do you have any guidance?
Sorry - no, I think that I'm the one who knows the least when it comes to linux and programming.
97
TCB Q&A Forum / Re: wifi adapter ralink rt5370
« Last post by coreplayer2 on April 10, 2014, 10:20:23 PM »
Support for this chip seems to have been removed from the kernel sources, so I compiled the official driver for the Ralink/MediaTek  RT5370  have sent it to Stone.Giant, if it is successful will make an extension to support these chips
98
dCore X86 / Re: Next release candidate.
« Last post by yoshi314 on April 10, 2014, 10:14:09 PM »
Maybe there should be some kind of script to put together the initrd with libraries from specific debian derivative repository and specific version ?

Since there is already ubuntu and debian, maybe offer user an option to make e.g. debian sid version (at his own risk) ?
99
TCB Talk / Re: sudoers file tinkering and now extra password prompt
« Last post by gerald_clark on April 10, 2014, 07:26:59 PM »
/home/tc/.profile calls sudo.
100
Raspberry Pi / Re: Building landing wheels while in flight
« Last post by mcdudeabides on April 10, 2014, 06:45:43 PM »
@Paul and Steen-
I agree with moving forward with some mechanism for upgrading without having to remove the SD card.  I do think that given the unique case that is piCorePlayer there is a way to accommodate upgrades with current session running shell script logic.  If there are serious architecture shifts for Tiny Core (or any dependent packages), then the upgrade process would become more disruptive (up to the point of full SD card rewrite).  There may need to be some deliberate change for the approach of someone starting new versus someone upgrading from prior start.  I would also anticipate a challenge in enabling/supporting the wide range of DAC cards.  Eventually there will be conflicts that prevent providing protocol stacks for all known DACs.  This would almost trigger a "TCE-like" environment where there are unique "packages" to load for the different DACs.  In any regard, I would be willing to volunteer efforts along the line of providing upgrades to the degree that we can control it.

I am also (quite selfishly) thinking of other embedded projects that would benefit from a remote upgrade approach.  The benefit of Tiny Core is that it is efficient, frugal and very embedded-friendly.  The downside is that it rapidly evolves and the upgrade method is now targeted to providing a new system image on a vanilla startup.  Thinking back to my process control days on Modcomp and Honeywell trigger a desire for a more robust deployment approach. 

Do you think it possible to include at least the "boot once" logic?  The goal being that a new image can be booted once, and if there is no way to confirm a positive execution (through user confirmation or script logic), then on power cycle the last "known good" image will be reconstituted and provide a recovery avenue?  The most elegant approach would provide the means at bootload (maybe like the berryboot VNC - and all it's hairy dependencies).  Perhaps there is something less elegant that will get most of the functionality.

In any event, I am willing to invest time in whatever approach is considered most viable and desired. 

Steen - this is really your creation.  Do you have any guidance?
Pages: 1 ... 8 9 [10]