I purchased a copy of Linux Magazine to test the new version of Knoppix; however, when I try to boot, it asks me to hit Enter to start the boot process. Knoppix 6.1 does not recognize my Enter key. Is this because I have a wireless USB keyboard, or do I have a defective disk?
Your guess about the wireless keyboard is most likely correct. At the point the boot graphic appears, no operating system is running, and there are no drivers or supporting software that could make your keyboard usable.
Some BIOSs support a "USB Legacy mode" with built-in USB drivers that make it possible to use a USB keyboard as if it were a regular built-in keyboard. Newer computers that lack a keyboard and PS/2 socket often support this feature. As long as the connection between the keyboard and the receiver plugged into the USB port use their own wireless protocol, with no additional driver, the keyboard should work. But if additional USB drivers are needed or the BIOS does not support an initial USB keyboard, your keyboard just won't work.
For this reason, the download versions of Knoppix usually have a timeout, after which the system will boot automatically, with no keyboard interaction necessary. But the versions that are published in magazines sometimes don't have this timeout. This safety feature ensures that the DVD does not boot the operating system accidentally, so the user must actively start it with a keystroke.
A workaround allows you to boot Knoppix without keyboard interaction, but you will need to rebuild the DVD.
To re-master the DVD:
- Copy the DVD contents to a directory on the hard disk. Use a filesystem with strict case sensitivity in file names because some scripts require, for example, the KNOPPIX directory to be named exactly like this, not knoppix or Knoppix or kNoPpIx. With FAT as the filesystem, use the mount option shortname=winnt as a mount option to get a more Unix-like mixed-case file-naming scheme that should work for building a Knoppix DVD.
The following Linux commands copy the contents of your DVD mounted at /media/dvd to USB flash memory mounted at /media/sdb1:
cp -Lr /media/dvd /media/sdb1/knoppix_dir chown -R u+w /media/sdb1/knoppix_dir
- The TIMEOUT parameter lurks in boot/isolinux/isolinux.cfg in the newly copied directory. Edit this text file and remove the # in # TIMEOUT 30.
TIMEOUT 30 tells the bootloader to wait just 30 tenths of a second (i.e., three seconds) before starting Linux automatically.
After the change, you have to re-create the .iso file:
mkisofs -l -r -J -no-emul-boot -boot-load-size 4 -boot-info-table -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat -o /media/sdb1/knoppix.iso /media/sdb1/knoppix_dir
After this command, /media/sdb1/knoppix.iso is a bootable ISO file, which can be written to DVD with the command:
growisofs -Z /dev/scd0=/media/sdb1/knoppix.iso
This new DVD should boot without the need for keyboard interaction.
If you frequently use different boot options, you can use the same procedure to change the APPEND lines in isolinux.cfg as well.
I bought Issue 103 yesterday and tried to install the SUSE Enterprise Desktop DVD; however, the 32-bit version does not work. The 64-bit version boots okay, but it gives me a message saying, "… your computer must use the 32-bit version … Reboot."
I've been buying your magazine for years, and this is the first time I've had a boot failure. Is there a fix for this other than buying a 64-bit machine? I checked online, and others are having similar problems with booting the SLED DVD. My computer searches for the 32-bit version boot record, gives up, and falls through to boot from the next bootable device. Others also relate this problem. From Debian – using a file manager – I can open and read files on the SLED 11 DVD with no problems. Running isoinfo shows that the DVD is very similar to your previous SLED 10 DVD that came with Issue 82.
Listing 1 shows a copy of my isoinfo output. I don't know why the DVD refuses to boot, but could it be that an autoboot file is missing?
01 debian:/home/jas# isoinfo -d -i /dev/hdc 02 03 CD-ROM is in ISO 9660 format 04 System id: LINUX 05 Volume id: SUSE_SLED-11-0-0.001 06 Volume set id: 07 Publisher id: Novell, Inc. 08 Data preparer id: CD-Team, http://bugs.opensuse.org/ Application id: 09 SUSE_SLED-11-0-0 Copyright File id: 10 Abstract File id: 11 Bibliographic File id: 12 Volume set size is: 1 13 Volume set sequence number is: 1 14 Logical block size is: 2048 15 Volume size is: 1904197 16 El Torito VD version 1 found, boot catalog is in sector 488 Joliet 17 with UCS level 3 found Rock Ridge signatures version 1 found Eltorito 18 validation header: 19 Hid 1 20 Arch 0 (x86) 21 ID 'Novell, Inc.' 22 Key 55 AA 23 Eltorito defaultboot header: 24 Bootid 88 (bootable) 25 Boot media 0 (No Emulation Boot) 26 Load segment 0 27 Sys type 0 28 Nsect 4 29 Bootoff 1E9 489
I received a replacement DVD, but it gives me the same problem. While I was waiting for the replacement, I tried the original in my son's Pentium 3 PC, an older generation machine. Guess what? The 32-bit side boots just fine! The problem lies in the fact the 32-bit side will not boot on my A7NX8 board with an AMD-based CPU chip.
In the early boot stage, BIOS tries to find a valid boot markup on your DVD, seeks to the location of the bootloader (which is a mini-program that loads the operating system kernel), optionally initializes a small ramdisk, and then gives control to the kernel's unpacking and initialization routine. On the DVD you mentioned, all of this seems to be OK, apart from the fact that on some computers, the bootloader isn't even starting. This tells me that the problem is not even related to the operating system kernel itself, which is what gives you "… boot this on a 64-bit machine."
Probably the problem is wrong assumptions by the BIOS OS loader routines. In early Knoppix versions, I noticed that booting from 700MB CDs sometimes failed on old computers, while (at that time) "standard" 650MB CDs booted fine. It looked like the BIOS routine had a maximum sector location built in that did not allow the bootloader to be placed at sectors above the 650MB limit. Of course, this is primarily a BIOS error, but instead of giving up and blaming the BIOS vendor, I found that just forcing the bootloader to be on a low-sector-count location was a good workaround for the problem.
The same thing might have happened here. ISO 9660 with "no emulation" boot (meaning that no boot floppy emulation is needed to load the OS) is the standard read-only filesystem that is still used on most read-only bootable optical media. Different operating systems allow different extensions, such as Rock Ridge or Joliet for long file names and paths and UDF for larger file sizes and packet-mode writing. The BIOS code for booting from CD or DVD does not know anything about the filesystem, and it just looks into the first few sectors for information about where to find the bootloader. With no strict rules about how this "simple" part has to be implemented, some BIOSes might make the (incorrect) assumption that the bootloader is located within the first 1024, 4096, 64K sectors – maybe aligned to a certain block size – or other assumptions that might match the great majority of bootable CDs/DVDs but, in some cases, are not followed because the general ISO standard does not really require them.
So maybe, entirely by chance, the bootloader is just present at a location of the DVD that is beyond the addressing scheme of the BIOS DVD loader – and apparently only on the 32-bit side of that DVD. This explains why it boots on some computers but not on all, regardless of the CPU's bit-ness.
A workaround (from Knoppix) is to pack the bootloader into a location right at the beginning of the image to circumvent this BIOS loading problem. To accomplish this, you have to remaster the DVD image and use mkisofs with a sort list to create a new bootable ISO image.
To start, I'll assume that you already copied the DVD contents to the hard disk in the dvd_dir directory (watch out for case sensitivity in file names on the underlying hard disk filesystem!) and that the DVD uses isolinux as its bootloader in no emulation mode.
Create a sort list for important boot files by editing /tmp/sort.list as follows:
dvd_dir/boot/* 1000003 dvd_dir/boot/isolinux/* 1000002
The pathname patterns should cover boot/isolinux/isolinux.bin and boot/isolinux/boot.cat, the bootloader and boot catalog, respectively, which are both read at boot time by the BIOS. Put them in a location very close to the beginning of the DVD ISO image when creating the image:
mkisofs -pad -l -r -J -sort /tmp/sort.list -no-emul-boot -boot-load-size 4 -boot-info-table -b boot/isolinux/isolinux.bin-c boot/isolinux/boot.cat -o dvd.iso dvd_dir
The -r and -J parameters create Rock Ridge and Joliet extensions, so the DVD can be read with long file names by Linux as well as Windows. These extensions should not hurt the boot process because all files relevant to the bootloader have short names and will not be affected by Joliet or Rock Ridge. -sort /tmp/sort.list will read in the priorities of files for mkisofs.
Some experts will doubt that sort lists for boot files are useful because standards don't require them for correct booting. But at least from my own experience, I can say that the command line has produced the most successful boot DVD images for me.
I would like to be able to set any root password I like. I have found that several distros of Linux have an annoying and unnecessary clause precluding a root password of six or fewer letters. It is not for some Linux hacker to tell me how many letters my root password is going to be, and if I want to use the empty string as a password, I should be able to do so. Please, could you advise me about the easiest method of achieving this.
Honestly, no kidding, I really prefer authentication by SSH or SSL public keys and resetting my password to an invalid value, which means there is no way for anyone to log in to my account without providing an acceptable key mechanism for secure and encrypted authentication with my ID.
But your question has a simple answer: With most distros, the plain, shell-based passwd command, issued as the root user, is free from any restrictions, even though in rare cases you might be notified if the system "thinks" that the password is weak.
To change your password with passwd:
- Get root in a shell.
- Type passwd username
Next, you will be prompted for a new password for that user, and the utility won't give you any feedback on the screen (not even the asterisks you usually see in graphical password managers). Just to be certain, you will need to enter the password twice – or maybe more often if you get the aforementioned warning.
If you want no password, just hitting the Return key is not enough because passwd will think you mistyped or changed your mind. To allow a login with no password at all, you have to use a text editor as root and kill the password field in /etc/shadow, /etc/passwd, or both (depending on which authentication method and style your system uses).
Search for the line that starts with the user you want to be able to log in with no password and remove the second field (between the : delimiters).
Be careful not to remove the colon (:); otherwise, your authentication might be broken so badly that you won't be able to log in anymore. If you change the second field of the user entry in both /etc/passwd and /etc/shadow to an asterisk (*) instead of removing it, the user will not be able to log in with any password at all.
A sample entry of /etc/passwd for the user guest with no password is as follows:
guest::1000:100:Guest User with no Password:/home/guest:/bin/bash
Note the second field, which is empty – with not even a white space – between the colons (::).
I'm not attempting to tell you what you should or shouldn't do, but I would like to just make a small note that a system on a public network that runs an authentication service modified to allow passwordless and unsecured logins for root will most likely get hacked and compromised within less than 42 seconds.
Buy this article as PDF
Bug database has a bug of its own that could allow an intruder to create an unauthorized account.
Report focuses federal resources on achieving universal Internet access.
Leading browser makers say “no” to porous encryption algorithm
Report from the X-Force group says attackers are using TOR to hide their crimes
Future Firefox extensions will be compatible with Chrome.
Better read this if you bought your computer before 2011
Users should upgrade to the new version as soon as possible
Xen project announces a privilege escalation problem for Qemu host systems
Attackers can compromise an Android phone just by sending a text message
PC vendor will pre-install Ubuntu on portables in India.