DSL v4.0 alpha1

Forum: Release Candidates
Topic: DSL v4.0 alpha1
started by: roberts

Posted by roberts on July 17 2007,04:58

DSL v4.0 Alpha 1 is now available in the Release Candidate area.

This is a very different version of DSL. It is based on the following wish list as expressed in the forums.

* New 2.4.34 kernel.
* Easier to use user interface
* A real desktop framework
* Drag-N-Drop capability
* Better and more flexible file associations
* Closer coupling of the icons and file manager
* Document centric capability
* Optional menu-less capability
* More intuitive interface to MyDSL extensions

Please read the new Getting Started document. There are many changes in icons, file manager, accessing menu and mydsl.

Note: This is NOT a release candidate. It is the first in an alpha cycle. A such, do expect anomalies.

Updated alpha cuts will be posted as they become available.

When posting feedback here in this forum, please be aware that DSL has four major installations methods.

1. Live CD
2. Frugal
3. Hybrid
4. Traditional

Please indicate which method is being used.

Be aware that this is a new system and that copying only KNOPPIX will not work!

You should test separately from exising installations of DSL.
Should you so attempt to do otherwise please be aware that the following files have changed and are likely in your backup.

1. .xinitrc
2. .desktop
3. .fluxbox/fluxter.bb
4. .fluxbox/menu
5. .jwmrc
6. .filetool.lst
7. .xfiletool.lst

The following are no longer used:

1. .xtdesktop/
2. .emelfm/

Posted by ^thehatsrule^ on July 17 2007,07:18

First impressions... some notes:
- looks like jwm is the wm by default
- the minirt contains scsi and sata modules for boot
- dfm takes over for icons and file manager - provides easier integration and more

I'll admit I was a bit lost when I first booted up it up as a livecd, and even ignored the dillo popup the first time round... like I missed my terminal icon on the desktop... but I'll play around with it more..

When I went to shut down... received numerous permission denied errors from touch and tar, but one distinct error after unmounting scite.uci had "rm: cannot remove `//.dfmdesk/MyDSL/scite.app': No such file or directory" -- I'm pretty sure that's supposed to be "~/" or something like that.

Other:
- right-click menu on the dfm desktop for XTerm starts the directory in /ramdisk/home/dsl/.dfmdesk -- not sure if this is the intended behaviour
- the icons look like they are very low in quality (at least, compared to the previous icons used with xtdesk). Was this done on purpose due to the sheer amount of new icons, or is this a limitation of the implementation of dfm?

EDIT:
I like the new styles for fluxbox/jvm and it fits well with that wallpaper (which is also perfect for those pseudo-transparent aterms)

Posted by curaga on July 17 2007,08:18

Might I ask what kind of install is hybrid?

I'd also be interested in what is in the kernel besides vanilla sources. Unionfs, cloop, bootsplash, supermount, ntfs-2g, loop-aes, -lck patchset etc?

Posted by curaga on July 17 2007,08:22

And should the modules & drivers section be divided to "DSL < 4.0" and "DSL => 4.0"?

Posted by sankarv on July 17 2007,09:25

first of all thanks for implementing this new version based on user requirements/feedbacks. Good work. there r some infos to be noted:

the current version 4.0 (RC) is missing in these few mirrors:

ftp://ftp.oss.cc.gatech.edu/pub/linux/distributions/damnsmall/ Fast!
< ftp://ftp.is.co.za/linux/distributions/damnsmall/ > (South Africa)
< http://gd.tuwien.ac.at/opsys/linux/damnsmall/ > (Austria) also rsync and FTP

i will test the version and soon let u know if found any issues..

Posted by roberts on July 17 2007,12:07

Quote (^thehatsrule^ @ July 17 2007,00:18)

- right-click menu on the dfm desktop for XTerm starts the directory in /ramdisk/home/dsl/.dfmdesk -- not sure if this is the intended behaviour
- the icons look like they are very low in quality (at least, compared to the previous icons used with xtdesk). Was this done on purpose due to the sheer amount of new icons, or is this a limitation of the implementation of dfm?

The xterm opening is based on where you are. On the desktop it opens in the desktop, as you have noted. Double like the home folder and then right click for xterm and you will have xterm opened there.

If you open the Apps folder and click the Aterm icon, it should behave as before. You should drag your choices of desktop icons from the Apps folder to the desktop.

I placed minimal icons on the desktop and would rather let the use select which applications they want. This is especially true for the drag and drop. If have placed all the traditional icons then you may not want to use beaver as your target drag and drop. I copy vi to the desktop and then drag shell scripts and lua on it to edit. Also, the remark has been made that many do not use many of the icons shown previously on the desktop. So I decided to have minimal default icons rather than possibly have an even more crowded desktop covered with icons.

The introduction of all of these new capabilities, was/is a challenge and of course I had to make decisions on how to keep size down. While at the same time, hearing that some older computers could not even use the existing icons. Therefore, I have chose to use much smaller, in byte count, icons. The remark has also been made that 48x48 icons were too big. I am now using 32x32. Actually I am still open to looking at other/alternative small icons. But size has always been more important to DSL than eye candy.

I have been acused of favoring JWM over fluxbox. Actually I am empathic to the new user of DSL and as such feel they would be more comfortable with JWM. I am using the very latest JWM and since it can share the icons used in DFM, I chose to implement the mini-icons. There is no space wasted by using the icons in JWM. I felt that the advanced user would find it very easy to use the desktop=fluxbox. As well, as the advanced user who doesn't use icons, desktop=fluxbox noicons

Actually, while I have been developing 4.0, I am using SWM as the window manager. This makes me walk the talk in supporting a menu-less document centric computing.

Posted by lucky13 on July 17 2007,12:10

I've only had about an hour with it on the computer behind me.

USE: Live CD
CHEATCODES: lowram
MACHINE: Pentium 200mhz, 64 MB RAM
ENVIRONMENT: sandbox/crash test system

Initial impressions: Booted straight up into JWM with four dfm icons on the left. I haven't messed around with dfm in years and it's not my favorite.

Looked around to see if there were any significant changes in menu structure and there really aren't any -- so anyone who's been using DSL should feel right at home.

Right-click on desktop is dfm menu, not DSL menu. Devices can be mounted/unmounted with right click on desktop now.

The first change I made was to change JWM focus setting from sloppy to click. The second was to set the background to a solid color using the desktop option in the menu rather than wallpaper.lua. I also tried to kill X using the dfm menu but it doesn't work (didn't look to see if that can be edited in the menu). I also hit quit in the dfm menu, then looked to see if there was a menu entry for it and there isn't. I quickly added one (killall dfm && dfm) and it works.

Then I made a couple text files to copy and move around to get a feel for dfm. I really don't think it's as intuitive as other file managers, but it works and it's good to have integration between the desktop and the file manager. I mean the intuitive part with respect to moving versus copying, especially copying from a directory to the desktop. I wish that were more configurable.

ISSUES
I mounted one of the DSL traditional-install partitions I have on the hard drive, tried to mydsl-load a couple extensions I have stored on it. Tried clicking on icon first, using mydsl browser local second, and then command line to see why it wasn't loading. Got read-only errors. Copied aumix.dsl to /tmp, checked permissions, tried again. Same problem. I double-checked and /dev/root and /ramdisk are mounted read-write.

Decided to download aumix.dsl on this computer and copy it to floppy. Tried to mount floppy on DSL 4 and got error "mount: unknown filesystem type 'msdos'" -- floppy was formatted using DSL on another computer so I know it should've worked. Looked at fstab and it's set for auto. I went to another room and successfully mounted the same floppy under DSL 2.1b partition without errors (didn't bother to mydsl-load because I already have aumix on that partition). So the problem isn't the floppy. Anyone else have any issues with FAT floppies?

I have to start getting ready for work, so I'll see if I can sort it out later. Overall, I like the direction this is going. Good job, Robert.

Posted by roberts on July 17 2007,12:14

Quote (curaga @ July 17 2007,01:18)

Might I ask what kind of install is hybrid?

I'd also be interested in what is in the kernel besides vanilla sources. Unionfs, cloop, bootsplash, supermount, ntfs-2g, loop-aes, -lck patchset etc?

A hybrid install is frugal plus persistent home and/or persistent opt.

I will be posting the kernel build directory as a tarball so that the advanced community will be able to contribute modules for their specific and unique hardware requirements.

There is so much to do and I am only one person, so in time.
I still have to make the boot floppy and will likely hold off on doing the other DSL images (editions) until the alpha series settles down

Posted by roberts on July 17 2007,12:37

Quote

I mounted one of the DSL traditional-install partitions I have on the hard drive, tried to mydsl-load a couple extensions I have stored on it. Tried clicking on icon first, using mydsl browser local second, and then command line to see why it wasn't loading. Got read-only errors. Copied aumix.dsl to /tmp, checked permissions, tried again. Same problem. I double-checked and /dev/root and /ramdisk are mounted read-write.

Possibly because your partiton containing the mydsl/ folder is owned by root?

The new mydsl implementation by way of the mydsl=hdXY boot code will create a mydsl folder on the specified drive/partiton and change it ownership to dsl.staff. The mydsl download directory now points directly to this location and the the link on the desktop also points to it. The .app shortcuts are then temporarily stored there. If you are using an existing mydsl/ folder be sure to change its ownership permission to that of dsl.staff

Posted by sml on July 17 2007,13:09

What about ipw2200 compatibility?

Posted by curaga on July 17 2007,13:50

We can't see from the kernel build directory which patches have been added...
Could you just mention them?

Posted by lucky13 on July 17 2007,14:18

roberts

Quote

Possibly because your partiton containing the mydsl/ folder is owned by root?

Okay, I'll double check. I think the floppy issue I had is from using the old 2.4.26 boot floppy. I'm going to go ahead and install.

Edit: Now working from traditional install. Both issues I experienced earlier are resolved. I was able to mount the floppy, copy a DSL file to /tmp, double-click it to load. Cool.

curaga

Quote

Could you just mention them?

Could we just be patient.

Posted by lucky13 on July 17 2007,14:46

Here are the menu entries I added for dfm in .jwmrc:
<Program icon="filemgr.xpm" label="re/start dfm">sudo killall dfm && dfm</Program>
<Program icon="filemgr.xpm" label="re/start dfm - su">killall dfm && sudo dfm</Program>

Edit: Initial impressions posted on my blog:
< http://lucky13.blogsavy.com/2007....essions >

Posted by lucky13 on July 17 2007,17:11

MIME types:
The default *.gz in .dfmext doesn't distinguish between standard tarballs and MyDSL tar.gz.

Is netscape/firefox for html intentional or should that be edited to dillo?

Need to add:
*.bfe;path_to_icon;aterm -T bcrypt -e bcrypt !@!
*.m3u;path_to_icon;xmms !@!

I'll edit/add to this if I find more. I can also hold off and just send you my revised .dfmext after I've had more time to play with it.

Posted by roberts on July 17 2007,18:10

Yes! I could use more mime types. Contributions welcomed. You can email me your .dfmext for my review.

One of the challenges, is that DSL has more than one editor, browser, etc. etc. So, should html be limited set to Dillo or Netscape, a link to Firefox?

As far as the .tar.gz goes, is it time to drop it as unique MyDSL extension association and use only the standard definition of a compressed tarball? I would like to depreciate it as a MyDSL extension.

Posted by lucky13 on July 17 2007,19:02

I'll work on converting my rox MIME-info files into an omnibus .dfmext later this afternoon. I'm also going to post my rox AppRun wrapper scripts to make more things (e.g., tarballs, bcrypt, etc.) a simple drag and drop process for those who want that kind of thing. Do you want me to start a thread for DSL 4.0 drag-and-drop wrapper scripts elsewhere or just post them on a page on my blog?

I'm ambivalent about which browser to use by default. I know it's always been dillo, which is much faster to load stuff than firefox is (noticeably so on my test machine per previous post). I set mine up even faster -- aterm -e netrik !@!.

I can live without tar.gz extensions so long as the ones in the repository are converted.

Posted by roberts on July 17 2007,19:25

Please post here, so I can easily see them and incorparate many into DSL 4.0. I knew you would be ready to contribute in this area. Until DSL 4.0 goes gold, this forum thread is for all things DSL 4.0. Looking forward to your suggestions for more and better mime types.

As far as the default mime type when DSL offers so many similiar applications, I have placed the .dfmext into the home directory, so it can be a personal preference thing. Still I recognize that many will be desired by many and should be considered for inclusion in 4.0.

The thing that is difficult in moving forward is supporting all the legacy stuff. I would like to get rid of the .tar.gz MyDSL extension type but then it would affect all previous versions of DSL. I don't want to have yet another copy of the extension to support both. I am finding it difficult to try to manage the four extension types as it is. I am still debating on the best approach.

Posted by roberts on July 17 2007,21:06

Quote

When I went to shut down... received numerous permission denied errors from touch and tar, but one distinct error after unmounting scite.uci had "rm: cannot remove `//.dfmdesk/MyDSL/scite.app': No such file or directory" -- I'm pretty sure that's supposed to be "~/" or something like that.

Found it. Fixed it!
Thanks for the feeback.

Posted by WDef on July 17 2007,22:19

Quote

What about ipw2200 compatibility?

Glad someone else raised this instead of me.

This would require compiling the ipw2200 driver code that has been backported to 2.4.xx.

When I tried this I had no luck . Robert may well have an angle I don't have. Tempestuous compiled this source for 2.4.31, so it is doable. Of course it might have been done on Woody or another system. He is active on the Puppy forum, I've been tempted to pm him over there and ask if he would help out.

Posted by roberts on July 17 2007,23:42

Your humble developer does not own or have such hardware.
I am hoping that the community here, like those in other distros, will contribute modules for their particular hardware requirements. I cannot do it all alone.

Posted by WDef on July 18 2007,12:42

Re:

Quote

As far as the .tar.gz goes, is it time to drop it as unique MyDSL extension association and use only the standard definition of a compressed tarball? I would like to depreciate it as a MyDSL extension.

One idea would be to do away with the tar.gz extension type and instead just have .dsl for both in future, and add a line of code to the extension loading scripts to "prescan" the extension for non-writeable paths along the lines of:

EXTENSION=/path/to/extension

If mkwriteable has not yet been run, then do:

Code Sample

tar -ztf $EXTENSION | while read LN; do case ${LN} in usr*|bin*|sbin*|boot*|lib*|var/lib*|var/cache*) /etc/init.d/mkwriteable; break;; esac; done

