console [urxvt] puzzle (Solved)

[mmmrr]

console [urxvt] puzzle

1-# syslinux‭ ‬/dev/sdc1
bash: syslinux‭: command not found
3-# /usr/lib/syslinux‭ ‬/dev/sdc1
bash: /usr/lib/syslinux‭: No such file or directory

i entered line 1 which has worked before
to install syslinux to a flash drive.

entered line 3 after checking location,
existence of syslinux directory containing
file 'syslinux.exe'.

using precise pup 571, frugal.

any insights or workarounds welcome.
cheers, mm

[bigpup]

entered line 3 after checking location,
existence of syslinux directory containing
file 'syslinux.exe'.

If syslinux.exe is in a directory named syslinux in /usr/lib/

Try this:
/usr/lib/syslinux‭/syslinux

[MochiMoppel]

3-# /usr/lib/syslinux‭ ‬/dev/sdc1
bash: /usr/lib/syslinux‭: No such file or directory
....
entered line 3 after checking location,
existence of syslinux directory containing
file 'syslinux.exe'.

Yeah, the directory and file might exist (they exist on my system too), but the problem is how you entered the command. When I copy the command from your post I receive the same error. Feeding a small selection to MMview reveals the problem: What seems like a space is in fact a string of 3 characters. I don't know why and how you entered the non-printable UTF-8 characters into your command, but it should make clear that bash sees /usr/lib/syslinux[U+202D]‭ - and a directory with that name does indeed not exist.

To fix it delete the spacing and replace with a single ASCII space - or type manually.
If all goes well you should still get an error message, but a less confusing one

Code: Select all

# /usr/lib/syslinux /dev/sdc1
bash: /usr/lib/syslinux: Is a directory

Cheers,
MM

[OscarTalks]

Just booted a fresh frugal of Precise 5.7.1 with pfix=ram (no save - all original).
The command which syslinux returns /usr/bin/syslinux which suggests that the syslinux executable is in PATH so the simple command syslinux SHOULD work, but /usr/bin/syslinux is a symlink to /usr/bin/syslinux-nomtools which looks a bit strange. I would espect to see a real binary executable named simply syslinux
I see that the ownership of /usr/bin/syslinux-nomtools is 1026, 1026
This probably does not matter, but you can change it to root, root thus:-
chown root:root /usr/bin/syslinux-nomtools

Looking at /usr/lib/syslinux I see that again the ownership is 1026, 1026 so worth changing it with:-
chown -R root:root /usr/lib/syslinux
The file /usr/lib/syslinux/syslinux.exe is a windows executable so no use here at all
There is no linux executable syslinux in the directory
The only thing in the directory which might be of use is the file mbr.bin
If you find that you need to install a fresh mbr into a drive you can use cat /usr/lib/syslinux/mbr.bin > /dev/sdc (or whatever device name)

[williams2]

/usr/bin/syslinux is a symlink to /usr/bin/syslinux-nomtools which looks a bit strange

In BionicPup64, syslinux and syslinux-nomtools are 2 files which are byte for byte identical (identical md5sums).
Puppy often has duplicate files, one of which should be a symlink, otherwise it is a waste of space.

In BionicPup64, syslinux and syslinux-nomtools are both owned by root:root.
and they both have permissions of 0755.
/usr/lib/syslinux/syslinux.exe does not exist.

The only thing in the directory which might be of use is the file mbr.bin

In BionicPup64, mbr.bin is 440 bytes, which is a tiny program that searches for the first partition with the boot flag set.
AFAIK, the BIOS does not search for the boot flag, it is the code in the first 440 bytes of the mbr that looks for the boot flag.

The rest of the 512 bytes of the mbr is the msDOS partition table.

In a GPT system, the mbr is mostly filled with zeros. UEHI does not use the master boot record or the partition boot records. UEHI understands files and file systems and can search for and find bootable configuration files in each file system's /boot/ directories (folders).

[mmmrr]

