| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
allows wider usage.
(closes: #487409)
Reported-by: Christoph Anton Mitterer <calestyo@scientia.net>
Signed-off-by: maximilian attems <maks@debian.org>
|
|
[ merge from 0.92bubuntu1 ]
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: maximilian attems <maks@debian.org>
|
|
Reported-by: Loïc Grenié <loic.grenie@gmail.com>
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>
|
|
as udev will start earlier, care to blacklist before it loads.
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>
|
|
if blkid is on initramfs use it.
Thanks to Joey Hess <joeyh@debian.org> for calling syntax.
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>
|
|
Newer modprobe will only look at .conf files.
(closes: #541864)
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)
|
|
fix wrong merge of e184c8c2a9ad4520cf0cf4536301c6ae6206e911
scripts/init-top/framebuffer: 84: Syntax error: ")" unexpected (expecting ";;")
|
|
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>
|
|
DO NOT USE -Qb for framebuffer.
Blank ttys when using vesafb (vga=xxx) LP: #129910
[ s/-Q/-q/ for modprobe options -maks ]
|
|
while at it cleanup the variable name that came due to legacy
naming nfsopts in a very early initramfs-tools release.
"The local-top/iscsi initramfs integration script uses the
configure_networking function, which depends on the IPOPTS environmental
variable set by the init script. However, this variable is not
available, because it's not exported from init, and local-top/iscsi is
not sourced but executed. Thus static IP configuration on the kernel
command line is not communicated to the script."
(closes: #516746)
Reported-by: Ferenc Wagner <wferi@niif.hu>
|
|
do the same dance here, same code, just slightly renamed variables.
|
|
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 <dilinger@debian.org>
|
|
(closes: #514997)
Reported-by: Michael Prokop <mika@grml.org>
|
|
since Lenny lvm2 ships it's own hooks scripts, no need to dup.
|
|
in 0.92m, the timeout for ipconfig in scripts/functions was set to 60
seconds. This broke our iscsi-rootfs setups.
It took me a while to debug this, but it seems that 60 seconds is not
enough for switches which have spanning-tree enabled, they need some
more time before they take up a port, in our case between 62 and 65
seconds.
(closes: #511085)
|
|
d-i uses to pass it with the value 1
Reported-by: Frans Pop <fjp@debian.org>
|
|
Fix buglet in parse_numeric where *:* would match mtd:root. We only
want to match numbers. This fixes redboot partition support.
Signed-off-by: Andres Salomon <dilinger@debian.org>
|
|
|
|
udev isn't started at this point and therefore can't create framebuffer
devices. This causes usplash not to run on PS3.
set sane permissions will making the char files.
This reverts commit 0aec8b0c22b7622841c4ab7a3b492b4d2657456f.
|
|
Uvesafb framebuffer driver needs v86d userspace program
but when fb driver is modprobed at init-top stage of initrd,
/dev/zero and /dev/mem are missing because udev have not
been run yet.
|
|
thanks martin f krafft <madduck@debian.org>
closes: #502058
|
|
|
|
rather than waiting forever (LP: #182940).
|
|
On OLPC machines, root is a nand device that is mounted as mtd0 (it is
neither a block device nor a char device). The arguments passed to the
kernel are "ro root=mtd0 rootfstype=jffs2".
Unfortunately, attempting to use an initrd based upon initramfs-tools
on such a machine results in a kernel panic and a syntax error.
Begin: Mounting root file system ... /init: line 172: syntax error:
0xmtd0
The probably appears to be in parse_numeric(); the init scripts
assume that normal devices are always prefixed with /, and root=
strings that aren't are raw device numbers (prefixing them with
0x). I'm not sure if there are other devices similar to mtd that
don't begin with a /.
How about something like the following patch? It's not foolproof,
but it at least ignores things that can't possibly be hex strings.
fixes partially #497133
|
|
after lenny the symlink of udev is meant to be gone,
support partial upgrades from lenny.
|
|
Please make log_begin_msg not emit a trailing newline - this makes the non-
"quiet" output cleaner and results in half as many lines being emitted. For
example:
Begin: Finding root filesytem ...
Done.
Becomes:
Begin: Finding root filesytem ... done.
Patch attached - it also adds a space and alters the case of "done" for
symmetry. This would be especially useful in Debian Live where we show a
large number of these messages by default.
(closes: #494257)
|
|
|
|
ubuntu sync
|
|
thanks to Frans Pop <elendil@planet.nl> for report,
idea stolen from Ubuntu, adapted their boot script
same boot param.
closes: #485786
Signed-off-by: maximilian attems <maks@debian.org>
|
|
Debian users were pasting that without getting the real trouble,
thanks for the better rephrasing.
|
|
add small comment on top, what for we need it.
Signed-off-by: maximilian attems <maks@debian.org>
|
|
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 <madduck@debian.org>
Signed-off-by: maximilian attems <maks@debian.org>
|
|
log_begin_msg already puts ... at the end of the stuff it prints, so no
need to have it in there explicitly.
Signed-off-by: martin f. krafft <madduck@debian.org>
Signed-off-by: maximilian attems <maks@debian.org>
|
|
Parse cmdline for resume_offset, export it and pass it to
the klibc resume binary.
Based on a patch by Alan Jenkins <alan-jenkins@tuffmail.co.uk>.
Bonus small codingstyle clean up of local-premount/resume.
|
|
found on testing that configure_networking() shouldn't make
assumption that ${DEVICE} is really already set.
this still allows to bail out if device is passed and set.
|
|
udev takes care to load the relevant modules.
also PS3PF never had landed in debian thus pretty useless
to take care of it just nuke it and be happy that
udev loading is fixed since 2.6.23-rc1.
|