Then mkwriteable only ever gets called if it needs to be and it doesn't matter anymore whether the extension has a .dsl or tar.gz suffix, so this would be backwardly compatible. This would also deal with "green" extensions that were mistakenly labelled .dsl when they only ever needed to be called .tar.gz

I think the .tar.gz extension suffix has always risked creating confusion for newbies with source tarballs and all kinds of other archives.

Posted by mikshaw on July 18 2007,13:13

That sounds like a smart, simple solution to me.
I was wondering about certain extensions, such as the Tcl/Tk widgets, which could not work as uci or unc but would be a waste of resources as dsl. Your idea would fix that, and perhaps would prevent some existing *.dsl files to not bother with mkwriteable.

There would be an issue with installation time, though. Listing tar contents can take a noticeable amount of time, depending on how many files are in the archive.

Posted by WDef on July 18 2007,17:17

Quote

Listing tar contents can take a noticeable amount of time,

The loop terminates as soon as a system dir is struck - since it's a pipe tar then stops listing files, so for "red" extensions it's quite fast. And, once mkwriteable has been called, it shouldn't get run at all.

The whole list will however get read for "green" extensions (a minority) if no red extensions have been loaded. I don't have any really big .tar.gz extensions, but on the 860K john-1.7.0.2.tar.gz it runs in 0.072s. On slow processors, maybe 10-15 times that delay is still tolerable.

As a backwards compatibility measure to get rid of the minority tar.gz's, I think it's probably wearable - people can wait a bit longer for the occassional large .tar.gz's to load?

If it proves to be a problem, another alternative might be to put an empty file in extensions for the sole purpose of flagging (for eg) that they are green and mkwriteable shouldn't be run, or to invent a new extension suffix, but I don't like either idea.

Posted by andrewb on July 18 2007,23:25

