Hardlink on wheezy by default for usb-stick?

May somebody can give me a hint. I am still using my old squeeze and it works the way I want. But my recent post about changing the owners rights, e.g. 777 or 755 anyway, it could be 644 as well. While configuring a new pc, just by chance I discovered how to enter the BIOS. And here it comes. I want to install from an usb-stick the debian-7.8.0-amd64-netinst.iso.
Allright, there should be no obstacle so far. But this usb-stick was formatted in ext4 on another debian 7.8 machine and this very usb-stick now is refusing me as root on squeeze to unpack even in the terminal the package. No matter if I try chmod, chown 644 -d name-of-the-file. I don't have permission to do so. That would mean for my humble understanding that this device has won a hardlink to the other machine, I truly don't have a clue. Is there someone out there who could give me a hint. Thanks a lot in advance, I keep gouging my way through this. Maybe I am wrong, and there is no hardlink, but only root can act as rwx, the rest is set to r.

debian-7.8.0-amd64-netinst.iso is not RAR archive

this is what I get, after typing as root.

root@rechenknecht2:/media/usb0# unrar e debian-7.8.0-amd64-netinst.iso
root@rechenknecht2:/media/usb0# unrar l debian-7.8.0-amd64-netinst.iso
root@rechenknecht2:/media/usb0# unrar y debian-7.8.0-amd64-netinst.iso

but it is such a package to be unpacked, I did it before, earlier version of wheezy, and where I am doing wrong?

maybe something like this:

mount -o loop -t iso9660 debian-7.8.0-amd64-netinst.iso /media/usb0/

yep, luky strike...it worked.

but after solving this, on rebooting after the changes of the BIOS, there comes up, the real grewsome two aspects.
changes to the American Megatrends Bios version 2.15.1236 in the boot sequence are not saved, even clicking so. I switches back to EFI or UEFI and furhtermore it tells me that there is no BIOS fils in this usb key. Where the hack do I slam in to that usb key any bios file. After rebooting the screen tells me about grub rescue. So the BIOS itself saves the BIOS to the storage device with a strange name, that means...never use a large usb-device for that, unless you have to much of them. But grub rescue> after rebooting continues. So any hints to that. Thanks in advance!!!

I've never attempted to 'read' an iso file using RAR.....
Instead i've always used mount, to then copy the files out of the mounted path, as you did for your own surprise.

I do not even understanding why you are surprised that an ISO file is not a RAR-archive?
Or how you associate this with with a hardlink issue, thats quite something different.

In regards how you attempt to read an iso file i must ask, how did you write that iso file onto your usb stick?

No, the BIOS doesnt store 'itself' on the stick.
But there must be files readable by the bios on the stick in order to boot, those are required, however they are not 'bios' (nor (u)efi either)

Simple said, (probably) technicly incorrect:
Your computer looks according to its config/setting for either an (U)EFI or a BIOS file on the device selected to load (hdd, cd/dvd, usb), if none required file was found, it reports that no OS could be detected and the booting fails.

hth

An ISO is not an archive, it is a raw disk image -- a raw cdrom/dvd/bluray disk image. This is why it works with mount, not archiver tools. It has to be something which understands cdrom format.

As an answer to sea, the BIOS of the version mentioned up above requires such a written line on the usb-media, though unpacked. It is an msi-board, the menu itself got some 12 entries for the boot sequence. So it may wasn't correct to put it like this, but until UEFI or something like this, I really never had to make such a fuss writing or connecting the boot media with on single bit of the BIOS. Or even a command-line for such a media. Who may is into this trouble with UEFI may knows about this. Nonetheless I am repairing my GRUB.
And yes he may looks to a former partition with an MBR, because there has been a pre-installed version of UBUNTU. As my attempt was to get unetbootin to install another OS (Debian). My problem startet. In this very case it is not the OS, whether UBUNTU or anything else, it is UEFI that stubbornly blocks any attempt to get access.

And learning from this article

https://www.linux.com/learn/tutorials/776643-how-to-rescue-a-non-booting-grub-2-on-linux/

I must be a fool to think there still is a MBR. This has been ages ago, nowadays it is called "shiny new Globally Unique Identifiers partition table (GPT)".

