Re: Building CD images including firmware
On Wed, May 8, 2019 at 7:24 PM Steve McIntyre wrote: > > I'm afraid not, this is YA place where things are not documented very > well at all. There's an extra set of options to pass in to the > debian-cd build, basically. Look at > > https://salsa.debian.org/images-team/setup/blob/master/buster/cronjob.daily May I ask a follow up question? What's the difference between "cd-including-firmware" and "images-including-firmware" under URL below? - http://cdimage.debian.org/cdimage/unofficial/non-free It seems same to me. Is it just symbol linked? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#927165: debian-installer: improve support for LUKS
On Tue, Jun 11, 2019 at 12:06 AM Guilhem Moulin wrote: > > Hi there, > > On Mon, 15 Apr 2019 at 23:24:19 +0200, Cyril Brulebois wrote: > >>> One could argue that cryptodisk support has never been supported by > >>> d-i anyway, > >> > >> Yup, and I suppose that's why I overlooked this in my mail to > >> debian-boot :-P Jonathan Carter had a similar report last week > >> > >> https://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/2019-April/008196.html > > > > While I'm usually fine to dismiss some bug reports as “it's unsupported, > > sorry”, making users' life harder doesn't seem really reasonable… :/ > > During last week's gathering at MiniDebConf Hamburg we (cryptsetup package > maintainer + KiBi) talked and came up with the following guide/notes: > > https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html Thank for the above doc, which is quite easy understanding and straightforward! I didn't notice this until it's mentioned by release announcement of D-I RC2 [1]. I confirmed with /boot set up in LUKS1, everything works fine. It‘d configure non encrypted /boot when in D-I, then after finishing D-I, and reboot to system, manually make LUKS1 for /boot partition. However, I found adding: GRUB_PRELOAD_MODULES="luks cryptodisk" to /etc/default/grub is not necessary. GRUB_ENABLE_CRYPTODISK=y is the only setting need to append manually. (/etc/fstab /etc/crypttab need to be edited for sure) Thanks again for your effort on the guide/notes above! [1] https://lists.debian.org/debian-devel-announce/2019/06/msg5.html -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#871835: speed up for debootstrap
On Sat, Aug 12, 2017 at 1:54 PM Thomas Lange wrote: > > old version 1.0.89 > real1m26.940s > user1m24.180s > sys 0m2.420s > > > including the patches > real0m39.481s > user0m50.444s > sys 0m2.748s have you compared with cdebootstrap? - https://tracker.debian.org/pkg/cdebootstrap Just curious.. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#871835: speed up for debootstrap
Dear Thomas, On Wed, Jan 2, 2019 at 7:51 PM Thomas Lange wrote: > > >>>>> On Sun, 23 Dec 2018 22:52:36 +0900, Roger Shimizu > >>>>> said: > > > On Sat, Aug 12, 2017 at 1:54 PM Thomas Lange > > wrote: > >> > >> old version 1.0.89 > >> real1m26.940s > >> user1m24.180s > >> sys 0m2.420s > >> > >> > >> including the patches > >> real0m39.481s > >> user0m50.444s > >> sys 0m2.748s > > > have you compared with cdebootstrap? > > - https://tracker.debian.org/pkg/cdebootstrap > cdebootstrap takes about 30 sec real time and 40 sec user time. Really thanks for your test result, and the patches! Since cdebootstrap usually install smaller set of packages, I think they're now pretty close at speed. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
RFC: android-style boot image support for flash-kernel
Hi there, I'm trying to support an ARM based RB3 / DB845c [1] dev-board with android-style boot image to flash-kernel. (Surely it's targeting to post-bookworm) Currently, the dev-board is supported by Linaro [2][3], and most kernel device-tree, patches and firmware are already upstreamed. I confirmed that with simple snippet below, generated boot.img can be used to boot the RB3 / DB845c dev-board with linaro's rootfs [3]. PS. mkbootimg [4] is a tool from android's package to generate boot.img image to boot the dev-board. My question is: - Currently flash-kernel is mainly u-boot based, is it proper to add "mkbootimg" based devices? - Does mkbootimg need to support udeb in order to support D-I for this dev-board in the future? If this dev-board is feasible, I'm planning to add a few similar dev-boards from the series. So your advice will be appreciated! gzip -c9 /boot/vmlinuz-6.1.0-8-arm64 > vmlinuz.gz cat vmlinuz.gz /usr/lib/linux-image-6.1.0-8-arm64/qcom/sdm845-db845c.dtb > Image mkbootimg \ --kernel Image \ --ramdisk /boot/initrd.img-6.1.0-8-arm64 \ --output boot.img \ --pagesize "4096" \ --base "0x8000" \ --kernel_offset "0x8000" \ --ramdisk_offset "0x100" \ --tags_offset "0x100" \ --cmdline "root=PARTLABEL=rootfs console=tty0 console=ttyMSM0,115200n8 clk_ignore_unused pd_ignore_unused" [1] https://www.96boards.org/product/rb3-platform/ [2] https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/latest [3] https://releases.linaro.org/96boards/dragonboard845c/linaro/debian/latest [4] https://packages.debian.org/unstable/mkbootimg Cheers, Roger
Re: RFC: android-style boot image support for flash-kernel
Dear Vagrant, Appreciate your response! On Sun, Apr 30, 2023 at 3:40 PM Vagrant Cascadian wrote: > > On 2023-04-30, Roger Shimizu wrote: > > I'm trying to support an ARM based RB3 / DB845c [1] dev-board with > > android-style boot image to flash-kernel. > ... > > My question is: > > - Currently flash-kernel is mainly u-boot based, is it proper to add > > "mkbootimg" based devices? > > My main worry here is investing too much in flash-kernel, rather than > replacing it... both require possibly significant effort, and I wonder > if that effort would not be better spent writing a more modular > replacement for flash-kernel? That said, I have not mustered the energy > to do this myself... > > To some degree, I have been the de-facto maintainer for flash-kernel, > but I am hesitant to make significant changes to it... it is not easy > code to read... Yes, I agree that flash-kernel is difficult to understand and maintain. But we have to use it (at least before any alternative appears), and extend it a bit to adapt to our recent needs. > > - Does mkbootimg need to support udeb in order to support D-I for this > > dev-board in the future? > > I *think* that the udeb (indirectly?) calls flash-kernel inside the > chroot... so I am not sure that would be necessary. There's no > "u-boot-tools" udeb, and many boards use mkimage from "u-boot-tools". Thanks for the info! I'll dig it deeper. > > gzip -c9 /boot/vmlinuz-6.1.0-8-arm64 > vmlinuz.gz > > cat vmlinuz.gz /usr/lib/linux-image-6.1.0-8-arm64/qcom/sdm845-db845c.dtb > > > Image > > mkbootimg \ > > --kernel Image \ > > --ramdisk /boot/initrd.img-6.1.0-8-arm64 \ > > --output boot.img \ > > --pagesize "4096" \ > > --base "0x8000" \ > > --kernel_offset "0x8000" \ > > --ramdisk_offset "0x100" \ > > --tags_offset "0x100" \ > > --cmdline "root=PARTLABEL=rootfs console=tty0 > > console=ttyMSM0,115200n8 clk_ignore_unused pd_ignore_unused" > > That seems "simple" enough, given you're using a Debian packaged kernel > and all. Not so different from the mkimage-style support for u-boot. I have some more good news. I found mkbootimg can be replaced by abootimg command, which is already supported by flash-kernel. And I already try to patch flash-kernel to work with the board. The only issue is we need to gzip the debian kernel, which is #831003 [1], and we already have two patches [2][3] for the ticket. I'm not sure which patch do you prefer, since they existed for so long, but still not merged yet. I tried the 2nd patch [3], and found it needs slightly update, otherwise it cannot be used. I posted the update on the MR. My patch already works well with this path. [1] https://bugs.debian.org/831003 [2] https://bugs.debian.org/831003#10 [3] https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/15 If you prefer the 1st patch, which is simpler and straightforward, just let me know, and I can test it and make adaptations if necessary. > It is a frustrating that there are so many ways to boot arm systems... > but that is the reality out there actually implemented in hardware... > > > live well, > vagrant Variety always costs. I just hope that could be limited to an acceptable level. Cheers, Roger
Bug#794403: flash-kernel: command "update-initramfs -uk " result in boot images in false version
Package: flash-kernel Version: 3.45 Severity: normal Tags: patch Dear Maintainer, Hook script "initramfs-hook/flash-kernel" will be called when update-initramfs is invoked. However flash-kernel only build the latest kernel version it find, rather than the specific version passing from update-initramfs. For example, after running "update-initramfs -uk ", the is successfully passed to "initramfs-hook/flash-kernel", and then "flash-kernel" script, but "flash-kernel" script simply ignore that version, except adding a "--force" flag, which is why this patch is here. I also checked the log for initramfs-hook/flash-kernel, as commit 7bacb9 the kernel version was actually not passed to "flash-kernel" script, but from commit e05fc9, this has been changed, which I think it means the flash-kernel script need to honor what kernel version update-initramfs is working on. Thanks and looking forward to your comments. Cheers, Roger -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (1, 'experimental') Architecture: armel (armv5tel) Kernel: Linux 4.0.0-2-kirkwood Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.56 ii devio 1.2-1+b1 ii initramfs-tools0.120 ii linux-base 3.5 ii ucf3.0030 Versions of packages flash-kernel recommends: ii u-boot-tools 2014.10+dfsg1-5 flash-kernel suggests no packages. >From 1af8343110d71fc4ba6da6e346a384cb910a2b05 Mon Sep 17 00:00:00 2001 From: Roger Shimizu Date: Mon, 3 Aug 2015 00:38:53 +0900 Subject: [PATCH] initramfs-hook: let flash-kernel build the correct version of boot images Currently, flash-kernel script simply ignores the kernel version passing from update-initramfs command, but just pick up a latest kernel to build boot images. This patch fixes that, by adding a "--force" flag to flash-kernel script. Signed-off-by: Roger Shimizu --- initramfs-hook/flash-kernel | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/initramfs-hook/flash-kernel b/initramfs-hook/flash-kernel index 21da5e6..92236b7 100755 --- a/initramfs-hook/flash-kernel +++ b/initramfs-hook/flash-kernel @@ -11,5 +11,4 @@ abi="$1" # ignored _initrd="$2" -exec flash-kernel "$abi" - +exec flash-kernel --force "$abi" -- 2.1.4
Bug#794403: flash-kernel: command "update-initramfs -uk " result in boot images in false version
Dear Ian, Thanks for your detailed comments! > I think your patch will break things by automatically installing (via > the initramfs hook in the kernel postinst) whatever kernel was most > recently installed/upgraded, instead of the latest kernel by version. > We do not want this: consider people who still have stable+testing in > their sources.list and the stable+testing kernel's both installed, they > are expecting to use the testing kernel and do not want to get a > surprise stable kernel installed whenever a DSA is issued against the > Linux package in stable. I understand your concern. Yes, the patch will change the behavior as the case you mentioned. However I feel it's still strange by current mechanism, using your case as example, the "testing" kernel images will get rebuilt when DSA (to "stable") is issued. In this case I think only stuff related to stable kernel can be modified, and all testing kernel stuff should be left untouched. So I consider there's a "bug" here need to be fixed. > An acceptable alternative to your patch might be to add support for a > new option in /etc/default/flash-kernel e.g. LINUX_KERNEL_VERSION which > names an explicit version which is the one which should should always > be installed in flash (unless overridden on the command line). Care > would need to be taken that the kernel exists and to do the right thing > if it is is removed. I like the idea to introduce an option for kernel version, but I also feel terrible considering that option need to be updated manually when kernel ABI gets changed. I see there're a few scripts under /etc/kernel/postinst.d/ which seems to monitor the kernel ABI changing. (also noticed the existence of flash-kernel script there...) I'm not familiar with that part, so need some time to go over. > I think a suitable algorithm for determining the version would be to > consider in order: > > 1. The version on the command line, if any. If one is given but > doesn't exist then error out. > 2. The version from /etc/default/flash > -kernel:$LINUX_KERNEL_VERSION, if it doesn't exist then fall > through to next option(*) with a big fat warning printed. > 3. The currently installed version with the greatest version > number. I feel comfortable with this order. And I think there need to be added another rule: only if the kernel version (deciding from the order list) matches the from update-initramfs command, the flash-kernel should not update boot images otherwise. > The fall through from option 2 to option 3 is important, otherwise a > kernel removal/upgrade/install (which invokes flash-kernel) may find > itself unable to complete if the desired kernel is missing and abort > the whole operation, which will be potentially tricky to recover from > since it will block further apt/dpkg operations until it is sorted out. > Installing the latest kernel if the preferred option is not available > seems better than failing in this case. > People who then want to boot an older kernel could set > LINUX_KERNEL_VERSION and call flash-kernel to make it take effect. I totally agree. Thanks for your consideration in overall! I'll think your points over again, and try to work out a solution. Cheers, Roger -- 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/CAEQ9gEm0_CQOL=pf=x082acablt6cz+302ggtptpdg_gaqa...@mail.gmail.com
Bug#802578: flash-kernel: Add/Update machine db for a few Buffalo Linkstation systems newly supported since Linux 4.3
Package: flash-kernel Version: 3.46 Severity: normal Tags: d-i patch Dear Maintainer, I'm happy to let flash-kernel to support a few Buffalo Linkstation systems, which newly supported by upstream Linux 4.3. I've confirmed those DTB are already ready for linux-image 4.3~rc5-1~exp1 in experimental deb repo. Hope you can merge my patch soon. Thank you! Cheers, Roger >From 368d065b975a51f2c4e3e3a84e593f16945fca30 Mon Sep 17 00:00:00 2001 From: Roger Shimizu Date: Wed, 21 Oct 2015 19:43:07 +0900 Subject: [PATCH 2/2] Add/Update machine db entries for a few Buffalo Linkstation systems Devices listed below are getting DT supported since Linux 4.3: - orion5x: LS-WTGL - kirkwood: LS-WVL/VL - kirkwood: LS-WXL/WSXL Device listed below is converted to DT from traditional way since Linux 4.3: - orion5x: LS-WSGL Signed-off-by: Roger Shimizu --- db/all.db| 37 + debian/changelog | 8 2 files changed, 45 insertions(+) diff --git a/db/all.db b/db/all.db index c4a1b1c..b3a489f 100644 --- a/db/all.db +++ b/db/all.db @@ -68,6 +68,39 @@ Boot-DTB-Path: /boot/dtb Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: yes +Machine: Buffalo Linkstation LS-WTGL +Kernel-Flavors: orion5x +DTB-Id: orion5x-linkstation-lswtgl.dtb +DTB-Append: yes +U-Boot-Kernel-Address: 0x8000 +U-Boot-Initrd-Address: 0x0 +Boot-Kernel-Path: /boot/uImage.buffalo +Boot-Initrd-Path: /boot/initrd.buffalo +Required-Packages: u-boot-tools +Bootloader-Sets-Incorrect-Root: yes + +Machine: Buffalo Linkstation LS-WVL/VL +Kernel-Flavors: kirkwood +DTB-Id: kirkwood-lswvl.dtb +DTB-Append: yes +U-Boot-Kernel-Address: 0x8000 +U-Boot-Initrd-Address: 0x0 +Boot-Kernel-Path: /boot/uImage.buffalo +Boot-Initrd-Path: /boot/initrd.buffalo +Required-Packages: u-boot-tools +Bootloader-Sets-Incorrect-Root: yes + +Machine: Buffalo Linkstation LS-WXL/WSXL +Kernel-Flavors: kirkwood +DTB-Id: kirkwood-lswxl.dtb +DTB-Append: yes +U-Boot-Kernel-Address: 0x8000 +U-Boot-Initrd-Address: 0x0 +Boot-Kernel-Path: /boot/uImage.buffalo +Boot-Initrd-Path: /boot/initrd.buffalo +Required-Packages: u-boot-tools +Bootloader-Sets-Incorrect-Root: yes + Machine: Buffalo Linkstation LS-XHL Kernel-Flavors: kirkwood DTB-Id: kirkwood-lsxhl.dtb @@ -81,7 +114,11 @@ Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: yes Machine: Buffalo Linkstation Mini +Machine: Buffalo Linkstation LS-WSGL Kernel-Flavors: orion5x +DTB-Append-From: 4.3 +DTB-Id: orion5x-lswsgl.dtb +DTB-Append: yes Machine-Id: 1858 U-Boot-Kernel-Address: 0x8000 U-Boot-Initrd-Address: 0x0 diff --git a/debian/changelog b/debian/changelog index 17f813e..f284b9c 100644 --- a/debian/changelog +++ b/debian/changelog @@ -3,6 +3,14 @@ flash-kernel (3.47) UNRELEASED; urgency=medium [Roger Shimizu] * Re-order machine db entries for "Buffalo Linkstation" series - move up entry: Buffalo Linkstation LS-XHL + * Add machine db entries for a few Buffalo Linkstation systems +newly getting DT supported since Linux 4.3: +- orion5x: LS-WTGL +- kirkwood: LS-WVL/VL +- kirkwood: LS-WXL/WSXL + * Update machine db entries for Buffalo Linkstation system converting +to DT since Linux 4.3: +- orion5x: LS-WSGL -- Roger Shimizu Wed, 21 Oct 2015 00:38:28 +0900 -- 2.1.4 >From b26086b875867af2d7f633a52a627c0baa3cb9f4 Mon Sep 17 00:00:00 2001 From: Roger Shimizu Date: Wed, 21 Oct 2015 00:41:26 +0900 Subject: [PATCH 1/2] Re-order machine db entries for "Buffalo Linkstation" series - move up entry: Buffalo Linkstation LS-XHL Signed-off-by: Roger Shimizu --- db/all.db| 24 debian/changelog | 8 2 files changed, 20 insertions(+), 12 deletions(-) diff --git a/db/all.db b/db/all.db index 7053f3e..c4a1b1c 100644 --- a/db/all.db +++ b/db/all.db @@ -68,6 +68,18 @@ Boot-DTB-Path: /boot/dtb Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: yes +Machine: Buffalo Linkstation LS-XHL +Kernel-Flavors: kirkwood +DTB-Id: kirkwood-lsxhl.dtb +DTB-Append: yes +U-Boot-Kernel-Address: 0x8000 +U-Boot-Initrd-Address: 0x0 +Boot-Kernel-Path: /boot/uImage.buffalo +Boot-Initrd-Path: /boot/initrd.buffalo +Boot-DTB-Path: /boot/dtb +Required-Packages: u-boot-tools +Bootloader-Sets-Incorrect-Root: yes + Machine: Buffalo Linkstation Mini Kernel-Flavors: orion5x Machine-Id: 1858 @@ -88,18 +100,6 @@ Boot-Initrd-Path: /boot/initrd.buffalo Required-Packages: u-boot-tools Bootloader-Sets-Incorrect-Root: yes -Machine: Buffalo Linkstation LS-XHL -Kernel-Flavors: kirkwood -DTB-Id: kirkwood-lsxhl.dtb -DTB-Append: yes -U-Boot-Kernel-Address: 0x8000 -U-Boot-Initrd-Address: 0x0 -Boot-Kernel-Path: /boot/uImage.buffalo -Boot-Initrd-Path: /boot/initrd.buffalo -Boot-DTB-Path: /boot/dtb -Required-Packages: u-boot-tools -Bootloader-Sets-Incorrect-Root: yes - Machine: Buffalo/Revogear Kurobox Pro Kernel-Flavors: orion5x Machine-Id: 1509 di
Re: Buffalo Linkstation systems newly supported since Linux 4.3
Dear Martin, Thanks for your feedback! >> Device listed below is converted to DT from traditional way since Linux 4.3: >> - orion5x: LS-WSGL > > Do you have a LS-WSGL for testing? The installer needs an update to > append the DTB (see > debian-installer/build/config/armel/orion5x/network-console.cfg). Unfortunately, I have no LS-WSGL. But I have LS-WTGL, which use the same orion5x kernel image. For kirkwood series (LS-WVL, LS-WXL etc), I have confirmed current 4.3 experimental kernel image can boot well after applying the flash-kernel patch included in this bug report. However, for orion5x series, I tried on LS-WTGL, it fails to boot. I may need add some kernel config to support DT from my previous testing. I'll open another bug regarding to kernel-image on this later. BTW. I'll try to port d-i to kirkwood based Linkstation later. Cheers, Roger
Re: Buffalo Linkstation systems newly supported since Linux 4.3
Status update for armel/orion5x DT support for kernel. flash-kernel: patch accepted, and already in sid now. linux-image-orion5x: patch submitted, bug#803159 However, I found another issue, the kernel image size for orion5x is already exceed the u-boot limit of LS-WTGL, the only orion5x box I have on hand. The kernel I can boot on that device need two patches: - the one submitted to bug#803159 (0001-armel-orion5x-enable-DT-support.patch) - revert file debian/config/armel/config.orion5x in commit b3b60bbdd13 [0] And it's working well on 3.16.7-ckt11-1+deb8u5, but not 4.3~rc5-1~exp1, because of the kernel image size. I'm wondering how to proceed. Some questions: - Is the size of d-i kernel smaller than common linux-image kernel? If so, there's still chance for d-i. - Will d-i support for LS-WSGL get lost due to the kernel size issue, even size of d-i kernel fits well? - bug#803159 is towards common kernel, for d-i kernel, do I need to open another bugreport? Thank you! Cheers, Roger Reference [0]: https://anonscm.debian.org/cgit/kernel/linux.git/commit/debian/config/armel/config.orion5x?id=b3b60bbdd13a9702dbd8e00bd9b35d49b625df31
Re: Buffalo Linkstation systems newly supported since Linux 4.3
>> The kernel I can boot on that device need two patches: >> - the one submitted to bug#803159 >> (0001-armel-orion5x-enable-DT-support.patch) >> - revert file debian/config/armel/config.orion5x in commit b3b60bbdd13 [0] > > How does that help? The kernel image was already too large before that I mentioned the working kernel is 3.16.7-ckt11-1+deb8u5. And I just checked it again, for jessie orion5x kernel, it's still within the limit. -rw-r--r-- 1 root root 1559256 Oct 12 09:27 /boot/vmlinuz-3.16.0-4-orion5x # D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported) >> I'm wondering how to proceed. Some questions: >> - Is the size of d-i kernel smaller than common linux-image kernel? > > No, it is the exact same kernel. Good to know. Thanks for the info, Ben! Cheers, Roger
Re: Buffalo Linkstation systems newly supported since Linux 4.3
> Ben has expressed his frustration with the limited size on some Orion > devices several times in the past. Given how old these devices are > now (plus the fact that we never had a lot of Linkstation users), I > think it doesn't make sense to add support for these devices now (or > in the case of LS-WSGL, to keep it alive). Understand the situation. Yes, the size target is hard to achieve for stretch kernel (4.x). But it's still fine for jessie (3.16). Since I still have two LS-WTGL boxes, so let me explorer a bit more. If any progress, I'll post here. Cheers, Roger
Re: Buffalo Linkstation systems newly supported since Linux 4.3
Dear Martin, Sorry, I forgot to ask one thing. > As Ben pointed out, it's the same kernel. Now I understand it's the same kernel, only need flash-kernel to build the boot image (add ID or DTB, etc). But I have no idea how initrd/initramfs for d-i get built. I guess there're some scripts in some repo. It'd be very helpful if you can provide those info. Thank you! Cheers, Roger
Bug#722735: Installation Report - Issue with config-debian script when installing on ARM Buffalo Linkstation HS-DSGL
On Fri, Dec 11, 2015 at 7:37 AM, Martin Michlmayr wrote: > Hi Tim, > > I just found your installation report from 2013 regarding Buffalo > Linkstation HS-DSGL that unfortunately nobody responded to, Thanks for CC me on Linkstation stuff. Unfortunately, I don't have HS-DSGL, either. I googled and found it's Linkstation Live variant, which is orion5x. > So if I understand you correctly, the config-debian script gives an > error. It checks whether sda1 or md0 are ext2 or ext3 filesystem. > But if I understand correctly, this is no longer called sda1 or md0 on > newer firmware versions but /dev/disk1-1something. So maybe in > addition to sda1 and md0, we should also accept disk1-1. I have a LS-WTGL which orion5x, but it has been installed Debian for years. I don't have original firmware on it any more. So I googled again, and found there're a few device name used, not sure which is old or new: - /dev/disk1_1 [0] - /dev/ls_disk1_1 [1] So Martin, you're going to include all possible device name into config-debian script? If so, I'll try to confirm it on orion5x stock firmware, hopefully within this month. Cheers, Roger [0] http://www.yamasita.jp/linkstation/2007/03/070303_core_dump.html [1] http://www.yamasita.jp/linkstation/0608/060805.html
Bug#810828: flash-kernel: update kernel address for Linkstation LS-WTGL
Package: flash-kernel Version: 3.52~bpo8+1 Severity: important Tags: patch X-Debbugs-Cc: t...@cyrius.com, i...@hellion.org.uk, rogershim...@gmail.com Dear Maintainer, For Linkstation LS-WTGL boots fine with linux-image-4.3, but fails with linux-image-4.4. Here's the fix ported from QNAP TS-109 (Bug #809476), and it's been confirmed to boot well on LS-WTGL. patch 0001 is irreverent to this bug, but a minor fix to flash-kernel package. patch 0002 is to update kernel address for Linkstation LS-WTGL Cheers, Roger From 2d50d50af94e499b046dd0ecf0b1ba0b8e984566 Mon Sep 17 00:00:00 2001 From: Roger Shimizu Date: Wed, 13 Jan 2016 01:14:16 +0900 Subject: [PATCH 1/2] fix the install location for etc/README.dtbs Signed-off-by: Roger Shimizu --- debian/flash-kernel.install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/flash-kernel.install b/debian/flash-kernel.install index 1273b0d..66b5888 100644 --- a/debian/flash-kernel.install +++ b/debian/flash-kernel.install @@ -2,7 +2,7 @@ initramfs-hook/flash-kernel etc/initramfs/post-update.d kernel-hook/zz-flash-kernel etc/kernel/postinst.d kernel-hook/zz-flash-kernel etc/kernel/postrm.d etc/db etc/flash-kernel -etc/README.dtbs etc/flash-kernel/dtbs/README +etc/README.dtbs etc/flash-kernel/dtbs flash-kernelusr/sbin initramfs-tools usr/share db usr/share/flash-kernel -- 2.1.4 From d0ec85cdda4f71ef1e8534d68e6c25e5bff376bf Mon Sep 17 00:00:00 2001 From: Roger Shimizu Date: Wed, 13 Jan 2016 01:45:44 +0900 Subject: [PATCH 2/2] update kernel address for Linkstation LS-WTGL in machine db For Linkstation LS-WTGL boots fine with linux-image-4.3, but fails with linux-image-4.4. Here's the fix ported from QNAP TS-109 (Bug #809476), and it's been confirmed to boot well on LS-WTGL. Signed-off-by: Roger Shimizu --- db/all.db | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/db/all.db b/db/all.db index 8262e14..6343f03 100644 --- a/db/all.db +++ b/db/all.db @@ -72,7 +72,7 @@ Machine: Buffalo Linkstation LS-WTGL Kernel-Flavors: orion5x DTB-Id: orion5x-linkstation-lswtgl.dtb DTB-Append: yes -U-Boot-Kernel-Address: 0x8000 +U-Boot-Kernel-Address: 0x00c08000 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage.buffalo Boot-Initrd-Path: /boot/initrd.buffalo -- 2.1.4
Bug#810828: flash-kernel: update kernel address for Linkstation LS-WTGL
Enclosed is the u-boot environment and dmesg (after applying the patch). LS-WTGL_env.txt.gz Description: GNU Zip compressed data dmesg_LS-WTGL_4.4.0-rc8-orion5x.gz Description: GNU Zip compressed data
Bug#809476: Linux 4.4-rc6 fails to boot on QNAP TS-109
On Wed, Jan 6, 2016 at 9:41 PM, Roger Shimizu wrote: > [Resend previous email to keep ARM experts in CC] > > On Thu, Dec 31, 2015 at 9:09 AM, Martin Michlmayr wrote: >> I tried to boot Debian's 4.4-rc6 kernel on my QNAP TS-109 and it failed >> to boot with: >> [ 19.380002] Unpacking initramfs... >> [ 19.380044] Initramfs unpacking failed: junk in compressed archive > > I see this error message on my Linkstation boxes for long time, but > most of time they just boot fine. > After seeing your report, now I understand the root cause why failing > sometimes. :-) > >> -U-Boot-Kernel-Address: 0x8000 >> +U-Boot-Kernel-Address: 0x00c08000 > > I tried this on local db (/etc/flash-kernel/db) of my Linkstation, but > it failed to boot. > Except above change, did you also changed the address in uboot > command? (like a few lines below) > >>> cp.b 0xff20 0x80 0x3f >>> setenv bootargs console=ttyS0,115200n8 root=/dev/ram rw >>> initrd=0x80,0x3f >>> bootm 0xff00 > >> u-boot loads it like this: >> >> ## Booting image at 0040 ... >>Load Address: 8000 >>Entry Point: 8000 > > I also don't understand where the address "0040" comes from. It's > neither in flash-kernel's db nor in uboot setting. > From my understanding, the kernel image stores in flash, which address > is 0xff00, and it will be copied to "8000" by uboot on boot > time, then kernel will uncompress the image and then boot. Am I missed > something? I asked Paul (in CC) who has been working on arm platform for years. He told me that, as my case, "ext2load" will load the uImage to 0x10 as instructed, then "bootm" will extract the "uImage" to "zImage" format to 0x8000 as mkimage configured, and kernel will boot from 0x8000 with initrd in 0x80. And these two addresses are also fixed in the kernel, which usually specified in "arch/arm/mach-/Makefile.boot". e.g. $ cat arch/arm/mach-orion5x/Makefile.boot zreladdr-y += 0x8000 params_phys-y := 0x0100 initrd_phys-y := 0x0080 The patch for this bug changed kernel start address from 0x8000 to 0xc08000. But kernel's zreladdr-y is still 0x8000, without changing. If kernel really uses this “zreladdr-y”, it may be trouble. If it only for "make uImage" to pass to mkimage when compiling, it will not be any problem. >From the result of "grep" in kernel tree, the latter one seems to be true. Cheers, Roger
Bug#810828: flash-kernel: update kernel address for Linkstation LS-WTGL
On Sat, Jan 23, 2016 at 7:17 AM, Martin Michlmayr wrote: > Your patch sets the kernel load address to 0x00c08000. So u-boot will > still load the kernel to 0x0010 but then (I guess) it's > uncompressed at 0x00c08000. The problem is that 0x00c08000 is only 4 > MB after the start of the ramdisk (0x0080), which doesn't leave a > lot of space for the ramdisk. > > You can change initramfs-tools from MODULES=dep to MODULES=most, > generate and I suspect it wouldn't boot. > > Can you try if something like 0x01a08000 works? > > BTW, I assume we need to change this for all Linkstation devices. I only pathced LS-WTGL because it's the only device I can boot with the change to 0x00c08000. I don't have other orion5x device, so I tested on a few kirkwood based Linkstation but all failed with this kinda of trick. Now it's cleared, as you said, 0x00c08000 is too low that big initrd may over-write to its address. I tried 0x01a08000, yes, my kirkwood devices boot okay, but still have the following error in dmesg: [0.361974] Unpacking initramfs... [0.884688] Initramfs unpacking failed: junk in compressed archive the initrd I used to test is 3.4M initramfs initrd. And it's 7.9M after gunzip. Indeed, I have no clue why initramfs complain there's junk, since kernel already set to higher address as 0x01a08000. Cheers, Roger
Bug#810828: flash-kernel: update kernel address for Linkstation LS-WTGL
On Sun, Jan 24, 2016 at 1:28 AM, Roger Shimizu wrote: > On Sat, Jan 23, 2016 at 7:17 AM, Martin Michlmayr wrote: >> Your patch sets the kernel load address to 0x00c08000. So u-boot will >> still load the kernel to 0x0010 but then (I guess) it's >> uncompressed at 0x00c08000. The problem is that 0x00c08000 is only 4 >> MB after the start of the ramdisk (0x0080), which doesn't leave a >> lot of space for the ramdisk. >> >> You can change initramfs-tools from MODULES=dep to MODULES=most, >> generate and I suspect it wouldn't boot. >> >> Can you try if something like 0x01a08000 works? >> >> BTW, I assume we need to change this for all Linkstation devices. > > I only pathced LS-WTGL because it's the only device I can boot with > the change to 0x00c08000. > I don't have other orion5x device, so I tested on a few kirkwood based > Linkstation but all failed with this kinda of trick. > > Now it's cleared, as you said, 0x00c08000 is too low that big initrd > may over-write to its address. > I tried 0x01a08000, yes, my kirkwood devices boot okay, but still have > the following error in dmesg: > > [0.361974] Unpacking initramfs... > [0.884688] Initramfs unpacking failed: junk in compressed archive > > the initrd I used to test is 3.4M initramfs initrd. > And it's 7.9M after gunzip. > > Indeed, I have no clue why initramfs complain there's junk, since > kernel already set to higher address as 0x01a08000. Now I know (or partly know) why initramfs complain there's junk, it's because there's in a kernel param "initrd=0x00800040,12M". After removing that kernel param, the kernel stops complaining, which proves change kernel address to 0x01a0 is fine. Since the kernel param "initrd=0x00800040,12M" is from stock firmware, and actually does no harm except the "there's junk" kmsg, I decide to leave it alone. So here's the patch to all Linkstation devices. I've confirmed it's working well on various orion5x and kirkwood based Linkstation devices, including LS-GL (device tree based), LS-WTGL, LS-VL and LS-WXL. I'll push this commit to git repo later. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1 From 172a0aec5ab9809945a27c1fc17832cfaa6fd1e7 Mon Sep 17 00:00:00 2001 From: Roger Shimizu Date: Wed, 13 Jan 2016 01:45:44 +0900 Subject: [PATCH] Update kernel address for Buffalo Linkstation devices machine db For Linkstation LS-WTGL boots fine with linux-image-4.3, but fails with linux-image-4.4. Deep research reveals that the initrd/initramfs space, starts from 0x0080, may be overwritten by kernel extraction by default configuration. So the fix is to move the target address of kernel image extraction address from 0x8000 to 0x01a0. Since initrd/initramfs is firstly placed from 0x0080 by u-boot, in this way, 18M space, from 0x0080 to 0x01a0, can be used by initrd/initramfs, which is enough for case like MODULES=most for initramfs-tools. This fix has been confirmed working well on various orion5x and kirkwood based Linkstation devices, including LS-GL (device tree based), LS-WTGL, LS-VL and LS-WXL. Therefore, I applied to all Linkstation devices. Signed-off-by: Roger Shimizu --- db/all.db | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/db/all.db b/db/all.db index 3f1dfcd..6c76653 100644 --- a/db/all.db +++ b/db/all.db @@ -49,7 +49,7 @@ Required-Packages: u-boot-tools Machine: Buffalo Linkstation LiveV3 (LS-CHL) Kernel-Flavors: orion5x marvell Machine-Id: 2913 -U-Boot-Kernel-Address: 0x8000 +U-Boot-Kernel-Address: 0x01a0 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage.buffalo Boot-Initrd-Path: /boot/initrd.buffalo @@ -60,7 +60,7 @@ Machine: Buffalo Linkstation LS-CHLv2 Kernel-Flavors: kirkwood marvell DTB-Id: kirkwood-lschlv2.dtb DTB-Append: yes -U-Boot-Kernel-Address: 0x8000 +U-Boot-Kernel-Address: 0x01a0 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage.buffalo Boot-Initrd-Path: /boot/initrd.buffalo @@ -72,7 +72,7 @@ Machine: Buffalo Linkstation LS-WTGL Kernel-Flavors: orion5x marvell DTB-Id: orion5x-linkstation-lswtgl.dtb DTB-Append: yes -U-Boot-Kernel-Address: 0x8000 +U-Boot-Kernel-Address: 0x01a0 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage.buffalo Boot-Initrd-Path: /boot/initrd.buffalo @@ -83,7 +83,7 @@ Machine: Buffalo Linkstation LS-WVL/VL Kernel-Flavors: kirkwood marvell DTB-Id: kirkwood-lswvl.dtb DTB-Append: yes -U-Boot-Kernel-Address: 0x8000 +U-Boot-Kernel-Address: 0x01a0 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage.buffalo Boot-Initrd-Path: /boot/initrd.buffalo @@ -94,7 +94,7 @@ Machine: Buffalo Linkstation LS-WXL/WSXL Kernel-Flavors: kirkwood marvell DTB-Id: kirkwood
"ts209" d-i image failed to build due to size
Dear Martin, As you may already know, "ts209" d-i image failed to build due to size, since two day ago. It was OK on Feb. 6th [0], but got failed since Feb. 7th [1]. My pushed big commit was on Feb. 9th, so it's me that break that stuff. :-D [0]: https://d-i.debian.org/daily-images/armel/20160206-00:15/build_orion5x_network-console.log [1]: https://d-i.debian.org/daily-images/armel/20160207-00:14/build_orion5x_network-console.log Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#814342: lowmem should not block when in network-console d-i mode
Package: lowmem Severity: normal X-Debbugs-Cc: rogershim...@gmail.com Dear Maintainer, There's a mode calling network-console in d-i, which let user to use SSH to connect to the target device for Debian installation. But if lowmem detects memory is low, it will block d-i and prevent SSH daemon to start, so user has no chance to see the warning by lowmem, and then proceed. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#844549: network-console broken: no screen to be resumed matching sh
On Tue, Nov 22, 2016 at 3:05 AM, Roger Shimizu wrote: > > I'll test the daily image on my Linkstation NAS. I tested the daily image on my armel devices. Both serial way and SSH way works fine. And if connect both serial and SSH (network-console), serial/SSH seems to share the same screen session, which is good and beyond what I expected. It's exceeded what I have imagined. Just one issue for SSH (network-console). Since the SSH session shares the same screen with serial, the screen size is limited to 80x25 (probably, I didn't count the number), which is too small to most recent monitor devices. Does it deserve a new bug report? What do you think of it? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#857808: debian-installer: Garbage on terminal with default TERM setting over serial console
Dear Adrian, On Wed, 15 Mar 2017 12:05:56 +0100 John Paul Adrian Glaubitz wrote: > I suspect that the regressions are related to Roger Shimizu's patch > to add support for GNU screen to debian-installer. I am therefore > adding Roger to the CC list of this bug report. He - or anyone > else - can also get access to a sparc64 porterbox to perform > installation tests. We - the sparc64 porters - are happy to > assist with these efforts. I'm interested how this could happend.. I have once experience only on porterbox to debug FTBFS issue of a pkg, but I don't know it can debug d-i. Could you kindly help on the following? - I guess my porterbox access has been expired. Do I need to apply it again in nm.debian.org? or you can enable my account (rosh) on your sparc64 porterbox? - How to start d-i in porterbox? I'm travelling this week so it'd be appreciated the above question could be answered by next Monday (Mar. 20). Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpUSXU9Rb6wL.pgp Description: PGP signature
Re: can't get the debian-installer code by svn
On Wed, 22 Mar 2017 16:17:08 +0800 (CST) harryyue123 wrote: > I want get a source code of debian-installer,but failed.the error > message is : > > harry@BJ-LD-1229:~/Project/000debian8.7$ svn co > svn://anonscm.debian.org/svn/d-i/trunk d-i Where did you get the URL of SVN repo? Now the repo has been moved to git: https://anonscm.debian.org/git/d-i/debian-installer.git Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgp0VucZ7gtZ4.pgp Description: PGP signature
Re: Last chance for d-i changes in stretch
[ Only keep d-boot@ ML ] On Fri, 26 May 2017 19:04:13 +0200 Cyril Brulebois wrote: > Hi, > > You might have noticed final preparations for d-i Stretch RC 4 are > underways. A new debian-installer upload (or a binNMU) will need to > happen before the first stretch release (aka. r0). If there's anything > you want or would like to include in r0, now is the time to mention it. Thanks for your continous work on d-i! Maybe it's too late for r0, but I'm still want to ask whether it's feasible to include the patch mentioned here: https://bugs.debian.org/839894#30 henrich provided the patch and he verified it worked well in his virtualbox environment. If it's really too late for r0, how about stretch p-u or r1? And how? Thanks for your consideration! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpGTgPGEuj2S.pgp Description: PGP signature
Re: Last chance for d-i changes in stretch
On Tue, May 30, 2017 at 4:27 AM, Samuel Thibault wrote: > That would also match partitions, might that not pose concerns? So maybe the following? > -/dev/[hsv]d[a-z0-9]| > +/dev/[hsv]d[a-z0-9]|/dev/[hsv]d[a-z][a-z]*| -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Last chance for d-i changes in stretch
On Tue, May 30, 2017 at 9:38 AM, Roger Shimizu wrote: > On Tue, May 30, 2017 at 4:27 AM, Samuel Thibault wrote: > >> That would also match partitions, might that not pose concerns? Now I think the following is better: > -/dev/[hsv]d[a-z0-9]| > +/dev/[hsv]d[a-z0-9][a-z]*| And I pushed the fix commit to branch "fix_839894": https://anonscm.debian.org/cgit/d-i/grub-installer.git/commit/?h=fix_839894&id=9927e8c Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Last chance for d-i changes in stretch
On Fri, Jun 2, 2017 at 9:58 PM, Hideki Yamane wrote: > > On Tue, 30 May 2017 21:52:06 +0900 > Roger Shimizu wrote: > > > -/dev/[hsv]d[a-z0-9]| > > > +/dev/[hsv]d[a-z0-9][a-z]*| > > > > And I pushed the fix commit to branch "fix_839894": > > > > https://anonscm.debian.org/cgit/d-i/grub-installer.git/commit/?h=fix_839894&id=9927e8c > > I've tested it with VBox and works well, see attached screenshot. Thanks for your verification! So I pushed the commit to branch master. > KiBi, if you're fine with it, please kindly help to release/upload. Hope it still can catch up with r0. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#814342: lowmem should not block when in network-console d-i mode
Dear Martin, On Thu, Feb 11, 2016 at 5:21 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-02-11 01:19]: >> Package: lowmem >> >> There's a mode calling network-console in d-i, which let user to use >> SSH to connect to the target device for Debian installation. >> But if lowmem detects memory is low, it will block d-i and prevent SSH >> daemon to start, so user has no chance to see the warning by lowmem, >> and then proceed. > > oldsys-preseed generates a preseed file that contains: > > # Just continue if d-i enters lowmem mode > add "$FILE" "lowmem/low" "note" > > So the real question is why this isn't working or why oldsys-preseed > isn't generating that on your device. Thanks for your info! Now it's clear, since in d-i, file build/pkg-lists/netboot/network-console/armel/orion5x.cfg oldsys-preseed # sata and ext2/ext3 modules are needed by oldsys-preseed to read the disk # -> disable due to size problems I think maybe it's necessary to split "orion5x" as: - orion5x with serial console support, which keeps current config, so as kuroboxpro can be supported - orion5x without serial console support, re-enable sata and ext4, but disable jffs2 and micro-evtd What's your idea? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#814342: lowmem should not block when in network-console d-i mode
On Fri, Feb 12, 2016 at 9:38 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-02-11 16:28]: >> Now it's clear, since in d-i, file >> build/pkg-lists/netboot/network-console/armel/orion5x.cfg >> >> oldsys-preseed >> # sata and ext2/ext3 modules are needed by oldsys-preseed to read the disk >> # -> disable due to size problems > > That doesn't explain what you're seeing. If oldsys-preseed cannot > read the disk on Buffalo devices, it should still generate a preseed > file with DHCP and a fallback IP address (as well as the lowmem > override). > > Please debug why (and what) is not working for you. Thanks for your guide! Now I trace to the following file: - https://anonscm.debian.org/cgit/d-i/oldsys-preseed.git/tree/oldsys-preseed It seems I need to write a block for device tree based Linkstation. >> I think maybe it's necessary to split "orion5x" as: >> - orion5x with serial console support, which keeps current config, so >> as kuroboxpro can be supported >> - orion5x without serial console support, re-enable sata and ext4, but >> disable jffs2 and micro-evtd >> >> What's your idea? > > "with serial console support" would be the netboot image. So you're > suggesting that Kurobox Pro should use the netboot image whereas other > Buffalo devices should use network-console. I think network-console is a special variant of netboot. And serial console install works well on network-console image. > I don't know if Kurobox Pro all have a serial console. I used to have > such a device but I cannot remember anything about it. I owned a Kurobox Pro long time ago, but I don't have it anymore. I now it's simply Linkstation Pro (LS-GL) + one additional NAND flash + external SATA interface. For d-i, we can treat Kurobox Pro the same thing as Linkstation Pro. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#814342: lowmem should not block when in network-console d-i mode
Control: reassign -1 oldsys-preseed Control: tags -1 + fixed pending On Fri, Feb 12, 2016 at 4:18 PM, Roger Shimizu wrote: > On Fri, Feb 12, 2016 at 9:38 AM, Martin Michlmayr wrote: >> * Roger Shimizu [2016-02-11 16:28]: >>> Now it's clear, since in d-i, file >>> build/pkg-lists/netboot/network-console/armel/orion5x.cfg >>> >>> oldsys-preseed >>> # sata and ext2/ext3 modules are needed by oldsys-preseed to read the disk >>> # -> disable due to size problems >> >> That doesn't explain what you're seeing. If oldsys-preseed cannot >> read the disk on Buffalo devices, it should still generate a preseed >> file with DHCP and a fallback IP address (as well as the lowmem >> override). >> >> Please debug why (and what) is not working for you. > > Thanks for your guide! > Now I trace to the following file: > - https://anonscm.debian.org/cgit/d-i/oldsys-preseed.git/tree/oldsys-preseed > > It seems I need to write a block for device tree based Linkstation. I pushed a commit that supposed to support all device-tree based Linkstation. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#814710: flash-kernel: script test_functions fails if there's local setting in /etc/flash-kernel/machine
Package: flash-kernel Version: 3.57 Severity: wishlist X-Debbugs-Cc: rogershim...@gmail.com Dear Maintainer, Script "test_functions" will be run during package building (I use git-buildpackage). But if if there's local setting in /etc/flash-kernel/machine, the script fails, log is like the following: = FK_CHECKOUT=. ./test_functions Expected machine to be Marvell SheevaPlug Reference Board but got Buffalo Linkstation LS-VL Expected machine to be Globalscale Technologies Dreamplug but got Buffalo Linkstation LS-VL passed: 19; skipped: 0; failed: 2 failed: test_get_cpuinfo_hardware failed: test_get_dt_hardware debian/rules:35: recipe for target 'override_dh_auto_test' failed ===== Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: "ts209" d-i image failed to build due to size
[remove CC 814...@bugs.debian.org due to my post has nothing to do with gnupg] Dear Martin, On Thu, Feb 11, 2016 at 4:36 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-02-11 00:12]: >> As you may already know, "ts209" d-i image failed to build due to >> size, since two day ago. >> It was OK on Feb. 6th [0], but got failed since Feb. 7th [1]. > > gpgv-udeb is now provided by gnupg2 rather than gnupg 1.4 and this > brought in a number of new dependencies, in particular libgcrypt20 > which is huge. I filed #814027 but I'm not sure how realistic it is > that this change will be reverted. > > Since GnuPG is only used for verification, I wonder if there's a > smaller tool that only does signature verification but I don't know. > > If we find no solution, I'll see if I can provide unofficial images > with the old gpgv-udeb. Thanks for the info! I tried to hack debian-installer, and split orion5x flavour into orion5x and orion5x-qnap. For orion5x-qnap, I removed a few qnap unused stuff in "pkg-lists" folder. I pushed my change to branch "split_orion5x" - https://anonscm.debian.org/cgit/d-i/debian-installer.git/log/?h=split_orion5x Here's comparison of error build log from debian-installer: branch master: File size 4465504 is larger than total, padded size 4194304. branch orion-qnap (after my change): File size 4394588 is larger than total, padded size 4194304. so the qnap d-i image has reduced 70k, and need another 200k reducement. I have no idea whether this kinda change valid. Maybe it's just proof of concept that size can be reduced. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#814710: flash-kernel: script test_functions fails if there's local setting in /etc/flash-kernel/machine
On Mon, Feb 15, 2016 at 10:21 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-02-14 22:59]: >> Script "test_functions" will be run during package building (I use >> git-buildpackage). >> But if if there's local setting in /etc/flash-kernel/machine, the >> script fails, log is like the following: > > Nice catch. I added a fix to git. Confirmed working well on my box (git-buildpackage doesn't complain anymore). Actually I tried to fix, but didn't find a simple way. So I open the ticket. Thanks for the clean fix! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
d-i daily 2/18 is missing for armel only
Dear D-I Maintainer, I cannot find today(2/18)'s armel d-i daily image [0], while other arch is correctly downloadable [1][2]. If there's build error, there should be build log to check, but unfortunately there's no 2/18's folder. So I'm asking what happened. [0] https://d-i.debian.org/daily-images/armel/ [1] https://d-i.debian.org/daily-images/amd64/ [2] https://d-i.debian.org/daily-images/arm64/ Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: d-i daily 2/18 is missing for armel only
On Thu, Feb 18, 2016 at 6:44 PM, Roger Shimizu wrote: > Dear D-I Maintainer, > > I cannot find today(2/18)'s armel d-i daily image [0], while other > arch is correctly downloadable [1][2]. > If there's build error, there should be build log to check, but > unfortunately there's no 2/18's folder. So I'm asking what happened. > > [0] https://d-i.debian.org/daily-images/armel/ > [1] https://d-i.debian.org/daily-images/amd64/ > [2] https://d-i.debian.org/daily-images/arm64/ Check again then found now 2/18 folder for armel is created. Usually it's run after GMT 0:00, so I guess it's build manually. So problem seems get solved. Just curious what went wrong... -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: d-i daily 2/18 is missing for armel only
Dear Cyril, Sorry, just found your email in my gmail's spam folder. So I replied previous email before seeing your email. On Thu, Feb 18, 2016 at 9:05 PM, Cyril Brulebois wrote: > Hi Roger, > > Roger Shimizu (2016-02-18): >> I cannot find today(2/18)'s armel d-i daily image [0], while other >> arch is correctly downloadable [1][2]. >> If there's build error, there should be build log to check, but >> unfortunately there's no 2/18's folder. So I'm asking what happened. > > Looking at /home/d-i/di/logs/di-autobuild_daily-armel-20160218- on > abel (the porterbox currently used for armel d-i daily builds), it > seems due to a transient network error at the beginning of the build, > hich triggered an early abort (and no logs are uploaded in that case). > > I've just started an out-of-cron run. If successful, it should appear > within a few hours (until dillon.debian.org gets files, and publishes > them through a mirror network for d-i.debian.org). Glad to know the reason. Yes, now the armel daily is there. Thank you! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
D-I status on device tree based armel orion5x/kirkwood Buffalo Linkstation
Dear Cryril, Martin, Iwamatsu-san, I'm happy to inform you that I confirmed 2/19 daily d-i network-console images are working fine on device tree based armel orion5x/kirkwood Buffalo Linkstation devices. I tried the following two devices: - Linkstation LS-WTGL (orion5x with 64M memory) - Linkstation LS-WVL (kirkwood with 256M memory) It's worth mention that even the device with 64M memory can still run d-i, though I tried a few times only once can really finish the installation. (For the device with 256M memory, I didn't met much problem.) Another thing I want to mention is that it still need a command line to create RAID1 /boot partition: mdadm --create /dev/md0 --level=1 --raid-devices=2 -e 0 /dev/sda1 missing Because partman-md only can create md device with metadata=1.2, which cannot be recognized by Linkstation's uboot (ARM bootloader) Except two tested ones, other Linkstation devices should be supported includes: - originally supported LS-GL(Pro/Live) / LS-WSGL(Mini) / LS-CHLv2 / LS-XHL - newly added by me: LS-VL / LS-WSXL / LS-WXL I've been working on this for months, since device-tree patch to upstream kernel. I'm happy that finally those orion5x/kirkwood NAS boxes, which already or almost lost support from vendor, can be supported by Debian. Thanks for your guiding and support! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
[RFC] screen/tmux support for network-console
Dear Martin and D-I Maintainer, I have a new idea on d-i/network-console: multi-console support (screen/tmux). For d-i on normal PC, we can simply press alt-F2 to get a console almost anytime during install, but it's not easy for current network-console if there's no serial console. So I'm wondering whether it's possible to add screen/tmux support. But I have a few questions listed below: - do I need to patch screen/tmux first to support udeb, and wait for the udeb to hid unstable? - is screen/tmux's deb is okay for local build of debian-installer image? - I want to keep "network-console" and add a new type such as "network-multiconsole", since there's already size issue on orion5x qnap devices. But how do it? Do I need to fork network-console.git repo? May it's a silly idea. So here's the RFC to hear other voice. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#815569: partman-md: it should be able to choose metadata={0, 1, ddf, imsm} when creating the RAID
Package: partman-md Version: 77 Severity: normal X-Debbugs-Cc: rogershim...@gmail.com Dear Maintainer, I'm porting d-i onto a few Buffalo Linkstation NAS devices recently. Linkstation's u-boot loader loads kernel/initrd from 1st partition of the disks, which only recognize metadata=0 (or so-called 0.90) for RAID-1 case. But as you know currently partman-md can only create metadata=1.2, so I have to type: mdadm --create /dev/md0 --level=1 --raid-devices=2 -e 0 /dev/sda1 /dev/sdb1 to create the /dev/md0 manually. BTW. partman-md can create the rest /dev/md1, /etc/md2, etc, without problem. So I ask you to support specify the metadata style when creating the RAID. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#815570: partman-md: it should be able to setup bitmap when creating the RAID
Package: partman-md Version: 77 Severity: normal X-Debbugs-Cc: rogershim...@gmail.com Dear Maintainer, As bitmap plays an important role in RAID, I recommend partman-md to have a menu to setup internal/external bitmap, and bitmap block size. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
flash-kernel has been blocked from entering testing for long
Dear Ian, Christian, flash-kernel has been blocked from entering testing for long time. The QA page [0] says it's because serious bugs, which I think there's only #813995 on the list. #813995 affects since 3.35+deb8u2, which is in stable [1]. Simply speaking, there's no critical issue for the package in sid. For such case, I suggest you release the blocking manually. Thank you! [0]: https://qa.debian.org/excuses.php?package=flash-kernel [1]: https://tracker.debian.org/pkg/flash-kernel Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: D-I status on device tree based armel orion5x/kirkwood Buffalo Linkstation
On Sat, Feb 20, 2016 at 5:59 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-02-20 00:42]: >> Another thing I want to mention is that it still need a command line >> to create RAID1 /boot partition: >> mdadm --create /dev/md0 --level=1 --raid-devices=2 -e 0 /dev/sda1 missing >> Because partman-md only can create md device with metadata=1.2, which >> cannot be recognized by Linkstation's uboot (ARM bootloader) > > I'm not very familiar with partman-md, but if there's no bug about > this yet, you may want to file one. Thanks for your suggestion! I actually filed 2 tickets: #815569 & #815570 >> I've been working on this for months, since device-tree patch to >> upstream kernel. >> I'm happy that finally those orion5x/kirkwood NAS boxes, which already >> or almost lost support from vendor, can be supported by Debian. >> >> Thanks for your guiding and support! > > Nice work! I'll bring more NAS devices for Debian. At least those device-tree, which is already accepted by subsystem maintainer but waiting for Linus' merging window, is easy to support if I can add it into Debian's kernel. I'll discuss this with Ben. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] screen/tmux support for network-console
Dear Martin, Thanks for your comments! On Sat, Feb 20, 2016 at 5:57 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-02-20 01:00]: >> So I'm wondering whether it's possible to add screen/tmux support. > ... >> May it's a silly idea. So here's the RFC to hear other voice. > > I often would like to have a second console. I think it's actually > more a problem for netboot rather than network-console because you can > simply open a second SSH connection with the latter. Actually, having multiply console is more than shell console, as d-i for PC, there're a few console for log output. I think it's also benefit for embedded world if we can see the log output while installing. And I have no idea what's netboot for. Maybe it's like the old business card CD image? > On the other hand, it's not clear how d-i can be started within > screen/tmux, but maybe you know. I think just let ssh start screen/tmux as shell, then screen/tmux can start normal d-i in the 1st console. I also have no idea where to start to change, just need some time to be familiar with so much projects in d-i. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: flash-kernel has been blocked from entering testing for long
On Tue, Feb 23, 2016 at 1:39 AM, Ian Campbell wrote: > On Tue, 2016-02-23 at 01:30 +0900, Roger Shimizu wrote: >> Dear Ian, Christian, >> >> flash-kernel has been blocked from entering testing for long time. >> The QA page [0] says it's because serious bugs, which I think there's >> only #813995 on the list. >> #813995 affects since 3.35+deb8u2, which is in stable [1]. >> >> Simply speaking, there's no critical issue for the package in sid. >> For such case, I suggest you release the blocking manually. > > This is not within the abilities of a regular maintainer, someone would > need to talk to the release team (I think). Good to know this. But actually you have tagged already, which is what I meant releasing the block. > However I noticed yesterday that the found versions for #813995 had > gotten mixed up when it was assigned back and forth. I fixed the tags > yesterday so hopefully it should soon decide that updating from 3.36 to > 3.38 will not introduce #813995 to testing (since it is already there). I didn't know you already handled this. Sorry for my noise. Thanks for doing so! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] screen/tmux support for network-console
On Wed, Feb 24, 2016 at 4:02 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-02-23 02:04]: >> Actually, having multiply console is more than shell console, as d-i >> for PC, there're a few console for log output. >> I think it's also benefit for embedded world if we can see the log >> output while installing. > > Sure, but with network-console you can easily achieve this by SSH to > d-i, open a shell, and typing "tail -f /var/log/syslog". Good to know this. But I think having screen/tmux still has it's value. >> And I have no idea what's netboot for. Maybe it's like the old >> business card CD image? > > netboot = install via network, do installation via serial console or tty > network-console = based on netboot; install via network, do installation via > SSH For serial console, I don't think screen/tmux can work on that. (screen can hold serial console as session, but not the other way around) For tty, it's already have left-alt-F4 console already, there's no need to having screen/tmux at all. So I plan to work on network-console only. >> > On the other hand, it's not clear how d-i can be started within >> > screen/tmux, but maybe you know. >> >> I think just let ssh start screen/tmux as shell, then screen/tmux can >> start normal d-i in the 1st console. >> I also have no idea where to start to change, just need some time to >> be familiar with so much projects in d-i. > > You could start by making a local udeb of tmux/screen. If I have done the udeb of screen/tmux, how to build into d-i? Currently I use "make reallyclean; make build_kirkwood_network-console" to build d-i image. But it seems using the udeb from apt repo, not local compiling. Another question is how to package udeb? I have a few experience on normal deb packaging, but I have no idea how to do it for udeb. Any way to install / debug udeb package? Sorry, there may be too many questions in this email. Even partly answered reply would be appreciated. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#815786: d-i does not ask for hostname
On Thu, Feb 25, 2016 at 5:12 AM, Martin Michlmayr wrote: > * Peter Nagel [2016-02-24 13:47]: >> The debian installer (within expert mode) does not ask for the (new) >> hostname but just takes the hostname from the flash memory. > > We read the hostname from your existing configuration, but I don't see > any code that actually sets this hostname in d-i (this might be a > bug). I'm learning d-i code these days, so just want to confirm... you mean the code in: http://anonscm.debian.org/cgit/d-i/oldsys-preseed.git/tree/oldsys-preseed Line: 291 HOSTNAME=$(grep "Server Name" $path/sda1/.config/uLinux.conf | sed 's/^.* //') hostname get from there, and d-i won't really set up $HOSTNAME? I guess hostname should be set by the Line 293: unset_matching_var "HOSTNAME" NAS$(echo "$MAC" | sed 's/^..:..:..://' | sed 's/://g') There're several calling to "unset_matching_var" for other devices in that script, so if it's not working, it should be a bug to report. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] screen/tmux support for network-console
Dear Philipp, On Thu, Feb 25, 2016 at 10:12 PM, Philipp Kern wrote: > On 2016-02-19 17:00, Roger Shimizu wrote: >> >> I have a new idea on d-i/network-console: multi-console support >> (screen/tmux). > > > To be honest: This would be incredibly exciting for serial console as well. Thanks for your feedback and favoring my idea! Since you and Martin both say it works for the serial case, I considered again and changed my mind. Yes, serial console like VT100 should be also applied. I joined d-i devel just weeks ago. So I need some time to be familiar with everything. I'll try to make it happen before Stretch. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#815786: d-i does not ask for hostname
On Fri, Feb 26, 2016 at 3:40 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-02-25 18:59]: >> the code in: >> http://anonscm.debian.org/cgit/d-i/oldsys-preseed.git/tree/oldsys-preseed >> Line: 291 >> HOSTNAME=$(grep "Server Name" $path/sda1/.config/uLinux.conf | sed 's/^.* >> //') >> >> hostname get from there, and d-i won't really set up $HOSTNAME? > > We read the hostname and store it as $HOSTNAME but then we do: > > add "$FILE" "netcfg/get_hostname" "string" "debian" > > I guess this should be $HOSTNAME (if set) or "debian". But I'm not > sure that's even worth fixing now. I think it deserves a fix, because RAID set-up also depends on the hostname as default name. see ML thread: https://lists.debian.org/debian-arm/2016/02/msg00062.html Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#815786: d-i does not ask for hostname
On Fri, Feb 26, 2016 at 9:57 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-02-26 09:44]: >> > I guess this should be $HOSTNAME (if set) or "debian". But I'm not >> > sure that's even worth fixing now. >> >> I think it deserves a fix > > It's not broken (see my follow-up). So you mean hostname actually is got from DHCP, so it's not broken here? I tried d-i on my Linkstation with 2 different device, in 2 different network (DHCP server), both of the final hostname are "debian", with RAID name also "debian". >> because RAID set-up also depends on the hostname as default name. >> see ML thread: >> https://lists.debian.org/debian-arm/2016/02/msg00062.html > > I know that. Guess why Peter filed this bug report. ;-) Exactly. I think the problem I mentioned above is the same as his one. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] screen/tmux support for network-console
On Thu, Feb 25, 2016 at 5:41 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-02-25 01:01]: >> If I have done the udeb of screen/tmux, how to build into d-i? >> Currently I use "make reallyclean; make >> build_kirkwood_network-console" to build d-i image. >> But it seems using the udeb from apt repo, not local compiling. > > You can put local udebs in build/localudebs $ ls -l build/localudebs/ total 4 -rw-r--r-- 1 roger roger 0 Feb 15 00:52 Packages -rw-r--r-- 1 roger roger 20 Feb 15 00:52 Packages.gz it seems the folder is a repo that need to update "Packages" file. do you know how to do it? >> Another question is how to package udeb? I have a few experience on >> normal deb packaging, but I have no idea how to do it for udeb. >> Any way to install / debug udeb package? > > I suggest you take a look at other packages that build udebs. I cloned screen's git repo, and made some changes to let it make udeb: https://github.com/rogers0/screen/tree/test_udeb I'll try it when I find way to do with "build/localudebs/" Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#815786: d-i does not ask for hostname
On Tue, Mar 1, 2016 at 2:46 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-03-01 00:25]: >> So you mean hostname actually is got from DHCP, so it's not broken here? >> I tried d-i on my Linkstation with 2 different device, in 2 different >> network (DHCP server), both of the final hostname are "debian", with >> RAID name also "debian". > > Debian installer should take the hostname in that order (later taking > preference): > > - "default" as default > > - Value from DHCP > > - Value from original firmware (if any) > > So if you get "debian", I assume no value comes from DHCP. (And I > assume you no longer have an original firmware config since you're > doing new Debian installations to the same disk.) > > Peter confirmed the installer got the hostname from DHCP. Are you > saying this is broken, or does your DHCP not supply a hostname? > > I'm not sure what you're trying to say. hostname from DHCP may work, but not every DHCP server provides one. Yes, I did new installation, and got "debian" as hostname. That's the same problem which Peter requested, ask for the hostname in d-i/network-console. >From implementation side, as you explained before, network-console requires network set-up in early stage, so it may be hard to set up hostname a second time. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] screen/tmux support for network-console
On Tue, Mar 1, 2016 at 2:41 AM, Martin Michlmayr wrote: >> > You can put local udebs in build/localudebs > > Just copy the .udeb into the directory. daily-build will update it. Thanks for your guidance! I put screen-udeb to build/localudebs, with a few screen's dependency library, which is currently .deb pull from regular apt repo. Yes, network-console target build well (qnap failed due to size problem), and boot well on my linkstation. After that, I tried to find how to hook "screen" into d-i/ssh session. Now I know, the project is rootskel [0], /etc/passwd shows the shell is "/bin/network-console", so it's the entry point when ssh shell is invoked. Then "/bin/network-console" will call the following scripts: /sbin/debian-installer /bin/network-console-menu /lib/debian-installer.d/S20speakup /lib/debian-installer.d/S30term /lib/debian-installer.d/S35framebuffer-linux /lib/debian-installer.d/S40term-linux /lib/debian-installer.d/S60frontend /lib/debian-installer.d/S65theme /lib/debian-installer.d/S69keep-translations /lib/debian-installer.d/S70menu /lib/debian-installer/menu I changed script /bin/network-console [1], to let it call "screen /bin/sh" rather than "/sbin/debian-installer /bin/network-console-menu". Put the modified network-console udeb into build/localudeb/ folder and build d-i image again. In this way “ssh installer@” end up a shell within screen. I confirm the screen works well, I can easily create another shell by "Ctrl-a Ctrl-c". So the screen is basically working. But calling the original "/sbin/debian-installer /bin/network-console-menu" command fails, and show the error message: *** Error in `debconf': munmap_chunk(): invalid pointer: 0x01146cac *** Aborted I traced, and found the issue occurred in the final line of script "/lib/debian-installer/menu": exec debconf -o d-i $MENU I guess debconf just crashed. Of course, it only crashes in screen shell. In normal shell it runs fine. So, how to solve it? Currently I have no clue yet. Except for the crash in debconf, I have other a few questions: - all libraries screen-udeb depends on need to be udeb? If I were DD, there'll be some NMU. But I'm not, it seems I need to open plenty of tickets to submit patches and RFS, etc.. - Currently I'm trying on Linkstation boxes, so need to build / copy image to HDD / move HDD to Linkstation, etc. too overhead, so I'm wondering whether there's quick way to test the network-console image. Thank you! [0] https://anonscm.debian.org/cgit/d-i/rootskel.git [1] https://anonscm.debian.org/cgit/d-i/network-console.git Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#816523: debian-installer: make fails if there's "APT::Default-Release" setting in system's apt.conf
Package: src:debian-installer Version: 20160112 Severity: normal X-Debbugs-Cc: rogershim...@gmail.com Dear Maintainer, build command "fakeroot make build_netboot" fails on my amd64 PC with the log: (build on other platform such as armel also has similar issue) E: The value 'jessie' is invalid for APT::Default-Release as such a release is not available in the sources Makefile:635: recipe for target 'stamps/get_udebs-netboot-stamp' failed make[2]: *** [stamps/get_udebs-netboot-stamp] Error 100 Makefile:285: recipe for target '_build' failed make[1]: *** [_build] Error 2 Makefile:279: recipe for target 'build_netboot' failed make: *** [build_netboot] Error 2 my /etc/apt/apt.conf has the following setting: APT::Default-Release "jessie"; when I comment out the setting above, the build can be done without problem. Although usually we build in unstable, I guess it's better to improve this in some way. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#816600: postinst: IPv6 address is not displayed in 'Start SSH' invitation
On Thu, Mar 3, 2016 at 8:12 PM, Hendrik Brueckner wrote: > Package: network-console > Version: 1.53 > Severity: normal > Tags: d-i patch > > Dear Maintainer, > > in IPv6-only environments, the "Start SSH" invitation does not include > the IPv6 address to log in to the installer system. Below is a patch > that extends the postinst script to detect an IPv6 address if no IPv4 > address could be found. Thanks for your patch! It's even better if you can include kfreebsd/hurd support. I guess you have this kinda test environment, which there's only IPv6 but no IPv4. So you just need to run the d-i in very early stage and find how to get IPv6 address, without really install/overwrite your system. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] screen/tmux support for network-console
On Thu, Mar 3, 2016 at 8:25 PM, Philip Hands wrote:
>
> It seems possible that it's upset by the TERM that screen is setting, or
> perhaps something related like COLUMNS. You could perhaps try setting
> that by hand to set the same TERM in screen as is set in the normal
> shell, just to see if that fixes it.
Thanks for your feedback!
I use "set" command to dump environment variables.
Here's the result. Yes, they're different, but I don't see any clue
would cause the crash.
For normal shell:
HOME='/'
IFS='
'
LOGNAME='installer'
MAIL='/var/mail/installer'
OPTIND='1'
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
PPID='1259'
PS1='\w \$ '
PS2='> '
PS4='+ '
PWD='/'
SHELL='/bin/network-console'
SSH_CLIENT=' 35805 22'
SSH_CONNECTION=' 35805 22'
SSH_TTY='/dev/pts/0'
TERM='linux'
TERM_TYPE='network'
USER='installer'
For shell in screen:
HOME='/'
IFS='
'
LOGNAME='installer'
MAIL='/var/mail/installer'
OPTIND='1'
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
PPID='1249'
PS1='\w \$ '
PS2='> '
PS4='+ '
PWD='/'
SHELL='/bin/network-console'
SSH_CLIENT=' 35818 22'
SSH_CONNECTION=' 35818 22'
SSH_TTY='/dev/pts/0'
STY='1249.pts-0.debian'
TERM='screen.linux'
TERMCAP='SC|screen.linux|VT 100/ANSI X3.64 virtual terminal:\
:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
:li#43:co#167:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\
:se=\E[23m:mb=\E[5m:md=\E[1m:mh=\E[2m:mr=\E[7m:\
:me=\E[m:ms:\
:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\
:vb=\Eg:as=\E(0:ae=\E(B:\
:ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\
:Km=\E[M:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\
:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:\
:k;=\E[21~:F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:\
:F5=\E[28~:F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:\
:FA=\E[34~:kb=:K2=\E[G:kB=\E[Z:kh=\E[1~:@1=\E[1~:\
:kH=\E[4~:@7=\E[4~:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:\
:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:'
TERM_TYPE='network'
USER='installer'
WINDOW='0'
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1
Re: [RFC] screen/tmux support for network-console
On Sun, Mar 6, 2016 at 5:15 AM, Philip Hands wrote: > Roger Shimizu writes: > >> On Thu, Mar 3, 2016 at 8:25 PM, Philip Hands wrote: >> >> I use "set" command to dump environment variables. >> Here's the result. Yes, they're different, but I don't see any clue >> would cause the crash. > > What I was suggesting was that you try running something like: > > unset TERMCAP > TERM='linux' > export TERM > /sbin/debian-installer /bin/network-console-menu > > to see if that allows it to run without crashing. I confirm the crash get resolved after "unset TERMCAP". It seems keep TERM=screen.linux is fine. Thanks so much for this point! > It might well look wrong, with broken line-drawing etc. but if it runs > without crashing then at least that points us at the cause of the > problem. Yes, UI/cursor-hightlight is bit strange. But it at least works. I'll try to make libraries, introduced by screen, udeb support first, and then fix the UI issue. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: Archive changes
On Mon, Mar 21, 2016 at 12:05 AM, Cyril Brulebois wrote: > Colin Watson (2016-03-16): >> On Wed, Mar 16, 2016 at 12:54:03AM +0100, Cyril Brulebois wrote: >> > Pretty sure this breaks (will break, when the change is propagated outside >> > experimental) d-i as it stands, due to the check on all 3 checksums in >> > net-retriever. >> >> Looking at the code, I don't think that's true. It skips checksums that >> are missing from Release, and it stops after the first checksum that it >> successfully finds. Unless I'm looking at the wrong bit of >> net-retriever? > > It's entirely possible I was thinking of an earlier version/approach, > different from what got implemented in net-retriever finally after the > last archive-side change. Apologies for any induced headscratching. I made the change for net-retriever, and pushed to branch "sha256_only" [0]. Could you help to review the code, please? Thank you! [0] https://anonscm.debian.org/cgit/d-i/net-retriever.git/commit/?h=sha256_only Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: Archive changes
On Tue, Mar 22, 2016 at 7:12 AM, Karsten Merker wrote: > > I have just tried a test install with today's armhf daily netboot > images, and net-retriever fails: > > Jan 1 02:56:42 net-retriever: error: > main/debian-installer/binary-armhf/Packages.xz not found in > /tmp/net-retriever-1160-Release (for SHA1 checksum). > Jan 1 02:56:44 anna[1156]: WARNING **: bad d-i Packages file I also confirmed this issue occurs on armel/marvell device. On Tue, Mar 22, 2016 at 10:34 PM, Roger Shimizu wrote: > > I made the change for net-retriever, and pushed to branch "sha256_only" [0]. > Could you help to review the code, please? Thank you! > > [0] > https://anonscm.debian.org/cgit/d-i/net-retriever.git/commit/?h=sha256_only I make build a deb package locally, put it into debian-installer's localudebs/ folder, and build a armel/kirkwood network-console target, by "make build_kirkwood_network-console". I confirmed the result image can be install successfully on my armel/marvell device, without the issue mentioned by Karsten. So the d-i issue should be resolved. I'll push this change to master branch later. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: Archive changes
Dear Christian, Cyril, On Wed, Mar 23, 2016 at 6:57 PM, Roger Shimizu wrote: > On Tue, Mar 22, 2016 at 7:12 AM, Karsten Merker wrote: >> >> I have just tried a test install with today's armhf daily netboot >> images, and net-retriever fails: >> >> Jan 1 02:56:42 net-retriever: error: >> main/debian-installer/binary-armhf/Packages.xz not found in >> /tmp/net-retriever-1160-Release (for SHA1 checksum). >> Jan 1 02:56:44 anna[1156]: WARNING **: bad d-i Packages file > > I make build a deb package locally, put it into debian-installer's > localudebs/ folder, and build a armel/kirkwood network-console target, > by "make build_kirkwood_network-console". > > I confirmed the result image can be install successfully on my > armel/marvell device, without the issue mentioned by Karsten. > So the d-i issue should be resolved. Could you help to make a release for d-i repo: net-retriever.git? I confirm it fixes the runtime issue of d-i. And the d-i daily is broken anyway, so my fix won't make things worse. Hope your early release can catch up tomorrow's d-i daily build. Thank you! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: Archive changes
On Thu, Mar 24, 2016 at 5:50 PM, Christian PERRIER wrote: > Quoting Roger Shimizu (rogershim...@gmail.com): >> Could you help to make a release for d-i repo: net-retriever.git? >> I confirm it fixes the runtime issue of d-i. >> And the d-i daily is broken anyway, so my fix won't make things worse. >> Hope your early release can catch up tomorrow's d-i daily build. > > Thanks for investigating (and hopefully fixing) this. I just upload > net-retriever with your changes. Appreciated your help! So I can test tomorrow's d-i daily, again. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: Archive changes
On Thu, Mar 24, 2016 at 10:29 PM, Roger Shimizu wrote: > On Thu, Mar 24, 2016 at 5:50 PM, Christian PERRIER wrote: >> Thanks for investigating (and hopefully fixing) this. I just upload >> net-retriever with your changes. > > Appreciated your help! > So I can test tomorrow's d-i daily, again. I confirm today's d-i daily is able to proceed the install, for armel/marvell and amd64 platform. > Karsten, If it's in your convenient, could you help to test on your armhf device again? Thank you! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] screen/tmux support for network-console
On Sun, Mar 6, 2016 at 9:29 PM, Roger Shimizu wrote: > Yes, UI/cursor-hightlight is bit strange. But it at least works. > I'll try to make libraries, introduced by screen, udeb support first, > and then fix the UI issue. Some progress updates for this RFC. I have made a few libraries udeb supported, and submitted patches by bug report [0][1][2]. There may need some time before those patches would be merged, and package get released. My question is, can I use local udeb library to build my udeb version of screen? and how? I find udeb related documentation is quite limited, so I ask the lists. Thank you and look forward to your reply! [0] https://bugs.debian.org/819358 [1] https://bugs.debian.org/819359 [2] https://bugs.debian.org/819397 Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
flash-kernel 3.61 release commit
Dear Christian, Thanks for release flash-kernel 3.61 for me! However, I find you maybe forget to check-in your release commit to alioth. That prevent me from making new commit after 3.61. Please kindly help. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] screen/tmux support for network-console
Dear Sven, Thanks for your guidance these days! On Thu, Mar 31, 2016 at 1:52 AM, Sven Joachim wrote: > On 2016-03-30 09:39 +0900, Roger Shimizu wrote: >> There may need some time before those patches would be merged, and >> package get released. >> My question is, can I use local udeb library to build my udeb version >> of screen? and how? > > Make sure to have udeb entries in the shlibs files of your locally built > libraries. See the --add-udeb option of dh_makeshlibs(1). Actually in my previous question was that my local build of screen-udeb still depends on libtinfo5, instead of libtinfo5-udeb. How to specify this dependency by force? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] screen/tmux support for network-console
On Sun, Apr 3, 2016 at 12:06 AM, Sven Joachim wrote: > On 2016-04-02 21:47 +0900, Roger Shimizu wrote: > If you added the "--add-udeb" option in ncurses' debian/rules, all it > takes is to actually install your locally built libncursesw5-dev along > all its dependencies (most importantly, the new libtinfo5 package and its > updated shlibs file). Yes, installing the locally built libncursesw5-dev, libtinfo-dev and libtinfo5 made the trick. screen-udeb now: Depends: libc6-udeb (>= 2.22), libtinfo5-udeb (>= 6) Thank you! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Merge orion5x/kirkwood to flavour marvell and marvell-qnap
Dear Martin, As you know I'm preparing GNU/screen support for d-i. To be specific, I'm going to add screen-udeb and it's dependency libtinfo5-udeb into d-i's initrd, which will cost about 350kb. In this way, it will exceed the size limit of a few qnap devices. Maybe there's another better way, however I managed to resolve the size issue by: - merge orion5x and kirkwood into new flavour marvell, except for 2 qnap devices - create a pseudo flavour marvell-tiny, which includes 2 qnap devices which initrd need to be <= 4MB - adjust pkg-lists/netboot/network-console/armel/* I already made these changes in branch "screen-udeb" [0] for open review. In the future, when screen-udeb [1] and libtinfo5-udeb [2] hit sid, I can easily add to d-i by: - add "screen-udeb" to pkg-lists/network-console - add "screen-udeb" to pkg-lists/netboot/network-console/armel/marvell-tiny.cfg, to keep the size safe Hope you can accept these changes this time, because you had some concern last time [3]. [0] https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=screen-udeb [1] https://bugs.debian.org/819988 [2] https://bugs.debian.org/819397 [3] https://lists.debian.org/debian-boot/2016/02/msg00438.html Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap
Dear Martin, Thanks for your feedback! On Mon, Apr 11, 2016 at 8:43 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-04-06 01:29]: >> Hope you can accept these changes this time, because you had some >> concern last time [3]. > > Unfortunately I don't have time to review the changes right now. I'm > happy with the creation of orion5x-tiny (or orion5x-qnap) if that > helps you. > > However, I'm not sure about merging orion5x and kirkwood into marvell. > Does that actually gain us anything? I see several downsides (the > most obvious one is that it would break the installer links; others > downsides, which are easier to fix, are that several other udebs would > need to be updated). Do you see any advantages (apart from using the > same name as the kernel)? I was about to write a list on pros and cons, but I only find pros, with some reasons/explanation. - Main purpose is to get ready for screen support, which surely cannot fit into qnap's image. By creating marvell and marvell-tiny, we can easily and safely add screen-udeb to marvell target and keep it from marvell-tiny target. - If creating orion5x-tiny or orion5x-qnap, the result is almost the same, and download links need to be updated, too. - For "some udebs need to update" part, I guess you mean the device list in libdebian-installer.git [4]. From what I tested, It works well with my previous patch without touching that part of code. Maybe there's some other issues/cases I didn't meet. [4] https://anonscm.debian.org/cgit/d-i/libdebian-installer.git/plain/src/system/subarch-arm-linux.c - I'm going to add new target "netboot-screen" and "netboot/network-screen" in addition to current target "netboot" and "netboot/network-console", because I think the verification of screen support takes months, if not years, on different platform such as mips/s390x/sparc/...etc. I don't want to suddenly add screen-udeb and break a lot arch/platform. During the "transition" period, with new target "netboot-screen" and "netboot/network-screen", the download links have to be appended/changed anyway. After the verification period, if all platform confirms to work well, we can choose to A) rename new targets to old nearest ones; or B) remove old targets and keep only the new ones. The previous one can keep download links, though. - By updating the download links, YES, the manual have to be updated. Let's face it since screen is introduced in, and manuals have to be changed a lot anyway. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
How to build debian-installer under amd64 (was: [RFC] screen/tmux support for network-console)
Dear boot list, I was building network-console d-i image under armel without problem, however now I meet problem under amd64. Here's my command to trigger the build on amd64: $ make reallyclean $ fakeroot make build_netboot Then after a while there's some warning/error: Selecting previously unselected package acpi-modules-4.4.0-1-amd64-di. (Reading database ... 0 files and directories currently installed.) Preparing to unpack .../acpi-modules-4.4.0-1-amd64-di.udeb ... Unpacking acpi-modules-4.4.0-1-amd64-di (4.4.6-1) ... debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. su: must be run from a terminal dpkg: error: error executing hook 'if [ -x /usr/share/debian-security-support/check-support-status.hook ] ; then /usr/share/debian-security-support/check-support-status.hook ; fi', exit code 256 Makefile:307: recipe for target 'stamps/tree-unpack-netboot-stamp' failed make[2]: *** [stamps/tree-unpack-netboot-stamp] Error 2 Makefile:285: recipe for target '_build' failed make[1]: *** [_build] Error 2 Makefile:279: recipe for target 'build_netboot' failed make: *** [build_netboot] Error 2 I also checked the daily build log [0], but without much clue. Could anyone kindly help on this? Thank you! [0] https://d-i.debian.org/daily-images/amd64/daily/build_netboot.log Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: Use newer debian installer with old distro
Dear Alan, If you're going to install old release, you can try the so-called "unofficial/backports" d-i images, created by kmuto: - http://kmuto.jp/debian/d-i/ - http://cdimage.debian.org/cdimage/unofficial/backports/ Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: joining the team
On Sun, Apr 24, 2016 at 6:35 PM, Ben Hutchings wrote: > On Sat, 2016-04-23 at 22:55 -0400, Nicholas D Steeves wrote: >> On 23 April 2016 at 07:28, Philipp Kern wrote: > [...] >> > I don't think there needs to be such a scary warnings on the kernel >> > version stretch will ship with. >> What version is this likely to be? 4.4.x? 4.6.x? From a >> btrfs-perspective, I hope it's an LTS. > [...] > > 4.10 FYI. Announcement: https://lists.debian.org/debian-release/2016/02/msg00626.html Discussion: https://lists.debian.org/debian-kernel/2016/02/threads.html#00019 -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap
[Add a few people ever expressed interest in GNU/screen for d-i work] On Tue, Apr 12, 2016 at 7:50 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-04-12 00:48]: >> I was about to write a list on pros and cons, but I only find pros, >> with some reasons/explanation. >> >> - Main purpose is to get ready for screen support, which surely cannot >> fit into qnap's image. > > Sorry for being unclear: I have no objections to introducing the -qnap > or -tiny image. I can see why this makes sense. > > But you also merge the orion5x and kirkwood images into marvell images > and I see a number of downsides with that (and no obvious advantages). > > Can you leave orion5x and kirkwood alone and introduce an > orion5x-qnap, without converting everything to marvell, or do you see > any advantages of combining orion5x and kirkwood into marvell? (If > there are advantages, please let me know.) Thanks for your feedback! I have a new idea which don't need to touch current orion5x/kirkwood anymore. It introduces two new targets: - netboot-screen, which add screen-udeb to previous netboot target - network-screen, which add screen-udeb to previous network-console target - previous netboot and network-console target is kept as it is So qnap images are only removed from armel/orion5x/network-screen.cfg, due to size issue. But it still exists in armel/orion5x/network-console.cfg. I have push the change to branch "netboot-screen" [5]. I don't have experience other than i386/amd64/armel, so for other ARCHs, I need other's help review and test. I plan to - collect feedback of code review before screen-udeb [1] and its dependency [2] get released. Both of the package are tagged as "pending", so I expect them to be released within 2-4 weeks. - modify the change [5] based on review feedback, and push it to master so we can check daily builds are fine for all ARCHs - ask users of all ARCHs related to check whether the GNU/screen is working well under d-i environment. Maybe need to add a wiki to track things efficiently. What do you think of my plan? Any suggestion is appreciated. Thank you! [1] https://bugs.debian.org/819988 [2] https://bugs.debian.org/819397 [5] https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=netboot-screen&id=302f5f Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
[RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
[Resend: change subject line to meet with current topic] [Add a few people ever expressed interest in GNU/screen for d-i work] On Tue, Apr 12, 2016 at 7:50 AM, Martin Michlmayr wrote: > * Roger Shimizu [2016-04-12 00:48]: >> I was about to write a list on pros and cons, but I only find pros, >> with some reasons/explanation. >> >> - Main purpose is to get ready for screen support, which surely cannot >> fit into qnap's image. > > Sorry for being unclear: I have no objections to introducing the -qnap > or -tiny image. I can see why this makes sense. > > But you also merge the orion5x and kirkwood images into marvell images > and I see a number of downsides with that (and no obvious advantages). > > Can you leave orion5x and kirkwood alone and introduce an > orion5x-qnap, without converting everything to marvell, or do you see > any advantages of combining orion5x and kirkwood into marvell? (If > there are advantages, please let me know.) Thanks for your feedback! I have a new idea which don't need to touch current orion5x/kirkwood anymore. It introduces two new targets: - netboot-screen, which add screen-udeb to previous netboot target - network-screen, which add screen-udeb to previous network-console target - previous netboot and network-console target is kept as it is So qnap images are only removed from armel/orion5x/network-screen.cfg, due to size issue. But it still exists in armel/orion5x/network-console.cfg. I have push the change to branch "netboot-screen" [5]. I don't have experience other than i386/amd64/armel, so for other ARCHs, I need other's help review and test. I plan to - collect feedback of code review before screen-udeb [1] and its dependency [2] get released. Both of the package are tagged as "pending", so I expect them to be released within 2-4 weeks. - modify the change [5] based on review feedback, and push it to master so we can check daily builds are fine for all ARCHs - ask users of all ARCHs related to check whether the GNU/screen is working well under d-i environment. Maybe need to add a wiki to track things efficiently. What do you think of my plan? Any suggestion is appreciated. Thank you! [1] https://bugs.debian.org/819988 [2] https://bugs.debian.org/819397 [5] https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=netboot-screen&id=302f5f Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#822941: debian-installer: cannot boot installed on VirtualBox with EFI-enabled
Dear Yamane-san, Thanks for your report! On Fri, Apr 29, 2016 at 5:33 PM, Hideki Yamane wrote: > Package: debian-installer > Severity: important > > Dear Maintainer, > > I found user notes Debian on VBox with EFI enabled environment cannot > boot, see http://qiita.com/zakuro9715/items/45e82473ce39914e04ed (in > Japanese) > > I've confirmed it with d-i9 alpha5. > And, it doesn't happen with Fedora 24 alpha and Ubuntu 16.04. > > > Step to reproduce: > > 1. setup Virtualbox VM with EFI enabled > 2. install Debian > 3. after installation, turn of VM > 4. turn on VM again > 5. not bootable, startup EFI shell It's very like bug#821341 [0] Please double confirm whether you use GPT partition. Thank you! [0] https://bugs.debian.org/821341 Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
Dear Rick, Thanks for your interest in GNU/screen support for D-I activity! On Fri, Apr 29, 2016 at 8:17 PM, Rick Thomas wrote: > > On Apr 24, 2016, at 9:00 AM, Roger Shimizu wrote: > >> - ask users of all ARCHs related to check whether the GNU/screen is >> working well under d-i environment. Maybe need to add a wiki to track >> things efficiently. >> >> What do you think of my plan? >> Any suggestion is appreciated. Thank you! > > I’m willing to test on a few architectures: Macintosh powerpc-32bit and > powerpc-64bit, Cubox-i (armhf), Sheevaplug (armel), OpenRC (armel). > > If you want me to test any of those, I’ll need some info: > > 1) What is this change supposed to accomplish? Do you have a canonical > use-case I can attempt to model? > 2) What kinds of test do you want me to perform? And what results are you > expecting? Actually, it's in "call for review" status, instead of "call for testing", because there's no built images ready yet. Of course you can build everything yourself, but it may take 1-2 hours for one ARCH, which I think it's too long. I called for review because I want to confirm that those changes are necessary. For example, I know for it's necessary to have GNU/screen support for armel/armhf/arm64 platform; howover, for i386/amd64 PC, it usually have CRT/LCD and physical keyboard attached, so it's easily to switch console by Alt-F1 ~ F4 during debian installing.So for i386/amd64 netboot targets, GNU/screen support is considered unnecessary. I want to know this kind of situation for other ARCHs. You mentioned Macintosh powerpc -32/-64, I think it's the same situation like i386/amd64 from point of view of GNU/screen support. They're unlikely needed. For other arm devices you have, I guess it's necessary. And I'll inform you when the testing images are ready, with instructions. :-D Thank you! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: "No kernel modules were found" during sid installation attempt (amd64)
On Fri, Apr 29, 2016 at 11:30 PM, Renato Bispo wrote: > Hello, > > While trying to install Debian Unstable from a USB stick with the mini.iso > from > debian/dists/unstable/main/installer-amd64/current/images/netboot/mini.iso, > as indicated by the InstallFAQ, the installer gives the following message: > > No kernel modules were found. This probably is due to a mismatch between the > kernel used by this version of the installer and the kernel version > available in the archive. > > I've searched for this problem and found a similar situation (it's from 2014 > and related to the Testing version at that time): > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749991. > > Running dmesg with the installer started, I see Linux version 4.3.0-1-amd64. > However, looking at the Packages list from > debian/dists/unstable/main/debian-installer/binary-amd64/Packages.gz, the > kernel related packages says Kernel-Version: 4.5.0-1-amd64. > > This is my first interaction with the Debian community, so I wasn't sure if > I should report a bug on this and decided to contact you through this > mailing list. d-i alpha was built on Jan, which latest kernel at that time was 4.3 so you use it to install stretch (by default, except you choose advanced), and currently latest kernel is 4.5 I suggest you to try d-i daily: https://d-i.debian.org/daily-images/ -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: unusability issues
Dear Christoph, On Mon, May 2, 2016 at 7:02 AM, Christoph Trunk wrote: > Hi there, > > I have just put Debian (unexpectedly) on my list of unusable, awkward and/or > unmanageable Linux distributions. > > The short version: I cannot even start using Debian, you keep me from > trying. > > The long version: Your live-CDs and live-CDs seem to regularly request a > username and a password. This is something I have never encountered with > other Linux distributions. If you meet something unusual on live CD, I suggest you read live's wiki [0] and email to live's list [1]. [0] https://wiki.debian.org/DebianLive [1] debian-l...@lists.debian.org Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
Dear Ben, Axel, Philipp, Thanks so much for your comments! On Sat, Apr 30, 2016 at 3:28 AM, Ben Hutchings wrote: > For a rack-mounted server, it is usually possible to attach a > (switched) keyboard and monitor, but there is contention for those > resources and machine rooms are not comfortable places for humans. > IP-KVMs are an option but often awkward to use and may rely on plain- > text authentication, Java applets and other insecure technologies. So > an ssh server and screen could be very useful on PCs too. Glad to know that my software solution can replace some hardware (IP-KVM). However, there's even no network-console (SSH) target for i386/amd64 yet [6]. So this use case, together with screen support, would be added from stretch. I'll skip network-console, and only add a "network-screen" target for i386/amd64. [6] https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/i386 On Sun, May 1, 2016 at 12:12 AM, Axel Beckert wrote: > I disagree that screen support for i386 in unnecessary. There are > rather popular x86 boards which only have a serial console and no VGA, > e.g.: > > http://www.pcengines.ch/alix3d2.htm (actually all but two models on > http://www.pcengines.ch/alix.htm) > http://www.pcengines.ch/apu.htm > http://www.pcengines.ch/apu2b2.htm > > So I think adding screen support to D-I on at least i386, too, would > add some value. Thanks for those links for products! Easy for me to understand with spec tables and pictures. So for those boards with serial ports, Debian can be installed by "netboot" image, which is called "netboot-screen" image after the screen support. (Of course network-screen image also can be used by SSH connection) On Mon, May 2, 2016 at 2:22 AM, Philipp Kern wrote: > Also servers with IPMI that only have a virtual serial port. (Yes, there > might be console redirection, but that doesn't always work or might > require an additional license.) I think screen support is worthwhile > everywhere. Or at least not at all detrimental. I'd, however, put an > emphasis on turning it on when the terminal is a serial or remote > console. Although it might not matter too much to have it always on… Good to know my solution can be used to save proprietary software license! I'm not sure about IPMI, but I guess either serial way (netboot-screen) or SSH way (network-screen) should be suitable for that use case. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Sat, Apr 30, 2016 at 10:02 AM, Rick Thomas wrote: > When I’m installing Debian on one of the serial-console-only boxes, such as > the SheevaPlug or OpenRD, I usually use the “network console” option that > allows me to use ssh to login and run the Debian installer from the comfort > of my office chair — away from the cold noisy machine room! If I need to see > the logs or test some parameters, I can always ssh again and get another > shell window. Of course, I still have to be there at the start-up, to push > the “reset” button and use the serial console to handle the initial > bootstrap/installation questions before the ssh server becomes available, but > that’s only for a few minutes. > > How does your proposed change alter that? As Martin pointed before (on my original RFC post), screen support seems not as important for network-console (SSH) target, compared to netboot (serial console) target. But here's some improvement by introducing screen to network-console: - you only need to have one SSH session to the device you run D-I, and you can have multiple task in one physical window: 1. run d-i; 2. have command line; 3. check install log - if your SSH connection is lost, by any reason, you can reconnect SSH, and screen will resume the session for you. Are you convinced? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: DebConf session(s)
On Tue, May 3, 2016 at 11:32 PM, Steve McIntyre wrote: > Hey folks. > > So, who's going to be in CapeTown? Should we propose some sessions for > d-i discussion/work? I'm going to attend. If it's possible, I'd like to join someone's talk on d-i, and introduce my work on GNU/screen support and maybe it's future. GNU/screen is already adopted by many users for years, so it's not rocket science, so it will just have 4-5 slides and 5 minutes is enough. This is my first visit to DebConf. Any suggestion would be appreciated. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
armel/armhf d-i daily fails for days?
Dear Cyril, Christian, It seems armel/armhf d-i daily fails for days [0][1][2]. Because there's no log for it, could you help to inform us what's happening on the build machine? Thank you! [0] https://d-i.debian.org/daily-images/daily-build-overview.html [1] https://d-i.debian.org/daily-images/armel/ [2] https://d-i.debian.org/daily-images/armhf/ Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Tue, May 3, 2016 at 1:59 AM, Axel Beckert wrote: > Hi Roger, > > Roger Shimizu wrote: >> However, there's even no network-console (SSH) target for i386/amd64 yet [6]. > […] >> [6] >> https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/config/i386 > > Maybe that's the wrong place to look for. Because I'm very sure I used > that feature already on Intel x86 architectures. And the required > packages exist for quite a while now: Dear Axel, Another place to look is: https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/pkg-lists But still no "network-console" for x86 series. Could you tell which image did you installed on x86 by SSH? Because those settings might change by time. Knowing the filename of working image will help to find the exact config file. Thank you! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Tue, May 3, 2016 at 4:13 AM, Rick Thomas wrote: > On Mon, May 2, 2016, at 10:01 AM, Roger Shimizu wrote: >> On Sat, Apr 30, 2016 at 10:02 AM, Rick Thomas wrote: >> > When I’m installing Debian on one of the serial-console-only boxes, such >> > as the SheevaPlug or OpenRD, I usually use the “network console” option >> > that allows me to use ssh to login and run the Debian installer from the >> > comfort of my office chair — away from the cold noisy machine room! If I >> > need to see the logs or test some parameters, I can always ssh again and >> > get another shell window. Of course, I still have to be there at the >> > start-up, to push the “reset” button and use the serial console to handle >> > the initial bootstrap/installation questions before the ssh server becomes >> > available, but that’s only for a few minutes. >> > > OK, I think I get it now. This would make the serial console > installation functionally much closer to the "normal" install (e.g. > desktop machine with video console). The ability to pick up and resume > a dropped session is an added bonus. > > As I said, I'll be happy to help test it. I made a local armel build supporting GNU/screen, and uploaded all files to my g/drive: https://drive.google.com/folderview?id=0BzkkBTJUgwbhTldTd18yTFZCQ2s#list (there're only two local built udeb file in localudebs/ folder: libtinfo5-udeb_6.0+20160319-2_armel.udeb screen-udeb_4.3.1-4_armel.udeb so this will be official after these two packages get uploaded.) So you can have a test on your armel devices. For devices originally use "netboot" image, please use "netboot/screen" image; for devices originally use "network-console" image, please use "network-screen" image. You should get GNU/screen started when you connect via serial console or SSH. You can switch windows by "Ctrl-A [1-4]". (press Ctrl-A, release both keys, and press the window number) All operation is exact same as normal GNU/screen usage. If you have any question or suggestion, just feel free to let me know. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: armel/armhf d-i daily fails for days?
On Sun, May 8, 2016 at 6:29 PM, Cyril Brulebois wrote: > Roger Shimizu (2016-05-08): >> It seems armel/armhf d-i daily fails for days [0][1][2]. Because >> there's no log for it, could you help to inform us what's happening on >> the build machine? > > Hi, > > It's a somewhat (ir)regular DNS issues, I've poked an admin on IRC a few > days ago, but might escalate to a ticket or so. Thanks for your info! Hope the DNS issues can be resolved soon. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
On Mon, May 9, 2016 at 4:21 PM, Rick Thomas wrote: > Thanks, Roger! > > I’ll give it a try on one of my sheevaplug boxes. > > As I understand it, I will follow the instructions on Martin’s page at > https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ > using the uImage and uInitrd files from your page at > > https://drive.google.com/folderview?id=0BzkkBTJUgwbhdjJqY1ZjY2xWem8&tid=0BzkkBTJUgwbhTldTd18yTFZCQ2s#list Thanks for helping to test! There're 4 folders in my local build for sheevaplug: kirkwood/netboot/marvell/sheevaplug kirkwood/netboot/marvell/sheevaplug-esata kirkwood/netboot/screen/marvell/sheevaplug kirkwood/netboot/screen/marvell/sheevaplug-esata The former two is the same as current d-i daily, without GNU/screen. The latter two is with GNU/screen support, which you should use. So, here it is: https://drive.google.com/folderview?id=0BzkkBTJUgwbhM29zYnUxckQzUUk&tid=0BzkkBTJUgwbhTldTd18yTFZCQ2s#list Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
d-i daily failed on amd64/i386/arm64 due to efi?
Dear boot list, I find most amd64/i386/arm64 d-i daily failed yesterday [0], seems due to efi error: mkdir -p ./tmp/cdrom_gtk/syslinux TYPE=template INCLUDE_GTK= IS_GTK= \ syslinux-cfgs boot/x86 ./tmp/cdrom_gtk/syslinux efi-image ./tmp/cdrom_gtk/grub_efi x86_64-efi x64 debian-installer/amd64 mkfs.fat 4.0 (2016-05-06) Total number of sectors (832) not a multiple of sectors per track (63)! Add mtools_skip_check=1 to your .mtoolsrc file to skip this test config/x86.cfg:38: recipe for target 'x86_grub_efi' failed Because I'm trying to support GNU/screen to each ARCH, so I'm wondering what's the root cause, and how to fix it. Thank you! [0] https://d-i.debian.org/daily-images/daily-build-overview.html Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: d-i daily failed on amd64/i386/arm64 due to efi?
On Tue, May 10, 2016 at 9:29 AM, Roger Shimizu wrote: > Dear boot list, > > I find most amd64/i386/arm64 d-i daily failed yesterday [0], seems due > to efi error: > > > mkdir -p ./tmp/cdrom_gtk/syslinux > TYPE=template INCLUDE_GTK= IS_GTK= \ > syslinux-cfgs boot/x86 ./tmp/cdrom_gtk/syslinux > efi-image ./tmp/cdrom_gtk/grub_efi x86_64-efi x64 debian-installer/amd64 > mkfs.fat 4.0 (2016-05-06) > Total number of sectors (832) not a multiple of sectors per track (63)! > Add mtools_skip_check=1 to your .mtoolsrc file to skip this test > config/x86.cfg:38: recipe for target 'x86_grub_efi' failed > > > Because I'm trying to support GNU/screen to each ARCH, so I'm > wondering what's the root cause, and how to fix it. > Thank you! > > [0] https://d-i.debian.org/daily-images/daily-build-overview.html I just saw Cyril filed BTS #823881. I'll look at it. Thanks! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: d-i daily failed on amd64/i386/arm64 due to efi?
On Tue, May 10, 2016 at 9:34 AM, Steve McIntyre wrote: > On Tue, May 10, 2016 at 09:29:02AM +0900, Roger Shimizu wrote: >>Dear boot list, >> >>I find most amd64/i386/arm64 d-i daily failed yesterday [0], seems due >>to efi error: >> >> >>mkdir -p ./tmp/cdrom_gtk/syslinux >>TYPE=template INCLUDE_GTK= IS_GTK= \ >>syslinux-cfgs boot/x86 ./tmp/cdrom_gtk/syslinux >>efi-image ./tmp/cdrom_gtk/grub_efi x86_64-efi x64 debian-installer/amd64 >>mkfs.fat 4.0 (2016-05-06) >>Total number of sectors (832) not a multiple of sectors per track (63)! >>Add mtools_skip_check=1 to your .mtoolsrc file to skip this test >>config/x86.cfg:38: recipe for target 'x86_grub_efi' failed >> >> >>Because I'm trying to support GNU/screen to each ARCH, so I'm >>wondering what's the root cause, and how to fix it. >>Thank you! >> >>[0] https://d-i.debian.org/daily-images/daily-build-overview.html > > KiBi has identified the cause (#823881). We have a temporary > workaround in now and he's just retriggered the builds. Dear Steve, Thanks for your info! After merging a few latest commits from d-i repo, yes, I can build x86 targets locally. I have another related question (though not related to the recent efi build issue)... that "cdrom/isolinux" target generates a few images [1], but how can I build a real CD/DVD image based on those binary? I cannot find in any document I searched. It'd be appreciated if you can help me to understand this part. Thank you! [1] https://d-i.debian.org/daily-images/amd64/daily/cdrom/ Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: [RFC] Call for review of GNU/screen support for D-I (was Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap)
Dear Rick, Thanks for your testing report! On Sat, May 14, 2016 at 4:18 PM, Rick Thomas wrote: > > Hi Roger, > > I got a chance to try it on my SheevaPlug. > > Executive summary: It worked as advertised and all the features you mentioned > seem to work (except I didn’t try disconnect and reconnect — see below for > details). I really liked being able to switch between VTs with a couple of > keystrokes! > > Here’s what I did and why I did it: > > First observation is that the way I normally do installations on this machine > (I keep it around for exactly this kind of testing, so I do a fair number of > installations on it) is to run screen as a terminal emulator on a desktop > machine that is connected to the Plug via a USB serial connection. If I did > that for this experiment, I’d wind up with screen running on the Plug inside > of screen running on the Desktop and the thought of keeping track of all the > levels of ctl-A gave me nightmares. Indeed. It will be messed up if running screen inside screen. If you have any suggestion to avoid this, just let me know. > So, I changed to using “cu” to run the USB serial connection. That worked > well enough. > > The installation proceeded smoothly while I experimented with the ctl-A <1-4> > options. It would have been nice to have the option of a more spacious > work-area — larger than 24x80 — but that’s a minor issue. I find this size of screen limitation, too. But I think this limitation is not introduced by GNU/screen, it exists before. > I didn’t try disconnecting, letting it run for a while un-attended, then > reconnecting because I didn’t have a clear idea of how to do that. > Specifically, what happens if I type ctl-A ctl-D? Do I get disconnected from > just the one window or all four of them? If I get disconnected from all of > them, what will I find myself talking to? Is it an interactive shell that I > can re-connect to the running disconnected screen by typing >“screen -R” > or something else? > > If I’m disconnected, can I drop the “cu” connection without causing havoc to > the running install? If I later re-instate the “cu”, what happens then? Do I > automatically get my screen session back again, or is there something I need > to do to to make that happen? Resume when re-connecting is mainly for network-console (via SSH). "screen -r" is done by debian-installer, user don't need anything extra. > These are all experiments I could have done during the install, but I > refrained because I wanted to verify that there weren’t any difficulties > associated with simply running the installer inside screen. Next time I get > a few hours, I’ll try installing again and experiment with dis-/re-connecting. I really appreciate you helping to confirm it working on other devices than I have on hand. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Re: armel/armhf d-i daily fails for days?
On Sun, May 29, 2016 at 4:45 AM, Cyril Brulebois wrote: > Hi, > > Roger Shimizu (2016-05-09): >> On Sun, May 8, 2016 at 6:29 PM, Cyril Brulebois wrote: >> > Roger Shimizu (2016-05-08): >> >> It seems armel/armhf d-i daily fails for days [0][1][2]. Because >> >> there's no log for it, could you help to inform us what's happening on >> >> the build machine? >> > >> > Hi, >> > >> > It's a somewhat (ir)regular DNS issues, I've poked an admin on IRC a few >> > days ago, but might escalate to a ticket or so. >> >> Thanks for your info! >> Hope the DNS issues can be resolved soon. > > It seems network issues are a somwhat recurring issue where both > machines are hosted, so Hector suggested we moved armel and armhf > builds to the porterbox already used for arm64 (asachi). The setup > was finalized earlier today, and it seems the 3 builds are working > fine and ending up on dillon as expected. > > Let's see if that works better on mid/long term. Kernel build on armel was also troubled, because of broken fan of one box [0]. I'm not sure whether they're related. Good to hear d-i daily build already has a promising solution on arm64. [0] https://lists.debian.org/debian-kernel/2016/05/msg00313.html Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#826976: Should partman-raid offer new partition types for RAID?
Control: reassign -1 partman-md
Re: Next d-i alpha release: late June
Dear KiBi, On Sat, Jun 25, 2016 at 7:22 AM, Cyril Brulebois wrote: > Having checked with -release already, I'm freezing udebs right away. I think the monthly release is done, so could you un-freeze the udebs? I see ncurses is still pending to testing [0]: - 11 days old (needed 10 days) - Not touching package due to block-udeb request by freeze (please contact the d-i release manager if an update is needed) [0] https://tracker.debian.org/pkg/ncurses Cheers, -- Roger Shimizu, GMT +2 Cape Town (in DebConf16) PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Next d-i alpha release: late June
Dear KiBi, Thanks for your prompting reply! On Sun, Jul 3, 2016 at 6:12 AM, Cyril Brulebois wrote: > Hi Roger, > > Roger Shimizu (2016-07-03): >> On Sat, Jun 25, 2016 at 7:22 AM, Cyril Brulebois wrote: >> > Having checked with -release already, I'm freezing udebs right away. >> >> I think the monthly release is done, so could you un-freeze the udebs? >> I see ncurses is still pending to testing [0]: >> - 11 days old (needed 10 days) >> - Not touching package due to block-udeb request by freeze (please >> contact the d-i release manager if an update is needed) > > The announce has not been published (it's not even prepared yet), so no, > the release hasn't happened yet. (Also, screen can wait a few more days > in any cases…) I saw it's already reached archive, so I thought it's done. OK. Understand. I just prepared the commit to support screen: - https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=screen_common&id=4141f4 I'm wondering whether I can push to master, so as I can test in the daily build, which uses sid. Cheers, -- Roger Shimizu, GMT +2 Cape Town (in DebConf16) PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Next d-i alpha release: late June
On Sun, Jul 3, 2016 at 12:44 AM, Cyril Brulebois wrote: > Roger Shimizu (2016-07-03): >> I saw it's already reached archive, so I thought it's done. >> OK. Understand. > > That's one part. Then images are built on pettersson, tested, and > eventually signed and published. We're not there yet. > >> I just prepared the commit to support screen: >> - >> https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?h=screen_common&id=4141f4 >> >> I'm wondering whether I can push to master, so as I can test in the >> daily build, which uses sid. > > Please don't. We want to avoid pushing changes which aren't relevant to > the release being prepared, in case we need to do some fixup before > uploading and building again. It's lucky that I didn't push. (I was just about to do so, but considering the last commit is releasing, so I think it's better to ask) Please let me know when it's ready to accept changes. Thank you! Cheers, -- Roger Shimizu, GMT +2 Cape Town (in DebConf16) PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Next d-i alpha release: late June
Dear KiBi, Thanks for your reply! On Mon, Jul 4, 2016 at 12:05 AM, Cyril Brulebois wrote: > Hi, > > Roger Shimizu (2016-07-03): >> On Sun, Jul 3, 2016 at 12:44 AM, Cyril Brulebois wrote: >> > Please don't. We want to avoid pushing changes which aren't relevant to >> > the release being prepared, in case we need to do some fixup before >> > uploading and building again. >> >> It's lucky that I didn't push. (I was just about to do so, but >> considering the last commit is releasing, so I think it's better to >> ask) > > Sure, asking when unsure is something that makes sense, and that is > appreciated. For next time: whenever the release announce reaches > debian-devel-announce@, it's OK to push anything anywhere (to git > repositories, to the archive, etc.). > > In this particular case, if you would have pushed, and if I needed to > re-upload debian-installer without your changes, I could have just > created a temporary stretch branch without it, so it wouldn't have been > the end of the world anyway. It's best to avoid running into this kind > of situations though. ;) Thanks for the explanation! Understand the process clearer. >> Please let me know when it's ready to accept changes. Thank you! > > Even if the release announce is not ready yet, the image build has > finished and testing shows no major regressions, so we're going to > publish this set of images as Stretch Alpha 7. I've lifted the udeb > freeze some time ago; and you can feel free to push changes to git > repositories, even if the announce has not been published yet. For the change I mentioned yesterday, I already tested on: - armel/kirkwood - amd64 and they're working as expected. So I just pushed the commit to add screen support. I hope all ARCHs still (daily) build fine when I get up tomorrow morning. If not I'll try to fix or simply remove the screen support for that specific ARCH. This has big impact to UI (added a top bar) and operation (Ctrl-A [1-4], previous Alt-F[1-4] is still working though). I hope it won't panic anyone. Cheers, -- Roger Shimizu, GMT +2 Cape Town (in DebConf16) PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Screen support (was: Next d-i alpha release: late June)
Dear KiBi, Thanks for your feedback! On Mon, Jul 4, 2016 at 4:48 AM, Cyril Brulebois wrote: > Cyril Brulebois (2016-07-04): >> Cyril Brulebois (2016-07-04): >> > Roger Shimizu (2016-07-04): >> > > For the change I mentioned yesterday, I already tested on: >> > > - armel/kirkwood >> > > - amd64 >> > > and they're working as expected. >> > > >> > > So I just pushed the commit to add screen support. >> > > >> > > I hope all ARCHs still (daily) build fine when I get up tomorrow morning. >> > > If not I'll try to fix or simply remove the screen support for that >> > > specific ARCH. >> > > >> > > This has big impact to UI (added a top bar) and operation (Ctrl-A >> > > [1-4], previous Alt-F[1-4] is still working though). >> > > I hope it won't panic anyone. >> > >> > I'm surprised to discover that screen support is not opt-in… > > So I've just checked: what started as "screen support would be nice to have > in some particular situation, on an opt-in basis" became "let's use screen > unconditionally", adding an extra line which means nothing for beginners, > possibly making dialogs overflow vertically. > > I really don't think that's a reasonable default. Yes, at first I thought screen enabled installer just fit embedded system such as ARM boards, after posting it to mailing, quite a few people told me it's good idea and is not specific for embedded system, but also for x86 server and other high performance server such as sparc64. So I think we can make screen as default, for the text based installer. > Oh and also: this totally breaks the graphical installer! Sorry to break the gtk installer. I just push a commit to disable screen on gtk images, hope it fix the issue, for the short term. For the long term, I will try to enable screen on gtk images, because gtk images also can be boot as text installer, by kernel param "DEBIAN_FRONTEND=newt". >> In addition to that, please don't forget to include a debian/changelog >> update with your commits… > > The commit message in debian-installer's git repository reads: > ,--- > | Add screen support in pkg-lists > | > | screen-udeb seems to be useful for most cases, except extremely size > | limited platform, such as armel/orion5x in netboot/network-console. > `--- > > which doesn't quite describe what's happening here, which is: screen being > used by default! I really expect commit messages (and their corresponding > changelog entries) to describe what they're doing! I'm sorry that commit log didn't pass the message. > Summary: While I'm very happy to see new features proposed, it is really > important that changes leading to such user-visible changes are > carefully checked, and documented. Of course, no-one can anticipate all > consequences, but introducing screen at the very beginning of the boot > sequence could have triggered a thought about the non terminal-based > installer… the graphical installer is even the default now! Yes, the gtk installer is default now, so I think it should be OK to have screen as default for text based installer. Of course, it still can be changed, since we're on the alpha stage and can have new things play around, and find the best position it should be. Cheers, -- Roger Shimizu, GMT +2 Cape Town (in DebConf16) PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Screen support (was: Next d-i alpha release: late June)
Dear KiBi, Sorry for not being able to reply earlier. You feedback keeps me thinking a fix. On Tue, Jul 5, 2016 at 7:35 AM, Cyril Brulebois wrote: > > I still disagree with the UI changes it imposes on everyone, for the > reasons I've already given. During RFC stage of adding screen-udeb, firstly I though it's not necessary for normal PC, which is not exact the same with "everyone" you mentioned but should be close to, however a few feedbacks convinced me that normal PC still need screen-udeb [0][1][2]. [0] https://lists.debian.org/debian-boot/2016/04/msg00369.html [1] https://lists.debian.org/debian-boot/2016/04/msg00377.html [2] https://lists.debian.org/debian-boot/2016/05/msg4.html I think the solution below is a middle ground, which I guess it can be accepted by everyone. - Keep screen-udeb in "common" for everyone, but don't start it automatically on i386/amd64. - Create a new "MEDIUM_SUPPORTED" or new folder under build/pkg-lists/ for i386/amd64, which start screen by default when it's not in gtk mode (detecting in runtime) In this way, for normal image, the screen wouldn't start by default, and headless PC owner can choose the later/new image, or choose the normal image and start screen manually (specifying DEBIAN_FRONTEND=newt). > I'm not OK with installing something everywhere except where it breaks > stuff. Instead, it should be specifically installed where it's needed. > (That remains to be determined.) I guess you mean gtk installer will never use screen, so screen-udeb should not be placed in gtk image. What I thought was that it should be convenient to have one CD/DVD to fix different task as much as possible, which shares the same idea as multi-arch image, so it'd be nice to have screen-udeb in gtk installer, which can start by specifying DEBIAN_FRONTEND=newt when we install on headless PC. My proposal above already takes this into account, so should be no problem. I didn't implement the proposal yet, just hope we can make a consensus first. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Screen support (was: Next d-i alpha release: late June)
On Wed, Aug 24, 2016 at 10:56 PM, Frederic Bonnard wrote: > Hi Roger/all, > I see that on some daily isos > ( http://cdimage.debian.org/mirror/cdimage/daily-builds/daily/current/) > screen seems to be activated by default. I'd like to know if there is a way > to disable it as this was discussed. > This question is related to : > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834601 . > Note : I've not tried this on a another arch though. Dear Frederic, Could you take a try the D-I for stretch alpha-7, which don't start screen by default? It's located under: http://cdimage.debian.org/cdimage/stretch_di_alpha7/ Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Screen support (was: Next d-i alpha release: late June)
On Thu, Aug 25, 2016 at 12:30 AM, Frederic Bonnard wrote: >> Could you take a try the D-I for stretch alpha-7, which don't start >> screen by default? >> It's located under: >> http://cdimage.debian.org/cdimage/stretch_di_alpha7/ > > Already tried and the issue doesn't appear on this one. > FTR, here are the tests ran on the isos on ppc64el : > http://ftp.unicamp.br/pub/ppc64el/DAT/ > With full history, we could see that the problem popped out July 12th > ( debian-testing-ppc64el-netinst.iso md5sum 61c40714e30b19c53866ef0947a6e33b ) The oldest info on that page is July 25th (debian-testing-ppc64el-netinst.iso ebf6e4c06e77f359e924e230b5399024) Where can I check the one of July 12th, or even older ones? > Does that mean that there is a higher possibility that screen is the problem > ? :) > What about the option ? Yes, highly possible. Let me think a way to debug. I'll reply to bug #834601 when I'm ready for it. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