OK, so I probably missed something obvious, but... is there an easy way to turn the DFM desktop context menu menu back on after it has been turned off (via the 'Desktop Context Menu' checkbox')? Is there any documentation for DFM? The website < http://www.kaisersite.de/dfm/ > doesn't seem to have any .

Posted by roberts on July 18 2007,23:41

Quote

add a line of code to the extension loading scripts

How can this be backward compatible when such is the case?
You cannot go back and change the mydsl loading scripts on all previous versions of DSL. I would have to release another special extension (patch) to effect this change. Further more, word of such must somehow be easily made available, else low end machines would once again be unable to run many extensions. As the .tar.gz are no longer available as they have been renamed .dsl. And without the "loading patch" these machined would likely run out of inodes ( caused by unnecessarily running mkwriteable) than real memory. This issue was given much consideration years ago. With that kind of change I could simply renamed .tar.gz and be done with it. Still I don't find either very apealing.

Consider also that this only affects those still booting legacy. Most distributions have moved on to unionfs. Must I continue to still support both unionfs and legacy?

Does not declobber clean up poorly built .dsl extensions that cause grief in the past with unionfs?

If this is still to be considered, at a minimum, a test should be made for
1. The operating mode is legacy.
2. The extension is of type .dsl

Posted by roberts on July 18 2007,23:43

Quote (andrewb @ July 18 2007,16:25)

Obviously, you should have an icon somewhere on your screen, right click on it and then the usual selection that you used to turn it off turns it on. It is a toggle. DFM for X11 -> Desktop context menu

I leave it on and use the bottom edge right click menu.

< dfm manpage >

Posted by jack_potter on July 19 2007,01:47

So far I am liking 4.0 a lot, thanks!

Posted by andrewb on July 19 2007,06:31

Is there an updated copy of the bootfloppy available? I have been using this so i can burn customised bootable CD's on an M$ machine for running DSL inside a virtual machine (VirtualBox).

Posted by WDef on July 19 2007,06:32

Quote

How can this be backward compatible when such is the case?
You cannot go back and change the mydsl loading scripts on all previous versions of DSL.

By 'backwards compatible" I meant that, with a test something like this added, the scripts could (to provide transitional support) be made to recognize both the old .dsl and .tar.gz and "new" .dsl which would, from then on, be redefined to include both red and green .dsl. Users could then be told to call any new "green" extensions .dsl, not tar.gz. Perhaps "backwards compatible" was the wrong way to express this - I was referring to the change being conveivably compatible with both old and new extension suffixes, but not with earlier dsl versions on low ram hardware.

Yes, users of previous versions of dsl on old hardware could then be running wkriteable unneccesarily on new extensions from the newly-broadened .dsl category and running into problems. This would be a mandatory upgrade to the new dsl version (or some sort of patch extension as you say) if they wanted to avoid that. But I don't see any way around that if you want to get rid of tar.gz while maintaining support for legacy. And if you don't and rely on unionfs to solve the problem, then users of even older pre-unionfs versions of dsl on old hardware will be left behind anyway. Perhaps can't avoid a mandatory upgrade for a minority of users to a newer dsl version one way or the other? Then there are an increasing number of those with newer hardware (me) for whom running mkwritable has no negative effects anyway.

Quote

Must I continue to still support both unionfs and legacy?

I've obviously assumed you would be, and didn't know dropping it was on the cards. I'm one of those often using a legacy boot, because I need ipw2000 with my hardware as you know (dsl-2.1b) (I however still try newer versions). Eventually that will be resolved also.

Quote

a test should be made for
1. The operating mode is legacy.
2. The extension is of type .dsl

Yes.

Granted it requires more thinking through, I've just raised it as an idea.

Posted by roberts on July 19 2007,17:34

Quote (andrewb @ July 18 2007,23:31)

Is there an updated copy of the bootfloppy available? I have been using this so i can burn customised bootable CD's on an M$ machine for running DSL inside a virtual machine (VirtualBox).

New boot floppy now posted to the Release Candidate area!

Posted by roberts on July 19 2007,18:49

A snapshot of the development kernel directory is now posted in the Release Candidate area. Hopefully this will faciliate those who wish/need to compile kernel modules.

Note: This is not an extension. It is a tarball.

Posted by Key on July 19 2007,20:05

I want to refer again to the message, which I have already posted in the feedback area:

" Unfortunately it still doesn't run on my new computer yet.
Same as at the 3.x versions.
I have burned the 4.0 alpha image to a CD.
Messages during booting:
Scanning for USB devices .. Done.
Can't find Knoppix filesystem, sorry.
Dropping you to a (very limited) shell.
DVD drive is connected via a SATA connection.
Is it possible to solve this problem with some added parameters in the boot-menu? But which parameters? I thought I have tried this also in 3.x without success. "

In the meantime, I have tried DSL 2.1b again.
As boot-parameter, I was using " dsl sata ".
Nearly the same as with 3.x and 4.0 alpha.

With 2.1b, there is the message:
"Checking for SATA .. none".
Obviously my SATA-Samsung-DVD-Drive will not be found from DSL :-(

What else can I try?
Will you add SATA support to DSL 4.0 as well?

Thanks in advance.

Posted by lucky13 on July 19 2007,20:46

Quote

What else can I try?
Will you add SATA support to DSL 4.0 as well?

Try setting ATA/IDE in your BIOS to legacy (from enhanced; this disables SATA) and see if that helps.

Posted by roberts on July 19 2007,22:19

SATA as provided with the kernel source is avilable in DSL 4.0.
It is untested, as I do not have such drives.

I have already posted:

Quote

DSL 4 is still supporting the old scsi modules, therefore to support SATA require the sata boot option as was implemented in DSL v2.1b.

By which, I mean:

Quote

As boot-parameter, I was using " dsl sata ".

DSL v3.x does not contain SATA modules.

Try with the necessary boot option: sata

Posted by andrewb on July 20 2007,00:07

Please can the newest version of neofb (0.4.1) be included rather than the current version.

Also move torsmo to v0.18 to deal with batteries not stored in the Bat0/1/2/... directories (for me symlinks don't seem to work to work-around this problem)

Posted by Key on July 20 2007,04:37

Quote (roberts @ July 19 2007,18:19)

DSL v3.x does not contain SATA modules.

Try with the necessary boot option: sata

As written, I have tried this already with DSL 2.1b.
As boot parameter, I was using " dsl sata ".

During boot, I have got the message:
"Checking for sata .. none"
Obviously there has no sata drive been found or is has only been checked for a sata harddisk, but not for a sata dvd/cd drive. Don't know.

I will try this week-end again to change some bios settings, maybe this will help.

I didn't have problems with booting the latest Knoppix release from Live-CD, therefore I thought it might work under DSL with a newer 2.4 kernel now as well.

Keep you informed.

Posted by andrewb on July 20 2007,05:38

I've just noticed that adding files to .filetool.lst has to be done 'manually' in V4 as the function in emelFM has been lost where a file could be selected & then the 'filetool' button. Just a comment that it might make things a bit more awkward for the "point'n'click" user.

Please also see my post:

< http://damnsmalllinux.org/cgi-bin....t=5;r=1 >

Posted by Juanito on July 20 2007,06:02

I tried DSL 4 for the first time today - a few notes:

1. USB boot from Cruzer Micro 1GB
2. I initially burnt a CD and ran the USB-HDD install script. I could not boot from USB - it appears that the ldlinux.sys file was not written. As I thought this might be due to the size of the USB stick (i.e. >512MB), I copied all of the files to /tmp, formatted the USB stick ext2, wrote all of the files back, renamed syslinux.cfg to extlinux.conf, ran extlinux and now the USB boot works fine.
3. The boot process loads KNOPPIX at about 12MB/s as opposed to DSL 3.4 which loads at about 6-7MB/s
4. The card manager no longer complains about my TI smart card reader
5. As per all other versions of DSL, I got a wierd looking display due to video ram problems with my Intel 855GM chip. Using xorg72.uci fixed this problem - now the display looks good @ 1024x768x24 and DSL 4 seems to handle the fonts better than DSL 3.4 (but this could be my imagination). I will need to look at building the drm and i915 modules for DSL 4.
6. Whilst I was getting the display sorted, I mounted another USB stick, copied some files and then unmounted it - this seemed to freeze the "/" icon and I could only mount another USB stick by using a terminal window. Similiarly, exit to prompt no longer worked and I was obliged to use exitcheck.sh from the terminal window.

Looks good so far

Posted by roberts on July 20 2007,07:21

I have tested the USB-ZIP version with success..
I will be sure to check the USB-HDD as well.

Recall, that pluging and unpluging pendrive in kernel 2.4 keeps cycling the drive letters. They don't stay constant and that can cause issues. This is handled better in 2.6. But we don't have that. Other than this known limitation I have not experieced such.

Posted by Juanito on July 20 2007,12:05

I downloaded linux-2.4.34.1.tar.gz and unpacked it:

Code Sample

# mkdir /usr/src
# chown dsl /usr/src
# chgrp staff /usr/src
# tar -xzvf /mnt/sda1/build/kernel_source/linux-2.4.34.1.tar.gz -C /usr/src

and then loaded gnu-utils.unc and gcc1-with-libs.unc and got this:

Code Sample

# cd /usr/src/linux-2.4.34.1
# make menuconfig
rm -f include/asm
( cd include; ln -sf asm-i386 asm)
make -C scripts/lxdialog all
make[1]: Entering directory `/KNOPPIX/usr/src/linux-2.4.34.1/scripts/lxdialog'
/bin/sh: line 1: gcc-2.95: command not found

>> Unable to find the Ncurses libraries.
>>
>> You must have Ncurses installed in order
>> to use 'make menuconfig'

make[1]: *** [ncurses] Error 1
make[1]: Leaving directory `/KNOPPIX/usr/src/linux-2.4.34.1/scripts/lxdialog'
make: *** [menuconfig] Error 2

so I loaded gcc-2.95.unc and tried again and the terminal window froze.

Am I missing something? How are you building the modules Roberts?

Posted by WDef on July 20 2007,12:44

gcc-2.95 is not being found.

Try loading gcc-2.95 followed by gcc-with-libs followed by gnu-utils.dsl in that order.

Posted by curaga on July 20 2007,13:28

Just a side note: 2.4 kernels starting from .34 compile with all gcc versions from 2.95 to 4.2

Posted by Juanito on July 20 2007,13:37

OK - I'll try that. In the meantime, I loaded versions of gcc-2.95, make, etc that I had compiled earlier (as they say in the best children's programmes) on DSL and tried again:

Code Sample

# ln -s /opt/build/bin/gcc /opt/build/bin/gcc-2.95
# cd /usr/src/linux-2.4.34.1
# cp .config /usr/src/linux-2.4.34.1/arch/i386/defconfig
# make oldconfig
# make modules

This worked for a while and then bailed out with:

Code Sample

gcc-2.95 -D -I/KNOPPIX/usr/src/linux-2.4.34.1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fno-builtin-sprintf -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i386 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=ip_conntrack_core -c -o ip_conntrack_core.o ip_conntrack_core.c
make[2]: *** No rule to make target `ip_conntrack_proto_generic.c', needed by `ip_conntrack_proto_generic.o'. Stop.
make[2]: Leaving directory `/KNOPPIX/usr/src/linux-2.4.34.1/net/ipv4/netfilter'
make[1]: *** [_modsubdir_ipv4/netfilter] Error 2
make[1]: Leaving directory `/KNOPPIX/usr/src/linux-2.4.34.1/net'
make: *** [_mod_net] Error 2

So far I have not found anything on this with Google.

I made a couple of tests with modules that had already compiled prior to the above:

1. The bluetooth modules load without errors.
2. The drm module will not load:

Code Sample

# insmod drm
Using /lib/modules/2.4.34.1/kernel/drivers/char/drm/drm.o
/lib/modules/2.4.34.1/kernel/drivers/char/drm/drm.o: cannot read ELF header from /lib/modules/2.4.34.1/kernel/drivers/char/drm/drm.o

Note that the graphics modules i810, i830, mga, etc are already in DSL-4 but the drm module is not - I may be mistaken, but I believe these modules will not work without the drm module?

Posted by curaga on July 20 2007,13:43

I wonder why there is a drm-*ver* tarball in www.kernel.org/pub/linux/kernel/v2.4?
Does that mean drm cannot be included in 2.4 kernels? Anyway, Juanito, get it there..

Posted by Juanito on July 20 2007,14:00

The folder drm-4.0 is included with Roberts 2.4.34.1 tarball (although it didn't compile prior to the error halting things) and drm/i830 work fine in DSL-3.4 with XFree86 - I'll try a few more things and see if I can't get it to work.

Posted by roberts on July 20 2007,14:18

I have started a separate topic thread under "Other Help Topics" as kernel 2.4.34 development. As development dicussion here is not what I am looking for in this area.

I am looking for functional issues, bugs, and operational questions on the new DSL v4.0 system.

Thanks,
Robert

Posted by Juanito on July 20 2007,14:43

Quote

Try loading gcc-2.95 followed by gcc-with-libs followed by gnu-utils.dsl in that order.

Hmm, interesting - I tried this twice (from a terminal window) and everything froze within a few seconds of loading gnu-utils (note that I was using unc extensions).

As a test, I tried almost the same thing with the same extensions in DSL-3.4 (except that gnu-utils was loaded at boot in order to load alsa) without problems. I also tried building modules in DSL-3.4 using Roberts 2.4.34.1 tarball and the build ran until the end without errors...

The drm module thus built is only 8 bytes (as it was under 2.4.34.1 now that I look) - perhaps this is something to do with the fact that CONFIG_X86_CMPXCHG is not set in .config (the dri site says it should be for 3d acceleration).

Edit: sorry - I saw your post after I posted this.

Posted by Juanito on July 20 2007,15:06

OK - back to testing the functionality

I copied the alsa and gnu-utils extensions to /mydsl and added the boot code alsa. On boot DSL-4 acts like DSL-3.4 in that it says it is going to auto configure alsa but after boot there are no alsa modules loaded. The alsa boot code had the effect of stopping the oss modules being loaded however.

After boot, I tried this:

Code Sample

# /opt/alsa/usr/sbin/alsa_init
Preparing modules for alsa...
Building card database..
Configuring intel8x0...
Running update-modules...
Creating snddevices...
Setting default volumes...
aumix: error opening mixer

Maybe I should be using dsl extensions?

Edit: Ah, yes - the alsa modules would need to be be compiled for 2.4.34.1 I guess...

Posted by lucky13 on July 21 2007,19:19

Robert, the rc.firewall extension doesn't work with 4.0. I got a fatal error and was prompted about filter tables and if all necessary modules were compiled...

BTW, jwm is much more convenient with a top-down tray. That way the menu also starts with the apps where the cursor is rather than having to move all the way up past exit, etc. See screenshot at:
< http://lucky13.blogsavy.com/2007/07/21/damn-small-linux-4-tweaks-etc/ >

Posted by roberts on July 22 2007,01:36

Quote (Juanito @ July 19 2007,23:02)

The lack of the ldlinux.sys is caused by the failure of the syslinux command, typically

syslinux /dev/sda1

This seems to happen more frequently on larger drives.
A work-around seems to be...

Create a .mtoolsrc file which contains mtools_skip_check=1
e.g.,

echo "mtools_skip_check=1" > .mtoolsrc

Then running the usbhdd script seems to correct the problem.
I will add the .mtoolsrc file to the next release.

Posted by roberts on July 22 2007,01:47

Quote (lucky13 @ July 21 2007,12:19)

The netfilter modules are currently cut, with the possiblity of being combined into the firewall extension. No final decision has been made. There are other modules up for review. DSL offers an enormous amount of modules (768) versus other small distros.

Yet, I have an easy mechanism to load additional modules at boot time (mydsl/modules). I think this is an area that could be disucssed with the less used modules being made available separately.

Posted by roberts on July 22 2007,02:06

Quote (roberts @ July 21 2007,18:36)

Quote (Juanito @ July 19 2007,23:02)

Thinking about this more, I am inclined to remove the pendrive installation scripts from core and more to a MyDSL extension.

I really don't want to allocate the space to also offer extlinux.

But if an extension is created then the user could be given the option of syslinux, or extlinux and newer versions of these programs could be more easily handled. Seems extlinux offers some advantages that should be considered.

Posted by roberts on July 22 2007,02:42

Quote

BTW, jwm is much more convenient with a top-down tray. That way the menu also starts with the apps where the cursor is rather than having to move all the way up past exit, etc.

The top placement is nice!
BTW, What is the difference than just setting the x=0 and y=0 ?

With the tray at the top, I like the desktop icons along the bottom. Select left->right, bottom->up and then update or sort.

Very flexible.

I am open to trying different layouts during the alpha cycle.

Posted by Juanito on July 22 2007,03:42

Quote

Thinking about this more, I am inclined to remove the pendrive installation scripts from core and more to a MyDSL extension.

A nice idea, but I'd be concerned that this would create a barrier to entry for new users wishing to boot from USB. At present you need to figure out how to burn and boot a CD and then select from a menu - if in addition you had to figure out how to find and download an extension, it might be a step too far...

Posted by Key on July 22 2007,06:07

Quote (lucky13 @ July 19 2007,16:46)

Quote

What else can I try?
Will you add SATA support to DSL 4.0 as well?

Try setting ATA/IDE in your BIOS to legacy (from enhanced; this disables SATA) and see if that helps.

I remember this BIOS "ATA/IDE" setting from an older computer, when SATA has recently been introduced.

On an ASUS Pundit P1 AH2, there is unfortunately no such Bios adjustment possible.

I don't know where to adress this issue to

Adress it do DSL 2.1 b or ask for a 100% working SATA support in DSL 4.0 ?

At the moment, I only see the possibility to boot the live-CD on an older computer with ATA/IDE. Burn the data to an USB-drive and try again on the new computer. But I am of course interested to know, if there is a possibilty that the final 4.0 version will have full SATA support?

I have the following drive:
Samsung SH-S183A SATA beige bulk (SH-S183A)
Maybe this information will help?

I am the only user having problems with SATA support in DSL 2.1 b ? Maybe it could work in DSL 4.0 with the even newer kernel ? I am a little bit disappointed, as it still doesn't run and I have to wait and hope ..

But it seems currently, that I am the only DSL user having an SATA drive and a bios where no "old" compatibility adjustments can be made. Hmmmmmmmm ...

Posted by roberts on July 22 2007,07:06

Without owning any SATA hardware to test, I can only direct you to try a few things...

DSL v4.0 has the kernel supplied SATA modules available during boot as shown in the boot time available modules:

[/tmp]# ls mroot/modules/scsi/
BusLogic.o aic7xxx.o gdth.o modules.lst sata_nv.o sata_via.o ultrastor.o
NCR53c406a.o ata_piix.o hptraid.o ncr53c8xx.o sata_promise.o sata_vsc.o usb-ohci.o
a100u2w.o ataraid.o ide-cd.o ohci1394.o sata_qstor.o sbp2.o usb-storage.o
advansys.o atp870u.o ide-scsi.o pas16.o sata_sil.o seagate.o usb-uhci.o
aha152x.o dtc.o ieee1394.o pci2000.o sata_sis.o silraid.o usbcore.o
aha1542.o eata.o initio.o pci2220i.o sata_svw.o t128.o wd7000.o
aha1740.o ehci-hcd.o libata.o pdcraid.o sata_sx4.o tmscsim.o
ahci.o fdomain.o megaraid.o psi240i.o sata_uli.o u14-34f.o
[/tmp]#

When you are dumped to a limited shell try:

insmod /modules/scsi/libdata.o
insmod /modules/scsi/ahci.o
insmod /modules/scsi/ata_piix.o
insmod /modules/scsi/sata_??

See if you get a hit.

HTH

Posted by ^thehatsrule^ on July 22 2007,07:55

Drive shouldn't matter, it's probably a problem with your chipset (some variant on nforce 5...)
Looking in sata_nv.c it looks like there are some references to it...
Web search shows: < http://http.download.nvidia.com/XFree86....ms.html > ... so maybe try "acpi=off noacpi"

Posted by Key on July 22 2007,08:51

Thank you for this information.
I have tried again.

Also I have noticed, that it is possible to use " dsl sata " in DSL 4 alpha as boot parameter. Nevertheless, no difference to DSL 2.1 b.

Enclosed, I will show you what was shown on the display:

..

Checking for SATA....
None.
Scanning for USB devices.... Done.
Can't find KNOPPIX filesystem, sorry.
Dropping you to a (very limited) shell.
Press reset button to quit.

Additional builtin commands available:
cat mount umount
insmod rmmod lsmod

knoppix# insmod /modules/scsi/libdata.o
insmod: /modules/scsi/libdata.o

knoppix# insmod /modules/scsi/ahci.o
/modules/scsi/ahci.o: init_module:
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

knoppix# insmod /modules/scsi/ata_piix.o
/modules/scsi/ata_piix.o: init_module:
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

knoppix# insmod /modules/scsi/sata_nv.o
insmod: a module names sata_nv already exists

knoppix# insmod /modules/scsi/sata_via.o
/modules/scsi/sata_via.o: init_module:
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

knoppix#

//

I will try this thing with "acpi=off noacpi" next

Edit:

Also no success with the boot option " dsl acapi=off noacpi sata " only that it is slower, but with the same result.

The latest Knoppix Live CD is running without problems.
Is it still an issue with the 2.4.xx kernel ?
Maybe I should have voted for the 2.6.xx kernel

Will DSL-N also be continued ?

Posted by lucky13 on July 22 2007,10:34

Quote

BTW, What is the difference than just setting the x=0 and y=0 ?

It's on bottom of that page -- valign and halign in the Tray attributes:
If anyone wants to change the tray to appear on top, edit the line beneath “additional tray attributes” that has x and y coordinates so it’s like this:
<Tray valign="top" halign="center" height="24">

Then it's just a matter of adjusting torsmo's y coordinate to 26 for a little "headroom."

Posted by lucky13 on July 22 2007,13:25

Quote

With the tray at the top, I like the desktop icons along the bottom. Select left->right, bottom->up and then update or sort.

I did that and I like it for the most part. I'd post another shot but my host is down. Again.

Posted by lucky13 on July 22 2007,19:59

I just posted a low quality video at youtube showing the convenience of a simple shell wrapper (to change backgrounds) for tedious tasks in DSL 4.0. I'm still going through my wrappers from rox and I hope some of you will be inspired to contribute better scripts than I tend to write.

(Sorry, partially nsfw from 43-57 seconds.)

< http://www.youtube.com/watch?v=3sKpdZZe7Z8 >

Posted by Juanito on July 23 2007,09:03

Now that emelFM is gone (or at least I cannot find it), it's not so obvious how to change the permissions on files, change files to executable, unpack tar.gz and extensions, copy files to folders owned by root, add files to .filetool.lst, etc, etc

Is there an easy way to do all of the above (i.e. not from a terminal window) in DSL-4 that I'm missing?

Posted by lucky13 on July 23 2007,12:17

Quote

Is there an easy way to do all of the above (i.e. not from a terminal window) in DSL-4 that I'm missing?

Right click on the file. Choose options. A box will open with details about the file. At the bottom is a series of boxes that should look familiar if you set permissions from emelfm. Click apply before exiting.

edit: See the menu additions I suggested earlier to re/start dfm between users dsl and root.

Posted by Juanito on July 23 2007,12:23

Quote

I tried this, but if the file is owned by root then setting the permissions will have no effect - is there a DSL-4 equivalent of opening emelFM as super-user?

Posted by lucky13 on July 23 2007,12:32

Quote

is there a DSL-4 equivalent of opening emelFM as super-user?

Posted by mikshaw on July 23 2007,14:15

Quote

<Program icon="filemgr.xpm" label="re/start dfm">sudo killall dfm && dfm</Program>
<Program icon="filemgr.xpm" label="re/start dfm - su">killall dfm && sudo dfm</Program>

This seems like a strange way to control a file manager, unless it's a situation where multiple instances of the program will cause problems.

Posted by lucky13 on July 23 2007,15:31

Quote

This seems like a strange way to control a file manager, unless it's a situation where multiple instances of the program will cause problems.

Let me explain my rationale. I don't know how well multiple instances play with each other if one rules the desktop and the other is a filer window. What I do know is there's no difference in appearance between the two instances (root, any other user). My own preference is to cycle completely between the two so there'd be less confusion between root/dsl dfm instances, e.g., mistakenly making changes in a root instance and then having an issue with permissions later. Maybe there's a way to change the background in a root window so it's red or something different (rox windows note if the user is root); I didn't see any options to set up any kind of distinction like that (other than perhaps setting an su option to open in details mode or something?) and I'm comfortable with the way I chose to handle it. I know when I switch to root and I know I have to switch back.

What would you suggest instead?

Posted by mikshaw on July 23 2007,18:21

I haven't even seen the newest changes yet, since I had only just downloaded 3.4 when the 4.0 alpha was released, so I have no idea how the file manager works. The only thing I thought was odd was that your method seems to insure that you can't run more than one file manager simultaneously.
My personal preference is to have some visual clue, such as the background color you suggested, because I *always* have midnight commander opened. Then on those times when I want mc as root I'll open a second one. I typically keep the default ugly blue background for the root mc, and use transparent background on the normal one.

Posted by lucky13 on July 23 2007,19:42

mikshaw:

Quote

I haven't even seen the newest changes yet, since I had only just downloaded 3.4 when the 4.0 alpha was released, so I have no idea how the file manager works.

It's set up so dfm manages the whole desktop. I just checked and I can open a filer window for dfm as su, but by default it opens to /home/dsl without anything signifying it's as su. There are no visual clues between instances so careless dragging and dropping between the su instance and any other (dsl on the desktop) instance can result in permission issues.

Those menu items I suggested will only kill and restart dfm, not any other file manager. I think that's the easiest solution since dfm controls the desktop and there's nothing to distinguish between root filer windows and user filer windows.

Since you haven't seen it yet, here's a basic screenshot (with my aesthetic tweaks):
< http://lucky13linux.wordpress.com/dsl-related-pages/dsl-40-screenshot/ >

And here's my crappy video of the desktop in action (I was way too conservative with my recording settings):
< http://lucky13linux.wordpress.com/2007....nd-drop >

JUANITO:
Another solution for you is to set up a script to open a filer window as root, such as

Code Sample

#!/bin/sh
exec sudo dfm

Give it a distinctive name like sudodfm so you'll know you're launching it as root. Then chmod it +x and set it wherever it's convenient for you. There won't be any signs that it's root, though, such as there was with emelfm (root@host in bottom left corner) so you'll have to remember which one is root and which of your others, if any, isn't. That's why I still prefer setting a killall in the menu or in a script and then running it all as one user or root.

Posted by roberts on July 23 2007,20:05

As with anything new, a learning curve. Just as the buttons and their code snippets did not exist on the initial emelfm.

Add2Filetool

#!/bin/bash
echo "$1" >> .filetool.lst
beaver .filetool.lst

Set the binary icon then drag and drop!

SuperPerms
#!/bin/bash
sudo dfm -setfile "$1"

Set an icon then drag and drop to change a file's permissions.

These will be in alpha2 and others I am sure

Posted by mikshaw on July 23 2007,23:00

Your explanation and screenshot cleared up a lot for me.
For my own tastes I think I would still continue to use mc as root's file manager, even if I was using dfm

Posted by builder on July 24 2007,02:53

I hate to say it but?
Alphfa 4 was not worth the dialup download.
MC sucks!!!!
I wrote better apps in dbIII.fox an Clipper back in the 1980's
Get real. I'm done with the obsolete 50 meg crap!

Posted by lucky13 on July 24 2007,14:39

Quote

I hate to say it but?

I probably shouldn't dignify this since it appears to be a feeble attempt to troll, but there are some things that need to be said in defense of the direction DSL is taking.

Quote

Alphfa 4 was not worth the dialup download.

It's alpha, not beta or official release. I don't know what your expectations were when you decided to download it, but Robert's notes make it clear that it includes an upgrade to a recent kernel and various changes targeted at making DSL more user-friendly by integrating desktop icons and file management via dfm. This gives DSL users more flexibility right off the CD. It also makes DSL more familiar in operation to people who aren't as experienced with Linux. These are good things.

It's also a good thing that DSL isn't making radical changes that will disaffect its veteran users. These are moderate measures that should appeal to a wider section of users. You can't make these kinds of compromises without potentially alienating users who want one thing instead of another, but I think Robert has done an excellent job of making things more accessible and fresher while remaining true to the DSL philosophy. These are reasonable changes and show that DSL continues to improve, evolve, and modernize (i.e., its new kernel) while remaining free of bloat.

Quote

MC sucks!!!!

Different strokes for different folks. Many of us use and appreciate midnight commander, and I'm sure there are many others who will want emelfm.dsl ASAP. As far as your ouburst goes, DSL uses dfm as its base file manager now, not mc, so I don't understand why you're having a tantrum. Other file managers are available in MyDSL, from apt-get, or you can compile from source if dfm and mc are inadequate for your needs.

Quote

I wrote better apps in dbIII.fox an Clipper back in the 1980's

Why don't you convert them over for use in Linux instead of reveling in your glory days from two decades ago?

Your blanket criticism of DSL 4 lacked any constructive feedback. That's the purpose of pre-release versions -- to find bugs, get feedback, etc., to benefit official releases. Maybe you'll keep that in mind should you ever download alpha/beta versions in the future.

Posted by humpty on July 24 2007,18:40

(frugal)
I just had a go. These are just first impressions.

bootup:
chown: /home/dsl/.dfmdesk/MyDSL/MyDSL/ no such file or directory.
chmod: /home/dsl/.dfmdesk/MyDSL/MyDSL/ no such file or directory.
chown: /home/dsl/.dfmdesk/MyDSL/ no such file or directory.

invalid device hdc1
(2nd compact flash on hdc1)

so I try to mount it manually,
(relocation error: mount : undefined symbol: blkid_known_fstype.

Clicked a bit in DFM. This made me say goodbye to the learning curve and went straight into fluxbox. The resolution degraded to 640,480 i think. No problem, found xsetup and all was ok.

Boy do I miss those single click icons. Icons make the world go 'round. Loaded up some extensions but I couldn't find a way to auto load the icons to the desktop.

Went back to DFM cos I couldn't find emelFM. Thought I'd give it
another chance. Getting used to it now. Have to manually create desktop icons for the extensions. Couldn't they be auto created?

Tried to create a folder in DFM, did not turn up on desktop?

Some files not shown in boot directory (/mnt/hda1). Had to
switch to 'detailed' mode and then back to 'normal' mode to see
them.

I dunno, this menu/right-click bias maybe too minimalistic for newcomers. It involves a lot of searching. I like the old setup,
where the user gets everything on his plate, and has the choice to minimise himself.

I like the drag/drop though. Is there no other alternative to DFM? Fluxbox is not so easy to setup now.

Posted by roberts on July 24 2007,20:53

I would strongly suggest to run from a live CD and learn about the new system, rather than to try to boot into an existing DSL environment.

For your first encounter you should boot

dsl base norestore

The extensions are handled differently in that everything is in the MyDSL folder. The download program, the extensions, both as packages( uci, unc, dsl), shown as a closed box icon, and as an application ready to run, shown as an opened box icon. Even the download program is in this folder. It is true, that currently, all extensions share a common, closed box and opened box icon. Currently that is only because every icon would need to be resized from every extension in the repository.

Frugal does work! in fact I only use frugal and have not experienced such problems. This may be alpha1 but it is not THAT alpha. I would not release it, if I could not use it, as I typically do.

I suspect, that you may be using frugal on a DOS/FAT filesystem, in which case unix permissions are not supported and would likely cause issues with the new system. We need to progress away for relying on FAT and be able to deploy unix permission. Otherwise, I might as well as do the "run eveything as root" mindless dance.

For fluxbox users I have in the Getting Started document explained how to access the menu and even change its access priorities. Everyone needs to read the new Getting Statrted document.

If you prefer fluxbox then your first testing of the system would be:

dsl base norestore desktop=fluxbox

If you hate icons

dsl noicons

If you want only to use X, fluxbox, noicons, and love MC

dsl desktop=fluxbox noicons

As I have stated int the Getting Started document. while using dfm for icons and file management, then fluxbox menu is available to the very bottom edge of the screen via the standard right click. If you don't like this default behavior, then toggle the dfm root menu off. DFM for X11 -> Desktop context menu. When toggled off, then fluxbox's menu can be accessed as before. Toggle back on by right click on any icon, select again DFM for X11 -> Desktop context menu.

We have double click to support drag and drop and easier user control of the desktop and integrated file managment.

If you are bold and want to try a menu-less system, then try

dsl desktop=swm

SWM a minimal resource WM, uses Alt-tab between windows, Ctl-tab between the 4 workspaces. This provides the maximum performance on low resource machines as well as providing maximum use of limited display screen system. And finally also provides a more RISOS type of feel.

DSL 4 opens with very few icons. The first task should be copy icons to your desktop. Your choice, its your system.

DSL 4 provides even more operating choices than before, it is more dense than ever before.

As I said in the opening announcement, DSL v4 is very different. I have not made such bold changes in UI since the beginning of DSL now almost 4 years ago.

I also realize that after 4 years of the same operational mode, a large change like this can be daunting.

Posted by humpty on July 25 2007,00:26

I'm not sure doing away with FAT is a good idea. I will try formatting with ext2 later. But I did not have any old backup.tar.gz present. Although I did boot from FAT using loadlin and I did have all the extensions in mydsl folder (perhaps I should rename it to MyDSL?) Surely, If the uci's and unc's are mapped to the base system, the permission of the actual source shouldn't matter(?)

Perhaps the extension loader could do the resize, it would not
waste the the icons of the old extensions?

Anyways, I'll try the live CD boot first.

Posted by rja on July 25 2007,04:35

Quote (Key @ July 22 2007,03:51)

Will DSL-N also be continued ?

DSL v4.0 alpha1 can start the boot with my SATA DVD drive, but it cannot load the Knoppix image. I ended up copying the image to a SATA hard drive, so I can get it to boot, but the DVD drive is not available after sata_nv.o gets loaded.

With Fedora 7 and a 2.6.22 kernel, I boot with "combined_mode=libata", but that did not help with DSL v4.0 alpha1. I also tried adding "libata.atapi_enabled=1", but that did not help, either. I noticed that there are fewer options shown with "modinfo libata" in the DSL version.

This is on an Nvidia 650i SLI based Abit Fatal1ty FP-IN9 SLI so it uses the sata_nv.o module.

When I boot, with:

boot: dsl dma base norestore sata

It boots like Key's example, but after:

Checking for SATA...

It displays:

Loading sata_nv.o.
Done
Scanning for USB devices... Done.
Enabling DMA acceleration for: hda [something]
Enabling DMA acceleration for: hdb [something]
Accessing DSL image at /dev/sdb1...

because I had copied the image to the root of my second SATA drive. After that, everything comes up normally, except for the SATA DVD drive which cannot be accessed.

Key, can you check which SATA controller you have when you run the Knoppix live CD? Try running "lspci" and see if there are any "Serial ATA Controllers".

Posted by andrewb on July 25 2007,04:44

Dmesg reports that the Kernel was compiled with gcc 2.95.4. The version of gcc in the repositry is 3.3.4. This is causing me problems trying to compile the latest madwifi modules (& would presumable do so for other modules) as the version numbers of the compilers as not compatible. Can there be some synchronisation of the compiler used to compile the kernel & the one in the repository.

Posted by ^thehatsrule^ on July 25 2007,04:53

I seem to remember a naming convention problem with sata... (hd* vs. sd*) Not sure if that's the cause of these problems though.

andrewb: did you try the gcc 2.95 extension?

Posted by roberts on July 25 2007,04:56

Madwifi 0.9.2 is the latest stable and that is in DSL v4.0.

Posted by Juanito on July 25 2007,05:02

This is not neccessarily a DSL-4 specific question, but what should the permissions/ownership be on the various files/folders created for an ext2 USB boot? Does it matter? I cannot check those created by the USB-HDD install script since these are for a FAT installation:

/KNOPPIX/KNOPPIX
/mydsl
/lost+found
boot.cat
boot.msg
extlinux.conf
extlinux.sys
f2
f3
german.kbd
linux24
logo.16
minirt24.gz

Posted by roberts on July 25 2007,05:37

root root /KNOPPIX/KNOPPIX
dsl staff /mydsl
root root /lost+found
root root boot.cat
root root boot.msg
root root extlinux.conf
root root extlinux.sys
root root f2
root root f3
root root german.kbd
root root linux24
root root logo.16
root root minirt24.gz

Posted by Big_Pc_Man on July 25 2007,13:43

I'm not sure this is the right place for this question but here goes:

In dsl 3.4 I was not not able to create a usb pendrive system using the apps/tools/install to usb-zip or hdd when the usb device is a 20G usb harddrive. Before I get started testing 4.0, could someone please advise me as to the possibility of using a "real" usb hdd in 4.0. The usb-zip approach works great for usb sticks since it automatically creates two partitions. Once the second partition is formated with mkfs it becomes a versatile persistent storage area for things like xampp ( /opt and /home). It would be great if dsl 4.0 allowed the usb-zip second partition to be any size.

Posted by Juanito on July 25 2007,13:53

Assuming that DSL would treat a USB HD as a USB stick, you could always install DSL manually - this works for large (>512MB) USB sticks formatted FAT, FAT32 and ext2 - then you can create partitions(s) to suit your needs. Note that you would need to use syslinux or extlinux from one of the DSL extensions if you wish to use FAT32 or ext2.

Posted by curaga on July 25 2007,14:25

Of course grub is also an option..

Posted by Big_Pc_Man on July 25 2007,17:11

I wonder what causes the partition size limitations on usb-zip?
This would seem simple to fix.

Posted by lucky13 on July 25 2007,20:22

Robert:

Quote

And finally also provides a more RISOS type of feel.

You might be interested in this interview with Thomas Leonard about rox:
< http://www.drobe.co.uk/riscos/artifact2002.html >

Posted by roberts on July 25 2007,22:02

Quote (lucky13 @ July 25 2007,13:22)

Robert:

Quote

And finally also provides a more RISOS type of feel.

You might be interested in this interview with Thomas Leonard about rox:
< http://www.drobe.co.uk/riscos/artifact2002.html >

As you know, I was ready to do a Rox/DSL system. I have developed a prototype. However, I have just too much legacy stuff to support to continue its development.

Also, as I have mentioned, all the additional directories, cause excessive inode use, which impacts the very very low memory systems. I would not be able to support these very low memory systems.

Also you can see, some of the feedback on DSL 4, from long time DSL users is not glowing. To change the UI after 4 years is difficult. Even though there are boot options to make the impact minimal. If I had done only a Rox/DSL I think I would lose many traditional *nix users.

Given both of the above situations and having spent the time to prototype Rox/DSL inspired me in my implementation of dfm and my xxx.app wrappers to emluate a Rox-like DND experience using the dynamic loadable MyDSL extensions.

I could have certainly gone off in another direction, using only UCIs, a natural for Rox, do a live CD Rox/DSL. But I would lose to many users and small machines.

There are parts of Rox that I do not especially like. For example, every program executeable is named AppRun. You use the directory name to find the actual executeable. My spin was to use xxxx.app, so that I can still easily use my unix tools to find executeables. I also do not like large taskbars and pagers. I like to save screen real estate for the task at hand. I have many small screen systems. The latest Rox is all Gtk2 and that is even more bloat.

What I have tried to achive with DSL 4.0 is to cover the spectrum of operational use from application centric to document centric.

Prior DSL versions where application centric, i.e., menu driven. Icons were only a convenience as application "start" buttons.

DSL 4 still supports this application/menu driven mode. But I wanted to introduce document centric/icon/DND mode of operation. I want to have this implemented as far as possible, i.e, no "application menu" needed (swm).

Having to support all previous operating and installation modes of DSL is a challenge, while still supporting the smallest of machines that were previouly supported and remain under 50MB. As well as still be able to leverage the MyDSL repository.

I don't want to bloat up. I don't want to be a small distro that requires 128MB+ to operate. Even if THAT (128MB) is new low-end machine.

And partly, I just wanted the challenge to try to implement this within the existing framework that I have built upon over the last 4 years.

Perhaps, it is time to make DSL bigger. But I am still having fun with this one. Perhaps a larger one will be based on this one. For now, lets work to improve DSL 4 and its many modes of operation.

Posted by lucky13 on July 25 2007,22:20

Quote

There are parts of Rox that I do not especially like. For example, every program executeable is named AppRun.

That's the part that's driving me crazy now, as I'm pulling my AppRuns from wrapper AppDirs and renaming so they can be used for dfm. I posted another video showing my shredder in action in DSL 4:
< http://lucky13linux.wordpress.com/2007....r-video >

Quote

I want to have this implemented as far as possible, i.e, no "application menu" needed (swm).

That definitely will be more RISCOS-like than using fluxbox or jwm. I haven't tried swm, but it sounds like it has almost as many features as oroborus.

Quote

Perhaps, it is time to make DSL bigger.

Heresy!

Quote

Perhaps a larger one will be based on this one. For now, lets work to improve DSL 4 and its many modes of operation.

I'd rather see DSL-N pick up where we left off since it's tied to being bloat-free rather than having a specific base size limit. I don't think DSL needs to grow to maintain its relevance and utility -- you've already proven that. Moving DSL-N along a rox-ish path would make more sense to me since it already has GTK2, could justify using python instead of lua, etc., and that way the legacy DSL users won't be put off. It could be a clean slate using CRBs.

Posted by rja on July 26 2007,22:00

I think that the problem with using an SATA DVD-ROM/CD-ROM is that the libata module for 2.4.34 needs atapi_enabled=1 before the drive will be recognized.

I guess that it will need to be added to the miniroot.gz so that the DSL image can be found on a SATA CD-ROM drive.

This page has some info on this for the 2.6 kernel:

< http://www.thinkwiki.org/wiki....ognized >

Posted by roberts on July 26 2007,22:39

DSL v4 is not using a 2.6 kernel.
However, interesting about the nopobe option, i.e, does

hdc=noprobe

or

hdc=noprobe hdc=cdrom ide1=0x170,0x376,15

help?

Posted by Key on July 27 2007,04:53

Quote (roberts @ July 26 2007,18:39)

DSL v4 is not using a 2.6 kernel.
However, interesting about the nopobe option, i.e, does

hdc=noprobe

or

hdc=noprobe hdc=cdrom ide1=0x170,0x376,15

help?

I will try it this afternoon ( european time

).
Thanks for this information.
Hope there is a way to get DSL 4 running soon from a live-cd on a SATA based DVD/CD-drive.

Posted by Key on July 27 2007,15:30

Quote (Key @ July 27 2007,00:53)

Quote (roberts @ July 26 2007,18:39)

DSL v4 is not using a 2.6 kernel.
However, interesting about the nopobe option, i.e, does

hdc=noprobe

or

hdc=noprobe hdc=cdrom ide1=0x170,0x376,15

help?

I will try it this afternoon ( european time

).
Thanks for this information.
Hope there is a way to get DSL 4 running soon from a live-cd on a SATA based DVD/CD-drive.

No difference, beside the fact, that it even takes longer time till the (very limited) shell appears.

I have tested again the following CD-roms with the following results:

Knoppix 3.1 beta > CD stopps without a message (?)
Knoppix 3.3 > Same result as DSL 4 alpha
Knoppix 3.82 > Same result as DSL 4 alpha
Knoppix 5.1.1 > Runs without a problem, all the hardware is recognized automatically without any boot-parameters.
DSL-N 0.1 RC4 > Seems to work, but the mouse pointer dosn't move, therefore no possibility to do further tests after completed boot.

Further ideas how to get DSL working on SATA machines ?
Or will DSL-N be continued in parallel to DSL 4 ?

Knoppix 5.1.1 and DSL-N 0.1 RC4 show the following message during boot:
" accessing cdrom at /dev/sr0 .. "

Posted by ^thehatsrule^ on July 27 2007,16:27

that's due to them using the 2.6.x kernel

Anyways, as I have previously suggested, you can try using dsl-initrd versions for now (though you'll probably have to make your own if you want to use 4a1)... it'd probably be easier to test out modules from there too.

Posted by Key on July 27 2007,17:31

Quote (^thehatsrule^ @ July 27 2007,12:27)

So you think there is no possibility to get the ordinary DSL 4 live-CD with 2.4.x kernel running on my new computer with SATA?

Unfortunately I do not know anything about dsl-initrd.
Maybe I should check in the forum.
But I am looking for an easy way.

Otherwise I will use my old computer to bring the data from the live-CD to an USB memory stick.
But this is what I would prefer more when the final version is available.

How easy is it to exchange the kernels ?
E.g. remove 2.4.x and add 2.6.x ?
Don't know their compatibility.
Must the surrounding code be rewritten completely for each new kernel?

Posted by roberts on July 27 2007,17:36

After reading articles and posts from Linux kernel developers, I think I am about to go mad.

First we have Con Kolivas, who claims 2.6 Kernel development favors servers and/or huge machines not at all typical of real world desktop users. Then we have the announcement from Willy Tarreau on kernel 2.4.35, in which he states, no backports to support newer hardware, laptops, etc will be accepted. That kernel 2.4 is really for servers and firewalls. He suggests that desktop users go to kernel 2.6.

=> <=

Apparently, we are experiencing the lack of backports to the 2.4 kernel with both SATA and ipw2200.

And now with the 2.4 maintainer proclaimming no such backports will be accepted. Seems I have been toling away for very little forward progress in advancing hardware support with a newer kernel.

Someting to think about.

< Con Kolivas on 2.6 Kernel >

< Willy Tarreua on the 2.4 Kernel >

Posted by Juanito on July 27 2007,17:47

Quote

Apparently, we are experiencing the lack of backports to the 2.4 kernel with both SATA and ipw2200

Not to mention bcmxx, cpufreq, drm/i915 and uvc...

There maybe a chance for drm/i915 if I can figure out how to make git use mesa/drm from two months ago and recompile the kernel with CONFIG_X86_CMPXCHG set.

Posted by lucky13 on July 27 2007,19:13

There's no confusion. I can empathize with Con Kolivas' feelings, but has he been able to substantiate that his patches are improvements in how 2.6 works on desktops? I hate to say it sounds like sour grapes, but it sounds like sour grapes.

As for 2.4 development, what I read and how I intepreted it's not quite so dire:

Quote

I'm open to merge the small updates required to maintain such systems running (eg: PCI IDs and such), but I will generally refuse all patches which add support for new desktop or notebook-specific hardware, unless the people present very convincing arguments.

IOW, older hardware will continue to be supported. If you make a convincing case, changes can be made for *NEW* HARDWARE AND *LAPTOP* SUPPORT. That's not unreasonable. You don't need to backport support for every piece of *new* hardware. Improvements can continue to be offered for older hardware.

I don't blame him. Look at all the dross being thrown into both kernel streams as it is. How the hell does supporting trivial stuff like "splash" improve interaction between kernel and hardware? All it does is mask it! That kind of crap belongs in userspace (and in operating systems that hide everything else like code from users), not built into a kernel or supported by it (compare LOC of Linux 2.6 and Linux 2.0 and then Minix 3). How long has DSL resisted updating kernels and even once reverting to an older kernel after updating? Isn't part of the reason size of newer kernels?

From my perspective, it's only logical that kernel development will move beyond supporting older architecture like i386 and i486 (as there are fewer and fewer of those machines) and that lines have to be drawn between what's supported in 2.4 and 2.6 just as there were when previous kernel lines were deprecated. There's a limit to how many new features should be backported because it's unlikely and impractical.

As far as Kolivas goes, the basic architecture support is the same on an i686 whether it's used in server or on a desktop, and the kernel can be custom configured to suit needs whether it's desktop, cluster, or in an embedded device. It's the job of a distro to make Linux suitable for specific uses (desktop, server, embedded, cluster), not of the kernel development team. Kernel developers can make the job easier of those configuring kernels for particular uses.

Who wins? Desktop distros? Linux doesn't have much marketshare in desktops as it is. It's also the view of the kernel development team that the desktop isn't the future; the desktop is rapidly becoming the past as it increasingly gives way to mobile devices. I'm sure there are mobile device vendors (like Palm!!) who wish more of their own submitted patches were included to make their jobs easier, too. The place where Linux actually prevails is in servers. That's where the biggest demand is and remains for kernel development. That's why there's a bias towards server performace. I disagree with Kolivas, though, that it's exclusively at the expense of desktop or mobile performance and that it's an either-or situation. All he's done by quitting is make it more difficult for his position to prevail.

Posted by rja on July 28 2007,05:48

I'll try to add some positive info to this post.

DSL 4.0alpha1 DOES boot with the "sata" code and detect my sata_nv controller and two SATA disk drives.

I added a IDE DVD-ROM drive to make it easier to test. I should have done this earlier so that there aren't too many variables at the same time.

When it boots, after the messages:

Checking for SATA....
Loading sata_nv.o...

Then, the word "Done." is written on top of the "Loading sata_nv.o..." line. It would be nice if the "Done." doesn't have a carriage return in front of it.

Then, it turns on dma, detects the ide cd on /dev/hdc, and boots up correctly.

Key, I think that your motherboard is also based on an Nvidia chipset, so you may be able to see the:

Loading sata_nv.o...

message before the "Done." message overwrites it, and dsl fails to find the KNOPPIX image on the CD.

If you see that sata_nv.o message, then you could use the knoppix cd to copy the dsl image to one of your SATA drives and it will be able to boot that way. It won't be as easy as using a live cd, but you could try out the other new features of dsl-4 that way.

Another thing that worked is the Nvidia gigabit ethernet with the forcedeth driver, so PXE booting might be another way to get it running.

I should have explained more about why I added the link about the 2.6 version of the drivers. It had an example of adding the atapi_enabled=1 option for the libata module to an initramfs, and I don't know how that is normally done under Debian. I thought that this might be an example of how to do that. Since that page is about 2.6 kernel versions and the Intel SATA driver, it wasn't a good choice to use it. My problem was that I couldn't get any hits on google for 2.4.34 kernels with SATA controlling an ATAPI device.

Oh, I forgot to mention that I tried all of those hdc=noprobe combinations, and none of them helped.

Posted by curaga on July 28 2007,07:11

Con did make some good points about why it's at the expense of desktops.

For configuring your kernel for your needs, you cannot select the cpu scheduler (can in -mm..) like you can select the i/o scheduler. Thus the one sharing cpu power is always geared for servers. The -ck patchset added a fairer cpu scheduler, better for desktops..

-- probably out of topic, but I did change to kernel 2.6.20.14 when I turned DSL 3.4 into a customized webkiosk for nipun.. I had to, besides compiling and moving to right places, edit linuxrc and later init scripts mostly for module names, but also some other things. Generally it went quite painlessly..

Posted by Key on July 28 2007,07:56

Thank you, rja.
This gives new hope.

I have checked for this " Loading sata_nv.o... " message,
but the boot-procedure is too fast for looking on it.
With my previous sent posts, I assume that it is loaded as well on my computer.

Nevertheless, I have checked for my mainboard specifications, which are as follows:

North Bridge: nVidia Crush 51PV
South Bridge: nVidia MCP 51
2 x SATA II
Phoenix - AwardBIOS v6.00PG
ASUS M2N8L ACPI BIOS Revision 0301

Unfortunately, there is no possibility to change to a native mode, as I remember from an older mainboard with SATA support.

As I am only a Linux user with a limited knowledge of the Linux / Knoppix / DSL - system technology, I would appreciate it, if you could explain step by step:
- Which file(s) copy from where to where?
- And how to access these files from where in which order?
Please give some more informatiom.

Nevertheless I still hope that the 2.6.x kernel will also be supported again in the future. Yes, I have voted for a new kernel 2.4.x as I thought that it will support SATA and network cards as well as the 2.6.x kernel does. But it seems that the support for 2.4.x is very limited and only older units will get full support. It is a pity.
DSL is the best distro for my purposes, as it allows me to bring it from a live-cd to an usb memory-stick in an easy way.
This is the main reason why I prever using DSL.
Also of course because of its modules and its "classic" look.

As already written, I do not know anything about Linux programming nor about the Linux system technology.
Isn't it possibly to do releases with both kernels, 2.4.x and 2.6.x, or does this mean a complete re-programming?
Just in order to have a better understanding.
Thank you in advance.

Posted by lucky13 on July 28 2007,11:58

Quote

Con did make some good points... The -ck patchset added a fairer cpu scheduler, better for desktops.

Has he made a bandaid or a really good solution? Measured *how*? Every time I look at a thread dealing with the issue, it boils down to anecdotal reports of better performance.

Quote

I did change to kernel 2.6.20.14

How big was the ISO, or at least the kernel, compared to the 2.4.26 one you replaced? Was it compiled in similar fashion? Or would that be an apples:oranges comparison?

Posted by curaga on July 28 2007,12:23

He had tons of user reports, I felt the difference too when I tried it.. I think he had some sort of benchmark program, but I haven't tried that.. For my experience it went like this:
when I have music playing in X and start Opera, the music stutters once. This did not happen with -ck enabled kernel.. But when I upgraded my kernel, I couldn't get it to boot with -ck, so it kinda left there ;)

Quote

How big was the ISO, or at least the kernel, compared to the 2.4.26 one you replaced? Was it compiled in similar fashion? Or would that be an apples:oranges comparison?

The kernel was bigger, but I was specifically requested for a 2.6 kernel for better h/w support. The kernel was 1.5mb and modules were 12mb, I just checked..
For "similar fashion" I guess you meant did it have as much support. No it didn't; it was for a webkiosk, so anything network related was in, but many filesystems and other stuff not needed were left out.
So comparing them would be an apples/oranges one, as they are for different purposes.

Iso became 93mb, I removed lots of stuff but also added gtk2, firefox2, java, flash 9..

Posted by lucky13 on July 28 2007,15:17

Quote

He had tons of user reports, I felt...

That's what the developers don't want. They want benchmarks that are quantitative, unbiased, objective, etc. Not feelings, not user reports, not "this happened here, but not here." Some criteria that can be presented that shows in black and white that one option is better than another.
< http://www.onegoodmove.org/fallacy/causal.htm >

By way of analogy (only regarding anecdote and not the merits of proposed codes), I can say that one brand of soap doesn't dry out my skin as much as another brand. How do I know this? Maybe I can "feel" some difference. But when I look at the ingredients for both brands, they're virtually identical. So I can start looking at other factors. I tried Brand A soap in winter when the air wasn't as humid as it is now, and now I'm using Brand B (100% humidity today). I feel a difference. Is it the soap or is it the climate?

The same kind of fallacy is true of snakeoil. Take some magical potion or herb (e.g., echinacea) and you won't get sick. Folks swear by it, so it must be true -- at least until there are studies done to see if it really works, and it usually doesn't.

From everything I've read, the empirical evidence was lacking about whether Kolivas' patch had any measurable benefit over any other scheduler. The developers wanted more than "I clicked on this and it stuttered, but I applied the patch and now it doesn't." That's why his scheduler code wasn't (yet) mainlined.

See this also:
< http://kerneltrap.org/node/14008 >

I strongly disagree with Kolivas' position that desktops are abandoned by 2.6+ development trends. This is like saying that Microsoft abandoned desktops by releasing Server 2008 and CE. With either OS, you have basically the same kernel and code base that can be configured in various ways to suit particular needs. These are, for lack of better ways of explaining, one-size-fits-all. They're just custom-tailored for servers, desktops, and mobile devices. With respect to Linux, that goes beyond distro-compiled kernels and includes custom patches like -ck, grsecurity, etc.

Excluding Kolivas' code from mainline does NOT mean Linux is taking a server-only approach -- it means Linus and other developers aren't convinced (yet) that Kolivas' approach is necessarily the best or even ready for inclusion. Everything I've read showed they had, for the most part, open minds and were continually willing to consider and review what he was suggesting.

It's now irrelevant if he's really walking away from even developing his patches and continuing to offer them as he has unless someone else picks up where he left off. Some of his ideas will probably be implemented eventually. It just won't be from his efforts.

Quote

Iso became 93mb, I removed lots of stuff but also added gtk2, firefox2, java, flash 9..

I had a hunch it would be in the ~100MB (or more) range.

Posted by Key on July 28 2007,15:34

Nice discussion, but how to proceed now?

Is there no easy way to support both kernels?

As I do not have enough knowledge about the Linux system technology, I do not know how much work and time is required to support both kernels in the same way. Can't they be exchanged easily? Do they have different adresses for different routines?

Posted by curaga on July 28 2007,16:02

@Key: DSL has chosen 2.4, so we won't be supporting both, or 2.6, at least in a while.
Adding it would be relatively "easy", but it would mean extra work for Robert, and as DSL-N already has a 2.6 kernel..

Posted by lucky13 on July 28 2007,16:10

Quote

Is there no easy way to support both kernels?

It can be done -- the Knoppix version which DSL is based had both kernels. It just can't be done in 50 MB.

The easiest and most sensible option seems to be for development on DSL-N to resume for people who need support for newer, more modern equipment. I don't think I want to see DSL become DSL-N and see legacy support dropped altogether. I also think there will continue to be a trickle of unofficial modules to support newer hardware in 2.4. If that happens, there needn't be a debate over 2.4 versus 2.6. If not, there's also no need to debate one or the other as long as DSL-N development resumes.

Posted by Key on July 28 2007,16:26

Quote (curaga @ July 28 2007,12:02)

I see and I agree.

On the other side, there will be more and more newer computers, which have problems with the 2.4.x kernel.
Maybe these problems have not been thought about before introducing the latest 2.4.x kernel version, as it has not been clearly known before, that there is a lack for support of newer hardware.

There are no news for DSL-N since almost a year now and with version 0.1 it seems that it is still in a really early status.

I would prefer exactly the same versions of DSL.
One with kernel 2.4.x (for older computers) and one with kernel 2.6.x (for newer computers), but no separation between DSL and DSL-N.
DSL is so flexible that further software can be added by the user itself afterwards.
I think there is no really need of a special DSL-N, but a need for DSL which will work on all computers.

Is there maybe an easy step by step instruction somewhere available, how the user can exchange the kernel by himself?

Posted by curaga on July 28 2007,16:51

Nope, it is different from system to system..

For kernel compilation there are dozens of guides though

Posted by lucky13 on July 28 2007,16:55

Quote

I would prefer exactly the same versions of DSL.
One with kernel 2.4.x (for older computers) and one with kernel 2.6.x (for newer computers), but no separation between DSL and DSL-N.

No. Nuh uh.

You're suggesting changes I don't think will make anyone happy. Such as moving DSL-N to GTK1 (with GTK2 extensions like DSL now has?) or DSL to GTK2 (with GTK1 extensions?). DSL sensibly has resisted going to GTK2. If I were to switch to DSL-N it would be for its GTK2 support (fortunately for me, hardware support isn't an issue or criterion).

I was about to post a poll in the DSL-N section when you posted this. I'm glad I didn't so I can include another choice.

Posted by Key on July 28 2007,17:04

Ok, I have not thought about this.
I only thought, that this could be a quick and easy way for everybody to have a look at the DSL 4 live-CD

I will check the forum now for kernel compilation.
Maybe I will understand how to exchange the kernels.
At least I will inform myself how this could be done.

Posted by rja on July 28 2007,18:00

Key, if you don't see the sata_nv.o get loaded, then this won't help. It depends on your SATA hard drives being recognized by DSL.

Our problem seems to be that 2.4.34.1 doesn't recognize an ATAPI CDROM on an SATA controller.

There are many ways around this. Copying the KNOPPIX image to a hard drive, installing an IDE CDROM, booting from the network, booting from a USB drive, etc. If anyone has other ideas, please post them. And of course, add any corrections to this if there are any mistakes.

These are the steps to get the KNOPPIX directory copied from the DSL iso to the root directory of one of your SATA drives which has a filesystem that DSL understands. This is similar to booting DSL with a "tohd=/dev/sdb1" cheatcode. After these steps are preformed, when the DSL CD is booted with the "sata fromhd=/dev/sdb1" cheatcodes, it will read the KNOPPIX image in the KNOPPIX directory. For this example, I'll use sdb1, the first partition on the second SATA drive, which already has an ext3 filesystem. I couldn't use my sda1 partition because it has an NTFS filesystem. If you need help creating a hard drive partition with a linux filesystem on it, ask and we can walk you thru that. Since you mentioned that you had booted Knoppix, and that you have two SATA drives on a Nvidia SATA controller, then this should work for you.

Copy the dsl-4.0_alpha1.iso to the first partition on the second SATA drive somehow. In this example, I'll use wget to perform a file transfer. You may already have a copy of the iso somewhere else and can copy it to the partition faster than having to perform the file transfer.

boot Knoppix-5.1.1 CD or DVD

Click on the penguin at the bottom left of the screen next to the K button. Choose the "Root Shell".

Code Sample

root@Knoppix:~# mount /media/sdb1
root@Knoppix:~# cd /media/sdb1
root@Knoppix:/media/sdb1# wget ftp://ftp.oss.cc.gatech.edu/pub/linux/distributions/damnsmall/release_candidate/dsl-4.0_alpha1.iso
root@Knoppix:/media/sdb1# mkdir dsl-4.0_alpha1
root@Knoppix:/media/sdb1# mount -o loop dsl-4.0_alpha1.iso dsl-4.0_alpha1
root@Knoppix:/media/sdb1# cp -R dsl-4.0_alpha1/KNOPPIX /media/sdb1
root@Knoppix:/media/sdb1# umount dsl-4.0_alpha1
root@Knoppix:/media/sdb1# rm dsl-4.0_alpha1.iso
root@Knoppix:/media/sdb1# cd
root@Knoppix:~# umount /media/sdb1

Then shutdown and boot the dsl-4.0_alpha1 CD with:

boot: dsl dma sata fromhd=/dev/sdb1

Plus whatever other cheatcodes you need for your setup. I like to add "secure" so you get a chance to read the messages on the screen before they get hidden.

Posted by ^thehatsrule^ on July 28 2007,18:03

I sympathize with Con's perspective. Using those benchmarks for qualitative results is for server setups anyhow... that's why user desktop oriented setups and problems don't get "seen." However, I have yet to actually use any bleeding-edge 2.6 kernel and no -ck patched kernels either, so I'll leave the arguments for those who have actually used both... (though it does present a pretty convincing case)

From my preliminary tests, _adding_ 2.6.22.1 to DSL 3.4 brought the size to ~70mb. This was by using Knoppix 5.1's (2.6.19?) .config and making everything new a module if possible (and adding things like KVM). Most of the options I have no idea about, but the modules came to ~60mb (currently included is ~20mb). Presumably, you could strip many modules out. The kernel itself is rather big and might not fit on a floppy, but this is just because of the Knoppix config being used.

Key: dsl-initrd just has all of the data.. i.e. KNOPPIX/KNOPPIX in the minirt so that it's all loaded to ram during boot. Probably memory isn't a problem for you since you have that setup

EDIT: just saw the above post...

Quote

Key, if you don't see the sata_nv.o get loaded, then this won't help. It depends on your SATA hard drives being recognized by DSL.

He showed that it was already loaded when he was manually insmod'ing the modules.

Unless it's a problem with his disk drive, putting the data on a sata-based hdd wouldn't really help either since it would go through the same southbridge chipset... but it might if it's some other problem?

Posted by lucky13 on July 28 2007,19:15

Quote

Presumably, you could strip many modules out.

Definitely *can* strip many out. Just look at what's coming in 2.6.23. Does a live CD need Xen? Lguest? HBA/SAN? KVM? I doubt it.
< http://news.zdnet.co.uk/software/0,1000000121,39288166,00.htm >
< http://www.linuxdevices.com/news/NS8736773877.html >

Posted by Key on July 29 2007,14:03

Thank you all for your answers.

Finally I have decided now to use my old computer in order to bring the DSL 4 alpha image to an USB memory stick.
I have choosen the USB-HDD installation and write-protected the USB memory stick after installation.

The results on my new computer are as follows:
USB memory stick has been recognized and the boot procedure did not stop.
There were some errors like I/O errors and SCSI diskerrors shown, but the boot procedure was done completely.

With the first mouse move, a drop-down menu has opened.
Same, but minor problem, as there was alreay in DSL 2.x and DSL 3.x.

Everything looks a bit different now.
I can not say yet, if it is better or if it is worse, as I did not do many tests.
What I have noticed at once, was the fantastic speed and the good access to the menus with the mouse in DSL 4 alpha.

Unfortunately I did not get access to the internet via my onboard network-card. So it seems that I have another problem there with the 2.4.x kernel. On my old computer, I have always got an access to the internet with DSL 2.x or DSL 3.x immediatly and automatically. Although I have tried many entries of the DSL 4 alpha network menu, I did not get access to the internet.

Really strange was, that only the very first boot-procedure of DSL 4 alpha on the USB memory stick was successfull.
After I have choosen "shutdown" I did not get the USB memory stick running again. Now it is always the same behaviour as I had with the live CD in the SATA drive.
Maybe there has been something stored to the harddisk which results to this problem or the USB memory stick became damaged? During shutdown there were a lot of errors (I think SCSI diskerrors) shown (repeating?) which I have interrupted with the CTRL-ALT-DELETE Keys.
I have tested this (remark: still write protected USB memory stick) also on my old computer atferwards, but there it even does not do the first boot steps. There is the message "boot error" from the bios shown at once. Unfortunately I do not know, if it would have been run on the old computer close after the installation, as I have not tested it there before.

Having main problems with SATA and network in DSL 4 alpha, there is probably no other way then using DSL-N. Maybe I will get the mouse working somehow as in DSL 4 alpha and maybe there will also be a newer version again sometimes.

Sometimes I hate waiting, but I think I have to wait now again

Other question:
There are so many users who have done already compilations with 2.6.x kernels in DSL 3.x oder DSL 4 alpha. Is it possible to get them somewhere in the internet? I would like to test it.

Posted by lucky13 on July 29 2007,16:48

Quote

During shutdown there were a lot of errors (I think SCSI diskerrors) shown (repeating?) which I have interrupted with the CTRL-ALT-DELETE Keys.

That's not a good thing to do when shutting down. Remember that Linux is unmounting devices when shutting down. The signal from ctrl-alt-del overrides what the system is doing so your USB stick probably didn't unmount properly. That's probably why it's not loading now.

Posted by Key on July 29 2007,17:11

Quote (lucky13 @ July 29 2007,12:48)

Quote

During shutdown there were a lot of errors (I think SCSI diskerrors) shown (repeating?) which I have interrupted with the CTRL-ALT-DELETE Keys.

There was no other possibility, as it looked like the shutdown hanged in a loop and was showing a lot of SCSI diskerrors scrolling up on the screen.

Maybe I will try again with a new installed usb memory stick, but it does not make much sense as my network / internet is also not working anymore with DSL 4 or kernel 2.4.x on my new computer.

With the quick test I have done, I did not see the mounting tool in the lower right corner anymore. Has it been moved or cancelled? Are all the drives still standardisized as unmounted as it has been in previous DSL versions? I hope so.

Posted by Key on July 29 2007,17:17

Quote (^thehatsrule^ @ July 28 2007,14:03)

Key: dsl-initrd just has all of the data.. i.e. KNOPPIX/KNOPPIX in the minirt so that it's all loaded to ram during boot. Probably memory isn't a problem for you since you have that setup

thehatsrule:
I have 2 GB RAM. This should be sufficient.
Unfortunately I still do not know exactly what initrd means.
What is the difference to the ordinary version and how to use?
Thanks in advance.

Posted by lucky13 on July 29 2007,17:28

Quote

Unfortunately I still do not know exactly what initrd means.

INITial RAM Disk. Here's an overview:
< http://www-128.ibm.com/developerworks/linux/library/l-initrd.html >

Posted by roberts on July 29 2007,22:38

I would like to keep this topic on specifics to dsl-4a1, and in particular bugs in the new user interface.

Specifics to an individual and on released versions of DSL or otherwise general questions and/or wish lists should be started in appropriate topic area(s).

I think it is well established that the newest of hardware may well not be supported with a 2.4 kernel. Lest we not forget that this very matter was discussed when I conducted the poll that resulted in dsl-4a1 being based on 2.4.34.

There is another, almost parallel topic, started under dsl-n (kernel 2.6)

Can we please move on and try to stay on-topic here.

I realize that there are likely not many who are interested in testing alpha level software. I do't want this entire topic to become a blog pertaining to the experiences of using new hardware. The initial questions and proposed solutions were appropriate but now it is move on.

Thanks.

Posted by lucky13 on July 29 2007,23:08

Quote

I would like to keep this topic on specifics to dsl-4a1, and in particular bugs in the new user interface.

Thanks. There are a few more things that need to be changed in .dfmext for file handling. I'll send my updated file to you in the next couple days.

Posted by globalsize on July 30 2007,04:24

This alpha is very spiffy, and I'm glad to be participating.
That said, when I tried to do a traditional install in X (the hd install), xterm closes before the install script gets to the point where it asks which bootloader you want to use. I rebooted and threw "install" at the boot prompt, and using the menu there the install proceeded with no problem (in fact, I'm using it right now on my laptop).
When I right click in DFM, there's a circle drawn on the desktop... not sure what that's all about.
The little CPU usage meter is nice in the bottom right corner, but I think it's best left off by default. With the meter on the desktop, it's a tad redundant. Right-clicking it doesn't get rid of it, and that might frustrate newer users.
Oh, and for Firefox, it would load a bit faster if that RSS feed was pulled from the bookmarks. Just a thought.

All in all, I think the direction for DSL 4 is a good one. Besides the install issues, I could see this being quite palatable for the masses:cool:

Oh, and for reference, I'm using a Toshiba 1555CDS Notebook (380MHz, 190MB RAM)

Posted by lucky13 on July 30 2007,04:58

Quote

when I tried to do a traditional install in X (the hd install), xterm closes before the install script gets to the point where it asks which bootloader you want to use.

I've done two hd installs and haven't experienced that.

Quote

When I right click in DFM, there's a circle drawn on the desktop... not sure what that's all about.

That's normal behavior for dfm.

Quote

The little CPU usage meter is nice in the bottom right corner, but I think it's best left off by default. With the meter on the desktop, it's a tad redundant.

Alternatively, those who don't want it can edit out the xload line in jwmrc. I don't know if that's affected by the lowram cheatcode. Maybe it should be?

Posted by curaga on July 30 2007,08:15

Is it just me or do the folder icons look like Windows 3.11?

I would consider this a bug in the UI ;)

Posted by humpty on July 30 2007,19:12

Have tried the Live CD with nothing added.
These are all negative issues by the way, please bear;

Alpha4 doesn't detect my CF card in an ide slot, so i took it out.

xsetup.sh did not automatically start, probably because it was satisfied with the auto-detects.

MyDSL folder doesn't always show the new box-icons after loading an extension nor delete them after unmounting using the uci-tool. The menu entries don't auto-go-away either.

So tried the install-to Usb-Zip (my bios doesn't support usb-hdd).
The usb-pen boots but stops; Looking for CDROM in /dev/sda1.
Can't find Knoppix system.. USB device 2 (..blah blah..) is not claimed by any active driver.
I don't have this problem with 2.1b (kernel 2.4.31) which is surprising.

Posted by lucky13 on July 30 2007,23:50

Quote

MyDSL folder doesn't always show the new box-icons after loading an extension nor delete them after unmounting using the uci-tool. The menu entries don't auto-go-away either.

Sometimes the refresh option doesn't work so well. I'd noticed that with my wrapper scripts (chmod +x and then refresh and they're still not executable), and that's why I suggested the re/start menu items. That's one of the shortcomings of dfm, imo. OTOH, it does refresh properly when deleting/shredding files (see my second video).

Posted by roberts on July 31 2007,00:17

Two options for better update/refresh.

1. right click in window and select update.

2. if you have the horsepower, right click in root (desktop) area and change "smart update time" to a lower value.

This default and others will be worked out as we go through the alpha cycle.