Getting a bit upset about GRUB RESCUE> that requires some commands like
ls, set. set prefix=(hd0.1) I put on another usb-stick the so called rescue-kit as mentioned here
Rescue your Windows & GNU/Linux systems - Rescatux & Super Grub2 Disk , I took the
super_grub2_disk_i386_efi_2.00s2.iso and after plugging it into the usb-port asking the commands mentioned above.
ls is telling me, there are as follows:

(hd0) (hd0,msdos2) (hd0,msdos1) (hd1) (hd1,msdos1)

while setting the following command at

grub rescue> set prefix=(hd1,msdos1)/boot/grub
grub rescue> set root=(hd1,msdos1)
grub rescue> insmod normal

there occurs the message:

error: file file '/boot/grub/i386-pc/normal.mod' not found.

Before that the error message was:

`grub_term_highlight_color` not found. Entering rescue mode....

throwing me back to

grub rescue>

After changing several times the boot sequence in the UEFI-Bios, saving it and exit, to try to reboot, the same procedure.
So I tried :

'dpkg-reconfigure grub-pc ' for effect

But there is no effect.

this link doesn't help me either. Any hints? Thanks a lot.

typing up and down the following commands as the link tells me to do

[SOLVED] error: symbol 'grub_term_highlight_color" not found. grub rescue>

always coming back to grub rescue> the same procedure as every time,

error: symbol 'grub_term_highlight_color' not found

then

entering rescue mode....

'grub rescue> 'dpkg-reconfigure grub-pc' for effect'

>set
>set prefix=(hd0,1) /boot/grub
>set root=(hd0,1)
>set insmod normal
>normal
>insmod linux
>linux /vmlinuz root=/dev/hd0,1 ro
>initrd /initrd.img
>boot

and looping back to
grub rescue>

even trying

fschk -y /dev/hd0,1

gives me no reply at all. The first repair-kit is on an usb-drive formatted in FAT32 to repair grub. Entering the BIOS it is flashing from the usb-drive.
Before all that I tried without success to execute the commands above with
sda for SATA-hdd.
And not even

'fdisk -l'

seems to work. Think I am done with uefi.

---------- Post updated at 11:42 PM ---------- Previous update was at 09:54 PM ----------

Starting now in efi mode the mobo tells me startup.nsh, wow, backslashes all over the place. This shell must be nuts.
This link gets me some help
https://packages.debian.org/wheezy/grub-efi-amd64
allthough I am at the very beginning of this.

 EFI Shell version 2.31 [5.8]
    Current running mode 1.1.2
    Device mapping table
      fs0  : Harddisk - Alias hd5a65535a1   blk0
             PciRoot(0x0)/Pci(0x13,0x0)/Sata(0x0,0x0)/HD(1,...,0x800,0xF3800)
      blk0 : Harddisk - Alias hd5a65535a1   fs0
             PciRoot(0x0)/Pci(0x13,0x0)/Sata(0x0,0x0)/HD(1,GPT,...,0x800,0xF3800)
      blk1 : Harddisk - Alias (null)
             PciRoot(0x0)/Pci(0x13,0x0)/Sata(0x0,0x0)/HD(2,GPT,...,0xF4000,0xBA43800)
      blk2 : Harddisk - Alias (null)
             PciRoot(0x0)/Pci(0x13,0x0)/Sata(0x0,0x0)/HD(3,GPT,...)
      blk3 : Harddisk - Alias (null)
             PciRoot(0x0)/Pci(0x13,0x0)/Sata(0x0,0x0)/HD(4,GPT,...)
      blk4 : BlockDevice - Alias (null)
             PciRoot(0x0)/Pci(0x13,0x0)/Sata(0x0,0x0)
      blk5 : BlockDevice - Alias (null)
             PciRoot(0x0)/Pci(0x1C,0x1)/PCI(0x0,0x0)

    Press ESC in 1 seconds to skip startup.nsh, any other key to continue.
    Shell>

fdisk -l is not recognized as an internal or external command, operable program or batch file. Invalid file system mapping on hd16c0b

...great.

while trying to unpack the rescue-kit on my usb-device, at the laptop there it says after typing

