Bug#793157: flash-kernel: syslinux-style boot configuration on recent u-boot versions
On Wed, Jul 22, 2015 at 08:44:44AM +0100, Ian Campbell wrote: > […] > It's hard to say without logs but I suspect you are missing the > contents of /etc/default/flash-kernel which according to your working > extlinux.conf in your case should should contain: > > LINUX_KERNEL_CMDLINE="root=/dev/mmcblk0p1 ro rootwait" It indeed cointained only “LINUX_KERNEL_CMDLINE="quiet"”. > This would normally be setup by d-i. You can either edit that file > directly or "dpkg-reconfigure -plow flash-kernel" in the chroot. > > You might also be able to add console=tty there to override the default > serial console. Done, and it now boots fine using the boot.scr, thanks! signature.asc Description: Digital signature
Bug#793157: flash-kernel: syslinux-style boot configuration on recent u-boot versions
On Tue, Jul 21, 2015 at 09:48:32PM +0100, Ian Campbell wrote: > > […] > > Long story short, I manually > > "manually" == with debootstrap from a host system or some other way? Yes, debootstrap from my amd64 laptop (second stage in a chroot with qemu-static). I also installed the kernel and flash-kernel in the chroot. I just deleted the /boot/extlinux directory and ran flash-kernel again in the booted system, but it still doesn't work. > > installed Debian Jessie (as well as linux-image-4.0.0-2-armmp and u > > -boot from u-boot-sunxi=2015.04+dfsg1-2) on an > > A20-OLinuXino-LIME2 from Olimex but couldn't get it to boot (even with the > > boot.scr created by flash-kernel when invoked in a chroot with > > “FK_MACHINE="Olimex A20-OLinuXino-LIME2" flash-kernel”) until I created the > > simple /boot/extlinux/extlinux.conf file attached. > > This is a bug, the boot.scr method is expected to work and should be > supported for this system, since there is a db entry. If it is broken > we'd like to know the details of how please, including full logs if > possible. It appears to load the kernel, and then nothing happens anymore, the screen is black and everything appears dead. I have not tried accessing it through the serial console as I don't have the required hardware (that is the reason why I haven't used d-i in the first place, as it lacks display support). > > I'm not sure whether flash-kernel is the correct package to implement this > > feature, but there should be a way to automaticaly generate such files. > > The extlinux packages support generating these files, that support just > needs to be split out and made non-x86 specific I think. > > That support shouldn't be duplicated in flash-kernel. Ok, seems sensible. The dtb file is currently selected by flash-kernel, though. signature.asc Description: Digital signature
Bug#793157: flash-kernel: syslinux-style boot configuration on recent u-boot versions
Package: flash-kernel Severity: normal syslinux-style /boot/extlinux/extlinux.conf superseed boot.scr in recent u-boot versions and seems to be the way forward for u-boot configuration, but I couldn't find anything to automatically generate them in Debian. Long story short, I manually installed Debian Jessie (as well as linux-image-4.0.0-2-armmp and u-boot from u-boot-sunxi=2015.04+dfsg1-2) on an A20-OLinuXino-LIME2 from Olimex but couldn't get it to boot (even with the boot.scr created by flash-kernel when invoked in a chroot with “FK_MACHINE="Olimex A20-OLinuXino-LIME2" flash-kernel”) until I created the simple /boot/extlinux/extlinux.conf file attached. I'm not sure whether flash-kernel is the correct package to implement this feature, but there should be a way to automaticaly generate such files. menu title LIME2 boot menu timeout 10 ontimeout linux LABEL linux KERNEL /boot/vmlinuz-4.0.0-2-armmp INITRD /boot/initrd.img-4.0.0-2-armmp fdt /boot/dtb-4.0.0-2-armmp append root=/dev/mmcblk0p1 ro rootwait
Re: Touchscreen support in d-i
Le jeudi 03 mars 2011 à 20:13 +0100, Samuel Thibault a écrit : [...] > I believe the name should clearly say that it's meant for touchscreens. > Else you'll get mixed with all the on-screen keyboards which are meant > for accessibility. > > Could be something like "touchkbd". Let's go with touchkbd, then! I've tried to open an alioth project for it, but it got rejected, as I'm not a DM. Either someone here could convince alioth admins to create this project, or it could be put elsewhere. Although I would prefer a separate project, I'm fine with it being maintained under say, d-i/touchkbd.git. signature.asc Description: This is a digitally signed message part
Re: Touchscreen support in d-i
Le jeudi 03 mars 2011 à 18:23 +0100, Cyril Brulebois a écrit : > Don't you want to maintain it under d-i/something.git on alioth? :) Why not, although it could really be used outside of d-i or even Debian, and we still have to figure out the "something" part :) > (I can stick to git-hg, but my sending patches might be less comfy for > you as far as merging is concerned?) Merges are not a problem for me, but it might be for you, I don't really know how git-hg handles that... signature.asc Description: This is a digitally signed message part
Re: Touchscreen support in d-i
Just so you know, I've started a new virtual keyboard project to address the second issue. It is inspired by matchbox-keyboard to a certain extent and compatible with its GTK input method (meaning, if you have matchbox-keyboard-im and use it, the keyboard will pop up only when needed, as matchbox-keyboard used to). The main concern of this project is i18n: indeed, where all (I honestly haven't found one that doesn't) on-screen keyboards use their own format, and thus, require someone write a config file for each layout, this one will fetch both keyboard geometry (currently, it will use the "Alpha" section of pc105 keyboards) and layout from X (using XKB). This, plus pango for text rendering, should make it work out of the box for any layout. However, the project is pretty young, suffers from a few bugs, its code should be cleaned up a bit, there should be some way to save additional space, and improve its look, so, any help would be appreciated! Oh, and more importantly, it needs a proper name. Anyway, it is usable already, and the current code can be found at http://hg.sitedethib.com/gikbd/ signature.asc Description: This is a digitally signed message part
Re: Touchscreen support in d-i
Since Squeeze has been released, I'm bringing back this topic, as I find it quite important. Le samedi 06 novembre 2010 à 17:52 +0100, Samuel Thibault a écrit : > Thibaut Girka, le Sat 06 Nov 2010 17:43:39 +0100, a écrit : [...] > > > You mean XLookupString ? > > > > Well, XLookupString works, but i thought there was a better way. > > I've made a quick and dirty modification to matchbox-keyboard, and it > > kinda works, but I'm not sure storing a list of keycode is really a good > > idea. > > What do you mean by "storing a list of keycode"? In a package? In the keyboard definition, so, in a package, yes. > I mean you can fetch it dynamically from the X server, and automatically > display a keyboard appropriately. I'm not sure how it works. We need some really special keyboard, not the geometry of a real keyboard. > You can even watch for layout > reconfiguration, thus no need to explicitely connect with console-setup, > just watch it change the X server layout. That would be the best way to do it I think! > > > Have a look at xkbprint, it exactly is able to show your keyboard as X > > > knows it. > > > > xkbprint prints the name of the keysyms, not the corresponding > > character... or I'm missing something. > > Well, yes, you can use XLookupString to convert the few ones where it'd > be needed to get a nicer output for the user (like eacute -> é, degree > -> °). I guess I just don't see what you think is missing from the X11 > protocol. Yeah, XLookupString is what I've ended up using. signature.asc Description: This is a digitally signed message part
Re: Move g_ether detection from hw-detect.sh to ethdetect.sh?
Le mardi 15 février 2011 à 17:57 +0100, Gaudenz Steinlin a écrit : > I would leave the code in hw-detect.sh unless you can solve a > specific problem with moving the code around. There is similar code > for other modules in hw-detect.sh (like firewire ethernet). It would make this code run only once instead of running it each time hw-detect is called (for instance, having a message about g_ether when detecting disks really is weird). This is not the only way, though (we could do like it's done for firewire ethernet). Regards, Thibaut Girka signature.asc Description: This is a digitally signed message part
Move g_ether detection from hw-detect.sh to ethdetect.sh?
Hi, I was wondering why g_ether (USB gadget module) detection/loading is done in hw-detect.sh, and whether ethdetect.sh would be better suited for that. g_ether is a USB gadget module, meaning that when it's loaded, the USB port behaves like an ethernet adaptator and cannot be used to do anything else. It is currently used as the primary network interface of the FreeRunner, and it is loaded in hw-detect.sh so that the installation can be done using network-console. Regards, Thibaut Girka. signature.asc Description: This is a digitally signed message part
Re: Touchscreen support in d-i
Le samedi 06 novembre 2010 à 16:31 +0100, Samuel Thibault a écrit : > Thibaut Girka, le Fri 05 Nov 2010 22:03:54 +0100, a écrit : > > Hm, but how to do that? > > I've had a quick look at what the gnome tools do, but it really seems > > overly complicated. Moreover, we want a simplified keyboard. > > Maybe we could just have keycodes in the keyboard definition, and use > > xlib to do the keycode to keysym lookup (that way, the layout of the > > virtual keyboard is the one set in X), but AFAIK, keycodes are > > vendor-dependant, and I can't find an xlib function to do KeyCode/KeySym > > to utf8 lookup. > > You mean XLookupString ? Well, XLookupString works, but i thought there was a better way. I've made a quick and dirty modification to matchbox-keyboard, and it kinda works, but I'm not sure storing a list of keycode is really a good idea. > Have a look at xkbprint, it exactly is able to show your keyboard as X > knows it. xkbprint prints the name of the keysyms, not the corresponding character... or I'm missing something. > Samuel > > signature.asc Description: This is a digitally signed message part
Re: Touchscreen support in d-i
Le jeudi 04 novembre 2010 à 23:40 +0100, Samuel Thibault a écrit : > Thibaut Girka, le Thu 04 Nov 2010 23:09:53 +0100, a écrit : > > - How to detect that there is no physical keyboard? > > In principle console-setup should be able to detect that. In some cases > it might not be possible to determine it accurately, so it may be good > to keep an icon available to start it from the touchpad. Yeah, I've seen that. But an icon? I'm not sure where/how to do it... > > - There are only a few layouts, and they are often incomplete/too basic. > > Does it worth the pain of fixing them/adding new ones? Can't it be done > > in a semi-automatic way? > > It should just support xkb-data layouts. Hm, but how to do that? I've had a quick look at what the gnome tools do, but it really seems overly complicated. Moreover, we want a simplified keyboard. Maybe we could just have keycodes in the keyboard definition, and use xlib to do the keycode to keysym lookup (that way, the layout of the virtual keyboard is the one set in X), but AFAIK, keycodes are vendor-dependant, and I can't find an xlib function to do KeyCode/KeySym to utf8 lookup. Gtk has its own functions and tables to do that, however, maybe we could use it, as it's already in d-i. > Samuel > > signature.asc Description: This is a digitally signed message part
Touchscreen support in d-i
This might not be the best moment to talk about that, but well... With the rise of tablet PCs, smartphones, etc., there are more and more computers with touchscreen as the primary input device, and possibly no real keyboard. In order to properly support such computers, d-i needs two things: touchscreen calibration and an on-screen keyboard. To address the first issue, we can run something like xinput-calibrator right after X is started (and save the result in the target's xorg.conf.d), it'll take care of everything, and won't show up if it doesn't detect any touchscreen. However, xinput-calibrator is written in C++, and I don't think it's welcome in d-i? Maybe this could be reconsidered, xinput-calibrator could rewritten in C, or something else could be chosen... I've already been working a bit on the second issue and have working matchbox-keyboard and matchbox-window-manager (a WM is needed in order for matchbox-keyboard to run properly) udebs. However, there is still a lot to do: - When should it be started? Currently, it's started right after X, with a script in /lib/debian-installer.d/ - How to detect that there is no physical keyboard? - The on-screen keyboard should use the selected layout. This should be easy by (re)starting matchbox-keyboard with some environment variables. - There are only a few layouts, and they are often incomplete/too basic. Does it worth the pain of fixing them/adding new ones? Can't it be done in a semi-automatic way? - What to do if the selected layout doesn't exist for matchbox? Let it fallback to the default one? Or should we display only matchbox-supported layouts? I think the first three points can be addressed by starting matchbox-keyboard from somewhere within console-setup, but I'm not too sure yet, as I have only had a quick look at this part of d-i. Any comment is welcome, Thibaut Girka. signature.asc Description: This is a digitally signed message part
Bug#602425: keyboard-configuration: keyboard_present always returns 0
Package: keyboard-configuration Version: 1.57 Severity: minor Tags: patch Because of the two first kbdpattern lines, any string matches the pattern, and keyboard_present will always return 0. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (120, 'unstable'), (105, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.36-rc7+ (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages keyboard-configuration depends on: ii debconf [debconf-2.0] 1.5.36 Debian configuration management sy keyboard-configuration recommends no packages. keyboard-configuration suggests no packages. -- debconf information excluded Index: debian/keyboard_present.sh === --- debian/keyboard_present.sh (révision 65318) +++ debian/keyboard_present.sh (copie de travail) @@ -12,8 +12,7 @@ esac [ -f /proc/bus/input/devices ] || return 0 -kbdpattern='' -kbdpattern="$kbdpattern\|AT Set \|AT Translated Set\|AT Raw Set" +kbdpattern="AT Set \|AT Translated Set\|AT Raw Set" kbdpattern="$kbdpattern\|Atari Keyboard" kbdpattern="$kbdpattern\|Amiga Keyboard" kbdpattern="$kbdpattern\|HIL keyboard"
Bug#593235: New patch
So, here is a new version of the patch.
Changes:
- Removed U-Boot env related things (now, I have to unblock this bug)
- Removed kernel re-compression (useless)
- Added a quick hack to workaround the padding thing, since #584166
probably won't be accepted upstream (I'll sort that out later).
Index: packages/flash-kernel/debian/control
===
--- packages/flash-kernel/debian/control (révision 65159)
+++ packages/flash-kernel/debian/control (copie de travail)
@@ -23,7 +23,7 @@
Priority: standard
XC-Package-Type: udeb
Architecture: arm armel armeb
-XB-Subarchitecture: iop32x ixp4xx kirkwood orion5x
+XB-Subarchitecture: iop32x ixp4xx kirkwood orion5x s3c24xx
Provides: bootable-system
Depends: cdebconf-udeb, installed-base
XB-Installer-Menu-Item: 7300
Index: packages/flash-kernel/debian/flash-kernel-installer.postinst
===
--- packages/flash-kernel/debian/flash-kernel-installer.postinst (révision 65159)
+++ packages/flash-kernel/debian/flash-kernel-installer.postinst (copie de travail)
@@ -32,6 +32,9 @@
"GLAN Tank")
return 1
;;
+ "GTA02")
+ return 1
+ ;;
"HP t5325 Thin Client")
return 1
;;
@@ -106,6 +109,12 @@
"GLAN Tank")
in-target update-initramfs -u || true
;;
+ "GTA02")
+ in-target update-initramfs -u || true
+ if ! apt-install uboot-mkimage; then
+ error "apt-install uboot-mkimage failed"
+ fi
+ ;;
"HP t5325 Thin Client")
in-target update-initramfs -u || true
if ! apt-install uboot-mkimage; then
Index: packages/flash-kernel/debian/flash-kernel-installer.isinstallable
===
--- packages/flash-kernel/debian/flash-kernel-installer.isinstallable (révision 65159)
+++ packages/flash-kernel/debian/flash-kernel-installer.isinstallable (copie de travail)
@@ -2,6 +2,9 @@
set -e
case "`archdetect`" in
+ arm*/s3c24xx)
+ exit 0
+ ;;
arm*/iop32x)
exit 0
;;
Index: packages/flash-kernel/initramfs-tools/hooks/flash_kernel_set_root
===
--- packages/flash-kernel/initramfs-tools/hooks/flash_kernel_set_root (révision 65159)
+++ packages/flash-kernel/initramfs-tools/hooks/flash_kernel_set_root (copie de travail)
@@ -23,6 +23,9 @@
# device?
root_type() {
case "$1" in
+ "GTA02")
+ echo "override"
+ ;;
"Buffalo Linkstation Pro/Live")
echo "override"
;;
Index: packages/flash-kernel/flash-kernel
===
--- packages/flash-kernel/flash-kernel (révision 65159)
+++ packages/flash-kernel/flash-kernel (copie de travail)
@@ -85,6 +85,7 @@
if [ "x$1" = "x--supported" ]; then
case "$machine" in
+ "GTA02")exit 0 ;;
"Buffalo Linkstation Pro/Live") exit 0 ;;
"Buffalo/Revogear Kurobox Pro") exit 0 ;;
"D-Link DNS-323") exit 0 ;;
@@ -141,6 +142,26 @@
subarch=$(echo "$kfile" | sed -e 's/.*-//')
case "$machine" in
+ "GTA02")
+ check_subarch "s3c24xx"
+ tmpdir="$(mktemp -d)"
+ printf "Generating u-boot image..." >&2
+ cp "$kfile" "$tmpdir/kernel"
+ # Hack to work around a bug in some U-Boot versions:
+ if [ $(($(stat -c '%s' "$tmpdir/kernel") % 4)) -eq 0 ]; then
+ echo >> "$tmpdir/kernel"
+ fi
+ mkimage -A arm -O linux -T multi -C none -n "$desc" -a 0x30008000 \
+ -e 0x30008000 -d "$tmpdir/kernel":"$ifile" "$tmpdir/uImage" >&2 1>/dev/null
+ rm -f "$tmpdir/kernel"
+ echo "done." >&2
+ if [ -e /boot/uImage.bin ]; then
+ echo "Creating backup of /boot/uImage.bin." >&2
+ mv /boot/uImage.bin /boot/uImage.bin.bak
+ fi
+ mv "$tmpdir/uImage" /boot/uImage.bin
+ rmdir $tmpdir
+ ;;
"Buffalo Linkstation Pro/Live" | "Buffalo/Revogear Kurobox Pro")
check_subarch "orion5x"
tmpdir="$(mktemp -d)"
signature.asc
Description: This is a digitally signed message part
Bug#593235: flash-kernel-installer: Please add gta02 support
Le mardi 14 septembre 2010 à 23:38 +0200, Martin Michlmayr a écrit : > > > Why do you need to compress the kernel? It should be a zImage or > > > LZMA-image already anywhere. > > > > Yeah, I know, that's a bit tricky (I commented it on the d-i target, but > > I haven't sent it yet). > > So, U-Boot have an image format called multi-file images. > > But there is only one header for the whole image, and so, only one > > compression method. > > This compression method is used both to uncompress the kernel and as the > > compression type of the initrd image. > > If I don't compress the kernel and say "-C gzip", U-Boot will try to > > uncompress the kernel, and will obviously fail (since the kernel is > > executable and uncompress itself). > > If I specify "-C none", it'll run the kernel just fine, but will fail to > > tell the kernel that the initrd image is gzip-compressed... > > So, the only way is to re-compress the kernel... > > We use multi-file images on the HP mv2120 and -C none works fine with > a regular kernel/compressed initrd combination. Does u-boot actually > need to tell the kernel that the ramdisk is compressed? AFAIK the > kernel figures this out itself... but I don't have a Freerunner so I > cannot verify this myself. Maybe you can test again if -C none works, > but it it doesn't then I guess your patch is fine (but maybe with a > comment). I've just tried (sorry for the *very* late reply, I'm busy with various things, and not really in the mood, these days), and you're right. I have probably hit the padding bug, and jumped a bit early to conclusions. I'll send a new patch in a few days. signature.asc Description: This is a digitally signed message part
Re: Bug#593109: r64784 - in trunk/packages/hw-detect: . debian
Le samedi 18 septembre 2010 à 22:13 +0200, Petter Reinholdtsen a écrit : > [Thibaut Girka] > > g_ether is not really a device driver, but a USB gadget module, like > > g_filestorage (that provides USB Mass Storage), and other things > > like that. > > Not quite sure I understand what this mean. But I take it that there > is USB device with some well known USB ID to detect for udev? Well, what I mean is that the driver itself (which g_ether is not) is not all: you have to choose how you want the device to behave: as an USB key (USB Mass Storage)? A network adaptater? A serial console? All those things are done by different modules (like g_ether), that are independent from the driver itself. In our case, the USB interface is the only usable network interface. Furthermore, the other modules are not really useful on this device (well, g_filestorage might be, but has important limitations afaik). http://www.linux-usb.org/gadget/ signature.asc Description: This is a digitally signed message part
Re: Bug#593109: r64784 - in trunk/packages/hw-detect: . debian
Le samedi 18 septembre 2010 à 21:39 +0200, Petter Reinholdtsen a écrit : > While I am fine with the patch as a solution for this problem, can > someone explain why the installed system do not load this module on > its own, for example using udev autodetection? While the USB port is the main network interface of the Neo Freerunner (along with the buggy wireless that's unusable in many situations), the USB port can be used for many other things. g_ether is not really a device driver, but a USB gadget module, like g_filestorage (that provides USB Mass Storage), and other things like that. So, you have a wide choice of modules, and I'm not aware of anything to switch between them. Regards, Thibaut Girka. signature.asc Description: This is a digitally signed message part
Re: On-screen keyboard for g-i
Le samedi 04 septembre 2010 à 07:44 +0200, Christian PERRIER a écrit : > (CC'ing you as I answer quite late and you might miss the answer. No > need to CC me back) (no need to CC me, I'm suscribed to the list) > Quoting Thibaut Girka (t...@sitedethib.com): > [...] > At very first glance, things are working: I just click on the virtual > keyboard and letters are entered. Thanks for your interest :) > A few comments: > - we'll need to have a way to activate this only for devices/machines > that need it. Yeah, but I'm not too sure about how to do this... maybe test if there is a touchscreen? I was planning to see if I can make a xinput-calibrator udeb in order to callibrate the touchscreen (for now, I'm shipping a calibration file). On my laptop, where I have no touchscreen, it says so and exit, maybe we can call it to calibrate the screen, then, if there is one, launch matchbox and matchbox-keyboard? > Probably in place of the standard keymap selection that > means nothing for such machines, I guess (moreover, I did choose the > French layout but the virtual keymap has a QWERTY layout Yeah, I'm only using the default one. Selecting the user-chosen layout would make sense, but matchbox-keyboard provides its own layouts. > - The äëö key is strange. Hitting it turns "e" into "ë", but not "a" > and "o". It also turns "2" to "1/2" and "3" to "3/4". That's how the default layout work, but indeed, that is strange, and I can't see why they made it that way (after all, it's the "äëö" key, why do only "e" => "ë"?). I can take care of that and improve a bit the layout, but I'm not really aware of the upstream situation. > - there are 4 keys at the bottom right, close to "@" that have simple > squares as symbols (probably characters dropped from the font used in D-I). Looking at the layout file, those keys are supposed to be the directional arrows, but no idea why they aren't displayed (they aren't on my laptop, which obviously can display them). I'm going to take a look at the code. signature.asc Description: This is a digitally signed message part
Re: On-screen keyboard for g-i
Le mardi 10 août 2010 à 16:42 +0200, Thibaut Girka a écrit : > Le mardi 10 août 2010 à 09:09 -0400, Christian PERRIER a écrit : > > Quoting Thibaut Girka (t...@sitedethib.com): > > > [...] > > > (I have patches for that, should I file a bug against the adequate > > > packages, with the patches included?). > > > > Sure, to guarantee that nothing is lost. > > Ok, will do that soon. Done: #592504, #592505, #593090 and #593093. #592505 (libfakekey0) and #593090 (matchbox-keyboard-udeb) have already been closed, but the packages will need a binNMU (they have been uploaded despite #592504 blocking them) when libxtst6-udeb will be available. > > Great work, anyway. Even though I haven't seen this, I think your > > descriptions gives a good picture of all this. > > Thanks > If you want to try, I can build an image for x86/qemu right now. "Right now"... well, here it is, but be patient, it's behind my home connection! http://www.sitedethib.com/files/mini.iso signature.asc Description: This is a digitally signed message part
Bug#593235: flash-kernel-installer: Please add gta02 support
Le mardi 31 août 2010 à 22:29 +0100, Martin Michlmayr a écrit : > * Thibaut GIRKA [2010-08-16 16:15]: > > -XB-Subarchitecture: iop32x ixp4xx kirkwood orion5x > > +XB-Subarchitecture: iop32x ixp4xx kirkwood orion5x s3c24xx > > Is s3c24xx what was decided in the end? I remember there was a lot of > discussion of s3c vs s3c24xx but I cannot remember the outcome. If you're talking about the discussion in #503292, then yes, s3c24xx was decided. > > + "GTA02") > > + return 1 > > Is this really what this device will be called in the mainline kernel? > IMHO it would make more sense to use a more descriptive name, but if > GTA02 has been decided already that's obviously fine. There is already basic (really basic, no display or even µSD) support in mainline kernel, and the name is "GTA02". > > + # Modify u-boot environment > > + rootfs=$(findfs /) > > + bootfs=$(findfs /boot) > > + modify_uboot_env $rootfs $bootfs > > + ;; > > I suggest you move this patch out to the patch in #586221. This way, > the current patch can be applied even without the fix for #586221. Ok, I'll probably do that. > > + check_subarch "s3c24xx" > > + tmp="$(tempfile)" > > + printf "Generating u-boot image..." >&2 > > + gzip -9 -c "$kfile" > "$tmp" > > Why do you need to compress the kernel? It should be a zImage or > LZMA-image already anywhere. Yeah, I know, that's a bit tricky (I commented it on the d-i target, but I haven't sent it yet). So, U-Boot have an image format called multi-file images. But there is only one header for the whole image, and so, only one compression method. This compression method is used both to uncompress the kernel and as the compression type of the initrd image. If I don't compress the kernel and say "-C gzip", U-Boot will try to uncompress the kernel, and will obviously fail (since the kernel is executable and uncompress itself). If I specify "-C none", it'll run the kernel just fine, but will fail to tell the kernel that the initrd image is gzip-compressed... So, the only way is to re-compress the kernel... > > + mkimage -A arm -O linux -T multi -C gzip -a 0x30008000 \ > > + -e 0x30008000 -n "$desc" -d "$tmp":"$ifile" > > "$tmp.uboot" >&2 1>/dev/null > > + echo "done." >&2 > > Will this actually boot on any Freerunner machines without the -p > option you proposed in #584166? If you're lucky. Indeed, the chances aren't negligible, maybe this bug will wait for #584166. signature.asc Description: This is a digitally signed message part
Bug#593235: flash-kernel-installer: Please add gta02 support
Package: flash-kernel-installer
Severity: wishlist
Tags: patch
Please add support for the gta02.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (120, 'unstable'), (105, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.35-rc3+ (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
>From b66179b25fc65dab8dee7cb3b867ca54bc8cee5c Mon Sep 17 00:00:00 2001
From: Thibaut Girka
Date: Sun, 15 Aug 2010 13:39:35 +0200
Subject: [PATCH 4/9] flash-kernel: add s3c24xx/gta02 support
---
packages/flash-kernel/debian/control |2 +-
.../debian/flash-kernel-installer.isinstallable|3 +++
.../debian/flash-kernel-installer.postinst | 16
packages/flash-kernel/flash-kernel | 16
.../initramfs-tools/hooks/flash_kernel_set_root|3 +++
5 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/packages/flash-kernel/debian/control
b/packages/flash-kernel/debian/control
index 7d1fc1a..1cc6427 100644
--- a/packages/flash-kernel/debian/control
+++ b/packages/flash-kernel/debian/control
@@ -23,7 +23,7 @@ Section: debian-installer
Priority: standard
XC-Package-Type: udeb
Architecture: arm armel armeb
-XB-Subarchitecture: iop32x ixp4xx kirkwood orion5x
+XB-Subarchitecture: iop32x ixp4xx kirkwood orion5x s3c24xx
Provides: bootable-system
Depends: cdebconf-udeb, installed-base
XB-Installer-Menu-Item: 7300
diff --git a/packages/flash-kernel/debian/flash-kernel-installer.isinstallable
b/packages/flash-kernel/debian/flash-kernel-installer.isinstallable
index fb56721..bd1b2af 100755
--- a/packages/flash-kernel/debian/flash-kernel-installer.isinstallable
+++ b/packages/flash-kernel/debian/flash-kernel-installer.isinstallable
@@ -2,6 +2,9 @@
set -e
case "`archdetect`" in
+ arm*/s3c24xx)
+ exit 0
+ ;;
arm*/iop32x)
exit 0
;;
diff --git a/packages/flash-kernel/debian/flash-kernel-installer.postinst
b/packages/flash-kernel/debian/flash-kernel-installer.postinst
index 164e464..eb7690a 100755
--- a/packages/flash-kernel/debian/flash-kernel-installer.postinst
+++ b/packages/flash-kernel/debian/flash-kernel-installer.postinst
@@ -33,6 +33,9 @@ write_to_flash() {
"GLAN Tank")
return 1
;;
+ "GTA02")
+ return 1
+ ;;
"HP t5325 Thin Client")
return 1
;;
@@ -104,6 +107,19 @@ case "$machine" in
"GLAN Tank")
in-target update-initramfs -u || true
;;
+ "GTA02")
+ in-target update-initramfs -u || true
+ if ! apt-install uboot-mkimage; then
+ error "apt-install uboot-mkimage failed"
+ fi
+ if ! apt-install uboot-envtools; then
+ error "apt-install uboot-envtools failed"
+ fi
+ # Modify u-boot environment
+ rootfs=$(findfs /)
+ bootfs=$(findfs /boot)
+ modify_uboot_env $rootfs $bootfs
+ ;;
"HP t5325 Thin Client")
in-target update-initramfs -u || true
if ! apt-install uboot-mkimage; then
diff --git a/packages/flash-kernel/flash-kernel
b/packages/flash-kernel/flash-kernel
index abf4849..06d29a0 100755
--- a/packages/flash-kernel/flash-kernel
+++ b/packages/flash-kernel/flash-kernel
@@ -85,6 +85,7 @@ fi
if [ "x$1" = "x--supported" ]; then
case "$machine" in
+ "GTA02")exit 0 ;;
"Buffalo Linkstation Pro/Live") exit 0 ;;
"Buffalo/Revogear Kurobox Pro") exit 0 ;;
"D-Link DNS-323") exit 0 ;;
@@ -140,6 +141,21 @@ fi
subarch=$(echo "$kfile" | sed -e 's/.*-//')
case "$machine" in
+ "GTA02")
+ check_subarch "s3c24xx"
+ tmp="$(tempfile)"
+ printf "Generating u-boot image..." >&2
+ gzip -9 -c "$kfile" > "$tmp"
+ mkimage -A arm -O linux -T multi -C gzip -a 0x30008000 \
+ -e 0x30008000 -n "$desc" -d "$tmp":"$ifile"
"$tmp.uboot" >&2 1>/dev/null
+ echo "done." >&2
+ rm -f "$tmp"
+ if [ -e /boot/uImage.bin ]; then
+ echo "Creating backup of /boot/uImage.bin." >&2
+
Bug#586221: flash-kernel-installer/uboot-installer patch
Here is a patch to do that (works only for the GTA02 for now).
From 10351531703fd014d460f67aa331873060cc062f Mon Sep 17 00:00:00 2001
From: Thibaut Girka
Date: Sun, 15 Aug 2010 13:38:33 +0200
Subject: [PATCH 3/9] flash-kernel-installer: add uboot-installer
---
packages/flash-kernel/check.d/_numbers |1 +
packages/flash-kernel/check.d/ext2_boot| 64 +
packages/flash-kernel/debian/control |2 +-
.../debian/flash-kernel-installer.di-numbers |1 +
.../debian/flash-kernel-installer.install |1 +
.../debian/flash-kernel-installer.postinst |1 +
.../debian/flash-kernel-installer.templates| 71 ++
packages/flash-kernel/debian/rules |2 +-
packages/flash-kernel/uboot-installer | 146
9 files changed, 287 insertions(+), 2 deletions(-)
create mode 100644 packages/flash-kernel/check.d/_numbers
create mode 100755 packages/flash-kernel/check.d/ext2_boot
create mode 100644 packages/flash-kernel/debian/flash-kernel-installer.di-numbers
create mode 100644 packages/flash-kernel/debian/flash-kernel-installer.install
create mode 100644 packages/flash-kernel/uboot-installer
diff --git a/packages/flash-kernel/check.d/_numbers b/packages/flash-kernel/check.d/_numbers
new file mode 100644
index 000..18d7600
--- /dev/null
+++ b/packages/flash-kernel/check.d/_numbers
@@ -0,0 +1 @@
+05 ext2_boot
diff --git a/packages/flash-kernel/check.d/ext2_boot b/packages/flash-kernel/check.d/ext2_boot
new file mode 100755
index 000..7109543
--- /dev/null
+++ b/packages/flash-kernel/check.d/ext2_boot
@@ -0,0 +1,64 @@
+#!/bin/sh
+# Check that the boot partition is of type ext2, and that it is marked as
+# bootable. Used for Openmoko FreeRunner (GTA02).
+
+machine=$(sed '/^Hardware/ {s/^Hardware\s*:\s*//;p}' /proc/cpuinfo)
+case "$machine" in
+ "GTA02")
+ ;;
+ *)
+ exit 0
+ ;;
+esac
+
+. /lib/partman/lib/base.sh
+
+for dev in $DEVICES/*; do
+ [ -d "$dev" ] || continue
+ cd $dev
+ open_dialog PARTITIONS
+ while { read_line num id size type fs path name; [ "$id" ]; }; do
+ [ "$fs" != free ] || continue
+ [ -f $id/method ] || continue
+ [ -f $id/acting_filesystem ] || continue
+ [ -f $id/mountpoint ] || continue
+ mountpoint=$(cat $id/mountpoint)
+ filesystem=$(cat $id/acting_filesystem)
+ if [ "$mountpoint" = / ]; then
+ root_fs=$filesystem
+ root_type=$type
+ root_path=$path
+ if [ -f $id/bootable ]; then
+root_bootable=yes
+ fi
+ elif [ "$mountpoint" = /boot ]; then
+ boot_fs=$filesystem
+ boot_type=$type
+ boot_path=$path
+ if [ -f $id/bootable ]; then
+boot_bootable=yes
+ fi
+ fi
+ done
+ close_dialog
+done
+
+# If no separate boot partition exists root acts as boot
+if [ -z "$boot_path" ]; then
+ boot_fs=$root_fs
+ boot_type=$root_type
+ boot_path=$root_path
+ boot_bootable=$root_bootable
+fi
+
+# We require an ext2 filesystem to boot
+if [ "$boot_fs" != ext2 ]; then
+ db_set flash-kernel-installer/uboot/boot_not_ext2 true
+ db_input critical flash-kernel-installer/uboot/boot_not_ext2 || true
+ db_go || true
+ db_get flash-kernel-installer/uboot/boot_not_ext2
+ if [ "$RET" = true ]; then
+ exit 1
+ fi
+fi
+
diff --git a/packages/flash-kernel/debian/control b/packages/flash-kernel/debian/control
index ce959a2..7d1fc1a 100644
--- a/packages/flash-kernel/debian/control
+++ b/packages/flash-kernel/debian/control
@@ -3,7 +3,7 @@ Section: utils
Priority: optional
Maintainer: Debian Install System Team
Uploaders: Martin Michlmayr , Wouter Verhelst
-Build-Depends: debhelper (>= 7.3.10)
+Build-Depends: debhelper (>= 7.3.10), dh-di
Standards-Version: 3.7.2
Vcs-Svn: svn://svn.debian.org/d-i/trunk/packages/flash-kernel
diff --git a/packages/flash-kernel/debian/flash-kernel-installer.di-numbers b/packages/flash-kernel/debian/flash-kernel-installer.di-numbers
new file mode 100644
index 000..0110b8d
--- /dev/null
+++ b/packages/flash-kernel/debian/flash-kernel-installer.di-numbers
@@ -0,0 +1 @@
+check.d lib/partman
diff --git a/packages/flash-kernel/debian/flash-kernel-installer.install b/packages/flash-kernel/debian/flash-kernel-installer.install
new file mode 100644
index 000..cd38ae6
--- /dev/null
+++ b/packages/flash-kernel/debian/flash-kernel-installer.install
@@ -0,0 +1 @@
+uboot-installer usr/share/flash-kernel-installer
diff --git a/packages/flash-kernel/debian/flash-kernel-installer.postinst b/packages/flash-kernel/debian/flash-kernel-installer.postinst
index 22bc6d1..164e464 100755
--- a/packages/flash-kernel/debian/flash-kernel-installer.postinst
+++ b/packages/flash-kernel/debian/flash-kernel-installer.postinst
@@ -5,6 +5,7 @@
set -e
. /usr/share/debconf/confmodule
+. /usr/share/flash-kernel-installer/uboot-installer
log() {
logger -t flash-kernel-installer "$@"
diff --git a/packa
Bug#593109: hw-detect: Register g_ether after loading it
Package: hw-detect Severity: minor Tags: patch For some (well, probably only the Neo FreeRunner), g_ether is automatically loaded by the installer, but it isn't loaded by the installed system. This patch registers g_ether, so that we can ssh to the device after installation. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (120, 'unstable'), (105, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.35-rc3+ (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash >From c04f45ee97dff8e82031e262180057d49e112f91 Mon Sep 17 00:00:00 2001 From: Thibaut Girka Date: Sun, 15 Aug 2010 13:31:13 +0200 Subject: [PATCH 2/9] hw-detect: register module g_ether after loading it --- packages/hw-detect/hw-detect.sh |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/packages/hw-detect/hw-detect.sh b/packages/hw-detect/hw-detect.sh index 32483c9..3fedfe4 100755 --- a/packages/hw-detect/hw-detect.sh +++ b/packages/hw-detect/hw-detect.sh @@ -216,6 +216,7 @@ if [ -d /sys/bus/platform/devices/s3c2440-usbgadget -o \ log "Detected S3C2410/S3C2440 SoC, loading g_ether" load_module g_ether + register-module g_ether fi # If using real hotplug, re-run the rc scripts to pick up new modules. -- 1.7.1
Bug#593108: hw-detect: Install mmc-modules automatically if needed
Package: hw-detect Severity: minor Tags: patch Some devices don't have a hard drive. Instead of manually specifying modules for each device, it might be possible to guess which device needs additional modules. This patch implements one way to do this, by installing mmc-modules if no disk are found. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (120, 'unstable'), (105, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.35-rc3+ (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash >From c784989b10d3e72601e59a8c73723166684fd12d Mon Sep 17 00:00:00 2001 From: Thibaut Girka Date: Sun, 15 Aug 2010 13:30:38 +0200 Subject: [PATCH 1/9] hw-detect: install mmc-modules if no disks are found --- packages/hw-detect/hw-detect.sh |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/packages/hw-detect/hw-detect.sh b/packages/hw-detect/hw-detect.sh index 3e49a42..32483c9 100755 --- a/packages/hw-detect/hw-detect.sh +++ b/packages/hw-detect/hw-detect.sh @@ -29,6 +29,13 @@ if [ -d /sys/bus/pci/devices ] && \ anna-install virtio-modules || true fi +# Install mmc modules if no other disks are found +# (ex: embedded device with µSD storage) +# TODO: more checks? move that to disk-detect? +if [ -z "$(list-devices disk)" ]; then + anna-install mmc-modules || true +fi + if [ -x /sbin/depmod ]; then depmod -a > /dev/null 2>&1 || true fi -- 1.7.1
Bug#593105: tasksel: Please add a "Smartphone" task
Package: tasksel Version: 2.82 Severity: wishlist Tags: d-i patch Hi, A "Smartphone" task providing a lightweight and small-screen-optimized dekstop environment (e17 might be a good candidate) as well as smartphone specific software (FreeSmartphone.org task, for instance) would be a good thing to have in tasksel. Here is a patch providing such a task, although its content and the way it is implemented might be discussable. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (120, 'unstable'), (105, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.35-rc3+ (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tasksel depends on: ii aptitude 0.6.3-3terminal-based package manager (te ii debconf [debconf-2.0] 1.5.33 Debian configuration management sy ii liblocale-gettext-perl1.05-6 Using libc functions for internati ii tasksel-data 2.82 Official tasks used for installati tasksel recommends no packages. tasksel suggests no packages. -- debconf information excluded >From bd2031bedd76d5adc62ae00c216a6a6c47db39fa Mon Sep 17 00:00:00 2001 From: Thibaut Girka Date: Sun, 15 Aug 2010 13:58:25 +0200 Subject: [PATCH] Add smartphone task --- Makefile |5 + info/smartphone.postinst |8 tasks/smartphone | 21 + tasks/smartphone-gta02 | 18 ++ tests/smartphone | 31 +++ 5 files changed, 83 insertions(+), 0 deletions(-) create mode 100644 info/smartphone.postinst create mode 100644 tasks/smartphone create mode 100644 tasks/smartphone-gta02 create mode 100644 tests/smartphone diff --git a/Makefile b/Makefile index bdff344..af55cf6 100644 --- a/Makefile +++ b/Makefile @@ -49,6 +49,8 @@ install: install-data: install -d $(DESTDIR)$(TASKDIR) \ $(DESTDIR)/usr/lib/tasksel/tests + install -d $(DESTDIR)$(TASKDIR) \ + $(DESTDIR)/usr/lib/tasksel/info install -m 0644 $(TASKDESC) $(DESTDIR)$(TASKDIR) for test in tests/*; do \ [ "$$test" = "tests/new-install" ] && continue; \ @@ -56,6 +58,9 @@ install-data: [ "$$test" = "tests/lang" ] && continue; \ install -m 755 $$test $(DESTDIR)/usr/lib/tasksel/tests/; \ done + for script in info/*; do \ + install -m 755 $$script $(DESTDIR)/usr/lib/tasksel/info/; \ + done for package in packages/*; do \ [ "$$package" = "packages/list" ] && continue; \ install -m 755 $$package $(DESTDIR)/usr/lib/tasksel/packages/; \ diff --git a/info/smartphone.postinst b/info/smartphone.postinst new file mode 100644 index 000..915fda1 --- /dev/null +++ b/info/smartphone.postinst @@ -0,0 +1,8 @@ +#/bin/sh +. /usr/share/debconf/confmodule + +db_get passwd/username +if [ -n "$RET" ]; then + sed -i -r -e "s,^NODM_ENABLED=.*,NODM_ENABLED=true," \ + -e "s,^NODM_USER=.*,NODM_USER=$RET," /etc/default/nodm +fi diff --git a/tasks/smartphone b/tasks/smartphone new file mode 100644 index 000..6969fef --- /dev/null +++ b/tasks/smartphone @@ -0,0 +1,21 @@ +Task: smartphone +Section: user +Relevance: 8 +Test-smartphone: 1 +Description: SmartPhone + This task installs software useful for a smartphone. +Key: + xorg + xserver-xorg-video-all + xserver-xorg-input-all + desktop-base + menu + e17 + nodm +Packages: list + fso-frameworkd + fso-utils +# Other stuff + xdg-utils + anacron + vala-terminal diff --git a/tasks/smartphone-gta02 b/tasks/smartphone-gta02 new file mode 100644 index 000..b1717c5 --- /dev/null +++ b/tasks/smartphone-gta02 @@ -0,0 +1,18 @@ +Task: smartphone-gta02 +Relevance: 8 +Section: user +Enhances: smartphone +Test-smartphone: GTA02 +Description: Environment for GTA02 + Hey, that rox TODO +Key: + fso-config-gta02 +Packages: list +# xserver-xorg-input-tslib + xserver-xorg-video-glamo + mtd-utils +# fso-gpsd + fso-gsmd + fso-abyss + zhone + foxtrotgps diff --git a/tests/smartphone b/tests/smartphone new file mode 100644 index 000..99d4855 --- /dev/null +++ b/tests/smartphone @@ -0,0 +1,31 @@ +#!/bin/sh +# Causes a task to be selected if the machine appears to be a smartphone. +set -e + +#TODO: more generic test? +# probably not, since we want device-specific things + +machine=$(grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//') + +case "$machine" in + "GTA02") + ;; + *) + # Machine not found + exit 3 + ;; +esac + +if [ "$TESTING_ENHANCER" ]; the
Re: How to configure a package (e.g.: nodm) for the "normal user"?
Le jeudi 12 août 2010 à 16:00 +0200, Petter Reinholdtsen a écrit : > Why not? It seem to be present in target, as the only one of the > user-setup-udeb templates. Do not have a test installation around > that actually created a local user during installation, so I can't > verify that it have any useful content. :) Oh, right, I can do that on my laptop, and it seems that it's pkgsel copying it to the target! So, my issue is probably solved, I'm trying right now :) Thanks, Thibaut Girka. signature.asc Description: This is a digitally signed message part
How to configure a package (e.g.: nodm) for the "normal user"?
Hi, I'm working on a "Smartphone" task that'll install, amongst other packages, e17 and nodm. I need to configure nodm, telling it which user to run X for. I first thought about a task-specific configure script, and found /usr/lib/tasksel/info. But it runs in the target, and so, can't access the passwd/username debconf value... I then thought about guessing from passwd (getting the list of users with id >= 1000 and if there is one and only one, configure nodm for it), but the user is only created in finish-install... So, how should I do that? In pre-pkgsel.d? In finish-install? In any other udeb? I don't really like this idea as it is really a task (maybe even package) specific issue... Hm... maybe the users can be set up at the end of base-install instead of finish-install? Is there any reason for that? Regards, Thibaut Girka. signature.asc Description: This is a digitally signed message part
d-i building broken?
Hi,
Today, I updated my repo and build-system, then tried to build d-i again.
It failed miserably with "dpkg: version '1%3a1.17.1-2' has bad syntax: invalid
character in version number".
I think it's due to dpkg upgrade, and especially because of the commit
662d97913fe8d9f4aa784ca7595c415c65202148 which introduce stricter (but correct)
parsing,
and the fact that installer/build/util/get_packages get its package versions
from the filename, which are escaped ("a:b" becomes "a%3ab").
I've not seen any complaint out there, so, maybe I'm the only one affected?
Weird.
Anyway, if that's not the case, I've attached a patch, which implements the
easiest, and maybe most "secure" way of getting the version string, but is
obviously slower: ask dpkg.
Regards,
Thibaut Girka.
diff --git a/installer/build/util/get-packages b/installer/build/util/get-packages
index 47b5aa9..a80fe16 100755
--- a/installer/build/util/get-packages
+++ b/installer/build/util/get-packages
@@ -189,7 +189,7 @@ lnpkg() {
local pkg=$1; local dir=$2 debdir=$3
local L LV l lv
for l in `find $dir -name "${pkg}_*" 2>/dev/null`; do
- lv=${l%_*}; lv=${lv##*_};
+ lv=$(dpkg -f "$l" Version); lv=${lv%"Version: "}
if dpkg --compare-versions "$lv" gt "$LV"; then
L=$l LV=$lv
fi
signature.asc
Description: This is a digitally signed message part
Re: On-screen keyboard for g-i
Le mardi 10 août 2010 à 09:09 -0400, Christian PERRIER a écrit :
> Quoting Thibaut Girka (t...@sitedethib.com):
> > Hi,
> > Lately, I've been trying g-i on the FreeRunner, and one of the obvious
> > issues is that the FR doesn't have a keyboard.
> > So, I've decided to make a matchbox-keyboard udeb.
> > First thing is that it requires a few libs which don't have a udeb yet
> > (I have patches for that, should I file a bug against the adequate
> > packages, with the patches included?).
>
> Sure, to guarantee that nothing is lost.
Ok, will do that soon.
> > Second thing is that it needs a window manager (otherwise, it'll be
> > misplaced, cover g-i, and take focus when clicking on it, which defeats
> > the purpose of an on-screen keyboard).
> > So, I've made a matchbox-window-manager udeb, configured differently
> > from the matchbox-window-manager package so it depends only on things
> > that already have a udeb.
> >
> > For now, each of the two packages ship a script
> > in /lib/debian-installer.d/ to start (unconditionally. How to be sure
> > there is no keyboard? Query X? udev? And I've heard about security keys
> > that behaves like keyboards...) after X.
> > Should this files be shipped in those packages, or in some other package
> > (rootskel-gtk, or some package made for the occasion)?
>
>
> Would be nice to have this in D-I SVN. Maybe first under people/
> before we move it to packages/ when things are reviewed/ready.
Well, those (matchbox-{window-manager,keyboard}-udeb) are built from the
same packages than matchbox-window-manager and matchbox-keyboard, so, it
shouldn't be in packages/.
I'll file a bug when I'm sure about the /lib/debian-installer.d/ thing.
> Great work, anyway. Even though I haven't seen this, I think your
> descriptions gives a good picture of all this.
Thanks
If you want to try, I can build an image for x86/qemu right now.
signature.asc
Description: This is a digitally signed message part
On-screen keyboard for g-i
Hi, Lately, I've been trying g-i on the FreeRunner, and one of the obvious issues is that the FR doesn't have a keyboard. So, I've decided to make a matchbox-keyboard udeb. First thing is that it requires a few libs which don't have a udeb yet (I have patches for that, should I file a bug against the adequate packages, with the patches included?). Second thing is that it needs a window manager (otherwise, it'll be misplaced, cover g-i, and take focus when clicking on it, which defeats the purpose of an on-screen keyboard). So, I've made a matchbox-window-manager udeb, configured differently from the matchbox-window-manager package so it depends only on things that already have a udeb. For now, each of the two packages ship a script in /lib/debian-installer.d/ to start (unconditionally. How to be sure there is no keyboard? Query X? udev? And I've heard about security keys that behaves like keyboards...) after X. Should this files be shipped in those packages, or in some other package (rootskel-gtk, or some package made for the occasion)? I've tried those packages on my FR, it seems to work perfectly: you can't notice the WM and the keyboard only shows up when an entry is selected (thanks to the gtk input module). Regards, Thibaut Girka. signature.asc Description: This is a digitally signed message part
Bug#592048: cdebconf: unable to display "${something}"
Package: cdebconf
Version: unable to display "${something}"
Severity: minor
Tags: d-i
I'm writing a tool to modify the u-boot environment on certain devices.
At a point, I'm showing the user the changes to make to his environment.
Such changes usually contains the "${mtdparts}" string, that triggers an
assertion error in cdebconf when displayed.
I have made several tests:
1°) db_subst uboot-installer/apply_changes CHANGES "$$" shows "$$",
2°) db_subst uboot-installer/apply_changes CHANGES "\${mtdparts}" aborts
3°) db_subst uboot-installer/apply_changes CHANGES "$\{mtdparts}" shows
"$\{mtdparts}", which is not what I want
Reading the source code, I finally came to the conclusion that cdebconf expands
"${...}" no matter what, and wants it to be a directive.
Reading the doc, I've found that a non-implemented directive does nothing and
is replaced by an empty string, so, here is my ugly hack that works:
db_subst uboot-installer/apply_changes CHANGES "$${!}{mtdparts}"
This feels a bit wrong, and I think there should be a better way to do that.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (120, 'unstable'), (105, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.35-rc3+ (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages cdebconf depends on:
ii debconf 1.5.33 Debian configuration management sy
ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib
ii libdebian-installer4 0.74 Library of common debian-installer
ii libnewt0.52 0.52.11-1 Not Erik's Windowing Toolkit - tex
ii libslang2 2.2.2-4The S-Lang programming library - r
pn libtextwrap1 (no description available)
cdebconf recommends no packages.
Versions of packages cdebconf suggests:
pn cdebconf-gtk (no description available)
--
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/20100807042003.11752.77276.report...@localhost.localdomain
Re: Thoughts about network-console
Le jeudi 05 août 2010 à 20:17 +0200, Frans Pop a écrit : > (No need to CC on replies: I read the list.) > > On Thursday 05 August 2010, Thibaut Girka wrote: > > If you're talking about user-setup, they are cleared, that the first > > thing I've checked (better done that checking network-console, it seems) > > before sending this mail. > > With user-setup the passwords are asked by a different (much earlier [1]) > script than the one that creates the accounts and sets the passwords. So > they *must* be in the debconf database for at least the time in between. > > The fact that they are cleared afterwards - only at the very, very end of > the installation: just before the reboot - seems to me like a mostly empty > gesture. At least for the attack vector you were concerned about. You're right, I was expecting it to do that at the end of the base-install step, but here too, it would be readable for quite a long time. signature.asc Description: This is a digitally signed message part
Re: Thoughts about network-console
Le jeudi 05 août 2010 à 14:58 +0200, Frans Pop a écrit : > On Thursday 05 August 2010, Thibaut Girka wrote: > > > Did you actually check this? The password templates are of type > > > 'password' and thus the value should be in > > > /var/lib/cdebconf/passwords.dat (and thus encoded) instead of in plain > > > text in questions.dat. > > > > Well, you can still db_get the password, can't you? > > Yes. > > > As said earlier, I was, for some reason, sure that the postinst script > > didn't clear the passwords... > > The fact that it clears the passwords is somewhat accidental (it has more > to do with allowing to re-enter the passwords if they are unequal than > with security considerations). > There are also other fields in passwords.dat, like the root and first user > passwords, that are possibly not cleared. If you're talking about user-setup, they are cleared, that the first thing I've checked (better done that checking network-console, it seems) before sending this mail. > Systems are vulnerable anyway when people have physical access to them. > That they are a bit more vulnerable during installation is almost > unavoidable, but in most cases the window (time from start of install to > reboot) is quite short. Well, depends on what you mean by "short", but I agree. > I don't think this is something we should worry too much about. Hence the "paranoid". signature.asc Description: This is a digitally signed message part
Re: Thoughts about network-console
Hi, > > Then, an untrustworthy colleague goes to the computer, and just > > reads /var/lib/cdebconf/questions.dat: installer's password is there, > > plain, clear text. > > Did you actually check this? The password templates are of type 'password' > and thus the value should be in /var/lib/cdebconf/passwords.dat (and thus > encoded) instead of in plain text in questions.dat. Well, you can still db_get the password, can't you? > Also, if you look at the postinst script for network-console, you'll see > that the template already *is* cleared after the password is asked. Oh, my bad, you're right. I've actually read it, but for some reason, I overlooked the exact thing I was searching for... > The only case in which AFAICT what you describe can be true is when the > template is preseeded [1] while the network-console component is not yet > loaded (because then the template could be created as a regular template > instead of as a password one). As preseeding passwords in itself already > lowers security, I don't really think this is an important bug. > > Please verify that you really do see readable passwords and describe the > exact scenario (architecture / image / installation method used) in which > you do. As said earlier, I was, for some reason, sure that the postinst script didn't clear the passwords... So, please ignore this first "issue", as it wasn't here in the first place. Regards, Thibaut Girka. signature.asc Description: This is a digitally signed message part
Thoughts about network-console
Hi, I have some thoughts that I would like to discuss with you about network-console: First is a (quite paranoid) security consideration: Let's say that some user wants to install Debian remotely in his working environment. He starts the installation in front of the computer, sets a password, that happen to be its daily-use one. He then do the remaining steps remotely. Then, an untrustworthy colleague goes to the computer, and just reads /var/lib/cdebconf/questions.dat: installer's password is there, plain, clear text. So, I think we should remove this password from the debconf database as soon as it is written to /etc/shadow. Second is quite the opposite: I would like to have a debconf boolean to display the password in the network-console/start note. The reason behind this is that, on some devices, with display and no usable input, we can (and were already doing) display network-console/start. On such devices, the password is set by a preseed file, so, showing it should be helpful to the user. I don't think there are strong security issues there, since somebody that have access to the screen probably have physical access to the device too. Making it a debconf boolean defaulting to false (and probably never displayed to the user?) should make it not be a security problem outside of the scope of the few devices with such preseeding. Best regards, Thibaut Girka. signature.asc Description: This is a digitally signed message part
Bug#591433: kernel-wedge: Please add g_ether to nic-usb-modules
Package: kernel-wedge Version: 2.64 Severity: wishlist Tags: d-i The Neo Freerunner possesses two nics, the first one being the wifi chip, which driver won't ever go upstream. The other is its USB port thanks to the g_ether module, which is already mainline since at least 2.6.32. So, please add g_ether to nic-usb-modules. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (120, 'unstable'), (105, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.35-rc3+ (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kernel-wedge depends on: ii debhelper 7.9.3 helper programs for debian/rules ii make 3.81-8 An utility for Directing compilati kernel-wedge recommends no packages. kernel-wedge suggests no packages. -- no debconf information -- 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/20100803005335.4440.79936.report...@localhost.localdomain
Automatically installing mmc-modules for targets requiring it
Hi, I'm currently working on a d-i image for the Neo Freerunner, and the only useful storage on it is the µSD (well, there is NAND, but it's not supported in d-i for now, and it's quite small). So, d-i have to install mmc-modules to do anything useful. I can see several ways to achieve that: 1°) Add mmc-modules in the target specific pkg-list. Easiest way, but not sure it's the best. 2°) Change mmc-modules priority to standard for the specific sub-architecture. IMO, this is quite wrong since every target of the sub-architecture will install mmc-modules automatically, although it doesn't hurt in my case, for now. 3°) Detect the machine by reading /proc/cpuinfo like flash-kernel does, and install mmc-modules for the targets that need it. 4°) Install mmc-modules if no disk are detected, using something like: if [ -z "$(list-devices disk)" ]; then anna-install mmc-modules || true fi I prefer the last one, since it's the most generic one, but maybe it is too generic? Thanks, Thibaut Girka signature.asc Description: This is a digitally signed message part
Re: [pkg-fso-maint] GSoC 2010: Debian Installer on Freerunner
> > Regarding the FreeRunner, I've got one since the beginning of the year, > > and I use it as my sole phone. > > I have flashed SHR unstable on the NAND, and I've manually (reading the > > so-called install.sh script) installed Debian on a µSD card, although I > > rarely > > use it. > > For porting d-i to it it would be good if we could get you a second > freerunner or if you have another phone you could use during this > time... Calls won't work during installation ;-) And you probably will > do many installations... Yeah, I have another phone that I can use, that's not an issue :) > > I haven't tried d-i on the FreeRunner yet, but I think the main > > issues/things to do would be: > > * Starting d-i. I can see two ways of doing it: > > - Putting it on a µSD card, maybe not the easiest thing if there's > > already something on it. > > - Using kexec on a host system to run d-i without altering the > > partition table beforehand. > > I and Luca Capello (gismo) worked on d-i for the freerunner at Debconf > 9. We decided back then that whatever method we choose it should be > supported by the factory default settings of the u-boot on the > freerunner. > > This means that you have to combine the kernel and initramfs into one > u-boot image. This is possible but a bit tricky to get right. Yeah, I've made some tests, and I can see how to create a multi-file u-boot image. I have yet to build a kernel along with an initramfs and see how to boot it properly :) > > * Using the kernel from pkg-fso > > This won't work. Period. If you want to integrate your work into the > official d-i you have to use a kernel built from the linux-2.6 package > in the main archive. > > So first all the bits to support the freerunner so that it can run d-i > must go into Linus kernel tree. As the kernel team most probably won't > accept any patches not accepted upstream. > > We basically need glamo mmc support in addition to basic boot support > for the freerunner to be able to support d-i. The glamo mmc support is > needed to access the SD card because the SD card is connected to the > glamo. > > Then we need a kernel configuration for the s3c24xx architecture and a > patch to enable an image for this architecture for linux-2.6. The kernel > configuration should be as similar as possible to the configurations of > the other kernel images (especially the other arm images). This is where > I stopped by the end of last year because of lack of time. If you want > to continue this work I can provide you with a partially working patch > for linux-2.6. Can't we use, for a start, linux-2.6-openmoko as it is? > > * Hacking g-i to work with the touchscreen and > > provide an on-screen keyboard. > > Gismo and I were rahter targetting the network-console mode of d-i that > is used on headless NAS devices. The idea was that d-i would setup the > usb network and you could connect to it by sshing over this usb network. > I think that would be far easier. I will need networking anyway to > download packages and wifi is not an option for the installer because > the support for connecting to encrypted networks in d-i is minimal AFAIK > and ar6000 won't most probably go upstream ever and therefore not be > included in the Debian kernel. Didn't think about that, but I guess it's the way to go. > > As far as I know, directfb is being dropped in favor of X11, so, it > > shouldn't be that much of an issue. > > * Including all those things in a fairly lightweight initrd. > > It depends on your definition of lightweight. I would call all the d-i > initramfs (it's technically not an initrd anymore) fairly heavyweight. Well, with X and so, it might have been quite challenging. > I expect the core d-i part of all of this to be small and not very > difficult. AFAIR we had it already running until the bootloader step at > Debconf with a custom version of the pkg-fso kernel. The hard parts are: > - Create a kernel package for the freerunner based on the linux-2.6 > package in main > - Figure out the best layout for booting Debian in parallel to another > distribution in NAND and configure u-boot to do the right thing and > warp all this into an udeb for the d-i. > - Post installation stuff like creating a fso/freerunner task which gets > automatically installed if a freerunner is detected. > > > I would be willing to be your mentor if your commited to properly integrate > your work into the existing Debian infrastructure (like useing a kernel > based on linux-2.6, make your modifications so that they are acceptable > to the d-i team). My d-i knowledge is a bit rusty, but I think I know > the basic things and could point you in the right direction if you have > any questions. I was planning to use the kernel package in pkg-fso, at least at the beginning, because I don't know the main differences yet. I'm interested in having a clean kernel package, however, I have no experience in kernel hacking. > I'm glad to see some
