Tiny Core Linux
Off-Topic => Archive / Obsolete => Release Candidate Testing => Topic started by: roberts on August 28, 2009, 02:26:41 PM
-
The Third Release Candidate of v2.3 (microcore_2.3RC3.iso), is now posted and ready for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release_candidates/microcore/
Change log for v2.3 Release Candidate 3
* New noautologin boot code. Be sure to have passwords setup, working, and saved.
* Updated tce-load now only calls flwget when appbrowser is running.
* Updated tce-load and tc-config now handles meta-extensions.
* Dropped default autoscan of tclocal for improved boot speed.
* Dropped nolocal boot code as now not needed.
* Cleanup of unused or unlinked busybox applets.
Note: Grab new Xprogs.core.tczl for latest changes in X prgorams (appbrowser)
See Change log for tinycore v2.3RC3 for details.
-
'Noticed a couple of things:
The usb stick, from which I boot, is no longer mounted automatically
"startx" appears to be missing from the latest Xprogs.core.tczl
Edit: I wasn't thinking straight there - as the usb stick is not mounted on boot, then nothing in /mnt/sda1/tce is loaded, hence no Xprogs.core.tczl, hence no "startx"
Note my boot codes are: quiet vga=773 noswap tce=sda1 waitusb=5 noscan text
-
Hi!
For me everything seems to work allright. I boot MC frugal from the harddisk. Thanks a lot for all improvements!
Have fun,
meo
-
'Noticed a couple of things:
The usb stick, from which I boot, is no longer mounted automatically
"startx" appears to be missing from the latest Xprogs.core.tczl
Edit: I wasn't thinking straight there - as the usb stick is not mounted on boot, then nothing in /mnt/sda1/tce is loaded, hence no Xprogs.core.tczl, hence no "startx"
Note my boot codes are: quiet vga=773 noswap tce=sda1 waitusb=5 noscan text
Nothing has changed that would account for this.
I would recommend to use UUID or LABEL instead of sda1
-
Hmm - using tce=UUID=yada-yada doesn't work either, but if I go back to RC2, but keep the latest Xprogs.core.tczl, then things work as expected again ???
-
Does using "pause" show anything?
-
No, I tried that, but all it shows is the absence of the line showing which extensions are being loaded.
I also re-downloaded RC3 and the RC3 md5sum (which checked out OK) and changed waitusb=5 -> 10 - all, unfortunately without result :(
-
Note my boot codes are: quiet vga=773 noswap tce=sda1 waitusb=5 noscan text
What is noscan?
I don't see that in tc-config.
-
I mention it here, but in fact it has happened from time to time with all versions of microcore and flwm - occasionally, when I click on the "X" button in Appbrowser it will not exit.
The shading to show the "X" button has been clicked-on appears, but the window stays open. If I click on the Appbrowser icon in wbar, another instance of Approwser starts, but exits normally when I click on the "X" button.
-
What is noscan?
I don't see that in tc-config.
'Could be a now "depreciated" boot code...
-
I am setting up an external USB hard drive to test.
Back later.
Edit:
OK. Just tested on a newly setup external USB hard drive.
with mircocore.gz, Xlibs.core.tczl, Xprogs.core.tczl, Xvesa.tcz, flwm.tcz, wbar.tcz, and an empty mydata.tgz all in a tce/ folder.
Test 1 boot options: waitusb=5 tce=sda1
Results: Booted normally into flwm X desktop with everything working.
Test 2: Same boot codes except added "text" option
Booted normally to $ prompt
At prompt entering startx
flwm X desktop started normally.
Everything appears to be operating as excepted.
With my production system working, a newly setup base system working, and meo's report of success, I don't see a problem.
Can you manuallt mount all .core. elements and minimal exteions, i.e, window manager, & wbar?
-
I tried manually mounting the minimal extensions - "startx" runs, but I get a black screen, a cursor like a big, fat "X" and no wbar.
Maybe usb drive does not equal usb stick (and Meo installed to hd?)?
-
That sounds like .profile and .xsession needs to be updated from /etc/skel
Please check.
-
I ran out of time to try today, I'll try tomorrow - sort of unlikely though as I do not have a backup and even if I did, it would not be loaded if the usb stick is not mounted?
-
startx is not in microcore, so, something mounted to give up a black screen with large X cursor.
What is mounted when booted to system prompt?
-
Setup and tested on a 64MB usb pendrive, ext partition via the usbinstall script.
No booting issues.
I do see that opt/jwmThemes needs to be removed from the default backup list.
-
I've tried many things without any luck...
My setup - extlinux - works fine with microcore_2.3RC2 and the latest Xprogs.core.tczl.
When I change microcore.gz to 2.3RC3, the usb stick is not mounted on boot. If I mount the usb stick after boot and load Xlibs.core.tczl, Xvesa.core.tcz, Xprogs.core.tczl, flwm.tcz and wbar.tcz, I cannot start X - I get a black screen and the big "X" cursor. If I <ctrl-alt-backspace> out of this, there are no error messages displayed and nothing in dmesg.
I do not use a back-up, but to double-check, I copied .xsession and .profile from /etc/skel with no change to the result.
At present my boot options are:
quiet vga=773 noswap tce=UUID=aaab6273-4a6c-4118-8eb2-e31a9b31edb3 waitusb=10 noscan text
I forgot to try without "noscan" - is it depreciated? Would it make a difference?
-
Try booting with "debug pause" and take note when the stick is recognized.
-
Another bout of troubleshooting...
Using extlinux.conf: display boot.msg
default tinycore
label tinycore
kernel /boot/bzImage
append initrd=/boot/microcore.gz quiet vga=773 noswap tce=UUID=aaab6273-4a6c-4118-8eb2-e31a9b31edb3 waitusb=10 text
implicit 0
prompt 1
timeout 300
F1 boot.msg
F2 f2
F3 f3
I tried varying "waitusb" from 5 -> 20 with no change
Using additional boot codes "debug pause" with microcore_2.3rc2 first, I get: usb-storage: device scan complete
scsi 0:0:0:0: Direct-Access Sony Storage Media 0100 PQ: 0 ANSI: 0 CCS
sd 0:0:0:0: [sda] 31326208 512-byte hardware sectors: (16.0 GB/14.9 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] 31326208 512-byte hardware sectors: (16.0 GB/14.9 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI removable disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
Scanning hard disk partitions to create /etc/fstab
Setting language to C done
Setting keymap to us done
Setting timezone to UTC done
Squashfs version 4.0...
Ignoring swap partitions as requested
Checking for tinycore applications...
Xlib.core Xprogs.core Xvesa.core beaver emelfm flwm glib1 gtk1 gtkfind wbar
Setting up window manager flwm done
Boot time config completed
Now changing only microcore.gz from rc2 -> rc3, I get: usb-storage: device scan complete
scsi 0:0:0:0: Direct-Access Sony Storage Media 0100 PQ: 0 ANSI: 0 CCS
sd 0:0:0:0: [sda] 31326208 512-byte hardware sectors: (16.0 GB/14.9 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] 31326208 512-byte hardware sectors: (16.0 GB/14.9 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI removable disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
Scanning hard disk partitions to create /etc/fstab
Setting language to C done
Setting keymap to us done
Setting timezone to UTC done
Squashfs version 4.0...
Ignoring swap partitions as requested
Boot time config completed
I also tried with additional boot codes "debug base norestore nolocal pause" and got the same result.
The last few dmesg entries, which come mixed in with the coloured tinycore boot messages are:
rc2Attached scsi generic sg0 type 0
squashfs: version 4.0 (2009/01/31) Phillip Lougher
ISO 9660 Extensions: RRIP_1991A
ISO 9660 Extensions: RRIP_1991A
intel_rng: FWH not detected
tg3 0000:09:00.0: wake-up capability disabled by ACPI
tg3 0000:09:00.0: PME# disabled
tg3 0000:09:00.0: irq 27 for MSI/MSI-X
rc3 Attached scsi generic sg0 type 0
squashfs: version 4.0 (2009/01/31) Phillip Lougher
tg3 0000:09:00.0: wake-up capability disabled by ACPI
tg3 0000:09:00.0: PME# disabled
tg3 0000:09:00.0: irq 27 for MSI/MSI-X
One of the keys to this would seem to be that something in the change from rc2 -> rc3 causes my usb stick not to be auto-mounted - but what?
In the case of rc3, after manually mounting sda1, manually loading Xlib.core Xprogs.core Xvesa.core flwm wbar, and running "startx", I noticed that the display appears to briefly show the standard blue background before dropping back to black with the big "X" cursor. Was this sort of thing cured by adding a "wait" somewhere way back when?
Since I do not have a backup and nothing else changed between moving from rc2 -> rc3 (I am using the latest Xprogs.core in both cases), I do not understand why this should happen...
-
In rc3, is there an entry for sda1 in fstab?
No entry - something in rebuildfstab?
An entry - for some reason not getting mounted. Add tons of debug echo statements and remove error redirection from mount commands in tc-config.
-
rc3 fstab (before manually mounting sda1):
# /etc/fstab
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
/dev/hda /mnt/hda auto noauto,users,exec 0 0 # Added by TC
/dev/hda1 /mnt/hda1 ntfs noauto,users,exec,ro,umask=000 0 0 # Added by TC
/dev/hda2 /mnt/hda2 ntfs noauto,users,exec,ro,umask=000 0 0 # Added by TC
/dev/sda /mnt/sda auto noauto,users,exec 0 0 # Added by TC
/dev/sda1 /mnt/sda1 ext2 noauto,users,exec,relatime 0 0 # Added by TC
According to diff, tc-config in rc2 and rc3 is identical, so I'm lost as to why sda1 would mount in rc2 and not rc3.
I'm not sure where the correct place in tc-config would be to insert debug echo statements to track this down, but if somebody could point me in the right direction, I could modify tc-config, remaster rc3 and see what this brings
-
The autoscan and find_mountpoint functions in tc-functions might be a good place to start, I think.
-
A cack-handed attempt at inserting debug lines in tc-config like this:
if [ "$TCVD_DEVICE" == "$TCVD_LOOPFILE" ]; then
echo Testing $1 for autoscan point 1
TCVD_DEVICE="$(autoscan $TCVD_LOOPFILE 'f')"
...
# Next search for tce and setup tce folder
echo Testing $1 for autoscan point 2
[ -z "$TCE" ] && TCE="$(autoscan 'tce' 'd')"/tce
if [ "$TCE" != "/tce" ]; then
echo Testing $1 for autoscan point 3
TCE_DEVICE="${TCE%%/*}"
echo $TCE_DEVICE
TCE_DIR="${TCE#*/}"
echo $TCE_DIR
if [ "$TCE_DEVICE" = "$TCE_DIR" ]; then TCE_DIR="tce"; fi
echo Testing $1 for mount point 1
find_mountpoint "$TCE_DEVICE"
echo $MOUNTPOINT
if [ -n "$MOUNTPOINT" ]; then
echo Testing $1 for mount point 2
echo "${BLUE}Checking for Tiny Core Applications... ${NORMAL}"
..gave this:Ignoring swap partitions as requested
Testing for autoscan point 2
Testing for autoscan point 3
UUID=aaab6273-4a6c-4118-8eb2-e31a9b31edb3
UUID=aaab6273-4a6c-4118-8eb2-e31a9b31edb3
Testing for mount point 1
Done
..then I ran out of time for today. I'll continue tomorrow, but feel free to give hints at where to go next...
-
What does /etc/sysconfig/tce.mount show?
-
rc2 - tce.mount=/mnt/sda1
rc3 - tce.mount=[empty]
-
Therein lies the problem. I set that file immediately after mountpoint determination.
I wish I could replicate the issue here.
However, tc-config should not be identical between rc2 and rc3.
rc3 has the autoscanning for tclocal and notcloal sections removed.
But also note, that Tiny Core and Micro Core share the same tc-config so I would think that there would be other reports of Tiny Core failing on use of pendrives. Still I do not know how wide spread community testing of this or any RC is.
Still works for me on three test devices.
Perhaps if you rebuild using tc-config from rc2 and let me know.
I will continue to test at my ending hoping for a failure that I can diagnose.
-
Therein lies the problem. I set that file immediately after mountpoint determination.
I wish I could replicate the issue here.
However, tc-config should not be identical between rc2 and rc3.
rc3 has the autoscanning for tclocal and notcloal sections removed.
But also note, that Tiny Core and Micro Core share the same tc-config so I would think that there would be other reports of Tiny Core failing on use of pendrives. Still I do not know how wide spread community testing of this or any RC is.
Still works for me on three test devices.
Perhaps if you rebuild using tc-config from rc2 and let me know.
I will continue to test at my ending hoping for a failure that I can diagnose.
I just installed tc 2.3rc3 on a usb stick using the usb installation tool and it boots and runs fine on my eeepc 900A.
-
Finally some progress...
The tc-config files in rc2 and rc3 are indeed different: $ ls -l /tmp/extract_rc3/etc/init.d/tc-config
-rwxr-xr-x 1 root root 17338 Sep 1 10:21 /tmp/extract_rc3/etc/init.d/tc-config
$ ls -l /tmp/extract_rc2/etc/init.d/tc-config
-rwxr-xr-x 1 root root 17742 Sep 1 10:21 /tmp/extract_rc2/etc/init.d/tc-config
..I must have confused the files at one point or another.
When I replace tc-config in rc3 with the tc-config from rc2 everything works fine, so it would seem that there is something in the rc3 tc-config that stops things working for me.
-
I just started to look further into this. However, not too much time today
I am able to replicate your issue by using your specific boot codes. That's good, as now I have something to diagnose. So by process of elimination, dropping 'noswap' worked.
Try dropping noswap and see what happens. What I suspect is that wait $fstab is not being found.
The logic with that construct could be cleaned up. Will look further into tonight when I return,
-
That's it :)
When I drop "noswap" everything works as expected
-
Solved! As I suspected, needed a wait $fstab_pid.
-
Is there a way to hotkey menu for jwm, like the alt-tab in flwm? (don't know what file the right-click desktop config is in) Thanks
-
Here's a suggestion that I hope will be easy for Robert to accept and helpful to others if he does.
Often when a new version of TC/MC is released, it comes with a note about files that have changed in the new release that might conflict with older versions in users' backups. I use grub to boot TC, so I update TC simply by replacing the file 'tinycore.gz' in my boot directory with the new one. (Of course I check that the new kernel matches the previous kernel, too.) When I boot the new version, the material in my backup overwrites the new and improved files just as the release announcement warns. Unfortunately, this makes it difficult to take advantage of the invitation to use the fresh ones. There are probably several ways to access the new files, but here's a simple idea that could beat them all. Could the updated files mentioned in the release announcement be made available for direct download? Maybe they could even be supplied as attachments to the announcement itself in the forums. This change in standard operating procedure shouldn't be too onerous: the developer has a copy of the files on a working new system, and the files involved are usually few in number and small in size.
Thank you Robert and Team TC for your ongoing work. I'm still loving it.
-
The updated files are in /etc/skel - you could just boot as normal and then copy them across?
-
Thank you Robert and Team TC for your ongoing work. I'm still loving it.
Thanks also for your patience while educating the user base. I'm still learning, and loving it.
-
/etc/skel holds all the default files needed to setup a new user.
The contents of such are copied into the users HOME directory.
The default backup is the users HOME directory and some of /opt.
The user, of course, also controls the contents of backup.
I do not assume that I can overwrite files in the user's HOME directory.
Besides the backup occurs later so the new files are actually overwritten by such backup.
It is actually best to do a diff on the files that I list as changed but likely in your backup.
I could add an Fltk GUI diff if it is deemed to be needed.
I recommend a diff so as you don't lose any customizations that you may have made.
You can see the differences before you copy over the changed files.
On any new release or released candidate you should boot it at least once with base norestore to see the effects of any changes, as this will ensure that your backup does not overwrite any of tne new files.
-
On any new release or released candidate you should boot it at least once with base norestore to see the effects of any changes, as this will ensure that your backup does not overwrite any of tne new files.
Good advice, just remember to uncheck the "backup box" before rebooting or shutting down or the backup file will end up with changes you may not want. I admit to making this mistake on several occasions.
-
Good advice, just remember to uncheck the "backup box" before rebooting or shutting down or the backup file will end up with changes you may not want. I admit to making this mistake on several occasions.
...which is why it's essential to occasionally backup the backup. There are a lot of ways to lose your backup.