root@rechenknecht2:/media/usb0/save# mount -o loop -t iso9660 grub-efi-amd64_1.99-27+deb7u2_amd64.deb /media/usb0/save
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

where the directory named /save is containing the debian-file. So there is a conflict at the basic, where the usb-drive with this very specific debian-packet is on an usb-drive that is formatted in FAT32 to fullfill the requirements of UEFI but working in the wrong place.
Any hints for this nutshell of microsoft? Setting the SATA to another plug? Thanks in advance.

quote:

"This represents only the beginning of the uses and benefits of EFI shell commands and scripts. Not only can EFI be used similarly to a MS-DOS device driver, its capabilities also remove the hassle of modifying the OS. Disk utility vendors can use EFI to craft powerful tools like platform-independent disk partitioning. Another of EFI's benefits is that the same device drivers can be used by many EFI-compliant platforms, thus providing a good return on investment. EFI allows users to create device drivers to access hardware directly without having to go through the OS, making the process both simpler and faster."

from

getting tired......to be simpler and faster, way beyond my expectations.

You are trying to mount a debian package.
Its just like your attempt to unrar an iso file.

deb != iso != rar
Though, you might have better luck with un[rt]ar the deb package.
But those are ment to be installed on an system, not mounted.

Try: (either just this, or use tab to autocomplete to the full file name you want to install, which ALWAYS ends on deb)

su
apt-get install grub-efi-amd64

Hope this helps

This is what it is may be about, there is a directory on the mentioned rescue-kit. My full path to it (using the laptop) on the usb-drive is

/media/usb0/save

going down to

/usr/share/bug/grub-efi-amd64 

that contains two files
named presubj as a simple textfile and
the funny named sript, a shell-sript. To be written down I pasted the code.

echo >&3
echo "*********************** BEGIN /proc/mdstat" >&3
cat /proc/mdstat >&3 2>&1 || true
echo "*********************** END /proc/mdstat" >&3

cat <<EOF
Information on any LVM volumes on this system is valuable to the GRUB
developers, but gathering this information requires the root password.
EOF
yesno "Do you want to provide LVM volume information?" nop
if [ "$REPLY" = yep ]; then
  echo >&3
  echo "*********************** BEGIN LVM" >&3
  su root -c "vgdisplay; pvdisplay; lvdisplay" >&3
  echo "*********************** END LVM" >&3
fi

echo >&3
echo "*********************** BEGIN /dev/disk/by-id" >&3
ls -l /dev/disk/by-id >&3 2>&1 || true
echo "*********************** END /dev/disk/by-id" >&3

echo >&3
echo "*********************** BEGIN /dev/disk/by-uuid" >&3
ls -l /dev/disk/by-uuid >&3 2>&1 || true
echo "*********************** END /dev/disk/by-uuid" >&3

exit 0

From stackoverflow.com
there is another hint
How can a Bootloader written in x86 Assembly be written to a USB Flash drive and support both BIOS and UEFI? - Stack Overflow

quote
"Removable media does not need to be GPT formatted in order for UEFI to boot from it. You need to create efi/boot folder on a FAT partition on a removable medium and place your UEFI bootloader there. File name must be bootx64.efi for X86-64 architecture. Booting in Legacy or BIOS mode will be handled without changes - via MBR. In pure UEFI boot mode it will read /efi/boot/bootx64.efi file.
Please note also, that FAT partition should be addressed by the first MBR partition entry and be active."

So right now I guessing what file to put down in this bootable directory?
The cited shell-script up above to rename it, file size is 1.7 kb or a file named
"boot.catalog" with a flie size of 2 kb but this is an unknown file (application/octet-stream)?
Any hints?

BTW coming back to the very outset ot this thread, there must be a hard link set by wheezy or system.d, because any usb-stick that once has been in touch whith wheezy only works properly on squeeze, when I type as root in the terminal

/umount/usb0

otherwise I am forced to work
a bit more complicated to copy files, just like

 stat %A filname

and afterwards

cp filename /media/foo

I am aware there is jessie burning up the charts.

