[News]

News

[Stats]

Stats

hmmmmm , no follow ups ?
no ideas from anyone ?

Has ANYONE had any luck mounting a loop filesytem ?

[ltmodem.o]

years back I had a machine with a 'win-modem' that used module ltmodem.o and was found on /dev/ttyS15 instead of the usual /dev/ttyS[1-4] .

You might try the commnd (as root)
# insmod ltmodem
or (as dsl)
$ sudo insmod ltmodem

Then see what output dmesg has with the command sting
$ dmesg  | tail -10
Look for output corresponding to your modem. If insmod gives an error that ltmodem is already installed
 pipe dmesg to less and search for it manually.
Use this info to configure ppp and you might be 'golden' .

4.11rc1 burned to cd for me without any issues.

I'm not sure what the OP is trying to do that isn't woking.
A better explanation of what he wants to do and what he has to work with might help get him where he wants to be.

[hdd]

Something that didn't come to mind during my previous responce was the use of appending where linuxrc in the initrd file should look for your KNOPPIX image. Adding "fromhd=/dev/sda7 to the DSL boot section and "fromhdd=/dev/sda10" to the append line of the Feather boot section should cure the problem you were having. Notice that Feather uses "fromhdd=/dev/xxx" and DSL uses "fromhd=/dev/xxx", with xxx being the device and partition.

My problem was more to the tune of both of them being in the same folder on a primary partittion.

OK so realising that a full blown database of where all the files reside  isn't feasible for a <50 meg distro. How about adding an alias to bashrc or bash_aliases that reads similar to

alias locate="du -ah / 2>&1| cut -f 2 | grep" for an output simular to full locate
or
alias locate="du -ah / 2>&1| grep" to show the file allocation size ?

The first instance takes a minute to complete. Every instance afterwards it is read from cached memory and the results are nearly instantaineous.

In ways, the alias is a bit better than using updatedb, which only runs once per day, any new files or newly mounted filesystems are immediately available and no diskspace is used on a read-only fs.

I haven't looked at the kernel cache useage before and after first use. Low memory machines (<32M) haven't seemed to suffer from this alias. The kernel keeps track of stale caches and flushes them regularly. Symlinks are shown as 0K in size if not piped through cut. And you get a quick ide of file size wlithout having to run ls -l once the file you are looking for is found.

Thanks for your eforts making DSL what it has evolved into, a great distribution that is portable and consistant from one machine to the next.

I found it for my feather install, I i have no idea yet if the same naming is used for dsl.
I gunzipped the feather minirt24.gz image, created an initrd directory , mounted the image there and opened the linuxrc file with a text editor (vim). searched down till I found
KNOPPIX_NAME="KNOPPIX"
the following line explained it all.  The linuxrc script is reading the kernels /proc/cmdline to see if the cloop image of the system files have been renamed or a specific name should be used in place of the default KNOPPIX.

Adding the phrase "knoppix_name=FEATHER" and "knoppix_name=DSL" to the respective append lines in my lilo.conf file before running lilo (again for the 300th time) will hopefully cure this issue for me.
 I'm getting ready to reboot and will post back , soon, if all goes well. If not I'll fix it from one of the other boot images on the harddive


It worked like a champ ! it rebooted back into dsl with my /KNOPPIX/KNOPPIX simlink pointing to /KNOPPIX/FEATHER.

I hope someone gets some good out of this . I certainly will.

It isn't the boot loader that is finding the 'wrong' knoppix image it is /linuxrc in the initrd file loaded with the kernel at boottime.

I have this issue too. Both of mine are in the KNOPPIX directory on a partittion. One now named FEATHER the other named DSL with a simlink pointing to the one I want to boot to on next boot. I have to remember to pull out any thumb drives that might contain an image also since /dev/sd* is checked befor dev/hd*.

I use LILO not GRUB and have the append="BOOT_IMAGE=FEATHER" and append="BOOT_IMAGE=DSL"  and still have this issue. I just change the simlink before rebooting.

