initramfs-tools.git/scripts/local, branch vyatta/VC6.3-2011.07.21/amd64

pre_mountroot(): reduce timeout to 30 seconds

2010-06-17T09:24:07+00:00

giant disk arrays, clusters will need to provide their own rootdelay= boot arg, they should have capable admins. 3 minutes wait is just too long for regular users. sync from ubuntu 0.96.1ubuntu1. Acked-by: Michael Prokop Signed-off-by: maximilian attems

hook-functions/init/scripts/local: add support for ubifs.

2010-06-16T14:48:06+00:00

MODULES=dep fails when / is ubifs. This patch adds support for something like root=ubi0:rootfs when ubi is modular. Quoting Martin: It essentially does three things: - adds the correct modules to the ramdisk (for MODULES=dep and MODULES=most) - reads ubi.mtd= from the command line - loads ubi with the ubi.mtd info and ignores the "Waiting for root" check I've successfully tested this with a kernel with modular ubi and with the following boot variants: console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs console=ttyS0,115200 ubi.mtd=2 root=ubi0_0 rootfstype=ubifs With console=ttyS0,115200 ubi.mtd=2 root=/dev/ubi0_0 rootfstype=ubifs I get an error that it cannot mount root but I suspect this is an ubifs error and has nothing to do with i-t (since at this point I can manually mount it with -t ubifs ubi0_0 whereas the /dev/ variant doesn't work). Tested with MODULES=dep and MODULES=most as well as with a kernel that has ubifs built in. Closes: #582858 Thanks: Martin Michlmayr Signed-off-by: Martin Michlmayr Reviewed-by: Michael Prokop

code cleanup: drop trailing whitespaces.

2010-06-14T10:10:28+00:00

Signed-off-by: Michael Prokop

scripts/functions: add get_fstype() from scripts/local

2010-04-04T03:31:49+00:00

allows wider usage. (closes: #487409) Reported-by: Christoph Anton Mitterer Signed-off-by: maximilian attems

scripts/local: fix blkid invocation

2010-02-24T23:57:13+00:00

49337bd looks bogus. It adds the test "[ command ... ]" but I think that should be just "command ..." Reporte-by: Ben Hutchings Signed-off-by: maximilian attems

scripts/local: Use blkid as backup fstype detection

2010-01-30T18:54:13+00:00

if blkid is on initramfs use it. Thanks to Joey Hess for calling syntax. Signed-off-by: maximilian attems

scripts/local: avoid mount -t unknown

2010-01-30T18:44:24+00:00

Since fstype does not support btrfs (#548047), and since udev 150, vol_id no longer exists, get_fstype sets FSTYPE to "unknown", and then the root filesystem is mounted using "mount -t unknown /dev/hda2 /root". Of course, that fails, and with a really unhelpful error message ("mount: device doesnot exist") Why not just skip the -t parameter if FSTYPE=unknown? Mounting the root fs was going to fail, so letting mount autodetect the fs type can't be worse. Attached patch does that and got my root on btrfs working. Workaround: boot with rootfstype=btrfs Signed-off-by: maximilian attems

allow root=mtd0 to be used; skip root checks if ROOT doesn't start with /dev.

2009-02-17T14:25:56+00:00

The attached patch is needed for booting with root=mtd0. Basically, the init scripts assume the root device should have a special device file somewhere, and if not will wait for it to appear. This patch changes it so that it only waits for a device file to appear if $ROOT starts with "/dev". In the case of things like ROOT=LABEL=foo, the init scripts will translate that to a device. With ROOT=mtd0, the init scripts will not check for a device, and will successfully mount the root filesystem. Signed-off-by: Andres Salomon

Merge more meaningful text for no root device panic from Ubuntu.

2008-07-04T23:46:31+00:00

Debian users were pasting that without getting the real trouble, thanks for the better rephrasing.

Wait for udevsettle after $BOOT-top scripts ran

2008-07-02T22:19:16+00:00

udev may be busy creating links for the root device by the time mountroot is called. udevsettle makes sure these are processed. I thus call udevsettle with a timeout of 10 seconds after the $BOOT-top scripts have run and before the ROOTDELAY hack kicks in. I thought about doing this with a local-top script instead, but there is no way to ensure that it'll run last; cryptsetup uses a hack to make sure it runs last, if we also use the same hack, there'll be a dependency loop. Signed-off-by: martin f. krafft Signed-off-by: maximilian attems