Heureka, yes he did it. Solved the problem, though UEFI is very nasty, no matter what OEM comes along with it. The crucial point was to format the usb-device in FAT16, don't you ask me why. (I am aware of the limits of FAT16 and the FAT32). But after I put on that usb-stick in the FAT16 format, I could finally run the net-installation, with Legacy + UEFI sequence. It gave me the chance to crash out the former ubuntu-partition and the rest I guess you know. Truly, one could operate with the CD, but honestly I have not used a CD for at least six years. But the headline still remains, because I was using a very old usb-stick, one with 1GB, this piece must be at least ten years old.

Seems to have found an answer to my almost desperate search for the reason, it is this nasty sudo while installing a system and entering user and group. Once you made this mistake, you rather do it again and step by step or you get along with a kind of phantom sudo, even after typing

apt-get purge sudo 

as root. Even in that case, have a look at the manpage of lsblk or search for more in the ubuntu-corner.

While getting along with a phantom sudo, it finds all the devices and may you would wish to have a real wide screen after typing as root the following:

su lsblk -o NAME,FSTYPE,UUID,RO,RM,SIZE,STATE,OWNER,GROUP,MODE,TYPE,MOUNTPOINT,LABEL,MODEL 

Note: after tearing out sudo-package!!! And afterwards once again, have a look at the rights, whatever it may be, 40770 or 10644. I thought to put this here, not as a final conclusion, but in my case, a very old usb-drive worked well with msdos format, on squeeze and wheezy. A brand new one is unknown to my older laptop, but seen on the new system at my desk. A even newer hdd acts as well to be seen as an irritating device that quote:

mount: according to mtab, /dev/sdb1 is already mounted on /media/usb0

that command was typed as root, su.
So take care, if you a using debian wheezy or installing it and if you want to exclude sudo, do this while installing it. Otherwise you probably have a stable ubunutu bla foo do or so. But not a pure blend of debian or root, in my opinion. So if anybody can give me a better conclusion, or clues or hints, thanks in advance.

got it, almost!

%wheel ALL=(ALL) NOPASSWD: ALL

feel at home, try it and replace, if you like to, NOPASSWD with PASSWD, the mentioned code gives you su-level-1, one password for both. And here comes the link, where you may read more about it.

https://help.ubuntu.com/community/RootSudo

But my error message trying this, is the following one

syntax error, unexpected word  `('

so this may be the clue to repair it, can anyone give me a hint, please??? Thanks in advance.

one step ahead it looks like this:
Well to solve this, without reinstalling it, it will take me some more time, thanks to redhat or the maintainer of the packet pam_wheel(8).
While typing as root

dpkg -l 

o have a view at all installed packages I need better glasses or I just cannot see this specific packet in the list. But the manpage is there.
This wheel must be hidden or part of the core-group. Maybe someone can answer this, if it is part of core, for I don't see any pam_wheel.
quote from the manpage
"pam_wheel was written by Cristian Gafton <gafton@redhat.com>."
asked him on google+ waiting for a reply
but after reading the following I got it this time after reading (in my mother tongue) not the quoting error.

https://www.debian.org/doc/manuals/debian-reference/ch04.de.html

but to cut a long story short you have to dive deep into the
package / file 'pam_wheel.so' to activate in /etc/pam.d/su
just root to act as su or root or members of this group.
Under

/etc/passwd your rights are '-rw-r--r--' root root
/etc/shadow your rights are '-rw-r-----' root shadow
/etc/group  your rights are '-rw-r--r--' root root

so this is for gnome desktop, bus as well for more unix than ubuntu.
The mentioned page in english, same content.

Chapter�4.�Authentication

thanks for your patience.

Final words on mounting points and fstab, I am quitting any update for wheezy 7.0.8 for the simple reason, that after the last update, four days ago, not even now a former pluggable usb-drive will only work or not due to the lack of a mounting point. I doubt that this is useful, to give each and every device around, a certain line in /etc/fstab. So I will probably move to external devices, that are recognized without editing every time the fstab as root.
Found this on stackexchange, well, probably shame on me, but it won't change my point of view.

 apt-get install usbmount

as root, su.
Thumbs up.

May for others this link can be useful who may still want to use their OS, whatever this may be (mint, buntu, debian based) and who cannot get acquainted to systemd and its tricky behavior. So here is something that can put the fun in your sys, but getting rid of systemd.
Have fun.

How to remove systemd from a Debian jessie/sid installation - Without Systemd