If I get to bothered by the problem I will fix it in both my respective minirt24.gz images and post the results/steps taken.

To the developer I send my many thanks !!!
My frugal install went without a hitch, thank you for including LILO.
 
I did have a problem , initially, with the kernel freezing at boottime. It is a 1GHz early Celeron in a Gateway 300 flexatxstc. The CPU doesn't seem to handle SMP kernels well. I had to add the boot-time kernel option "no-hlt" .

After the install I added a second HD thinking I was going to play around a bit loop mounting the fs's on the device.
After MANY failed attempts trying to mount known partittions as loop devices.
 
#mount -t ext2 -o loop,offset=32256,ro /dev/hdb /mnt/hdb1

I decided to write a small script to probe the first 10,000 512 byte sectors for filesystems thinking maybe my math skills were failing. This would(should) also pick up on the next 2 partitions if successful and mount them over the top of the first one.

it was something like :
#! /bin/bash
for a in 0 1 2 3 4 5 6 7 8 9
    do for b in 0 1 2 3 4 5 6 7 8 9
    do for c in 0 1 2 3 4 5 6 7 8 9
    do for d in 0 1 2 3 4 5 6 7 8 9
    do for e in 0 1 2 3 4 5 6 7 8 9
    do echo "sector $a$b$c$d$e at offset $[512*$[$[$a*10000]+$[$b*1000]+$[$c*100]+$[$d*10]+$[$e]]]"
         losetup -d /dev/loop0 # was added later thinking the loop wasn't resset
         mount -t ext2 -o loop,offset=$[512*$[$[$a*10000]+$[$b*1000]+$[$c*100]+$[$d*10]+$[$e]]] /dev/hda \                      /mnt/hda1 && echo SUCCESS ! ! ! && break     
    done ; done ; done ; done ; done     
# end of script

This lilttle script works with varying distros but seemed to bomb out with DSL 4.11 rc1.
The first run of the batch script ran without finding anything. The first line of output from it was as expected. It probed the MBR and gave an error from mount that no fs was found. Every successive probe returned "ioctl: LOOP_SET STATUS: Invalid Argument" . hmmm sounds like the loop wasn't unconfigured. So I drop a line in to delete the loop settings on every attempt. #losetup -d /dev/loop0. Still no luck with this. I now get the error that no such address for that loop device. That wasn't it. The next thought was a typo in the $[$[$]] 's. no , I tried it by hand figuring the location and entering it at the command line using both mount -o and losetup -o.

Changing the bs from 512 to smaller values gave similar results. Till it was reduced below 16 bytes. With a bs from 1 byte to 16 bytes it gave the same errors as the first.  As it probed the first 32 bytes of the MBR the error was as expected. After that it gave the LOOP_SET_STATUS error. I also tried setting the script to start on the known partittion and in an area filled with zeros. no luck. it still gave the same LOOP_SET_STATUS error.

I tried a few different hardrives including several usb thumb drives with the same result. The partitions could be mounted straightforward but mounting an image of them fails as does trying to mount a fs at a particular offset from the actual device.

During the process I 'forked' my train of thought to try encrypted filesystems using aes encryption and played with that a bit but couldnt tell that actual encryption was taking place. While running hexdump on the encrypted image all the content seemed to be completely visible. Mounting the fs without encryption also yeilded the same results. The files were readable. The only obfuscation seemed to be  in how the image was created. The command :
#dd if=/dev/urandom of=encrypted.img bs=1M count=100         
filled the file with random characters instead of all 00 00 00 00 00 00 00 00's.

I'm not sure if the 2 loop issues are related but thought to mention them both to make people aware a problem may exist if they are expecting to keep private data private or if they are trying to recover a partittion after a corupted MBR. Being aware that other tools exist for this purpose , this was the one I had at hand and wanted to give it a go.

I have my doubts I will check back in on this forum to answer questions or continue the discussion but hope I have provided enough information to make this a repeatable exercize for others.