1. 12 Oct, 2012 1 commit
    • Jeff Layton's avatar
      vfs: allocate page instead of names_cache buffer in mount_block_root · a608ca21
      Jeff Layton authored
      
      First, it's incorrect to call putname() after __getname_gfp() since the
      bare __getname_gfp() call skips the auditing code, while putname()
      doesn't.
      
      mount_block_root allocates a PATH_MAX buffer via __getname_gfp, and then
      calls get_fs_names to fill the buffer. That function can call
      get_filesystem_list which assumes that that buffer is a full page in
      size. On arches where PAGE_SIZE != 4k, then this could potentially
      overrun.
      
      In practice, it's hard to imagine the list of filesystem names even
      approaching 4k, but it's best to be safe. Just allocate a page for this
      purpose instead.
      
      With this, we can also remove the __getname_gfp() definition since there
      are no more callers.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      a608ca21
  2. 01 Jun, 2012 1 commit
  3. 05 May, 2012 1 commit
    • Sasha Levin's avatar
      init: don't try mounting device as nfs root unless type fully matches · 377485f6
      Sasha Levin authored
      
      Currently, we'll try mounting any device who's major device number is
      UNNAMED_MAJOR as NFS root.  This would happen for non-NFS devices as
      well (such as 9p devices) but it wouldn't cause any issues since
      mounting the device as NFS would fail quickly and the code proceeded to
      doing the proper mount:
      
             [  101.522716] VFS: Unable to mount root fs via NFS, trying floppy.
             [  101.534499] VFS: Mounted root (9p filesystem) on device 0:18.
      
      Commit 6829a048102a ("NFS: Retry mounting NFSROOT") introduced retries
      when mounting NFS root, which means that now we don't immediately fail
      and instead it takes an additional 90+ seconds until we stop retrying,
      which has revealed the issue this patch fixes.
      
      This meant that it would take an additional 90 seconds to boot when
      we're not using a device type which gets detected in order before NFS.
      
      This patch modifies the NFS type check to require device type to be
      'Root_NFS' instead of requiring the device to have an UNNAMED_MAJOR
      major.  This makes boot process cleaner since we now won't go through
      the NFS mounting code at all when the device isn't an NFS root
      ("/dev/nfs").
      Signed-off-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      377485f6
  4. 23 Mar, 2012 1 commit
  5. 07 Jan, 2012 1 commit
  6. 05 Jan, 2012 1 commit
    • Chuck Lever's avatar
      NFS: Retry mounting NFSROOT · 43717c7d
      Chuck Lever authored
      Lukas Razik <linux@razik.name> reports that on his SPARC system,
      booting with an NFS root file system stopped working after commit
      56463e50 "NFS: Use super.c for NFSROOT mount option parsing."
      
      We found that the network switch to which Lukas' client was attached
      was delaying access to the LAN after the client's NIC driver reported
      that its link was up.  The delay was longer than the timeouts used in
      the NFS client during mounting.
      
      NFSROOT worked for Lukas before commit 56463e50 because in those
      kernels, the client's first operation was an rpcbind request to
      determine which port the NFS server was listening on.  When that
      request failed after a long timeout, the client simply selected the
      default NFS port (2049).  By that time the switch was allowing access
      to the LAN, and the mount succeeded.
      
      Neither of these client behaviors is desirable, so reverting 56463e50
      
      
      is really not a choice.  Instead, introduce a mechanism that retries
      the NFSROOT mount request several times.  This is the same tactic that
      normal user space NFS mounts employ to overcome server and network
      delays.
      Signed-off-by: default avatarLukas Razik <linux@razik.name>
      [ cel: match kernel coding style, add proper patch description ]
      [ cel: add exponential back-off ]
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Tested-by: default avatarLukas Razik <linux@razik.name>
      Cc: stable@kernel.org # > 2.6.38
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      43717c7d
  7. 02 Nov, 2011 1 commit
    • Will Drewry's avatar
      init: add root=PARTUUID=UUID/PARTNROFF=%d support · 79975f13
      Will Drewry authored
      
      Expand root=PARTUUID=UUID syntax to support selecting a root partition by
      integer offset from a known, unique partition.  This approach provides
      similar properties to specifying a device and partition number, but using
      the UUID as the unique path prior to evaluating the offset.
      
      For example,
        root=PARTUUID=99DE9194-FC15-4223-9192-FC243948F88B/PARTNROFF=1
      selects the partition with UUID 99DE.. then select the next
      partition.
      
      This change is motivated by a particular usecase in Chromium OS where the
      bootloader can easily determine what partition it is on (by UUID) but
      doesn't perform general partition table walking.
      
      That said, support for this model provides a direct mechanism for the user
      to modify the root partition to boot without specifically needing to
      extract each UUID or update the bootloader explicitly when the root
      partition UUID is changed (if it is recreated to be larger, for instance).
       Pinning to a /boot-style partition UUID allows the arbitrary root
      partition reconfiguration/modifications with slightly less ambiguity than
      just [dev][partition] and less stringency than the specific root partition
      UUID.
      
      [sfr@canb.auug.org.au: fix init sections warning]
      Signed-off-by: default avatarWill Drewry <wad@chromium.org>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      79975f13
  8. 31 Mar, 2011 1 commit
  9. 23 Mar, 2011 1 commit
  10. 03 Jan, 2011 1 commit
  11. 26 Oct, 2010 1 commit
  12. 17 Sep, 2010 2 commits
    • Chuck Lever's avatar
      NFS: Use super.c for NFSROOT mount option parsing · 56463e50
      Chuck Lever authored
      
      Replace duplicate code in NFSROOT for mounting an NFS server on '/'
      with logic that uses the existing mainline text-based logic in the NFS
      client.
      
      Add documenting comments where appropriate.
      
      Note that this means NFSROOT mounts now use the same default settings
      as v2/v3 mounts done via mount(2) from user space.
      
        vers=3,tcp,rsize=<negotiated default>,wsize=<negotiated default>
      
      As before, however, no version/protocol negotiation with the server is
      done.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      56463e50
    • Jens Axboe's avatar
      do_mounts: only enable PARTUUID for CONFIG_BLOCK · 6d0aed7a
      Jens Axboe authored
      
      When CONFIG_BLOCK is not enabled:
      
      init/do_mounts.c:71: error: implicit declaration of function 'dev_to_part'
      init/do_mounts.c:71: warning: initialization makes pointer from integer without a cast
      init/do_mounts.c:73: error: dereferencing pointer to incomplete type
      init/do_mounts.c:76: error: dereferencing pointer to incomplete type
      init/do_mounts.c:76: error: dereferencing pointer to incomplete type
      init/do_mounts.c:102: error: implicit declaration of function 'part_pack_uuid'
      init/do_mounts.c:104: error: 'block_class' undeclared (first use in this function)
      Reported-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      6d0aed7a
  13. 16 Sep, 2010 1 commit
  14. 15 Sep, 2010 1 commit
    • Will Drewry's avatar
      init: add support for root devices specified by partition UUID · b5af921e
      Will Drewry authored
      
      This is the third patch in a series which adds support for
      storing partition metadata, optionally, off of the hd_struct.
      
      One major use for that data is being able to resolve partition
      by other identities than just the index on a block device.  Device
      enumeration varies by platform and there's a benefit to being able
      to use something like EFI GPT's GUIDs to determine the correct
      block device and partition to mount as the root.
      
      This change adds that support to root= by adding support for
      the following syntax:
      
        root=PARTUUID=hex-uuid
      Signed-off-by: default avatarWill Drewry <wad@chromium.org>
      Signed-off-by: default avatarJens Axboe <jaxboe@fusionio.com>
      b5af921e
  15. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  16. 15 Sep, 2009 1 commit
    • Kay Sievers's avatar
      Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev · 2b2af54a
      Kay Sievers authored
      
      Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
      very early at kernel initialization, before any driver-core device
      is registered. Every device with a major/minor will provide a
      device node in devtmpfs.
      
      Devtmpfs can be changed and altered by userspace at any time,
      and in any way needed - just like today's udev-mounted tmpfs.
      Unmodified udev versions will run just fine on top of it, and will
      recognize an already existing kernel-created device node and use it.
      The default node permissions are root:root 0600. Proper permissions
      and user/group ownership, meaningful symlinks, all other policy still
      needs to be applied by userspace.
      
      If a node is created by devtmps, devtmpfs will remove the device node
      when the device goes away. If the device node was created by
      userspace, or the devtmpfs created node was replaced by userspace, it
      will no longer be removed by devtmpfs.
      
      If it is requested to auto-mount it, it makes init=/bin/sh work
      without any further userspace support. /dev will be fully populated
      and dynamic, and always reflect the current device state of the kernel.
      With the commonly used dynamic device numbers, it solves the problem
      where static devices nodes may point to the wrong devices.
      
      It is intended to make the initial bootup logic simpler and more robust,
      by de-coupling the creation of the inital environment, to reliably run
      userspace processes, from a complex userspace bootstrap logic to provide
      a working /dev.
      Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarJan Blunck <jblunck@suse.de>
      Tested-By: default avatarHarald Hoyer <harald@redhat.com>
      Tested-By: default avatarScott James Remnant <scott@ubuntu.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2b2af54a
  17. 15 Jun, 2009 1 commit
  18. 01 Apr, 2009 1 commit
  19. 21 Feb, 2009 1 commit
  20. 07 Jan, 2009 1 commit
    • Arjan van de Ven's avatar
      async: Asynchronous function calls to speed up kernel boot · 22a9d645
      Arjan van de Ven authored
      
      Right now, most of the kernel boot is strictly synchronous, such that
      various hardware delays are done sequentially.
      
      In order to make the kernel boot faster, this patch introduces
      infrastructure to allow doing some of the initialization steps
      asynchronously, which will hide significant portions of the hardware delays
      in practice.
      
      In order to not change device order and other similar observables, this
      patch does NOT do full parallel initialization.
      
      Rather, it operates more in the way an out of order CPU does; the work may
      be done out of order and asynchronous, but the observable effects
      (instruction retiring for the CPU) are still done in the original sequence.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      22a9d645
  21. 06 Jan, 2009 1 commit
    • Marton Balint's avatar
      do_mounts: add device info to mount message · bca1033b
      Marton Balint authored
      
      In the past, I used the root=...  command line parameter to specify the
      root filesystem to the kernel.  Now it seems that specifying it is not
      necessary.  The kernel detects the root filesystem even if the kernel
      command line is empty.  My root fs is on a raid1 device by the way, and I
      am not using initrd for the boot process.
      
      If the kernel detects the root filesystem somehow, I think it should print
      out the result of this detection, otherwise I will not know which device
      has the root filesystem.  Or is there an easy way to get this information
      on a running system?  I had a quick look at the /proc and /sys
      filesystems, but haven't found anything useful there.
      Signed-off-by: default avatarMarton Balint <cus@fazekas.hu>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bca1033b
  22. 09 Oct, 2008 1 commit
  23. 26 Jul, 2008 1 commit
  24. 25 Jul, 2008 1 commit
  25. 14 Jul, 2008 1 commit
  26. 14 May, 2008 1 commit
  27. 15 Feb, 2008 1 commit
  28. 06 Feb, 2008 1 commit
  29. 25 Jan, 2008 2 commits
    • Kay Sievers's avatar
      Driver core: convert block from raw kobjects to core devices · edfaa7c3
      Kay Sievers authored
      
      This moves the block devices to /sys/class/block. It will create a
      flat list of all block devices, with the disks and partitions in one
      directory. For compatibility /sys/block is created and contains symlinks
      to the disks.
      
        /sys/class/block
        |-- sda -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
        |-- sda1 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1
        |-- sda10 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda10
        |-- sda5 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda5
        |-- sda6 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda6
        |-- sda7 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda7
        |-- sda8 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda8
        |-- sda9 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda9
        `-- sr0 -> ../../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0
      
        /sys/block/
        |-- sda -> ../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
        `-- sr0 -> ../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0
      Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      edfaa7c3
    • H. Peter Anvin's avatar
      security: remove security_sb_post_mountroot hook · bced9528
      H. Peter Anvin authored
      The security_sb_post_mountroot() hook is long-since obsolete, and is
      fundamentally broken: it is never invoked if someone uses initramfs.
      This is particularly damaging, because the existence of this hook has
      been used as motivation for not using initramfs.
      
      Stephen Smalley confirmed on 2007-07-19 that this hook was originally
      used by SELinux but can now be safely removed:
      
           http://marc.info/?l=linux-kernel&m=118485683612916&w=2
      
      
      
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: James Morris <jmorris@namei.org>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      bced9528
  30. 16 Jul, 2007 1 commit
  31. 09 May, 2007 1 commit
  32. 08 May, 2007 1 commit
  33. 30 Sep, 2006 1 commit
    • David Howells's avatar
      [PATCH] BLOCK: Make it possible to disable the block layer [try #6] · 9361401e
      David Howells authored
      
      Make it possible to disable the block layer.  Not all embedded devices require
      it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
      the block layer to be present.
      
      This patch does the following:
      
       (*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
           support.
      
       (*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
           an item that uses the block layer.  This includes:
      
           (*) Block I/O tracing.
      
           (*) Disk partition code.
      
           (*) All filesystems that are block based, eg: Ext3, ReiserFS, ISOFS.
      
           (*) The SCSI layer.  As far as I can tell, even SCSI chardevs use the
           	 block layer to do scheduling.  Some drivers that use SCSI facilities -
           	 such as USB storage - end up disabled indirectly from this.
      
           (*) Various block-based device drivers, such as IDE and the old CDROM
           	 drivers.
      
           (*) MTD blockdev handling and FTL.
      
           (*) JFFS - which uses set_bdev_super(), something it could avoid doing by
           	 taking a leaf out of JFFS2's book.
      
       (*) Makes most of the contents of linux/blkdev.h, linux/buffer_head.h and
           linux/elevator.h contingent on CONFIG_BLOCK being set.  sector_div() is,
           however, still used in places, and so is still available.
      
       (*) Also made contingent are the contents of linux/mpage.h, linux/genhd.h and
           parts of linux/fs.h.
      
       (*) Makes a number of files in fs/ contingent on CONFIG_BLOCK.
      
       (*) Makes mm/bounce.c (bounce buffering) contingent on CONFIG_BLOCK.
      
       (*) set_page_dirty() doesn't call __set_page_dirty_buffers() if CONFIG_BLOCK
           is not enabled.
      
       (*) fs/no-block.c is created to hold out-of-line stubs and things that are
           required when CONFIG_BLOCK is not set:
      
           (*) Default blockdev file operations (to give error ENODEV on opening).
      
       (*) Makes some /proc changes:
      
           (*) /proc/devices does not list any blockdevs.
      
           (*) /proc/diskstats and /proc/partitions are contingent on CONFIG_BLOCK.
      
       (*) Makes some compat ioctl handling contingent on CONFIG_BLOCK.
      
       (*) If CONFIG_BLOCK is not defined, makes sys_quotactl() return -ENODEV if
           given command other than Q_SYNC or if a special device is specified.
      
       (*) In init/do_mounts.c, no reference is made to the blockdev routines if
           CONFIG_BLOCK is not defined.  This does not prohibit NFS roots or JFFS2.
      
       (*) The bdflush, ioprio_set and ioprio_get syscalls can now be absent (return
           error ENOSYS by way of cond_syscall if so).
      
       (*) The seclvl_bd_claim() and seclvl_bd_release() security calls do nothing if
           CONFIG_BLOCK is not set, since they can't then happen.
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      9361401e
  34. 26 Sep, 2006 1 commit
    • Greg Kroah-Hartman's avatar
      Driver Core: add ability for drivers to do a threaded probe · d779249e
      Greg Kroah-Hartman authored
      
      This adds the infrastructure for drivers to do a threaded probe, and
      waits at init time for all currently outstanding probes to complete.
      
      A new kernel thread will be created when the probe() function for the
      driver is called, if the multithread_probe bit is set in the driver
      saying it can support this kind of operation.
      
      I have tested this with USB and PCI, and it works, and shaves off a lot
      of time in the boot process, but there are issues with finding root boot
      disks, and some USB drivers assume that this can never happen, so it is
      currently not enabled for any bus type.  Individual drivers can enable
      this right now if they wish, and bus authors can selectivly turn it on
      as well, once they determine that their subsystem will work properly
      with it.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d779249e
  35. 26 Jun, 2006 1 commit
  36. 30 May, 2006 1 commit
  37. 15 May, 2006 1 commit
    • Andy Whitcroft's avatar
      [PATCH] root mount failure: emit filesystems attempted · be6e028b
      Andy Whitcroft authored
      
      When we fail to mount from a valid root device list out the filesystems we
      have tried to mount it with.  This gives the user vital diagnostics as to
      what is missing from their kernel.
      
      For example in the fragment below the kernel does not have CRAMFS compiled
      into the kernel and yet appears to recognise it at the RAMDISK detect
      stage.  Later the mount fails as we don't have the filesystem.
      
        RAMDISK: cramfs filesystem found at block 0
        RAMDISK: Loading 1604KiB [1 disk] into ram disk... done.
        XFS: bad magic number
        XFS: SB validate failed
        No filesystem could mount root, tried: reiserfs ext3 ext2 msdos vfat
          iso9660 jfs xfs
        Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
      Signed-off-by: default avatarAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      be6e028b
  38. 26 Mar, 2006 1 commit