Been seeing that since Karmic, and just reproduced it with Natty.
In /usr/share/initramfs-tools/scripts/functions, function
configure_networking() is called from the initramfs to setup a network
connection for e.g. diskless booting. This function doesn't call `udevadm
settle` or anything similar to wait until the NICs are made available by udev.
So many times booting fails with messages like "ipconfig: no devices to
configure" etc.
Attaching a screenshot that displays the problem. configure_networking tried to
call ipconfig before the NIC was available, so booting failed. After a couple
of secs udev initialized the NIC.
Adding a call to `wait_for_udev 10` inside the configure_networking() function
solves the problem.
Tested in 3 different PCs and 1 vbox VM, they all experienced the problem
previously and they worked fine after applying the patch.
LP: #682445
Reviewed-by: Michael Prokop <mika@debian.org>
Signed-off-by: maximilian attems <max@stro.at>
USB modules are not normally loaded at break=top time but since USB
keyboards are very common we should take the effort to try to load
extra kernel modules at break (=panic) time. This patch closes#615831
and has been adapted from comments mentioned in
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/229732
and tested on a HP ProLiant MicroServer that lacks a PS2 port
completely.
[ Removed the check for an eventual PS2 driver as it might be running
mice and not a keyboard -maks ]
Closes: #615831
Reviewed-by: Michael Prokop <mika@debian.org>
Signed-off-by: maximilian attems <max@stro.at>
Loading a kernel module can crash the system so it is useful that the
user sees which module might be causing trouble.
Signed-off-by: maximilian attems <max@stro.at>
When running update-initramfs in verbose mode
stdout leaks into the environment and the behaviour
is different from running without the verbose option.
Closes: #601319
Reviewed-by: maximilian attems <max@stro.at>
Signed-off-by: Michael Prokop <mika@debian.org>
If you pass a root= argument with a numeric device number
(i.e. root=0806), that's currently resolved by running mknod to create
a /dev/root device with an appropriate major/minor number and setting
ROOT=/dev/root (the parse_numeric function in scripts/functions).
However, this /dev/root device is completely unknown to udev. On
Ubuntu, this leads to problems because we use udev to wait for the
root device to appear. Since /dev/root isn't in udev's database, the
boot hangs forever (well, it hangs until rootdelay passes).
udev's standard configuration creates /dev/block/N:N symlinks for
every block device in its database (see the first non-comment line of
/lib/udev/rules.d/50-udev-default.rules). Setting ROOT to the
/dev/block/N:N symlink instead of creating a new /dev/root device and
setting ROOT to that solves Ubuntu's problem.
See https://bugs.launchpad.net/bugs/576429 for more discussion.
I think I actually want to take a different approach in order to
maintain the current semantics of setting root=X:Y.
In particular, if the user passes in a value that has a prefixed 0,
that will get passed directly to mknod, which would treat the number
as octal. So root=010:0 would actually create a device with major
number 8. Instead of trying to resolve this directly, we can use the
shell's arithmetic expansion to get a decimal number back.
Closes: #606806
[ change condition from specific udev script to udevd availability. ]
Signed-off-by: maximilian attems <max@stro.at>
Reviewed-by: Michael Prokop <mika@debian.org>
Currently if a system administrator uses "panic=60 break=top" boot
options initramfs prints
Spawning shell within the initramfs
but does not actually spawn the shell since panic= disallows
that. This patch explicitely informs the user about the reboot and
hints that by reminving panic= he/she can get break= debugging to
work.
Signed-off-by: Timo Juhani Lindfors <timo.lindfors@iki.fi>
[ small wording change -maks ]
Signed-off-by: maximilian attems <max@stro.at>
The purpose of panic= is to make the system reboot automatically on
panic but also give the interactive user some time to see what went
wrong.
Signed-off-by: Timo Juhani Lindfors <timo.lindfors@iki.fi>
Signed-off-by: maximilian attems <max@stro.at>
usplash is not released in Squeeze and is no longer in Debian unstable.
Thus nuke usplash calls and any ref to it.
Signed-off-by: maximilian attems <max@stro.at>
Reviewed-by: Michael Prokop <mika@debian.org>
when $DEVICE is not set (which is now default), otherwise ipconfig may
receive a valid DHCP response, but fails to break out of the loop and is
called repeatedly.
thanks to Petter Reinholdtsen, i think i've figured out the
initramfs-tools portion of this problem (there may still be outstanding
issues with ipconfig).
tested the attached patch, which seems to address the issue for me at
least.
Closes: #584583
Signed-off-by: maximilian attems <max@stro.at>
version is "the" essential exported variable by mkinitramfs.
Use it's string length to determine that we are on mkinitramfs stage
and not trying to boot a not precached initramfs image.
hook scripts on boot can exit due to random failures and shouldn't
interrupt boot there.
Signed-off-by: maximilian attems <maks@debian.org>
this should make bug reports concerning bogus hook scripts easier to
handle, like the *loooong* iscan story.
Closes: 586554
Signed-off-by: maximilian attems <maks@debian.org>
code up the nfs rootdelay in a more efficient way.
here people need the time it takes, so stay on 180s.
Signed-off-by: maximilian attems <maks@debian.org>
The condition of log_end_msg was always true.
Calling do_nfsmount before the loop lets us drop two other checks.
Signed-off-by: Ferenc Wagner <wferi@niif.hu>
Signed-off-by: maximilian attems <maks@debian.org>
only run them when sytax is good. Idea from LP: #570243.
important now that we have errexit on for them.
Signed-off-by: maximilian attems <maks@debian.org>
To make sure the user can read any error messages displayed. (LP: #243226)
usplash and other may cause the user to land somewhere,
where nothing is displayed.
merge from Ubuntu with adding conditional chvt invocation,
as it may not be around.
Thanks: Luke Yelavich <themuso@ubuntu.com>
Thanks: Colin Watson <cjwatson@ubuntu.com>
Signed-off-by: maximilian attems <maks@debian.org>
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 <mika@debian.org>
Signed-off-by: maximilian attems <maks@debian.org>
the removal of vol_id compat code as requested in #585419
is to early as we need it for Lenny upgrades.
Nevertheless have the comment point to the newer tool. :)
Thanks: Christoph Anton Mitterer <calestyo@scientia.net>
Signed-off-by: maximilian attems <maks@debian.org>
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 <tbm@cyrius.com>
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Reviewed-by: Michael Prokop <mika@debian.org>
Execute call_scripts() under "set -e" so hook
scripts can exit initrd build iff necessary.
Closes: #396388
Signed-off-by: Michael Prokop <mika@debian.org>
initramfs-tools currently requires a device to be hard-coded, but this
is not much use if the network device is not known ahead of time. If
the device specified in either /etc/initramfs-tools/initramfs.conf or
on the ip=xxx kernel command line.
usefull for multiple net devices.
Based on patch by Tim Small <tim@seoss.co.uk>
Closes: #566295, #575766
Reviewed-by: Vagrant Cascadian <vagrant@freegeek.org>
Signed-off-by: maximilian attems <maks@debian.org>
looks like i missed a few things on implementing BOOTIF support properly.
somehow i managed to get the order of the mac address backwards. i know i
tested it many times..
Signed-off-by: maximilian attems <maks@debian.org>
might not be all, but a first go in stricter mkinitramfs.
as bonus remove old amusing unused varialbe from day 2..
Signed-off-by: maximilian attems <maks@debian.org>
if tsort is available, use it instead of custom sorting code
if a pre-cached order file is available, use that instead
[ move cache_run_scripts from scripts/functions to hook-scripts
as only used on mkinitramfs build and not on boot ]
Signed-off-by: maximilian attems <maks@debian.org>
Here is a bug description and a patch. Please consider it.
The patch solves a an LTSP client problem that arises when
the clients are connected to Cisco switches that have
spanning-tree calculations enabled.
Also related to:
http://git.debian.org/?p=kernel/initramfs-tools.git;a=commitdiff;h=9c3ec61b1a5e2feaa8d9c6de737eaa00eb446a9c
And
http://git.debian.org/?p=kernel/initramfs-tools.git;a=commitdiff;h=115134f07a0dd042355a2a6fb5a5ca987b000f5d
Here in an extensive explaination:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/181258
Also in the following:
I can report the same problem. A number of diskless clients go
flawlessly through a PXE boot, then the net interface is brought down
when the Linux kernel boots and suddenly, dhcp does not work anymore.
Background research on the network: The clients are connected to Cisco
switches. The configuration of the switches makes them run spanning-tree
calculations. This usually takes some seconds but for large networks it
can take up to 30 40 seconds.
The network port on the switch is turned on, when this calculation has
been finished. This is primarily a security measure.
See also: http://networkers-online.com/blog/2008/08/what-is-bpdu-filter/
If this security measure is turned off, the client boots without
problems. :)
To debug the problem, the following boot line was used:
kernel amd64/vmlinuz
append ro initrd=amd64/initrd.img nbdport=2000 debug=100 break=1
ip=dhcp
In my case, this causes a timeout as can be seen on the attached
screenshots. The kernel loads the NIC module e1000e and reports the type
of NIC et.c. The kernel time reported is 5.927 .
The debug shows the following:
configure_networking
[ -n eth0 ]
[-e /tmp/net-eth0.conf ]
ipconfig -t 60 eth0
At about 6.4 in kernel time, the NIC module reports further about it's
IRQ configuration.
Two seconds (2 sec) later at about 8.56 the NIC module reports that the
Link is up at 100 Mbps full duplex.
Some milliseconds later it signals ADDRCONF(NETDEV_CHANGE): eth0: link
becomes ready .
At this point in time, ipconfig is just waiting for an answer to the
DHCP-discover that really was choked by the switch.
Now this is an obvious flaw in the script. It would be much more
reasonable to try repeatedly with increasing timouts. This would also
be much more efficent.
may I suggest the following timeouts:
4
8
16
30
60
The sum of this timeout is about 120 seconds.
I did some testing with exponential timeout with 1 2 4 8 16 30 ...
and it solved the problem, but it seems that ipconfig runs once
additionally after it has actually done the job.
I am running tests now with an exponent of n/1.5 instead of n.
That would give a sequence of (ca)
2 3 4 6 9 16 25 36 64 100
Attached are a jpeg screenshot of the boot sequence and of
course the patch. The patch is relative to the present git
snapshot.
--
Kindest Regards, Anna Jonna Ármannsdóttir, %& A: Because people read from top to bottom.
Unix System Aministration, Computing Services, %& Q: Why is top posting bad?
University of Iceland.
Signed-off-by: maximilian attems <maks@debian.org>
49337bd looks bogus. It adds the test "[
command ... ]" but I think that should be just "command ..."
Reporte-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: maximilian attems <maks@debian.org>
updated patch against current master, using only shell, and with a cleaner
method to convert BOOTF to a typical mac address.
(closes: #567540)
Signed-off-by: maximilian attems <maks@debian.org>
Sometimes one misses the error message printed by the panic helper function,
for example when attaching a serial console after the fact, or if kernel
messages resulting from udev activity obscure or scroll it away.
Please consider adding some facility like the attached patch.
Thanks,
Feri.
(closes: #569033)
Signed-off-by: maximilian attems <maks@debian.org>
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 <maks@debian.org>
fb should be loaded after initramfs by init to have a beautiful
userland. allows faster boot not to try parsing crazy things
with only posix sh at our hands.
this will need a README.DEBIAN section as noone is now currently
loading fbcon.
Signed-off-by: maximilian attems <maks@debian.org>
thrive for a smaller initramfs,
were loading of the modules is so fast that acpi should be loaeded
by udev after init(8) call.
Signed-off-by: maximilian attems <maks@debian.org>
The i915 DRM module doubles as a framebuffer of sorts, at least in kernel
mode-setting setups; like its cousins intelfb and i810fb, it effectively
requires intel-agp despite not actually using any of its symbols. As
such, could you please arrange for scripts/init-top/framebuffer to give
it the same treatment, per the following patch?:
(closes: #533258)
Signed-off-by: maximilian attems <maks@debian.org>
make it more concise:
* use POSIX ${parameter:+word}
* replace *[/]*) by just */*)
* test exit code of command -v rather then running test -x on it
while we are at it fix another command -v usage in scripts/functions.
Reviewed-by: Colin Watson <cjwatson@ubuntu.com>
Signed-off-by: maximilian attems <maks@debian.org>
the regex was overly severe not allowing dots althoug they are
useful as word ending.
based on a patch in launchpad, that didn't get all occurences right,
but was a good start.
(LP: #305837)
After further experimentation, I discovered additional problems that my
first patch did not address, namely that
1) Some FB drivers need the AGP subsystem up and running before they
are loaded and
2) intelfb needs intel-agp.ko, but does not have a dependency on it.
intelfb does not actually *work* on my testsystem after this (it
crashes), but unlike with plain initramfs-tools, it loads (and prints
something useful if loaded with the probeonly option). I'll try to find
out why it fails to work tomorrow; it's probably an unrelated issue.
[ make the patch applyable, probably whitespace damaged, fix comments,
no need to pass -q to modprobe that is set globaly -maks ]
(closes: #416063, #455876)
Signed-off-by: maximilian attems <maks@debian.org>