first of all: apologies for not replying sooner.
i did not receive any notice of replies.
now i'll read them. thank you. mm

[mmmrr]

here is where i copied the command.
i have used this guide sucessfully in the past.
the command comes in a footnote but i'm
including the whole text, as it is an historic document.
--------------------::
make-a-puppy-flash-drive

The easy way to install Puppy Linux on a flash drive with no CD drive

The following article by rcrsn51 (murga-forum name) was copied from the Puppy Linux Forum (http://www.murgalinux.com/puppy/viewtopic.php?t=54566). it is so well written that I just had to make a PDF to share. There are apparently many ways of carrying out this process but in my humble opinion, this is, without doubt the easiest and most versatile way....bk

Beginning of forum article

In order to proceed, the following things must be true.
1. Your flash drive has the standard DOS/Win boot code on its MBR. It should, but see the note at the end.
2. The flash drive partition is flagged as bootable. Check this with Gparted.
3. Your Linux has the syslinux bootloader package. It probably does.

Here are the steps.

1. Determine the device name of your flash drive partition. It should be something like sdb1. But making a mistake with the device name can cause bad things to happen. Buyer beware.

2. Plug in the flash drive but don’t mount it.
in console, Type then enter:

syslinux /dev/sdxy

where sdxy is the flash drive partition.

This installs the syslinux bootloader.

3. Mount the flash drive and make a file named syslinux.cfg containing the following line:
[observe spacing. it is critical]

default vmlinuz initrd=initrd.gz pmedia=usbflash

4. Download the Puppy ISO file and mount it.

in console type then enter, a line at a time:

mkdir mnt
mount -o loop pupxxx.iso mnt

[xxx = pup version number from iso]

5. Copy three files from the mounted ISO to the flash drive
- vmlinuz, initrd.gz and pupxxx.sfs.

6. Unmount everything and boot off the flash drive.

If it won’t boot, here are some trouble-shooting questions.

Do you know for sure that your machine supports USB bootability? Many older machines (and some newer
ones) don’t. The best scenario is where the BIOS detects the flash drive as a secondary hard drive.

Have you modified your BIOS boot priority list to enable USB booting?

How is the flash drive formatted? Some users report better results with fat16 than fat32.

Does the MBR of your flash drive contain the standard boot code? If not, you can manually update the code as
follows:

1. Locate a file named “mbr.bin” in the syslinux package. Look for it in a folder like /usr/lib/syslinux.

2. Write this file onto the MBR of your flash drive using a command like:
in console, type then enter:

dd if=mbr.bin of=/dev/sdb

Note that this command uses “sdb” and not “sdb1”

End of forum article

If you would like to try another Puppy Linux Version on the same flash drive just delete the files you copied from
the mounted ISO; vmlinuz, initrd.gz and pupxxx.sfs. Mount another Puppy ISO and copy the same three files to
your flash drive.

----------------------------------------------------------------------
i think i would have copied/pasted the command
into the console.
cheers, mm

[mmmrr]

apologies again for delay. ill-health took time.
finding that the pups i wanted to put on bootable usb,
came with that process as a menu item. which worked.
i returned to this topic, read the several suggestions
by well-known contributers, thank you all very much.

most of it went over my head but i can follow directions
without needing to understand them. having found the
relevant menu item my need to solve this issue died.

best wishes, mm

[rockedge]

thank you for the solution and I'll add in that I really like the avatar you've chosen. for your profile.

Inspired the idea of what I can do with some of the many many fractals I generate playing around with FRACTINT in DOSBox

[mmmrr]

thank you. i suppose it was a solution of sorts.
reminds me: 'no answer is an answer as well'.

i was impressed by the speed & depth of response.
the title/subject was worded to catch expert eyes.

took me some years to realise that an abstract
avatar would be easy to make, easy for me to
look at, easy to pick out during speedy scrolling.

also, dear rockedge, many thanks for this forum.

it is the heart of puppy, always has been, [john
murga, rip], now you. l know no other technically
focussed forums so informative, so helpful, so courteous
indeed so kind, [nooby, rip], as those in puppyland.

barry kauler set a fine example of profound technical
wizardry, clear explanation, a friendly willingness to learn
as well as to teach.

big cheers all round..mm

[Phoenix]

/usr/bin/syslinux is a symlink to /usr/bin/syslinux-nomtools which looks a bit strange

In BionicPup64, syslinux and syslinux-nomtools are 2 files which are byte for byte identical (identical md5sums).
Puppy often has duplicate files, one of which should be a symlink, otherwise it is a waste of space.

In BionicPup64, syslinux and syslinux-nomtools are both owned by root:root.
and they both have permissions of 0755.
/usr/lib/syslinux/syslinux.exe does not exist.

The only thing in the directory which might be of use is the file mbr.bin

In BionicPup64, mbr.bin is 440 bytes, which is a tiny program that searches for the first partition with the boot flag set.
AFAIK, the BIOS does not search for the boot flag, it is the code in the first 440 bytes of the mbr that looks for the boot flag.

The rest of the 512 bytes of the mbr is the msDOS partition table.

In a GPT system, the mbr is mostly filled with zeros. UEHI does not use the master boot record or the partition boot records. UEHI understands files and file systems and can search for and find bootable configuration files in each file system's /boot/ directories (folders).

Actually it might not be the case, if its in the squashfile, the squashfile employs deduplication. If it is the savefile/savefolder then yes it will be duplicated. And UEFI, not UEHI

[williams2]

squashfile employs deduplication

Yes. Which is why I didn't point out that there are 3 or 4 copies of bzip2 in /bin
Or that some Pups have 2 or 3 copies of perl.

Although, while I assumed that duplicate files take up no more space than symlinks (assuming the files are small enough) I have not actually tested it.

So I created 2 dirs in /tmp/ named aa and bb.
I made a 1MB file named a in /tmp/aa/
I copied a to /tmp/bb.
I made 4 copies of a in /tmp/bb/, named b, c, d, and e.
Then I created symlinks in /tmp/aa/ named b, c, d, and e.

So /tmp/aa/ uses 5MB of space,
and /tmp/bb/ uses 1 MB of space.

Code: Select all

# cd /tmp/
# mkdir aa bb
# cd aa
# dd if=/dev/urandom bs=1M count=1 > a
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0158584 s, 66.1 MB/s
# cp a /tmp/bb/
# cp a /tmp/bb/b
# cp a /tmp/bb/c
# cp a /tmp/bb/d
# cp a /tmp/bb/e
# cd /tmp/
# ll aa
total 1.0M
-rw-r--r-- 1 1.0M Jul 12 20:38 a
lrwxrwxrwx 1    1 Jul 12 20:40 b -> a
lrwxrwxrwx 1    1 Jul 12 20:40 c -> a
lrwxrwxrwx 1    1 Jul 12 20:40 d -> a
lrwxrwxrwx 1    1 Jul 12 20:40 e -> a
# 
# ll bb
total 5.0M
-rw-r--r-- 1 1.0M Jul 12 20:38 a
-rw-r--r-- 1 1.0M Jul 12 20:39 b
-rw-r--r-- 1 1.0M Jul 12 20:39 c
-rw-r--r-- 1 1.0M Jul 12 20:39 d
-rw-r--r-- 1 1.0M Jul 12 20:39 e
# 
# mksquashfs aa aa.sfs
# mksquashfs bb bb.sfs
#
# ll *sfs
-rw-r--r-- 1 1.1M Jul 12 20:43 aa.sfs
-rw-r--r-- 1 1.1M Jul 12 20:43 bb.sfs
# 

which shows that aa.sfs and bb.sfs are about the same size. 1.1MB

aa.sfs has a 1MB file and 4 symlinks.
bb.sfs contains 5 files, each 1MB, a total of 5MB)

So squashfs can efficiently compress a file system containing some duplicate files.