Wills' Projects: Operating Systems

This may possibly be as simple as having run out of memory - which is especially likely if you've got an old machine: a flat 4MB of RAM is not a great deal of memory if your boot disk is configured to copy its root filesystem into memory (a RAM disk) as well.

Alternatively, there may be a problem with hardware probing, ie. when Linux is trying to work out what disks you have, and so on. If you're running an old kernel, it can stall when probing hardware newer than its source code is - or you may simply have hardware that doesn't talk to the kernel in the expected manner (because it's broken). In either case, the kernel "debug" parameter is useful, and you might also try another kernel and see what that detects; you can then configure your preferred kernel to ignore the device in question, use kernel parameters to specify the right settings, or build a new kernel - one either without that hardware support, or with support as a module.

The kernel and shell print messages via the 'tty' devices and/or /dev/console when starting up; when this is not possible, the "legacy" output mechanism is used to deliver the above complaint. Note: when copying an existing distribution from one disk (or disk image) to another, then the Linux devices in the /dev directory may need to be adjusted to suit the new kernel.

Non-destructive Linux partitions (using UMSDOS, the Unix+MSDOS filesystem) need to have the directories initialised with `umssetup` or `umssync`, as the special Unix 'permission', 'device', and "filename style" characteristics cannot otherwise be preserved.

Also be careful that you've not used a cut-down version of tar - some reduced-size versions do not store device nodes properly in their archives; use of inappropriate `mount` options might be another possibility.

Pressing RightAlt-ScrollLock can be useful, as it reveals a variety of pieces of kernel trace information without the need for access to a prompt.

When building boot floppies, it can help to shrink the root filesystem by not having an /sbin/init, or using an alternative to it; for example, /sbin/init might be a symlink to /bin/sh, or the kernel might have to be instructed to use /bin/sh instead. If present in the kernel parameters, 'auto' is passed on to /sbin/init, but when some sleight of hand runs a shell instead, the shell assumes it has been passed a valid command line, and looks for an 'auto' program to run. This typically fails, with the normal "command not found" report.

This can be resolved by reconfiguring or not using SysLinux (eg. where loadlin is an option), or removing the /sbin/init symlink (modern kernels will look for /bin/sh unaided and not pass it unnecessary options).

Yes! The answer to this is simply "follow the Bootdisk-HOWTO 'in reverse'", ie. for every stage used in building a disk, there's a corresponding stage in disassembling the same disk.

If the disk cannot be mounted normally, the first sector will look (to the BIOS of the PC) like a boot block, but actually be a kernel; this can be proved with `file -s /dev/fd0`. Hence, 'rdev' and similar tools can be used to determine the kernel size, and whether this kernel looks for a root filesystem on that disk or another one. If the rest of the disk contains the initial ramdisk, you can use 'dd's `skip=` parameter to read beyond the kernel part. Feeding this output into gunzip will probably result in a complaint about "trailing garbage" but will also leave you with an image you can write to disk (or then mount via the loopback interface).