Re: Graphical installer on arm64 (netboot and cdrom)
On 2020-04-21 14:14 +0300, Alper Nebi Yasak wrote: > > IMO, the right answer is "tty0 not even being in /proc/consoles in this case > (where it should've also been the /dev/console) is a kernel bug". This is my opinion too, although I'm prepared to change it if someone can given a good reason why this behaviour is reasonable. Well done for posting a kernel patch to fix it. I hadn't noticed as I don't watch kernel stuff. However even if we get that sorted in due course we may in practice have to deal with kernels currently getting this wrong for many years so some bodging and heuristics in D_I may also be experient. One thought - can we just perhaps use /dev/console 'anyway' and that'll get us the right thing even when tty0 has not been properly enabled when it should have been? (I've forgotten how all this works and would need to go read the runes again, and most of my test platforms are currently not easily accessible...) > I tried to > write a patchset [1] a while back, but received no feedback except from > kbuild test bot saying it's broken (s/#elif/#else on the last patch). I > don't know if I did anything wrong or anything right at all. > > [1] > https://lore.kernel.org/lkml/44156595-0eee-58da-4376-fd25b634d...@gmail.com/T/ Hmm. I have no idea if you are doing this right either, but it all sounds plausible. I guess a reports with the s/#elif/#else fix is in order anyway, and that might prompt a response from someone with console clue. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Graphical installer on arm64
On 2020-01-05 22:06 +0300, Alper Nebi Yasak wrote:
> I've been working on getting Debian installer to run on my chromebook
> (kevin) for a while and I've also tested Wookey's patches [1] for enabling
> the graphical parts. The inputs didn't work with just those udebs as
> reported then, but adding 'event-modules-${kernel:Version}' as well to the
> pkg-list fixed that for me.
Great that you've followed up on this. Thanks.
> Can anyone else test this on other arm64 machines? I'm pretty sure it would
> work, but I suspect chromebook hardware to be weird so my success might not
> be indicative of general success.
Sure. I'll test it on eMAG and ThunderX.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Bug#923022: console-setup ships minified shell scripts
Package: console-setup Version: 1.189 Severity: normal Tags: patch /bin/setupcon and /usr/bin/ckbcomp-mini are both shell scripts that are minified (preprocessed to remove comments, whitespace and indenting) before being shipped in the udeb. /usr/lib/base-installer.d/20console-setup and usr/share/console-setup/keyboard-configuration.config setupcon is a 38K script before minifying and 22K afterwards. It's extremely difficult to read to work out what on earth it is doing when in that state, and this is sometimes necessary (e.g. when debugging debian-installer). ckbcomp-mini goes from 5.4K to 3.3K keyboardconfiguration from 47K to 44K The debian config and postinst scripts get the same treatment (in the conventional and udeb packages Why are we minifying these scripts? Perhaps it made sense once to squeeze the size of console-setup by a few K (maybe 24?), but it seems very unlikely to be useful any more, given the cost of making comprehension of the code almost impossible. Attached is a patch to stop doing this. (It makes the udeb 6K bigger) commit dac59c59d9a71612e8a1fbca744ba3b53f57663e Author: Wookey Date: Sat Feb 23 04:10:42 2019 + Stop minifying shell scripts diff --git a/debian/changelog b/debian/changelog index ea8a91d..c43b1db 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +console-setup (1.190) unstable; urgency=medium + + * Stop minifying shell scripts + + -- Wookey Sat, 23 Feb 2019 03:23:03 + + console-setup (1.189) unstable; urgency=medium * Team upload diff --git a/debian/preprocessor b/debian/preprocessor index a9c3aa5..9571309 100755 --- a/debian/preprocessor +++ b/debian/preprocessor @@ -94,11 +94,6 @@ else }' "$file" >$tmp && cat $tmp >"$file" fi -if [ "$mini" ]; then -sed -e 's/^[ \t]*//' -e 's/^#[^!].*//' -e 's/^#$//' <"$file" >$tmp \ - && grep . $tmp >"$file" -fi - rm $tmp exit 0
Re: Multiple console support in d-i
OK. Steve stayed up very late last night checking that this worked OK on x86 and adding some useful logging (allowing for the fact that it needs to work before syslog is actually started). We've checked some more stuff today, including testing the matching finish-install functionality on full installs, and reverting my fancy inittab seddery to go back to simply appending which is more reliable and easier to understand. We are now confident that the 'use init' version is the superior (cleaner and more reliable) approach. That's all merged in the attached patches which we reckon are now ready for general use. I will do some more testing (to check I've not broken hurd - bsd doesn't seem to be built at the moment so there is nothing to break), and of course we are ready to prod it some more if we find this does actually cause unhelpful behaviour for anyone. I also need to check the docs which no doubt need a few updates. I've found a couple of other things whilst poking about in the D-I entrails. There is plenty of cruft from older ways of doing things, which of course tends to get ignored if it's not actually breaking things, largely due to chronic undermanning in D-I land. I'll file some bugs and patches. None of it is urgent, but worth noting before I forget. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ diff --git b/debian/changelog a/debian/changelog index a7c80c3..e23b91e 100644 --- b/debian/changelog +++ a/debian/changelog @@ -7,7 +7,11 @@ rootskel (1.127) UNRELEASED; urgency=medium [ Holger Wansing ] * Remove trailing whitespaces from changelog file, to fix lintian tag. - -- Samuel Thibault Fri, 08 Feb 2019 01:50:37 +0200 + [ Wookey ] + * Support multiple consoles - Run D-I on all enabled consoles + * Rename reopen-console to choose-consoles + + -- Wookey Fri, 22 Feb 2019 15:57:39 + rootskel (1.126) unstable; urgency=medium diff --git b/src/etc/inittab-hurd a/src/etc/inittab-hurd index a7b8a23..eeff7e2 100644 --- b/src/etc/inittab-hurd +++ a/src/etc/inittab-hurd @@ -2,10 +2,9 @@ # busybox init configuration for debian-installer # main rc script -::sysinit:/sbin/reopen-console /sbin/debian-installer-startup +::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup # main setup program -::respawn:/sbin/reopen-console /sbin/debian-installer # convenience shells tty2::askfirst:-/bin/sh diff --git b/src/etc/inittab-kfreebsd a/src/etc/inittab-kfreebsd index 748f19b..c328548 100644 --- b/src/etc/inittab-kfreebsd +++ a/src/etc/inittab-kfreebsd @@ -2,10 +2,9 @@ # busybox init configuration for debian-installer # main rc script -::sysinit:/sbin/reopen-console /sbin/debian-installer-startup +::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup # main setup program -::respawn:/sbin/reopen-console /sbin/debian-installer # convenience shells ttyv1::askfirst:-/bin/sh diff --git b/src/etc/inittab-linux a/src/etc/inittab-linux index a7b8a23..d7136e2 100644 --- b/src/etc/inittab-linux +++ a/src/etc/inittab-linux @@ -2,10 +2,7 @@ # busybox init configuration for debian-installer # main rc script -::sysinit:/sbin/reopen-console /sbin/debian-installer-startup - -# main setup program -::respawn:/sbin/reopen-console /sbin/debian-installer +::sysinit:/sbin/choose-consoles /sbin/debian-installer-startup # convenience shells tty2::askfirst:-/bin/sh @@ -19,3 +16,6 @@ tty4::respawn:/usr/bin/tail -f /var/log/syslog # re-exec init on receipt of SIGHUP/SIGUSR1 ::restart:/sbin/init + +# main setup program +# Entries will be added here as the system starts up diff --git b/src/sbin/Makefile a/src/sbin/Makefile index dec554e..f1a4f5f 100644 --- b/src/sbin/Makefile +++ a/src/sbin/Makefile @@ -8,7 +8,7 @@ files_exec = \ debian-installer-startup \ shutdown \ init:init-$(DEB_HOST_ARCH_OS) \ - reopen-console:reopen-console-$(DEB_HOST_ARCH_OS) \ + choose-consoles:choose-consoles-$(DEB_HOST_ARCH_OS) \ steal-ctty ifeq ($(DEB_HOST_ARCH_OS),linux) diff --git b/src/sbin/reopen-console-hurd a/src/sbin/choose-consoles-hurd similarity index 61% rename from src/sbin/reopen-console-hurd rename to src/sbin/choose-consoles-hurd index 7f9b54e..bef2b73 100755 --- b/src/sbin/reopen-console-hurd +++ a/src/sbin/choose-consoles-hurd @@ -4,9 +4,9 @@ # corresponding to the console we are actually using. console= -if ! [ -f /var/run/console-device ]; then - tty > /var/run/console-device +if ! [ -f /var/run/console-devices ]; then + tty > /var/run/console-devices fi # Some other session may have it as ctty. Steal it from them -exec /sbin/steal-ctty $(cat /var/run/console-device) "$@" +exec /sbin/steal-ctty $(cat /var/run/console-devices) "$@" diff --git b/src/sbin/reopen-console-kfreebsd a/src/sbin/choose-consoles-kfreebsd similarity index 87% rename from src/sbin/reopen-console-kfreebsd rename to src/sbin/choose-consoles-kfreebsd index 6dec149..2dd292a 100755 --- b/src/sbin/reopen-console-kfreebsd +++
Re: Multiple console support in d-i
On 2019-02-21 00:55 +, Steve McIntyre wrote:
> Hey Wookey,
>
> Reviewing the code from your patches in sequence, I think the approach
> looks good *except* I think you've missed a patch or a commit or
> something.
>
> Trying to apply debian-installer-multiple-consoles.patch and
> rootskel-multiple-consoles-inittab.patch in sequence, there are patch
> failures. They clearly depend in that order for the changes in
> src/etc/inittab-linux, but the src/sbin/reopen-console-linux hunks
> don't match up. The last thing I want to do here is miss a line in the
> middle of fixing up by hand and break this... :-)
>
> Could you post a single patch against current HEAD with all of your
> changes rolled up please?
Well, there are two branches. The original implmentation and the 'use init'
implementation.
So attached are two independent (i.e. each is against rootskel HEAD) for those.
Original: rootskel-multiple-consoles2.patch
Init-based: rootskel-multiple-consoles-inittab3.patch
Use one or the other, not both.
The finish-install patch has to be separate because it's a different git repo.
Also included.
Required in either case.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
diff --git a/src/etc/inittab-linux b/src/etc/inittab-linux
index a7b8a23..437e208 100644
--- a/src/etc/inittab-linux
+++ b/src/etc/inittab-linux
@@ -5,7 +5,7 @@
::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
# main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
+::respawn:/sbin/reopen-console --all-consoles /sbin/debian-installer
# convenience shells
tty2::askfirst:-/bin/sh
diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux
index 3287dd0..e13bfa3 100755
--- a/src/sbin/reopen-console-linux
+++ b/src/sbin/reopen-console-linux
@@ -1,74 +1,68 @@
#!/bin/sh
# In order to give proper access to the tty, we need to locate the device
-# corresponding to the console we are actually using.
+# corresponding to each console we are actually using.
+
+# This script is run twice, once at sysinit to run the debian-installer-startup
+# rc scripts, and once to start the installer itself.
+# The first time it parses the consoles used, the second time they are read from files
+# The startup scripts need to be run just once (on one console) (not idempotent)
+# The installer is run on all the enabled consoles (using the --all-consoles option)
+
NL="
"
-console=
-if ! [ -f /var/run/console-device ]; then
- # If the kernel emitted a "handover" message, then it's the one
- case $(uname -r) in
- 2.6.2*|2.6.3[01]*)
- console="$(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console handover: boot \[.*\] -> real \[(.*)\]$/\2/p')"
- ;;
- 2.6.3[234567]*)
- console="$(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled, bootconsole disabled$/\2/p')"
- ;;
- *) # >= 2.6.38
- console_major_minor="$(get-real-console-linux)"
- console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
- console="${console_raw##*/}"
- ;;
- esac
-
- # Except if it is the wrong type...
- if [ "$console" ] && [ "$(console-type)" = serial ] && \
- expr "$console" : "tty[0-9]" >/dev/null; then
- console=
- fi
+if ! [ -f /var/run/console-devices ]; then
consoles=
- if [ -z "$console" ]; then
- # Retrieve all enabled consoles from boot log; ignore those
- # for which no device file exists
- for cons in $(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled/\2/p')
- do
- if [ -e "/dev/$cons" ]; then
-consoles="${consoles:+$consoles$NL}$cons"
- fi
- done
- # Only one console? Then we are good.
- if [ $(echo "$consoles" | wc -l) -eq 1 ]; then
- console="$consoles"
+ preferred=
+ # Retrieve all enabled consoles from kernel; ignore those
+ # for which no device file exists
+
+ kernelconsoles="$(cat /proc/consoles)"
+ for cons in $(echo "$kernelconsoles" | sed -n -r -e 's/(^.*) .*\((.*)\).*$/\1/p' )
+ do
+ status=$(echo "$kernelconsoles" | grep $cons | sed -n -r -e 's/(^.*) *.*\((.*)\).*$/\2/p' )
+ if [ -e "/dev/$cons" ] && [ $(echo "$status" | grep -o 'E') ]; then
+ consoles="${consoles:+$consoles$NL}$cons"
fi
- fi
+ # 'C' console is 'most prefered'.
+ if [ $(echo "$status" | grep -o 'C') ]; then
+ preferred="$cons"
+ fi
+ done
- if [ -z "$console" ]; then
- # Locate the last enabled console present on the command line
- for arg in $(cat /proc/cmdline); do
- case $arg in
- console=*)
-arg=${arg#console=}
-cons=${arg%%,*}
-if echo "$consoles" | grep -q "^$cons$"; then
- console=$cons
-fi
-;;
- esac
-
Re: Multiple console support in d-i
On 2019-02-21 00:55 +, Steve McIntyre wrote: > Hey Wookey, > > Reviewing the code from your patches in sequence, I think the approach > looks good *except* I think you've missed a patch or a commit or > something. > > Trying to apply debian-installer-multiple-consoles.patch and > rootskel-multiple-consoles-inittab.patch in sequence, there are patch > failures. They clearly depend in that order for the changes in > src/etc/inittab-linux, Yeah - I noticed after posting that one patch depended on the other, as opposed to them being independent, which wasn't what I meant to do. Sorry about that. > Could you post a single patch against current HEAD with all of your > changes rolled up please? Will do. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Multiple console support in d-i
On 2019-02-09 04:11 +, Wookey wrote: > Future work: > > All this faffage has made me realise that a better approach to all > this would probably be to get rid of all this 'steal-ctty' bodgery, > and use init to do it's job: it's designed to run multiple things on > multiple consoles, and deal with file handles and them failing etc. > > The catch is that to make this work we'd have to use sysinit: to run > the console-choosing code, then write a new inittab containing one > respawn:/sbin/debian-installer for each console instance, then HUP > init. This should do exactly the right thing (assuming that busybox > init isn't too thick to get HUPing right). OK. This does indeed work nicely and is a cleaner solution than what is currently in D-I. It probably works for hurd and bsd too assuming their init behaviour is similar? (I think kill -HUP 1 should do the same thing on all 3 kernels?) (anyone up for testing these?) So now inittab looks like: # main rc script ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup # main setup program tty0::respawn:/sbin/debian-installer ttyAMA0::respawn:/sbin/debian-installer (these lines added for whatever consoles are found) (and the rest as before - spare shells, tty4 for logging and restart stuff) Attached is a patch implementing this. It does rely on the inittab comment '# main setup program' existing in order to anchor the sed edit, so perhaps a comment should go in there so someone doesn't accidentally edit it in the future and break this code? Or we could just use a simple append (it's not aesthetic just putting them on the end but it does work fine), or just 'insert at line n'. Given the constrained environment I don't think it matters much - maintainability is probably the most important thing here. Steal-ctty is still present for the initial run of the debian-install-startup scripts but I suspect it's not actually needed. Anyone know if there was ever a good reason for running the rc scripts through this as well as doing so for the installer itself? This all works with netbook-gtk too (X starts on framebuffer, as before) Feedback on this patch is welcome. Note that my finish-install patch should be applied too if this one is used. Issues: The framebuffer console came up with some UTF-8 chars as blocks (ones not in 8859-1?). I've seen this before once with the old code then it went away again, so I'm not sure it's anything to do with these changes but it might be. The LANG=C.UTF-8, TERM=linux, TERM_TYPE=virtual, TERM_FRAMEBUFFER=yes, which seems reasonable. Clues welcome. fonts or TERM configuration? Further work: There is more tidying that could be done here, but some discussion is in order first. With things done this way 'reopen-console' is something of a misnomer as it only gets run once. 'choose-console' would be better. Or possibly something like 'initialise-installer' as it now chooses the consoles, calls the init-script runner and reinits to start the real installer. Perhaps a more logical split is choose-consoles: (OS-specific) 1) parses consoles, saves in /var/run files 2) runs debian-installer-startup debian-installer-startup: (OS-independent) 1) modifies inittab 2) runs startup scripts 3) HUPs init This seems a bit cleaner and better-named? Also is there any point having choose-console run $@ now there is only one thing it runs (debian-installer-startup)? The fly in this pointment is that there is one script that uses the existing /sbin/debian-installer-startup. That is debian-installer-launcher/debian-installer.sh which runs it in a live image chroot so moving the restart init there would be an unexpected change of interface. The desire to leave that interface alone results in this: choose-consoles: (OS-specific) 1) parses consoles, saves in /var/run files 2) modifies inittab 3) runs debian-installer-startup 4) HUPs init debian-installer-startup: (OS-independent) 1) runs startup scripts Which is essentially the existing patch, but renaming reopen-console -> choose-consoles currently we have: ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup but I suggest we just change it to: ::sysinit:/sbin/choose-consoles and choose consoles can explicitly run /sbin/debian-installer-startup This just makes it a bit more obvious how things work/fit together. Have I missed anything? Does anyone care about all this? Shall I just stop now (it's working fine) or tidy a bit more to make the names clearer and reduce the cruft further? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ commit 7b3718082645c2265f96b8349ae25a31f3bc73e3 Author: Wookey Date: Mon Feb 11 16:39:40 2019 + Use inittab to run multiple installers diff --git a/src/etc/inittab-linux b/src/etc/inittab-linux index 437e208..830ee94 100644 --- a/src/etc/inittab-linux +++ b/src/etc/inittab-linux @@ -5,7 +5,6 @@ ::sysinit:/sbin/reopen-console /sbin/debian-in
Re: Multiple console support in d-i
On 2019-01-19 11:08 +, Steve McIntyre wrote:
> On Sat, Jan 19, 2019 at 04:27:05AM +0000, Wookey wrote:
[Re: adding multiple console support to D-I, including changing
/var/run/console-device with one device line to be
/var/run/console-devices with 1 or more lines]
> >The only other place this affects is
> >packages/finish-install.d/90console which reads
> >/var/run/console-device when tidying up at the end in order to write
> >inittab entries for the used console device (serial, xen, etc).
So here is the patch for that so that the right file is looked in and
any serial devices are dealt with as before, alowing for the fact there
may be more than one console device listed.
This code is not well-tested yet, but I think it does the right
thing. Review welcome. I can't see any reason why running through this
more than once should change anything, but I could be missing something.
I note that there is a load of upstart support in here. Can anyone
thing of a reason to keep that? I suspect it should go. Happy to do that if we
agree.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
commit 2e238ab985eebd44f29cc7b5cd6b7cacc71d792e
Author: Wookey
Date: Fri Feb 15 01:50:44 2019 +
Update to deal with multiple consoles
diff --git a/finish-install.d/90console b/finish-install.d/90console
index bd2f528..0045046 100755
--- a/finish-install.d/90console
+++ b/finish-install.d/90console
@@ -38,72 +38,76 @@ case "$(udpkg --print-os)" in
hurd)
# TODO: detect VGA hurd console, and enable it in installed
# system.
- console=console
+ consoles=/dev/console
;;
*)
- console=$(cat /var/run/console-device)
- console=${console#/dev/}
+ consoles=$(cat /var/run/console-devices)
;;
esac
-if [ -f /target/etc/init/tty1.conf ]; then
- upstart_tty1=/target/etc/init/tty1.conf
- upstart_console () {
+for console in $consoles
+do
+ console=${console#/dev/}
+
+ if [ -f /target/etc/init/tty1.conf ]; then
+ upstart_tty1=/target/etc/init/tty1.conf
+ upstart_console () {
echo "/target/etc/init/$1.conf"
- }
-elif [ -f /target/etc/event.d/tty1 ]; then
- upstart_tty1=/target/etc/event.d/tty1
- upstart_console () {
+ }
+ elif [ -f /target/etc/event.d/tty1 ]; then
+ upstart_tty1=/target/etc/event.d/tty1
+ upstart_console () {
echo "/target/etc/event.d/$1"
- }
-else
- upstart_tty1=
-fi
-
-case "$console" in
-tty[A-Zu]*|duart*)
- log "Configuring init for serial console"
- consoletype=${console%%[0-9]*}
- ttyline=${console#$consoletype}
- ttyspeed=$(chroot /target stty --file /dev/$console speed)
- ttyterm="$TERM"
-
- flowctrlarg=""
- if uses_hw_flowcontrol $console; then
- flowctrlarg="-h "
+ }
+ else
+ upstart_tty1=
fi
- if [ -z "$ttyterm" ]; then ttyterm=vt100; fi
- if [ -z "$ttyspeed" ]; then ttyspeed=9600; fi
+ case "$console" in
+ tty[A-Zu]*|duart*)
+ log "Configuring init for serial console"
+ consoletype=${console%%[0-9]*}
+ ttyline=${console#$consoletype}
+ ttyspeed=$(chroot /target stty --file /dev/$console speed)
+ ttyterm="$TERM"
+
+ flowctrlarg=""
+ if uses_hw_flowcontrol $console; then
+ flowctrlarg="-h "
+ fi
- if [ -f /target/etc/inittab ]; then
- # Disable regular VTs
- if [ -z "$KEEP_VT" ]; then
+ if [ -z "$ttyterm" ]; then ttyterm=vt100; fi
+ if [ -z "$ttyspeed" ]; then ttyspeed=9600; fi
+
+ if [ -f /target/etc/inittab ]; then
+ # Disable regular VTs
+ if [ -z "$KEEP_VT" ]; then
sed -i -e "s/^\([1-6]\):/#\1:/" /target/etc/inittab
+ fi
+ # Enable serial console
+ sed -i -e "s/^#T0\(.*\)ttyS.*/T$ttyline\1$console $ttyspeed $ttyterm/" \
+ /target/etc/inittab
+ sed -i -e "s/^\(T$ttyline.*\) -8/\1/" /target/etc/inittab
+ sed -i -e "s/^\(T$ttyline.* \)-L/\1$flowctrlarg-L/" /target/etc/inittab
+ fi
+ if [ "$upstart_tty1" ]; then
+ sed -e "s/^\(exec.*getty \).*/\1-L $console $ttyspeed $ttyterm/" \
+ -e "s/tty1/$console/g" \
+ "$upstart_tty1" > "$(upstart_console "$console")"
+ sed -i -e "s/^\(exec.*\) -8/\1/" "$(upstart_console "$console")"
+ sed -i -e "s/^\(exec.*\)-L/\1$flowctrlarg-L/" "$(upstart_console "$console")"
+ fi
+ if [ "$(readlink /target/sbin/init)" = "/lib/systemd/systemd" ] ; then
+ chroot /target systemctl --no-reload --quiet enable serial-getty@"$console".service
fi
- # Enable serial console
- sed -i -e "s/^#T0\(.*\)ttyS.*/T$ttyline\1$console $ttyspeed $ttyterm/" \
- /target/etc/inittab
- sed -i -e "s/^\(T$ttyline.*\) -8/\1/" /target/etc/inittab
- sed -i -e
Bug#911133: Debian Installer assumes serial console on arm64
Here is a patch to debian-installer to enable it to run D-I on all available
consoles.
This is one part of making arm64 machines work 'just like PCs' in the installer.
I have also done some work on getting the graphical installer
working. I have enabled that, but input is not working yet, so 'more
later' on that.
The multiple-console support involves a major revamp of
'reopen-consoles-linux' in rootskel in debian-installer, to get rid of
a load of old cruft, and use /proc/consoles (i.e. the kernel's list)
to choose the set of enabled consoles, running the startup rc scripts
on just one console (to avoid doing things twice), then running
debian-installer itself on all the consoles that are enabled and have
device files.
More details are available in the thread steve linked to on debian-boot.
It seems like there is actually a cleaner way to do this, by getting
init to do the heavy process/session/parallel-tasks lifting (instead
of reopen-consoles and steal-ctty). I have a proof-of-concept patch
for that, but it's not actually working right yet. I'll send that in
when it does if I don't hit any roadblocks.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
diff --git a/src/etc/inittab-linux b/src/etc/inittab-linux
index a7b8a23..437e208 100644
--- a/src/etc/inittab-linux
+++ b/src/etc/inittab-linux
@@ -5,7 +5,7 @@
::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
# main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
+::respawn:/sbin/reopen-console --all-consoles /sbin/debian-installer
# convenience shells
tty2::askfirst:-/bin/sh
diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux
index 3287dd0..e13bfa3 100755
--- a/src/sbin/reopen-console-linux
+++ b/src/sbin/reopen-console-linux
@@ -1,74 +1,68 @@
#!/bin/sh
# In order to give proper access to the tty, we need to locate the device
-# corresponding to the console we are actually using.
+# corresponding to each console we are actually using.
+
+# This script is run twice, once at sysinit to run the debian-installer-startup
+# rc scripts, and once to start the installer itself.
+# The first time it parses the consoles used, the second time they are read from files
+# The startup scripts need to be run just once (on one console) (not idempotent)
+# The installer is run on all the enabled consoles (using the --all-consoles option)
+
NL="
"
-console=
-if ! [ -f /var/run/console-device ]; then
- # If the kernel emitted a "handover" message, then it's the one
- case $(uname -r) in
- 2.6.2*|2.6.3[01]*)
- console="$(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console handover: boot \[.*\] -> real \[(.*)\]$/\2/p')"
- ;;
- 2.6.3[234567]*)
- console="$(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled, bootconsole disabled$/\2/p')"
- ;;
- *) # >= 2.6.38
- console_major_minor="$(get-real-console-linux)"
- console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
- console="${console_raw##*/}"
- ;;
- esac
-
- # Except if it is the wrong type...
- if [ "$console" ] && [ "$(console-type)" = serial ] && \
- expr "$console" : "tty[0-9]" >/dev/null; then
- console=
- fi
+if ! [ -f /var/run/console-devices ]; then
consoles=
- if [ -z "$console" ]; then
- # Retrieve all enabled consoles from boot log; ignore those
- # for which no device file exists
- for cons in $(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled/\2/p')
- do
- if [ -e "/dev/$cons" ]; then
-consoles="${consoles:+$consoles$NL}$cons"
- fi
- done
- # Only one console? Then we are good.
- if [ $(echo "$consoles" | wc -l) -eq 1 ]; then
- console="$consoles"
+ preferred=
+ # Retrieve all enabled consoles from kernel; ignore those
+ # for which no device file exists
+
+ kernelconsoles="$(cat /proc/consoles)"
+ for cons in $(echo "$kernelconsoles" | sed -n -r -e 's/(^.*) .*\((.*)\).*$/\1/p' )
+ do
+ status=$(echo "$kernelconsoles" | grep $cons | sed -n -r -e 's/(^.*) *.*\((.*)\).*$/\2/p' )
+ if [ -e "/dev/$cons" ] && [ $(echo "$status" | grep -o 'E') ]; then
+ consoles="${consoles:+$consoles$NL}$cons"
fi
- fi
+ # 'C' console is 'most prefered'.
+ if [ $(echo "$status" | grep -o 'C') ]; then
+ preferred="$cons"
+ fi
+ done
- if [ -z "$console" ]; then
- # Locate the last enabled console present on the command line
- for arg in $(cat /proc/cmdline); do
- case $arg in
- console=*)
-arg=${arg#console=}
-cons=${arg%%,*}
-if echo "$consoles" | grep -q "^$cons$"; then
- console=$cons
-fi
-;;
- esac
- done
+ if [ -z "$consoles" ]; then
+ # Nothing fo
Re: Multiple console support in d-i
On 2019-02-09 04:11 +, Wookey wrote:
> On 2019-01-25 03:45 +0000, Wookey wrote:
>
> Attached is a patch which provides working multiconsole support for
> linux (not hurd or bsd, sorry).
>
> One bug I just noticed in the bit we did today is that the 'default'
> preferred console (for when one is not indicated by the kernel) avoids
> the existence-check for the /dev file, so that should be
> improved. It's not hard, but I'll resist doing it now and sending an
> untested patch :-)
OK. Updated version attached which is more robust about choosing the
'preferred' console.
I did some tests and discovered that, at least on thunderx, you get
slightly different behaviour WRT kernel command line options than the
old code, but I don't think it really matters.
Essentially the set of consoles is now 'those listed on the kernel
command line + whatever UEFI says is the default console'. Previously
you got 'whatever UEFI says is the default console, or the last one on
the kernel cmd line'. i.e the kernel no longer overrides the UEFI console,
it gets added. Now that D-I works on all provided consoles this doesn't
really matter much.
So on thunderx, for example, you get this:
default (nothing specified):
consoles: /dev/ttyAMA0
preferred: /dev/ttyAMA0
cmdline: console=tty0
consoles: /dev/tty0 /dev/ttyAMA0
preferred: /dev/tty0
cmdline: console=tty0 console=ttyAMA0
consoles: /dev/tty0 /dev/ttyAMA0
preferred: /dev/tty0
cmdline: console=ttyAMA0
consoles: /dev/ttyAMA0
preferred: /dev/ttyAMA0
Which all seems reasonable.
Testing this on some other machines/arches is the next thing to do, although
just checking what /proc/consoles shows tells you what should happen.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
diff --git a/src/etc/inittab-linux b/src/etc/inittab-linux
index a7b8a23..437e208 100644
--- a/src/etc/inittab-linux
+++ b/src/etc/inittab-linux
@@ -5,7 +5,7 @@
::sysinit:/sbin/reopen-console /sbin/debian-installer-startup
# main setup program
-::respawn:/sbin/reopen-console /sbin/debian-installer
+::respawn:/sbin/reopen-console --all-consoles /sbin/debian-installer
# convenience shells
tty2::askfirst:-/bin/sh
diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux
index 3287dd0..e13bfa3 100755
--- a/src/sbin/reopen-console-linux
+++ b/src/sbin/reopen-console-linux
@@ -1,74 +1,68 @@
#!/bin/sh
# In order to give proper access to the tty, we need to locate the device
-# corresponding to the console we are actually using.
+# corresponding to each console we are actually using.
+
+# This script is run twice, once at sysinit to run the debian-installer-startup
+# rc scripts, and once to start the installer itself.
+# The first time it parses the consoles used, the second time they are read from files
+# The startup scripts need to be run just once (on one console) (not idempotent)
+# The installer is run on all the enabled consoles (using the --all-consoles option)
+
NL="
"
-console=
-if ! [ -f /var/run/console-device ]; then
- # If the kernel emitted a "handover" message, then it's the one
- case $(uname -r) in
- 2.6.2*|2.6.3[01]*)
- console="$(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console handover: boot \[.*\] -> real \[(.*)\]$/\2/p')"
- ;;
- 2.6.3[234567]*)
- console="$(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled, bootconsole disabled$/\2/p')"
- ;;
- *) # >= 2.6.38
- console_major_minor="$(get-real-console-linux)"
- console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
- console="${console_raw##*/}"
- ;;
- esac
-
- # Except if it is the wrong type...
- if [ "$console" ] && [ "$(console-type)" = serial ] && \
- expr "$console" : "tty[0-9]" >/dev/null; then
- console=
- fi
+if ! [ -f /var/run/console-devices ]; then
consoles=
- if [ -z "$console" ]; then
- # Retrieve all enabled consoles from boot log; ignore those
- # for which no device file exists
- for cons in $(dmesg -s 262143 |
- sed -n -r -e 's/(.*\])? *console \[(.*)\] enabled/\2/p')
- do
- if [ -e "/dev/$cons" ]; then
-consoles="${consoles:+$consoles$NL}$cons"
- fi
- done
- # Only one console? Then we are good.
- if [ $(echo "$consoles" | wc -l) -eq 1 ]; then
- console="$consoles"
+ preferred=
+ # Retrieve all enabled consoles from kernel; ignore those
+ # for which no device file exists
+
+ kernelconsoles="$(cat /proc/consoles)"
+ for cons in $(echo "$kernelconsoles" | sed -n -r -e 's/(^.*) .*\((.*)\).*$/\1/p' )
+ do
+ status=$(echo "$kernelconsoles" | grep $cons | sed -n -r -e 's/(^.*) *.*\((.*)\).*$/\2/p' )
+ if [ -e "/dev/$cons" ] && [ $(echo "$status" | grep -o 'E') ]; then
+ consoles="${co
Re: Multiple console support in d-i
On 2019-01-25 03:45 +, Wookey wrote: > So, unless anyone can see a problem with this approach, I'll finish > this off. Trying to do it with separate /var/run/consoles and > /var/run/extra-consoles files was getting very messy. OK. This took way longer than I hoped as it was not entirely trivial to get everything working. Attached is a patch which provides working multiconsole support for linux (not hurd or bsd, sorry). After getting the proc/console choosing code working nicely the installer was still mysteriously not working (nothing on consoles except debug) unless I let it respawn in which case it sort of worked (things appeared but input oddness and continuous respawning isn't much use to anyone). I was confused for a while as to what was going on but eventually worked it out. Just to recap: The objective here is to run D-I on all the enabled consoles, (and ideally not fiddle with the code any more than is needed). First step was upgrading the console parsing code to use /proc/consoles to get the list, noting the preferred console if there is one marked as such. The main complication is that reopen-consoles is run twice by init, once with debian-installer-startup and once with debian-installer: # main rc script ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup # main setup program ::respawn:/sbin/reopen-console /sbin/debian-installer The first run of reopen-console works out which consoles to use, and writes it in a file, (/var/run/console-devices), the second run just uses that file. debian-installer-startup is just a shell script that runs through all the debian-installer-startup.d rc scripts, like S01mount, S04countcpus-linux-hppa, S10syslog. debian-installer actually runs the installer, on the second invocation of reopen-consoles. So the original plan was just to run $@ (debian-installer) on the found consoles. But doing that for the rc scripts is not helpful. Most of it is idempotent, but you end up with two syslogs and two klogds and running it all twice on different consoles really isn't right. So I added an --all-consoles option to declare that we want something (/sbin/debian-installer in this case) run on all the consoles. # main rc script ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup # main setup program ::respawn:/sbin/reopen-console --all-consoles /sbin/debian-installer It's also worth noting that 'steal-ctty' cannot set the process as 'controlling tty' when two are run, because only one process can be controlling tty in a session. So I did add error checking to that (it had none before), but had to take it out again for the 'set ctty' IOCTL as it's correct for it to fail in the muti-console case. So what happens now is that the rc-scripts are run on the 'preferred' console (or the first console listed if none are marked preferred), then D-I is run on all of them. It does not return to init in this case (as previously discussed). This is an important improvement so despite it having ended up rather late in the day, I hope we can include this for buster. I'm happy to do more work on tidying up any breakage if we find any. Future work: All this faffage has made me realise that a better approach to all this would probably be to get rid of all this 'steal-ctty' bodgery, and use init to do it's job: it's designed to run multiple things on multiple consoles, and deal with file handles and them failing etc. The catch is that to make this work we'd have to use sysinit: to run the console-choosing code, then write a new inittab containing one respawn:/sbin/debian-installer for each console instance, then HUP init. This should do exactly the right thing (assuming that busybox init isn't too thick to get HUPing right). That is way cleaner and I'm happy to have a go at that, but it feels more intrusive and unless I'm very lucky it may take a while so I sugest we go with the above for now, as it works already. One bug I just noticed in the bit we did today is that the 'default' preferred console (for when one is not indicated by the kernel) avoids the existence-check for the /dev file, so that should be improved. It's not hard, but I'll resist doing it now and sending an untested patch :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ diff --git a/src/etc/inittab-linux b/src/etc/inittab-linux index a7b8a23..437e208 100644 --- a/src/etc/inittab-linux +++ b/src/etc/inittab-linux @@ -5,7 +5,7 @@ ::sysinit:/sbin/reopen-console /sbin/debian-installer-startup # main setup program -::respawn:/sbin/reopen-console /sbin/debian-installer +::respawn:/sbin/reopen-console --all-consoles /sbin/debian-installer # convenience shells tty2::askfirst:-/bin/sh diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux index 3287dd0..32dfd24 100755 --- a/src/sbin/reopen-console-linux +++ b/src/sbin/reopen-console-linux @@ -1,74 +1,67 @@ #!/bin/sh # In order to give proper access to the tty, we need
Re: Multiple console support in d-i
On 2019-01-23 08:35 +, Ian Campbell wrote:
> On Wed, 2019-01-23 at 03:41 +0000, Wookey wrote:
> > Any idea how we should choose a D-I primary console when none of them
> > is marked 'preferred'? Or should D-i do away with the concept and try
> > to treat them all equally (which is a slightly more intrusive
> > change).
> Even if the bug were fixed it seems sensible to deal with this case,
> last one (with sufficient other flags set) seems like as good as
> anything...
OK. I've had 'fun with shell' getting this right and gone through a
couple of iterations.
After some thought, so far as I can see the 'preferred' console
concept is no longer useful once D-I runs on more than one. We don't
know which one the user is going to actually use, and the whole point
is that all the instances should work the same. We're not trying the
choose the 'right' console any more, just exposing the interface on
all the ones that (should) work.
The only reason for keeping it would be to keep the reopen-console
logic more like it currently is, so that the preferred console got to
replace the reopen-consoles process (via exec) and the others didn't
(becoming child processes of reopen-consoles dash instance). But you
end up with rather cleaner code if in fact you just run D-I on all enabled
consoles and treat them equivalently (as child processes). New version
(with debug still in) attached to show what I mean (or see below).
However this does lead to a question about D-I and inittab respawn logic.
Currently reopen-console ends with
exec D-I
so D-I replaces the process.
It is started with this inittab line:
::respawn:/sbin/reopen-console /sbin/debian-installer
Do we ever make use of D-I finishing in such a way that init finds the
process is gone and respawns? My assumption is that we don't want this
to happen, at least in general (otherwise the installer would restart
when you finished, rather confusingly). But perhaps there are error
cases when this is wanted?
The reason it matters is because it affects how the multiple D-Is on
different consoles should be started and what we should do when one
quits, or all quit.
My current code does this:
for cons in $(cat /var/run/console-devices)
do
# Some other session may have console as ctty. Steal it from them
( exec /sbin/steal-ctty $cons "$@" & )
done
#don't return to init
sleep infinity
Which just starts a D-I on all the consoles, then sits forever (to
stop init from re-running this code over and over). You _could_ have
some extra logic to make one special, and exec that one, and keep the
others as child-processes, but I'm not convinced that this achieves
anything (except complexity, and potentially confusingly different
behaviour between consoles), unless the respawning is important in
some way I have failed to grok so far?
(You'll note the above is rather nicer than my first effort with two
different /var/run/* files, and $console and $extraconsoles). Having
just the one 'consoles used' list file makes it all cleaner. (I've
fixed up finish-install/finish-install.d/90console to deal with more
than one console listed in that file too)
Possibly what we'd really like is that if you quit _any_ console D-I
instance then it would return and respawn, but a) I can't work out how
to do that (you can only exec one thing) and b) does it actually help?
So, unless anyone can see a problem with this approach, I'll finish
this off. Trying to do it with separate /var/run/consoles and
/var/run/extra-consoles files was getting very messy.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
#!/bin/sh
# In order to give proper access to the tty, we need to locate the device
# corresponding to each console we are actually using.
NL="
"
if ! [ -f /var/run/console-devices ]; then
consoles=
preferred=
# Retrieve all enabled consoles from kernel; ignore those
# for which no device file exists
kernelconsoles="$(cat /proc/consoles)"
for cons in $(echo "$kernelconsoles" | sed -n -r -e 's/(^.*)
.*\((.*)\).*$/\1/p' )
do
echo "cons in /proc/consoles: $cons"
status=$(echo "$kernelconsoles" | grep $cons | sed -n -r -e
's/(^.*) *.*\((.*)\).*$/\2/p' )
echo "console: $cons, status: $status"
if [ -e "/dev/$cons" ] && [ $(echo "$status" | grep -o 'E') ];
then
consoles="${consoles:+$consoles$NL}$cons"
fi
# 'C' console is 'most prefered'. Do we care?
if [ $(echo "$status" | grep -o 'C') ]; then
preferred="$cons"
fi
done
echo "after parsing, consoles set to: $consoles"
echo "after parsing, preferred is: $preferred"
Re: Multiple console support in d-i
On 2019-01-22 08:23 +, Ian Campbell wrote: > On Tue, 2019-01-22 at 04:31 +0000, Wookey wrote: > > On 2019-01-20 03:02 +, Ben Hutchings wrote: > > > Reading /proc/consoles is exactly what you should do. > > > > Checking this on a booted thunderx machine (with no explicit kernel cmdline > > options) it lists > > ttyAMA0 > > > > If I boot with explicit console=tty0 console=ttyAMA0 on the kernel cmdline > > then they both appear in /proc/consoles, AMA0 last > > > > If I boot with explicit console=tty0 on the kernel cmdline > > then they both appear in /proc/consoles, AMA0 still last > > Do the various flags not differ between the different cases? You are right. I wasn't taking note of those: E=enabled C=preferred console p=used for printk buffer a=safe to use when CPU is offline console=tty0 tty0 -WU (EC p )4:7 ttyAMA0 -W- (E p a) 204:64 console=ttyAMA0 tty0 -WU (E p )4:7 ttyAMA0 -W- (EC p a) 204:64 console=tty0 console=ttyAMA0 tty0 -WU (E p )4:7 ttyAMA0 -W- (E p a) 204:64 Any idea how we should choose a D-I primary console when none of them is marked 'preferred'? Or should D-i do away with the concept and try to treat them all equally (which is a slightly more intrusive change). Currently I use the one marked 'C' or the last one if none. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: arm64 graphical installer
On 2019-01-19 11:12 +, Steve McIntyre wrote: > [ Adding CC to debian-arm for interest ] > > On Sat, Jan 19, 2019 at 03:39:44AM +0000, Wookey wrote: > >I've done some work on getting the graphical installer going on arm64. > > \o/ > > >I was not able to demonstrate that the resulting build works fully, > >because when it tries to boot the kernel I get "Error: Invalid Magic > >number..., you need to load the kernel first". No idea why that's > >changed due to adding more module packages? Clues welcome. OK, this turned out to be 'pulled USB stick out before it was fully written' (forgot the fsync option). So in fact it does boot fine with lots of extra modules, but still no working keyboard/mouse input. For this fairly basic X server what is it expecting as input device? Is it using udev?, /dev/events?, libinput?, evdev? something else? (I'm a bit vague about how this fits together). It all works fine when I boot into X with standard debian. Comparing module lists and Xorg logs... on real debian its using 'driver libinput': [ 1411.187] (II) Using input driver 'libinput' for 'LITE-ON Technology USB NetVista Full Width Keyboard.' [ 1411.187] (**) LITE-ON Technology USB NetVista Full Width Keyboard.: always reports core events [ 1411.187] (**) Option "Device" "/dev/input/event2" [ 1411.187] (**) Option "_source" "server/udev" on D-I (netboot-gtk) we have: xserver-xorg-input-evdev-udeb udev-udeb libevdev2-udeb kbd-udeb x11-xkb-utils-udeb xkb-data-udeb input-modules uinput-modules usb-modules but not: xserver-xorg-input-libinput-udeb or libinput (which does not have udebs for any arch, so presumably not relevant) Is that expected? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Multiple console support in d-i
On 2019-01-20 03:02 +, Ben Hutchings wrote: > /proc/consoles shows everything on the global console_drivers list. > Every time a console is added to the list the kernel logs a message > with the format "%sconsole [%s%d] enabled\n". So these should match, > except that (1) it is also possible to unregister consoles, and reopen- > consoles doesn't account for that (2) the kernel log might have rolled > over so that reopen-console-linux doesn't see the messages. > > > Does it include any/all listed explicitly on the kernel command line? > > It's a bit more complicated than that. The kernel has a table of up to > 8 "preferred" console devices, which can be specified on the kernel > command, or through Device Tree or platform code, or by a hypervisor. > The device specified last (which usually means the last console= > argument on the command line) is the most preferred. > > If some preferred devices are specified, then console_drivers will > include all the console devices that are preferred *and* have been > found to exist, and the most preferred (if it exists) will be first. > > Otherwise, the kernel seems to enable the first console device found to > exist. > Reading /proc/consoles is exactly what you should do. Checking this on a booted thunderx machine (with no explicit kernel cmdline options) it lists ttyAMA0 If I boot with explicit console=tty0 console=ttyAMA0 on the kernel cmdline then they both appear in /proc/consoles, AMA0 last If I boot with explicit console=tty0 on the kernel cmdline then they both appear in /proc/consoles, AMA0 still last So /proc/consoles does indeed correspond to the set of enabled consoles listed by dmesg, however the last-listed on the cmdline is not necessarily the last in the list. Perhaps this is influenced by the device EFI specifies as the default console? What it doesn't do (which I was hoping for) is automagically note that there is a display attached (that could be used as a console) unless you tell it to look. Anyone know what would it take to make tty0 appear as a valid console on a thunderx machine without having to explicitly list it on the kernel command line? This is what we'd ideally like to happen. I've modified reopen-console-linux to use /proc/console and run D-I on all found. I'll test that on tue when back at suitable machine, and post here when it shows signs of working. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Multiple console support in d-i
On 2019-01-19 20:11 +, Ben Hutchings wrote: > On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote: > [...] > > * add lots more console= options to the grub.cfg for arm64 (to cover > >all the possibilities), then let d-i startup work out which devices > >exist from /proc/cmdlinge and spawn d-i on each. > [...] > > I think you should look in /proc/consoles, not /proc/cmdline. The > format is documented in > https://www.kernel.org/doc/Documentation/filesystems/proc.txt Interesting. Currently reopen-consoles does: if d-i console not already recorded set console using kernel 'handover' message (in dmesg) if running pre 2.6.38 kernel unless it's set to serial on a non-serial tty, in which case unset it make list of 'enabled consoles' from 1st 260k of dmesg if one matching device, then set as console if still not found (only) one, set to last one in kernel command line args if still not found one, default to /dev/console record chosen console fi start d-i on recorded console. I'm not entirely convinced that all this logic is actually needed/optimum, but I don't know the history of it. How exactly does /proc/consoles fit into that? The docs say it is "registered system consoles". Does that correspond to the same list of 'enabled consoles' the above is currently fishing out of dmesg? Does it include any/all listed explicitly on the kernel command line? My current code leaves all this alone and just records/uses all enabled consoles on the command line, not just the last one, but ideally we'd autodetect and/or hardcode all the sensible available consoles and run on them. If 'read /proc/consoles (and check the devices exist)' does this, then that sounds very sensible. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Multiple console support
Arm64 (arm in general in fact) has a rather fundamental problem with
D-I, which is that both serial and display are sensible default
devices for the installer to run on. Which is 'correct' depends very
much on the hardware and the circumstances. You may be installing a
server in rack, or a dev board with no display, in which case serial
is ideal, or you may have a chromebook or an ARM desktop machine with
a screen plugged in and no easy access to the serial console.
This problem doesn't arise on x86 where there is 'always' a screen (or
some BIOs magic to reflect what would be on the screen to serial).
Steve (McIntyre) and I have been thinking about what to do about this,
so did some investigation and came up with a plan. Essentially it was
to run d-i on both if they are configured/available. This way anyone
looking at just one or the other will see D-I as they expect. The
patch is not intrusive and essentially nothing changes if there is
only one console so this should be a low-risk change.
There are some further questions about whether we enable just
specified consoles (from kernel command line), or all
available+enabled consoles, but we can mess with that once the basic
support is in.
So far I have done a proof-of-concept hack and demonstrated that
running two instances does in fact work nicely without anything
obvious breaking. The console selection still needs some work/checking
(I've run out of time for that tonight, but it can easily be fished
out of the kernel command line args. (or we could get fancier).
The changes are in reopen-console (in rootskel), which runs the
initial d-i menu via an inittab entry, using steal-ctty to make sure
file handles and controlling tty are set up correctly.
Essentially all that has to happen is run extra copies on the other console:
--
echo /dev/$console > /var/run/console-device
echo /dev/$extraconsole > /var/run/extraconsole-device
fi
# Some other session may have console as ctty. Steal it from them
# Run D-I on other console if one given
if [ -n $extraconsole ]; then
( exec /sbin/steal-ctty $(cat /var/run/extraconsole-device) "$@" & )
fi
exec /sbin/steal-ctty $(cat /var/run/console) "$@"
---
(attached as rootskel-multiple-consoles.patch)
The only other place this affects is
packages/finish-install.d/90console which reads
/var/run/console-device when tidying up at the end in order to write
inittab entries for the used console device (serial, xen, etc).
We also added some error-checking to steal-ctty.c which it might be
smart to include, because it currently segfaults if you don't give it
the right number of parameters, and silently fails if you run it in a
context where the calling process is not a session-master.
That's in steal-ctty-errorcheck.patch
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
commit 860e5132001dc8a9fb032ada312d590cabc497db
Author: Wookey
Date: Fri Jan 18 18:44:09 2019 +
Add steal-ctty error checks
diff --git a/src/sbin/steal-ctty.c b/src/sbin/steal-ctty.c
index 0f3b14f..05a775f 100644
--- a/src/sbin/steal-ctty.c
+++ b/src/sbin/steal-ctty.c
@@ -22,8 +22,12 @@ int main(int argc, char ** argv)
while (fd > 2) {
close(fd--);
}
-ioctl(0, TIOCSCTTY, (char *) 1);
-execvp(argv[2], [2]);
+if (-1 == ioctl(0, TIOCSCTTY, (char *) 1)) {
+ perror("steal-ctty:ioctl");
+}
+if (-1 == execvp(argv[2], [2])) {
+ perror("steal-ctty:execvp");
+}
/* never reached. */
return 0;
}
commit 053b796076981da6fbe38e8e7663f822d935b79b
Author: Wookey
Date: Fri Jan 18 18:45:03 2019 +
run two installers
diff --git a/src/sbin/reopen-console-linux b/src/sbin/reopen-console-linux
index 87a7f7a..431bff0 100755
--- a/src/sbin/reopen-console-linux
+++ b/src/sbin/reopen-console-linux
@@ -70,7 +70,13 @@ if ! [ -f /var/run/console-device ]; then
console=console
fi
echo /dev/$console > /var/run/console-device
+ echo /dev/$extraconsole > /var/run/extraconsole-device
fi
-# Some other session may have it as ctty. Steal it from them
-exec /sbin/steal-ctty $(cat /var/run/console-device) "$@"
+# Some other session may have console as ctty. Steal it from them
+# Run D-I on other consoles if they are given
+if [ -n $extraconsole ]; then
+( exec /sbin/steal-ctty $(cat /var/run/extraconsole-device) "$@" & )
+fi
+exec /sbin/steal-ctty $(cat /var/run/console) "$@"
+
signature.asc
Description: PGP signature
arm64 graphical installer
I've done some work on getting the graphical installer going on arm64.
It's not quite finished, but Steve suggested I publish where I'm at so
I can get some help with the right set of module packages, and we can
start fixing up missing bits.
The first patch (enable-arm64-netboot-gtk.patch) enables the
support. This allows X to start on the display (if the correct console
is found/specified - see next mail). This looks lovely, but there is
no input working, because there are no no x input drivers installed,
nor modules for USB devices (keyboard and mouse are USB).
The second patch (add-missing-arm64-netboot-modules.patch) endeavours
to fix that, by putting arm64 on the same basis as amd64 in terms of
modules loaded. However not all module packages are built for arm64
so I had to remove some to get a working build.
Missing modules (not built on arm64) are:
mouse-modules
speakup-modules
acpi-modules
sound-modules
we should fix that too.
I was not able to demonstrate that the resulting build works fully,
because when it tries to boot the kernel I get "Error: Invalid Magic
number..., you need to load the kernel first". No idea why that's
changed due to adding more module packages? Clues welcome.
This all sounds more broken than it is: the difficult bit of the
graphics works fine, we just need to make sure the right modules for X
input are available too.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
From b8d5ea7d37670c6c5f9cc251e1cfc5f007388eb6 Mon Sep 17 00:00:00 2001
From: Wookey
Date: Tue, 8 Jan 2019 18:14:22 +
Subject: Add support for graphical installer to arm64
diff --git a/build/config/arm64.cfg b/build/config/arm64.cfg
index d9e782d..f320324 100644
--- a/build/config/arm64.cfg
+++ b/build/config/arm64.cfg
@@ -1,4 +1,4 @@
-MEDIUM_SUPPORTED = cdrom netboot device-tree u-boot
+MEDIUM_SUPPORTED = cdrom netboot netboot-gtk device-tree u-boot
KERNELMAJOR = 2.6
# The version of the kernel to use.
diff --git a/build/config/arm64/netboot-gtk.cfg b/build/config/arm64/netboot-gtk.cfg
new file mode 100644
index 000..0f1d246
--- /dev/null
+++ b/build/config/arm64/netboot-gtk.cfg
@@ -0,0 +1,24 @@
+MEDIA_TYPE = netboot image
+
+NETBOOT_DIR_TARGETS = $(TEMP_INITRD) $(TEMP_KERNEL)
+
+TYPE = netboot/gtk
+
+TARGET = $(NETBOOT_DIR) $(NETBOOT_TAR) $(MINIISO)
+EXTRANAME = netboot/gtk/
+
+BOOT_SCREEN_DIR = $(NETBOOT_PATH)/boot-screens/
+
+MANIFEST-NETBOOT_DIR = "PXE boot directory for tftp server (graphical installer)"
+MANIFEST-NETBOOT_TAR = "tarball of PXE boot directory (graphical installer)"
+MANIFEST-MINIISO = "not so tiny CD image that boots the graphical netboot installer"
+
+IS_PURE_GTK = 1
+
+KEEP_GI_LANGS = 1
+
+VIDEO_MODE=$(VIDEO_MODE_GTK)
+
+# All images that include cdebconf should include symbols needed by these
+# plugins.
+EXTRAUDEBS += cdebconf-gtk-entropy
From b0bc63a3baeb1e46c469d75ff7d68929be267949 Mon Sep 17 00:00:00 2001
From: Wookey
Date: Sat, 19 Jan 2019 03:13:40 +
Subject: Add missing modules (usb, fat, virtio) to arm64 netboot build and
xorg modules to netbook-gtk
diff --git a/build/pkg-lists/netboot/arm64.cfg b/build/pkg-lists/netboot/arm64.cfg
index e07dff0..18ca630 100644
--- a/build/pkg-lists/netboot/arm64.cfg
+++ b/build/pkg-lists/netboot/arm64.cfg
@@ -11,9 +11,22 @@ nic-modules-${kernel:Version}
nic-usb-modules-${kernel:Version}
nic-wireless-modules-${kernel:Version}
virtio-modules-${kernel:Version}
+usb-modules-${kernel:Version}
fb-modules-${kernel:Version} ?
input-modules-${kernel:Version} ?
-#for all targets
+# In case they need to load a driver image.
+mountmedia
+media-retriever
+fat-modules-${kernel:Version}
+usb-storage-modules-${kernel:Version}
+mmc-modules-${kernel:Version} ?
+
+# brltty
+brltty-udeb
+serial-modules-${kernel:Version} ?
+usb-serial-modules-${kernel:Version} ?
+uinput-modules-${kernel:Version} ?
+#for all targets
diff --git a/build/pkg-lists/netboot/gtk/arm64.cfg b/build/pkg-lists/netboot/gtk/arm64.cfg
new file mode 100644
index 000..2d8530a
--- /dev/null
+++ b/build/pkg-lists/netboot/gtk/arm64.cfg
@@ -0,0 +1,10 @@
+#include "gtk-linux"
+
+#mouse-modules-${kernel:Version}
+xserver-xorg-input-evdev-udeb
+xserver-xorg-video-fbdev-udeb
+
+#speakup-modules-${kernel:Version}
+#sound-modules-${kernel:Version}
+#console-setup-linux-fonts-udeb
+#espeakup-udeb
signature.asc
Description: PGP signature
Bug#851790: installation-reports: DNS not working
On 2017-01-19 11:04 +0100, Cyril Brulebois wrote: > Steve McIntyre <st...@einval.com> (2017-01-19): > > On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote: > > > > > >The workaround are to make sure the chroots are up-to-date (which should > > >be the case now on the build daemons). An other alternative would be to > > >avoid copying a library in mklibs if it is already present in the image. > > >That might break if some very strict dependencies are used, though > > >I guess the way the udebs are downloaded, they should always have the > > >same or a newer version than in the chroot. > > > > Thanks for the explanation - it's appreciated! > > Yeah, thanks for the confirmation. OK. I tested today's image (2017-01-23 04:56) and the install went through OK, so we are back in sync and this issue is gone for now. It should probably be retitled to something about library sync/using host libs and left open until it's fixed propoerly. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#851790: installation-reports: DNS not working
Package: installation-reports
Severity: grave
Tags: d-i
Justification: renders package unusable
Dear Maintainer,
The current installer, with the new 4.9 kernel, is unable to resolve
domains, so is quite seriously broken.
This was noted during install on an arm64 gigabyte MP30-AR1
desktop/server, when choose-mirror failed, but it soon became clear
that DNS was not working.
Testing on an x86 VM with the same daily image (18th Jan 2017) found
the same problem. Going back to the rc1 installer image (4.8 kernel)
it works OK.
Tests showed that the network came up fine and things are pingable by IP, but
not name:
# ping wookware.org
ping: bad address 'wookware.org'
# ping 93.93.131.118
PING 93.93.131.118 (93.93.131.118): 56 data bytes
64 bytes from 93.93.131.118: seq=0 ttl=50 time=19.892 ms
similarly the failing line from the choose-mirror log works if an address is
inserted:
Jan 18 17:04:11 choose-mirror[31201]: DEBUG: command: wget --no-verbose
http://debian-mirror.cambridge.arm.com/debian/dists/stretch/Release -O - | grep
-E '^(Suite|Codename|Architectures):'
Jan 18 17:04:11 choose-mirror[31201]: WARNING **: mirror does not support the
specified release (stretch)
# wget --no-verbose
http://debian-mirror.cambridge.arm.com/debian/dists/stretch/Release -O - | grep
-E '^(Suite|Codename|Architectures):'
wget: unable to resolve host address 'debian-mirror.cambridge.arm.com'
# wget --no-verbose http://10.1.194.51/debian/dists/stretch/Release -O - | gre
p -E '^(Suite|Codename|Architectures):'
Suite: testing
Codename: stretch
Architectures: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
2017-01-18 17:47:12 URL:http://10.1.194.51/debian/dists/stretch/Release
[177979/177979] -> "-" [1]
resolv.conf is as expected:
search cambridge.arm.com
nameserver 10.1.2.24
nameserver 10.1.2.23
(adding nameserver 8.8.8.8 makes no difference)
Watching packets go by when doing a VM install it is clear that the
local DNS server returns the correct response, but this is being ignored
or lost by the D-I initrd.
attached is an strace of strace ping wookware.org > /tmp/tracelog 2>&1
That gets a response from the server OK, but then goes on to ask the
other one. a working strace then uses the provided IP address. So
there is nothing obviously going wrong there.
-- Package-specific info:
Boot method: USB
Image version:
http://gemmei.acc.umu.se/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso
Date:
Machine: Gigabyte MP30-AR1, (and x86 VM)
Partitions: (default guided LVM, with separate /home chosen)
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot: [O]
Detect network card:[O]
Configure network: [O]
Detect CD: [O]
Load installer modules: [O]
Clock/timezone setup: [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives: [O]
Install base system:[E]
Install tasks: [ ]
Install boot loader:[ ]
Overall install:[ ]
Comments/Problems:
Worked as expected until DNS needed
--
Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.
Once you have filled out this report, mail it to sub...@bugs.debian.org.
removed automatic info as this report written on different machine fro install.
execve("/bin/ping", ["ping", "wookware.org"], [/* 14 vars */]) = 0
brk(NULL) = 0xc9893000
faccessat(AT_FDCWD, "/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x86677000
faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
openat(AT_FDCWD, "/lib/aarch64-linux-gnu/tls/aarch64/libc.so.6",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib/aarch64-linux-gnu/tls/aarch64", 0xc66b2660, 0) =
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/aarch64-linux-gnu/tls/libc.so.6", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib/aarch64-linux-gnu/tls", 0xc66b2660, 0) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/aarch64-linux-gnu/aarch64/libc.so.6",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib/aarch64-linux-gnu/aarch64", 0xc66b2660, 0) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/aarch64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib/aarch64-linux-gnu", {st_mode=S_IFDIR|0755,
st_size=360, ...}, 0) = 0
openat(AT_FDCWD,
Bug#807312: src:debian-installer: please provide binary package for use by debian-installer-netboot-images
> what do you mean by that? Source packages like cross-gcc-4.9-armhf > *do* have cross-arch build-deps. Were you talking about missing > support in britney to properly transition source packages with > cross-arch build-deps? Is there a bug about this open somewhere? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770925 Stalled since debconf. Although that's actually the wanna-build code, rather than britney. We've been waiting for w-b to be implemented before we could sensibly worry about britney. But time is getting short if we are to have this working this release. Aurelien - can we help move this along? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: Packages to install be default for Stretch
+++ Samuel Thibault [2015-05-06 01:09 +0200]: Ansgar Burchardt, le Tue 05 May 2015 20:45:09 +0200, a écrit : - info, texinfo, install-info: I admit having used info only in desperation. Most documentation comes in man page format. - demote to optional Proper autoconf, automake, gcc, etc. documentations only really come in info format. Indeed. If we are going to have an info reader installed can it please be pinfo instead of info? It's _so_ much better. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150506022113.gi24...@halon.org.uk
Re: Help with the arm64 and ppc64el installation-guides needed
+++ Karsten Merker [2015-04-09 18:13 +0200]: Hello everybody, the release date for Jessie is near, but the installation-guide does not seem to contain any arm64/ppc64el-specific information yet. It would be nice if those who are familiar with those platforms could provide patches against the installation guide, so that we can release with proper documentation. At least some basic information about the supported hardware for the overview at https://jenkins.debian.net/userContent/installation-guide/installation-guide-arm64/en/ch02s01.html OK. I've done this. I don't seem to have commit rights (should I?) Sendingen/hardware/supported/arm.xml Transmitting file data .svn: E13: Commit failed (details follow): svn: E13: Can't open file '/svn/d-i/db/txn-current-lock': Permission denied so patch attached. I'll work on the 2nd part now. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ Index: en/hardware/supported/arm.xml === --- en/hardware/supported/arm.xml (revision 69739) +++ en/hardware/supported/arm.xml (working copy) @@ -6,49 +6,57 @@ para -ARM systems are a lot more heterogenous than the i386/amd64-based PC -architecture, where all systems share a common system firmware (BIOS or/and -UEFI) which handles the board-specific basic hardware initialization in a -standardized way. +ARM systems are much more heterogenous than the i386/amd64-based PC +architecture, so whilst 64-bit ARM machines should boot in a +standardised way, like PCs, the situation is more complicated for +32-bit ARM machines. -The ARM architecture is used mainly in so-called quotesystems-on-chip/quote (SoCs). -These SoCs are designed by many different companies with vastly varying -hardware components even for the very basic functionality required to bring -the system up. Systems using them usually lack a common system firmware -interface and as a result, on ARM systems the Linux kernel has to take care -of many system-specific low-level issues which are handled by the -mainboard's BIOS in the PC world. +/para +para +The ARM architecture is used mainly in so-called +quotesystems-on-chip/quote (SoCs). These SoCs are designed by many +different companies with vastly varying hardware components even for +the very basic functionality required to bring the system up. System +firmware interfaces have been increasingly standardised over time, but +especially on older hardware firmware/boot interfaces vary a great +deal, so on these systems the Linux kernel has to take care of many +system-specific low-level issues which are handled by the mainboard's +BIOS in the PC world. + /para para +At the beginning of the ARM support in the Linux kernel, the hardware +variety resulted in the requirement of having a separate kernel for +each ARM system in contrast to the quoteone-fits-all/quote kernel +for PC systems. As this approach does not scale to a large number of +different systems, work was done to allow booting with a single ARM +kernel that can run on different ARM systems. Support for newer ARM +systems gets implemented in a way that allows the use of such a +multiplatform kernel, but for several older systems a seperate +specific kernel is still required. +/para -At the beginning of the ARM support in the Linux kernel, this resulted in -the requirement of having a seperate kernel for each ARM system in contrast -to the quoteone-fits-all/quote kernel for PC systems. As this approach does not -scale to a large number of different systems, work has started to be able to -provide a single ARM kernel that can run on different ARM systems. Support -for newer ARM systems gets implemented in a way that allows the use of such -a multiplatform kernel, but for several older systems a seperate specific -kernel is still required. - +para Because of this, the standard debian; distribution only supports -installation on a selected number of older ARM systems in addition to the -newer systems which are supported by the ARM multiplatform (armmp) kernel. +installation on a selected number of older 32-bit ARM systems in +addition to the newer (32 and 64 -bit) systems which are supported by +the ARM multiplatform kernels (called 'armmp' on 32-bit armhf, no +flavour name on 64-bit arm64). /para para - The ARM architecture has evolved over time and modern ARM processors provide features which are not available in older models. debian; therefore -provides two ARM ports, the debian;/armel and the debian;/armhf port. +provides three ARM ports: the debian;/arm64 port for all 64-bit machines, and the debian;/armel and the debian;/armhf ports for 32-bit machines. debian;/armel targets older ARM processors without support for a hardware floating point unit (FPU), while debian;/armhf works only on newer ARM processors which implement at least the ARMv7 architecture with version 3 of the ARM vector floating point
Bug#781344: debian-installer: Enable entering a local mirror name in 'mirror URL' menu as well as 'country' menu'
Package: debian-installer Severity: wishlist Currently it is possible to select 'Enter Manually' from the top of the country list when choosing a debian mirror to netinstall from. A user quite reasonably looks for this option when given the list of mirrors, not when given the list of countries, so it should be available there too. Tested on Jessie d-i RC2 -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150327184713.18301.82436.report...@e106839-lin.cambridge.arm.com
Bug#759442: discover: run dh-autoreconf to update for new architectures
Package: discover Version: 2.1.2-5.2 Severity: normal User: debian-...@lists.debian.org Usertag: arm64 This package failed to build on arm64. Here is the buildd log: https://buildd.debian.org/status/fetch.php?pkg=discoverarch=arm64ver=2.1.2-5.2stamp=1408296386. It is one of hundreds of packages which need autoconf updates in order to build on new architectures such as arm64, mips64el, ppc64el and or1k. Re-autoconfing is the recommended way to deal with the general case of this problem in Debian, as it works now and in the future, and ensures packages remain buildable from source. This page ( https://wiki.debian.org/Autoreconf ) contains information on this issue, and details for maintainers on how to update their packages: The porter teams are working hard to get the new architectures ready for jessie, and time is short, so do please try to fix this issue promptly. It's often trivial to do. -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.60-kvm-i386-20140609 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827095605.24538.62439.report...@stoneboat.aleph1.co.uk
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
+++ Kees de Jong [2014-08-12 02:03 +0200]: Are we really comparing RAM here as if it were the 90's? How many people here use Android? Today it needs 512 MB to function properly. In two years that could be 1 or 2 GB and that's a mobile OS. How much RAM does your browser use? Too much! I agree browsers use more ram than desktops these days, or at least the big ones (firefox, chrome) do. My Chrome/Firefox easily uses 1 GB. My GNOME 3.10 desktop (running Fedora now because I needed a modern GNOME version for Exchange support for work) is using about 800 MB to 1200 MB. Do I really care? No, because RAM is cheap and I have 8 GB. Do I need to buy more? No, because 8 GB is still more than enough. That's fine so long as your hardware is new enough to take more memory. Anyone with an ARM machine will be in the 512MB/1G/2G camp. My laptop (x200s) officially maxes out at 4G, although it turns out that 8G does actually work in practice. Memory usage does still matter as your hardware doesn't have to be particularly old to have RAM of a size that is likely to all get used, and on arm (increasingly being used for netbook/laptop/desktop usage) it's practically guaranteed. So yes, it's not the 1990s but I think we should aim to make Debian to work tolerably well on 2 or 4G systems. Alistair posted numbers suggesting 600MB for gnome3 or KDE, 360 for XFCE, 300 for LXDE, which is a difference, but not a huge one. Very significant on a 512MB machine, but not that significant on 2G. You say 800-1200 above which is twice as much. Is this the differnce between initial boot up and usage after some time, or 'various add-ons'? Knowing what 'typical' numbers are would be useful. I have various well-used XFCE desktops I could check but I'm not sure how to get a cmparable RAM-usage number of them. If you can't run GNOME because you don't have the system specs to run a modern desktop then you can select XFCE/LXDE in the installation menu. But let's be fair, those people are a minority. And a default should fit the needs of the majority. And since people easily have 4 GB of RAM or more these days with the basic 3D acceleration I only had 2G RAM till last year (when I had to buy some more because browsers take so much damn RAM). I think we should at least consider those people in the 'typical machines' bucket. (even a Raspberry Pi can run GNOME 3) A Pi is only 512MB, so 'barely'. Like most arm hardware memory levels are still low by modern x86 standards. They are like late 90s/early 2000s x86 machines in this regard. I don't want to over-emphasise the arm thing - it is still a minority sport - but it's a growing area of usage where memory is still limited. I just wanted to counter a little the 'everyone has buckets of RAM these days' view, whilst acnowledging that it is no longer the 90's and a 512Mb machine will struggle with any modern desktop+browser (which is sad IMHO - dawkins knows what software, especially browsers, do with all that memory! - hundreds of Mb for simple tables of built packages, for example, but I digress :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812085008.gl7...@stoneboat.aleph1.co.uk
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
+++ Anthony F McInerney [2014-08-12 00:02 +0100]: XFCE: total used free sharedbuffers cached Mem:506756 362468 144288 6568 22756 179264 -/+ buffers/cache: 160448 346308 Swap: 392188 0 392188 GNOME: total used free sharedbuffers cached Mem:506756 500360 6396 1948840 37724 -/+ buffers/cache: 461796 44960 Swap: 392188 66672 325516 LXDE: total used free sharedbuffers cached Mem:506756 316504 190252 8500 18920 149812 -/+ buffers/cache: 147772 358984 Swap: 392188 0 392188 KDE: total used free sharedbuffers cached Mem:506756 499724 7032 6772 10516 109760 -/+ buffers/cache: 379448 127308 Swap: 392188 21632 370556 Thanks for this, interesting. Could you do MATE too please? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812085136.gm7...@stoneboat.aleph1.co.uk
Bug#734743: debootstrap: Assumes MAKEDEV is in /sbin which may not be true on a non-debian rootfs
Package: debootstrap Version: 1.0.56 Severity: normal If using debootstrap to create a debian or ubuntu rootfs on a non-debian system, the baked-in assumption that MAKEDEV is in /sbin is wrong. (It's not true on an OE rootfs, for example). The instructions in README for creating such a rootfs say: Unpack the tarball then: make devices.tar.gz export DEBOOTSTRAP_DIR=`pwd` debootstrap sid sid The make devices.tar.gz step fails when MAKEDEV is not in /sbin. We could stop using MAKEDEV, as suggested in #571136. In the meantime, changing the line in Makefile MAKEDEV := /sbin/MAKEDEV to MAKEDEV ?= /sbin/MAKEDEV would allow make to be called with a setting for where MAKEDEV is (copying a version over from somewhere should be practical) make MAKEDEV='/home/user/utils/MAKEDEV' devices.tar.gz I tested this and it work (so long as an absolute path is given) -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140109140644.16616.53401.report...@stoneboat.aleph1.co.uk
Re: modifying and verifying debian installer for armhf board (a10-eoma68)
+++ Luke Kenneth Casson Leighton [2013-05-20 15:22 +0100]: but also, this is /sbin/init rather than /init - which one should really be executed (as process 1) - both exist. /sbin/init exists on a standard debian wheezy (or ubuntu raring) rootfs. /init doesn't. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130520150958.gl11...@stoneboat.aleph1.co.uk
Re: modifying and verifying debian installer for armhf board (a10-eoma68)
+++ luke.leighton [2013-05-19 10:37 +0100]: On Sun, May 19, 2013 at 7:49 AM, Ian Campbell i...@hellion.org.uk wrote: Sounds like you want a network-console flavour image, like the ones used for kirkwood, http://www.cyrius.com/debian/kirkwood/qnap/ts-41x/install/ it does, doesn't it? i've been thinking that through (and also looking at the source of debian-installer). the only thing that doesn't make sense is: it's all set up to require a password. so i'm tempted to just do an experiment - just because i can - to use busybox-telnetd - because the route of using openssh _has_ been solved already but isn't quiiite appropriate, and i think telnetd-over-g_ether will turn out to be a very useful combination. I used this for balloon bootstrapping about 4 years ago, mostly because ssh is annoying if you have a pile of boards to fill with code as, even when you got the keys right, it bitches everytime you put a new one in that the other end has changed. It is possible to nobble this but telnetd is a lot simpler for this application. As someone else has pointed out a console on an ACM gadget driver is also good. how do you tell debian-installer i don't want a kernel installed thanks for offering? Not sure, but don't we really want to make a D-I setup with a local kernel package to install? I believe that functionality exists, although I've never got round to trying it myself. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130519201141.gg2...@stoneboat.aleph1.co.uk
Bug#673644: Message at end of successful install talks about floppies (should be updated)
Package: debian-installer Version: wheezy alpha Severity: minor Tags: d-i At the end of a successful install you get the 'installation complete' message: installation is complete, so it is time to boot into your new system. Make sure to remove the installatio media (CD-ROM, floppies), ... I suggest that be updated to (DVD, USB drive, CD) or something. (A very minor nit - otherwise my experience of wheezy-A1-amd64-netinst on an atom N450 dev board was excellent - well done). -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120520114746.28744.46380.report...@kh.home.wookware.org
Re: Wheezy release: CDs are not big enough any more...
+++ Mehdi Dogguy [2012-05-16 16:24 +0200]: On 16/05/12 13:41, Wookey wrote: is there any reason not to just upload this to Debian? There are ITPs filed for it: - http://bugs.debian.org/582884 - http://bugs.debian.org/576359 Yes. I discovered that when I went to file an ITP :-) It turns out that there is a problem preventing upload. The rather generic name 'usb-creator' was objected-to and a request made to change it to 'startup-disk-creator' (The name the app shows). Upload seems to be stalled on changing the name of the launchpad project to give matching source and binary names. This seems well-meaning but has the unfortunate effect that nothign has happened for a year, despite several people expressing an interst in uploading. I also tested it with a debian installer image and found that it is bust due to a load of ugly code dealing with the syslinux transition from 2.3x to 2.4x around Ubuntu 10.04-10.10 (generating old images whilst running on a new machine, and vice versa, different package and different syntax). It blows up on debian due to 'GNU/Linux' not being a valid version. As we don't even have syslinux-legacy in Debian all this mess should probably just be thrown away. https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1000527 My python-foo wasn't up to actually fixing it myself. Nor do I know how important it is to keep this sort of old-release compatibility (how old?). Anyone with the enthusiasm to fix the upstream-renaming thing, or this code (not hard, just fiddly) could get this into Debian promptly I think. Wookey -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120518121724.gu11...@stoneboat.aleph1.co.uk
Re: Wheezy release: CDs are not big enough any more...
+++ Timo Juhani Lindfors [2012-05-15 21:01 +0300]: Yes, turns out I failed to read the instructions right, presumably due to thinking I knew how this worked (i.e. you can't just put an iso stright onto a USB stick, and you need 'hd-media' for USB sticks). I'm glad to see that this has got significantly simpler. ubuntu uses the usb-creator package to provide a dbus api that allows normal users to create usb installation media. (It carefully checks that you can not write to the internal hard disk). I think this is what most inexpert users would like to see - a reasonably idiot-proof GUI tool for downloading an installer image and putting it on the USB stick for them. usb-creator is in ubuntu but not Debian for no good reason. It has already had Debian support added. One of the uploaders, and the person who added the Debian support is a DD: Dmitrijs Ledkovs. Dmitri - is there any reason not to just upload this to Debian? I see a couple of places in the UI where it says 'Ubuntu' and it would be good if it got a bit cleverer and put in the appropriate string with dpkg-vendor, as it already does for the logo files. I also fixed up the build so it skips the not-present dh-translations on Debian, and otherwise modified the deps for Debian. I'll do some testing tonight when I have USB sticks to hand. There are probably quite a few useful utilities like this in Ubuntu universe that should get uploaded. Wookey -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516114114.gj11...@stoneboat.aleph1.co.uk
Re: Wheezy release: CDs are not big enough any more...
+++ Steve McIntyre [2012-05-15 13:38 +0100]: [ re-adding CC to debian-cd and debian-boot ] 2. USB-targeted images I've also tweaked DVD#1 of each set to fit in 4GB instead of the normal 4.7GB, so that it fits on a 4GB USB stick to make it more useful. We could quite readily produce (say) 2GB images specifically designed for smaller USB sticks if enough people consider that to be useful. I'm thinking that would be a specific single extra image. Thoughts? I have always installed from USB stick (or SD card) on everything for the last several years. It must be 4 years since I used a CD or DVD. Especially on dev boards (x86 or arm) that is usually the only medium slot you have. I assume this is common. And the USB-stick process is not as simple as it might be because you have to find the HD-media files and then _also_ find an iso image to put on. It's no wonder newbs are still downloading CD/DVD images. Only last night I tried to install current testing to an intel dev board. I tried using unetbootin which is a great way of making the USB-key install process less cryptic, but for some reason it failed to get unstable images, and could only manage testing ones. (I'll check that and file a bug tonight). I think we could usefully focus on making the USB-stick/MMC card experience simple as that covers an awful lot of modern use-cases. It currently feels like a bit of a 'poor relation'. That might mean recommending the use of Unetbootin (and making sure it works), or providing complete say 2G and 4G images and some simple way of burning them. Maybe a 'debianised' version of unetbootin that just provides debian images and hides most of the gory details, but will help stop you shooting yourself in the foot? It looks to me like we have all the parts for that, it's just the emphasis needs changing, or maybe even just the docs updating (I may not be doing this the easiest way - it's not totally obvious from the debian download page what to do - AIUI you have to read the install docs, and understand to download the hd-media files (either the image gzip or the files) and an iso from somewhere else and put it all on the stick.) 3. Which installer image(s) should we link to as preferred? We're currently linking to the multi-arch amd64/i386 netinst CD from the front of www.debian.org. I think that's still a good choice, but I'm open to being convinced otherwise. add a netinst USB image would be a good thing IMHO. Along with the equivalent tool to a CDburner to make it painless. Maybe even make netinst USB sticks the default over CDs? And try to hide the 'hd-media' name at least in initial download selection, because it is geek-accurate, but rather confusing to a newcomer. Wookey -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515142459.gf11...@stoneboat.aleph1.co.uk
Debconf11 multiarch-related-items meeting notes
We held a meeting during debconf discussing policy on things which multiarch enables: partial architectures, cross-compilers in the archive, cross-comiled uploads, and a few other things. I've posted the meeting notes here: http://wiki.debian.org/Multiarch/Debconf11MultiarchRelatedMinutes reproduced here: Multiarch cross-architecture meeting minutes Held at Debconf 11 2011-07-26. 5pm Present. Approx 12 people, including Steve Langasek(vorlon) (chairing), Wookey (minuting), Mark Hymers(mhy) (FTPmasters), Adam Barratt(adsb) (Release team), Andreas Barth(aba) (Release team), Steve McIntyre(sledge) (Install Media team), Mattias Klose(doko) (gcc maintainer), Aurellien Jarno(aurel32) (eglibc maintainer, ports buildd maintainer), Neil Mcgovern(maulkin) (release team), Tollef Fog Heen(mithrandir), Goswin von Brederlow(goswin), Philip Kaluza(pixelpapst) (minuting) + 1 other (sorry, don't know name) All errors in these notes are Wookey's fault. A lot of people said a lot of things, and getting down the significant points of what was said without missing anything important was not particularly easy, so there are probably a few things missing, and potentially some misrepresentations (although few comments are attributed). please just fix up anything that needs it. (Philip Kaluza's version of the minutes is also included below). Agenda for meeting roughly: * keep grub-pc in amd64 ? * partial architectures ? * what to do with gcc-multilib * cross-compilers in archive * cool things to do in the future * stuff that's not arch-independant in contents, but is in there use. (firmware etc.) * How to manage install media Firstly: are there any serious blockers (e.g. dpkg) before usingmultiarch in main. In short, 'No'. Partial arches? Use cases: 1. 'almost complete' e.g amd64, but with 32-bit grub. 2. 'optimised' (a few packages). Also ABI-incompatible and optimised: These are not the same, but could probably most easily be treated the same by infrastructure. Examples of partial arches are: * sparc64 and ppc64: could expand to full arch, win32 won't. (this is a relatively exotic 'future' possibility dak (on the ftpmaster side) doesn't care whether a package set is closed across an arch but britney (release team) does. Some discussion of when it is useful to have mixed 64/32 arch or not. What packages are pointless in 64-bit form on sparc64, for example. x86_64 is faster than x86_32, but sparc64 is not faster than sparc32 (so no real point making it a full arch). Build/release people would like to see the definition of an arch being: Arch is something that has to be built on that arch (where arch is a set). This works well for 64/32 or i386+i686. Archive size: are there major restrictions? ftpmasters: It's already way too big so lets just press on. Biggest churn is in dists. mirror pulse size is more costly than disk size. Are we going to have smaller package files? Maybe - this depends on implementation. In a small partial arch we can merge small extra files into host arch package. Is this a good idea? Does apt do the right thing anyway? It should do Needs testing. likely partial arches: i686, ppc64, sparc64, s390x, mips64, arm/x86 optimisations? ABI-comptible optimisations are not the same as ABI-incompatible. But could be treated the same way. As well as sparc64 needing base sparc packages, sparc has a sparc64 kernel. So neither arch is complete alone. (but definition of both as needing in both works) Does allowing partials mean that incentive to move base build of a port forward (eg would we still be using 286) is removed? No, because toolchain support is dropped eventually. We still need to drop old stuff and move base along. What if you have i386/686/amd64 all on one machine/install. Discussion about installing with 3 DVDs until you have all arches you want. How should install media work? Agreement: Need to have correct user interface for this. For upgrades as well as installs. reportbug needs to report the arch of package. Otherwise we have no chance of reproducing bugreports. So does popcon. vorlon: dpkg -l should do the right thing already. Can we drop 32 and 64-bit 'foreign' kernels now? (i.e -amd64 kernel from i386) Kernel team would like to do it now, but may well have to wait one release. (ask kernel team for input) Big picture: How to handle first upgrade to MultiArch ? That may need release-note update to say 'get this package first', then do dist-upgrade. This always causes some breakage. How do we decide on arch qualification for release? someone needs to define some criteria. How do we define the set of stuff for percent-built? Subject needs work. Do we want to get rid of anything depending on gcc-multilib? Doko wants to keep mulitilib capability. Cross-compilers in the archive Are we going to upload some. How do we decide which set? How do we implement cross-builds. From gcc package? gcc
Fw: Re: Starting Debian installer from Grub2 on Flash
[Forwarded from Debian-arm list to somewherre where the answers might be better known. ] - Forwarded message from Jean-Michel Pouré - GOOZE jmpo...@gooze.eu - From: Jean-Michel Pouré - GOOZE jmpo...@gooze.eu Date: Tue, 01 Mar 2011 03:12:39 +0100 To: debian-embed...@lists.debian.org Subject: Re: Starting Debian installer from Grub2 on Flash Reply-To: jmpo...@gooze.eu List-Id: debian-embedded.lists.debian.org X-Spam-Status: No, score=-6.6 required=4.5 tests=BAYES_00,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.5 Le lundi 28 février 2011 à 23:02 +0100, Jean-Michel Pouré - GOOZE a écrit : Can Debian installer be started and installed on the same CF Flash? We would like users to be able to make their own installation using Debian installer and network. Therefore a minimal installer should reside on CF. A bonus would be the installer being recognized by Grub2 and proposed as a rescue boot. I followed instructions from the Debian installer hd-media. This is an ALIX 2D13 board with serial console. So I modified sys.conf to boot from console (ok). Then I modified the image bootloader with serial console support (ok). Now the CD net-install image boots but does not recognize the flash drive. I am aware that PXE installation works. But we would like to offer users and installer on FLASH to ease installation. Any idea? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu -- To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298945559.5842.8.camel@acer - End forwarded message - Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110301022924.gm9...@dream.aleph1.co.uk
Bug#387424: debian-installer: No option to install kernel/inirtd without base system
Package: debian-installer
Severity: wishlist
I recently had a hard time recovering a system after upgrading the
hard drive. Eventually d-i let me sort things out but it was
difficult, slow, and has probably caused some other problems in the
process due to having to overwrite a load of existing stuff on the
drive.
The ability to simply install a new, bootable, kernel/initrd after
booting with d-i would have made things enormously easier. Given the
way stock kernel+initrd debian systems now work, it seems to me that
this situation ('I changed something so it won't boot - I need a new
kernel/initrd pair') will be a fairly common event that d-i ought to
be able to cater for, so I humbly request that separating 'install
base system' and 'install kernel/initrd' be considered. (Perhaps it
already is in which case it needs to be easier to discover - I
couldn't see how).
(I was using a d-i version from a few months ago so ignore me if this
is all fixed in the latest version.)
Details:
The old drive had reiserfs on hda1. The new drive had ext3 on
hda4. Grub was the bootloader. Everything was copied over, but of
course it wouldn't boot because the grub bootloader knew it should be
booting from hda1, and, more seriously - the intrd only had the
reiserfs module, not the ext3 module so couldn't boot from ext3 no
matter what I told it to try. The stock kernel without initrd didn't
understand either fs and so not using the initrd was not an option
either.
Booting with a grub CD didn't help as grub wasn't really the main
problem (but it took me a while to realise this).
Booting with d-i, either in rescue mode or in normal mode let me see
the new drive rootfs, but the only way I could see to let me install a
new kernel was to do 'install new base system', which overwrites a
whole pile of stuff (in this case with older stuff as my d-i was older
than the unstable system I was trying to boot/recover).
I did try 'expert' mode but I got stuck with that. Perhaps it does
separate 'install kernel' and 'install base'?
In fact the 'install kernel' failed anyway due to presence of existing
/lib/modules so in the end I had to copy the kernel and initrd
packages off the cd, then pivot_root, then udpkg -i the packages. (I
couldn't see how to run udpkg so it operated on the rootfs in /target
not /(the initrd) - how does d-i deal with this?).
This did finally (after some 10 hours of messing about) get me a
system which tried to boot off the new drive (hooray!). It just seems
to me that it shouldn't be this hard, And I thought I was a fairly
competent user. The initrd scheme (with a very minimal base kernel)
makes it much harder to get out of things when you make an
incompatible boot change. d-i is the natural next port of call, so
making it as easy as possible to deal with this situation seems
worthwhile (obviously with out overly distracting from the primary
task of d-i as an installer).
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-k7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
queries re ARM port
OK, I've spent a couple of evenings reading the docs and trying to grok the whole thing. I think I've mostly got it but I have a few questions: 1) Some .cfg files in build/config/ specify MEDIA_TYPE instead of TYPE. Type seems to be the main things that decides which package lists are used, but I don't quite see how it works with MEDIA_TYPE - can someone explain the difference? I started adding some text on the bottom of build/README about what the various makfile variables are for (as most of the job seems to be filling in the right variables in your .cfg fragment so long as you don't want to do anything too exotic) - a crib sheet for these would be handier than having to work through the makefile and scrits to work out what to fill in. As I don't know what I'm doing I am in danger of talking rubbish of course - feel free to correct me, or add some more :-) 2) I haven't worked out yet where I have to tell the system that I want to use a serial console. Does it need to be set in Cdebconf or in a kernel boot string somewhere? This feels like a dumb question, but wandering about hasn't answered it for me yet. 3)d-i 'doesn't support cross-compiling'. This makes life slightly harder for me, although it's better than bootfloppies, where native compiles took forever. Looking at it, I can't see that much needs to change to make this possible except getting the various instances of dpkg-architecture to give the right answers (which I think can be done with dpkg-cross). Then it should just get .udebs of the correct arch. Is there something I haven't appreciated about how it works which is going to make cross-compiling really tricky? If not I might try and get it working, just because it's convenient for me. TIA (I'm away next week so nothing doing for a while - it's peter's turn for a bit now :-) Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ARM d-i port - someone add me to the alioth project please
+++ Karsten Merker [04-02-24 09:31 +0100]: ah, hello Karsten - got home eventually then? How's the ankle? :-) Generally it can work on a serial console, but there are still several bugs: - you have to select US/English, choosing another language like French or German will cause a complete hang on serial console - kbd-chooser only works if there are also loadable keymaps included, even though they do not make sense for a system with serial console - sometimes there are display problems / stranger characters on serial cnsole OK, that's good enough for getting something going, I hope. What is needed to make UTF-8 consoles work properly? kernel changes or D-I changes? Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer on arm status
+++ [EMAIL PROTECTED] [04-02-23 18:53 +]: On Mon, Feb 23, 2004 at 05:49:57PM +, Wookey wrote: +++ Peter Naulls [04-02-23 13:07 +]: In message [EMAIL PROTECTED] Anthony Towns [EMAIL PROTECTED] wrote: It's time to get debian-installer ported to arm; all the major porting work should already have been done getting it to work on other arches, so what's left should be fairly straightforward. If you can't get this working, arm's status as a supported arch will have to be reviewed: there's no point releasing a distribution that can't be installed. (It'd be possible to release arm with a different installation toolset than d-i, but I can't imagine that'd be any easier or much more useful than getting d-i ported) You're right of course, and as you observe it really is getting to 'make it work or have arse kicked' time. Part of the problem is of course that arm installation has always been somewhat 'distributed' - there is a special version of bootfloppies for most 'supported' machines because the default one doesn't actaully work, and an awful lot of people using debian-derived stuff don't use either b-f or d-i to get things installed - they use some random bootloader for the board in question. So in fact debian-arm remains useful to a lot of people even without a working debian-installer. That's not really an adequate excuse for not making it work on at least the suitable machines, and hopefully it will be better suited to weird hardware than b-f was. We'll see. I've now got uptodate on d-i again at alioth and will take a look at what needs doing for lart/balloon. Poor old vince has found he can't do the kernel _and_ D-I - there aren't enough hours in the day. While true to some extent I did get D-I to the point where I had working tftp images for winder, bast, riscstation. I tried to talk to #debian-boot about autobuilders and kernel-image builders and (as usual) got blown off, this was several months ago and my tree is now very very out of date so needs to be done again... One point, I was going to use the kernel udeb image thingy but in its current form adding all the ARM sub arches would make it generate an additional 40odd packages from the one source...this seemed grossly excessive and I wanted to find a more elegant solution. One issue which was being cleared up but hadn't been resolved was that the final image stuff wanted to put a single vmlinuz file down for all sub arches...with several subarches to choose from we ended up without a sensible kernel for the bootloader to start except for one target :-/ OK - we need to have this discussion on debian-boot I think, in order to work out how best to proceed, so I've added it. D-B people - Is the above still true? ARM currently has (approximately) one kernel per machine. Even just supporting the existing supported stuff and things that have enough resources for installing Debian to be a vaguely sensible thing to do (which excludes quite a lot of potential machines), means at least 10 kernel udebs, and some lesser number of initrds and module sets. Likely targets that someone cares about enough to support are: Iyonix, RiscPC, Riscstation, Netwinder, Balloon, CATS, LART. Advice on best way to proceed is welcome. For much arm hardware using debootstrap rather than D-I may actually make more sense/be easier. We (arm people) need to look at that too. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer on arm status
+++ Jeff Bailey [04-02-24 09:19 -0500]: On Tue, 2004-02-24 at 08:55, Wookey wrote: D-B people - Is the above still true? ARM currently has (approximately) one kernel per machine. Even just supporting the existing supported stuff and things that have enough resources for installing Debian to be a vaguely sensible thing to do (which excludes quite a lot of potential machines), means at least 10 kernel udebs, and some lesser number of initrds and module sets. That's not really that bad. Given the time limit, it's not bad enough that I'd spend any time worrying about it that I could spend doing porting work. =) OK, fair enough. Likely targets that someone cares about enough to support are: Iyonix, RiscPC, Riscstation, Netwinder, Balloon, CATS, LART. Looking at the Woody boot disks, ARM has support for CATS, LART, RiscPC and Netwinder there. Are these other ones new machines that are supported, or did they fit somehow boot off of those other images? They are new, although Riscstation and Iyonix have been supported with special-case bootfloppies stuff for a while now. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ARM d-i port - someone add me to the alioth project please
OK, having had my arse kicked by AJ, I'm going to spend a bit of time trying to get Lart and balloon working with D-I - Can D-I work down a serial console as primary interface? If not then it's no good on these platforms, and I'll take a look at riscpc instead. I had looked at this a while ago, but since it moved to D-I, my cvs copy was broken, so extra faff was involved and Vince said he was doing it so I let it slide. However it turns out that vince is too busy with kernels to manage D-I porting as well so it hasn't happened, which means I need to sort out alioth CVS use. I've just signed up (set a password) for my account so I can wander round the web stuff, but I can't do a non-anymous cvs checkout: CVS_RSH=ssh cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/d-i co debian-installer snip [EMAIL PROTECTED]'s password: Permission denied, please try again. Do I need to wait for something to get updated (at midnight?) or do I need adding as a developer to the project to get userid cvs access? If so can someone do that please? thanx Presumably adding me to a project as a developer means it will appear on my 'home page' list too? And I've just opened my debian-boot mailbox for the first time in quite a while to find 15,000 new messages (and 16,000 old ones). You _have_ all been busy :-) Once I can check out a version that I know I'll be able to do commits on I'll get stuck in (or do I need to work on an anymous checkout until some competence is shown? - I hope not that's a faff we can all do without). I used to know how b-f worked, but don't know much about d-i. Is there a porters doc I should read before getting stuck in, or any other useful getting-started info? I've got plenty of other comitments like everyone else of course, especially emdebian, which I don't want to let slide as it's actually getting somewhere right now, but the continued lack of an arm d-i port is becoming critical so I should try and do my bit. Anything else adminy that needs doing, or things I should know? TIA Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer anyone?
+++ Adam C Powell IV [03-12-17 00:28 -0500]: On Tue, 2003-12-16 at 15:13, Petter Reinholdtsen wrote: [Adam C Powell IV] Greetings, Just wondering if anyone's tried ARM yet; if not, I might give it a go on my Netwinder... I'm not aware of anyone working on d-i for ARM yet. I look forward to your progress reports. Thanks. Just after the initial post, I looked at the d-i webpage, and noticed that someone named Vince (forgot the last name and am offline, sorry) has made a kernel-image udeb with which d-i boots, and is being sponsored by Othmar. Is this udeb available somewhere? That's Vince Sanders aka kyllikki who works for Simtec http://www.simtec.co.uk/ Now a DD. cc:ed for an update Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#127975: config option for calling hwclock
On Sun, Jan 06, 2002 at 02:20:37PM +, Philip Blundell wrote: In message [EMAIL PROTECTED], Matthias Klose write s: Installing on an Apple Quadra 950 (m68k), I found the first boot hanging when trying to read the hardware clock, and more important, hanging during shutdown, resulting in a fsck for the next boot. Found out the hard way, that the hardware clock is broken on this machine (Debian archives 1999). I realize that the hardware clock works on most systems, but a question (probably for m68k only) to set HWCLOCKACCESS to 'no' in /etc/default/rcS (which is read by hwclock.sh) would be welcome ... Is there really nothing that hwclock can do to detect and avoid this situation? I would be loath to add this kind of stuff to the boot-floppies, particularly if it means the user has to ask more questions. (Admittedly that probably doesn't matter so much for m68k, but still.) Exactly the same problem still exists for RiscPCs with 2.2 kernels (I think it was fixed in recent 2.4 kernels), so some scheme to avoid this automatically would be nice. On riscPCs we added a 'if dpkg-platform = riscpc don't run hwclock' to util-linux. That's a hack too - but is it a more acceptable one? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug: cdimage.debian.org should warn against downloading with an ISDN connection
On Mon 26 Nov, Richard Atterer wrote: On Sun, Nov 25, 2001 at 10:12:53PM +, Philip Blundell wrote: Internal ISDN cards need a pile of modules, plus some supporting user-space stuff. I don't think there is any hope of adding this to the woody boot-floppies at this stage in the game, Hm, OK - so I think the cdimage website will advise people that only the option of downloading a minimal bootable CD image is available to ISDN users, not that of installing from floppy discs. You need to be careful with the use of the term 'ISDN' as this refers to the connection not the computer interface, which is the bit that may cause boot-floppies problems if you have anunsupported sort. i.e. it is only internal ISDN adaptors that cause problems, not extrnal ones that use a serial or ethernet interface - they look just like modems or routers respectively and work fine. I have a serial extrernal ISDN TA here and it work OK with bootfloppies. So the website should say that people with internal ISDN adaptors can't do a network install, but those with extranl ISDN TAs can. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Arm bf problems - termwrap and null strings
On Mon 08 Jan, Adam Di Carlo wrote: Wookey [EMAIL PROTECTED] writes: I've got some Arm boot-floppies (from CVS about 10 days ago ~ 2.2.19) which nearly work. I've fixed a couple of problems and I'll post diffs here when I get a set that work. Sure. Do you have (and, if not, want) direct CVS access? No I don't have it, and yes it would be useful. I'm not fully Debian-approved yet, but I'm partway through the nm process. Current problems are: 2) dbootstrap falls over trying to set the hostname. If you kill it (so it restarts) then it continues but /etc/hostname ends up being "(null)" 9which caues more problems later), so I suspect a similar problem to the one below but haven't gone into the detail yet - that's next to investigate, straight after this mail. I just wonder if this is a prob others found which is now fixed in CVS? Not that I know of. I suggest we keep looking into this. This turned out to be a missing BoxResume() somewhere in utilities/dbootstrap/ I wonder why this didn't show up for other people - maybe I picked a bad moment to take a CVS snapshot. Sounds good, looking forward to your patch. Hope it comes soon. Ah, well, therein lies a tale. Unfortunately I had a minor disaster with incorrectly mapped function keys on a terminal so I managed to bin my working copy. It's not hard to regenerate - just tedious and I haven't got round to it with Xmas and hols and things. Hence the delay... If I was working with CVS directly that would probably be more reliable. I've got some stuff coming up that needs urgent attention bt should be able to get back on this in a couple of weeks (after NY Linux expo). Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#67888: marked as done ([CVS-fixed] Netwinder/arm port shouldn't ask about maintaining 2.0 compatability)
On Mon 27 Nov, Adam Di Carlo wrote: Wookey [EMAIL PROTECTED] writes: On Thu 23 Nov, Adam Di Carlo wrote: Wookey [EMAIL PROTECTED] writes: On Tue 21 Nov, Debian Bug Tracking System wrote: From [EMAIL PROTECTED] Sat Jul 29 01:11:08 2000 Return-path: [EMAIL PROTECTED] The debian installer for potato worked just fine on the netwinder, one I convinced it to tftp boot the provided netwinder-rescue image. One hitch though -- the question about maintaining 2.0 compatability for the ext2 fs should be removed and forced to "yes". Answering "no" causes the netwinder's firmware (which is just a stripped down linux kernel) to be unable to read the filesystem -- so it is unable to boot the system. Not that big a deal though. Could you file this as a bug? erm, are you confused adam? The above para has already been filed as a bug and you replied saying it was fixed in bf2.2.17 (see below - it was this message that I replied to). That's all fine so far as I can tell. Or do you mean I should file the fact that this causes (may cause?) a different problem for RiscPC as a bug? Yes, the different problem. OK. I've researched this a little and have actually found a good reason to keep kernel 2.0 compatibility by default (the RISCOS ext2fs reader iscafs needs it). So we can stick with the same option as netwinders for now. I'll include this in my forthcoming boot-floppies patches for arm, and not file a bug about it. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building arm boot floppies - python error in dbootstrap/lang
On Fri 24 Nov, Michael Sobolev wrote: On Fri, Nov 24, 2000 at 06:18:01PM +, Wookey wrote: Now, when I do make release - When it gets to boot-floppies/utilities/dbootstrap/langs dir it compiles iconv.so OK and then does: ./ver2.py 0 i386 langs.xml (I'm suspicous about that i386, but replacing it with 'arm' doesn't affect the error and it does seem to have been deliberately overridden- what is this about?) The result is; Well, this i386 is about the contents of *.src (*.xml) files. So this needs only to be changed in case this set of boot floppies is being built for arm platform. :) Actually, it's something that should be changed as soon as something reasonable appears in *.src files... snip But, it's only needed if we want lc on arm platform. :) see below What version of debian you are using, BTW? 2.2r0 Can I just skip this stuff as yet more language-specifc jiggery-pokery that I almost certanly don't need? Hopefully so, and actually you should not see anything about langs directory if you have not set USE_LANGUAGE_CHOOSER=true in config file. That's not true. As with the previous problem I mentioned (about bf-utf libraries) even though I have USE_LANGUAGE_CHOOSER=false it still generates iconv.so, dumper.pyc helpers.pyc, all the .xml files, lans.o and langs.c If you could fix it so this didn't happen that would save some time where LC-bootfloppies are not required. Anyway. thanx to all for your help. I've finally got some RiscPC bootfloppies built (only takes about 6 hours :-/ ). Now I just have to make them work properly. I can see from the scripts that a fair amount of work is needed to get proper ARM sub-arch support. I'll work on this and send in some patches as soon as the present panic is over. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building arm boot floppies - python error in dbootstrap/lang
On Fri 24 Nov, Wookey wrote: The arm boot-floppies building saga continues. replying to my own post - sorry (just to save anyone spending too much time investigating) ./ver2.py 0 i386 langs.xml ImportError: ./iconv.so: R_ARM_PC24 relocation out of range This may be an arm-specific problem (I've asked a guru about that), OK, the guru came through with an updated glibc and this fixes that problem, so it's not a bf thing. I'd still like to know what all this stuff is for though. I'll see how far I get this time Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#67888: marked as done ([CVS-fixed] Netwinder/arm port shouldn't ask about maintaining 2.0 compatability)
On Thu 23 Nov, Adam Di Carlo wrote: Wookey [EMAIL PROTECTED] writes: On Tue 21 Nov, Debian Bug Tracking System wrote: From [EMAIL PROTECTED] Sat Jul 29 01:11:08 2000 Return-path: [EMAIL PROTECTED] The debian installer for potato worked just fine on the netwinder, one I convinced it to tftp boot the provided netwinder-rescue image. One hitch though -- the question about maintaining 2.0 compatability for the ext2 fs should be removed and forced to "yes". Answering "no" causes the netwinder's firmware (which is just a stripped down linux kernel) to be unable to read the filesystem -- so it is unable to boot the system. Not that big a deal though. Could you file this as a bug? erm, are you confused adam? The above para has already been filed as a bug and you replied saying it was fixed in bf2.2.17 (see below - it was this message that I replied to). That's all fine so far as I can tell. Or do you mean I should file the fact that this causes (may cause?) a different problem for RiscPC as a bug? From [EMAIL PROTECTED] Tue Nov 21 05:21:28 2000 This bug was fixed in one of the last two versions of the boot-floppies, either 2.2.17 or 2.2.18, both of which are in Potato now. Erm, this is all fine for netwinders, but for a riscpc (the other main arm desktop platform) this option does not need to be forced to yes. This is just one of many things that vary between arm platforms (which are fairly hetrogenous). I don't know what the disadvantage is, but if it affects disk speed then as the riscps is 'very slow' in this dept it would be nice to have the choice. There are several things that need to be done differently for different arm sub-platforms. Is there an approved mechanism for this at the moment or not? You'd have to ask the ARM porters. Other arches with subarches (such as sparc) look in /proc/cpuinfo and such and automatically deal with this. I _am_ the ARM porters :-). Well, it's not quite that bad, but I'm one of a very few people working on bf for ARM. I take your point that it is better to check this at runtime if possible and take appropriate action than to make different boot-floppies sets, where possible. I was just wondering whether there was official bf policy on how to deal with subarches so that things remained consistent. I'll check out the code and get it to use /proc/cpuinfo if appropriate. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debinst: non-msdos partition table creation support
On Wed 01 Nov, Glenn McGrath wrote: I understand how msdos partition tables work now, its just a bunch of ugly hacks to make use of legacy structures that are long obsolete. msdos partitions need to be supported for machines that need microsoft compatability (and other OS's ?), but i think that we should provided users the ability to create a non-crap partition table. There are heaps of other partition tables formats around, i dont know much about any of them though, i will look into it. RiscOS machines (ARM) use a whole host of partition formats (all third parties invented their own as the original OS assumed one partition per disk). There are at least 4 in quite common use, probably more like 7 in total. We have a libfdisk for boot-floppies which supports 2 of these so far and more will be added (I just got info on a new one promised yesterday). I don't know if any of these provide useful extra functionality over the DOS scheme, but most are simpler, not having sub-partitions. This also means they have more entries, typically 8. Not all ARM machies use this. Eg netwinders have PC-BIOS type partitions on their drives. Most other ARM machines don't have drives at all, just CF cards - I don't know if they allow partitioning :-) So, not sure if that's actually much use to you, but feel free to ask me about ARM partitioning if you need to know, or need things testing or spec sanity-checking to make sure all the above rubbish can be supported. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: boot problem
n Fri 03 Nov, Tim Veazey wrote: Hello, I've just attempted to install debian for the first time (new to the linux world too). The installation seems to go ok. However, when it comes time to reboot, the system freezes after the following boot message: "Setting the System Clock using the Hardware Clock as a reference..." Anyone have any ideas? Thanks very much for your help. You don't say what system you are installing on, but this always happen if you install 2.2r0 on a riscPC (ARM) for example. Hit ctrl-C to get past this point. Then do update-rc.d hwclock remove to stop it happening every time (it will also hang on shutdown) We have done a new util dpkg-platform which can be used in scripts like hwclock to stop it running on platforms where it is broken. However this isn't in the main distribution yet until there is agreement about how the platforms are to managed in this respect. (Contact Chris rutter for details on how this is prgressing). Updated util-linux and debianutils packages to fix this problem are included in our (Aleph One's) ARM 2.2r0 unofficial debian distribution. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: boot-floppies 2.2.17 req'd packages
On Fri 06 Oct, Adam Di Carlo wrote: Here's the list of pkgs from potato-porposed-updates which I used for boot-floppies 2.2.17: base-config_0.33_i386.deb debconf-tiny_0.2.80.17_all.deb libc6_2.1.3-13_i386.deb locales_2.1.3-13_i386.deb makedev_2.3.1-46_all.deb task-x-window-system-core_1.2_i386.deb Porters, please try to replicate this list. Porters, is anyone working on boot-floppies 2.2.17 for non-i386 ? Chris Rutter and Peter Naulls have both been working on boot-floppies for ARM from the CVS since version 2.2.16. Risc-PC support is now basically fixed and patches are being prepared (and some sent in I think). Unfortunately Chris's net connection has been down for about a week so everything has stalled until itis fixed. This should mean we can compile bf 2.2.17 for arm shortly, but I can't be too specific without talking to them. Does bf have to be built manually or do the build daemons get to do it? The ARM build-daemon is now working properly so if it's automatic then it should hhappen automagically in due course? Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
