Bug#1068898: Reinstate OpenRD netboot images for bookworm
* Cyril Brulebois [2024-04-13 08:25]: > I don't mind doing that again, but what's the game plan here? If systems > are already installed and working fine, then d-i is irrelevant. Well, maybe someone wants to install Debian, either because they find an old OpenRD somewhere or because Rick's hard drive dies or something. > For any new systems people might want to deploy, installing bullseye > then upgrading to bookworm already works? Of course, but bullseye will be moved to archive.d.o at some point (I know you can install from there, but then you have to specify the mirror). Anyway, I have no game play. Like I said, it's probably all a waste of time, but Debian bookworm works on OpenRD and d-i should work if we add the image, we already have a patch... so it seems like we should just do it. My game play is that I'm a perfectionist but I am aware there are pretty much no users of Debian on OpenRD (I only know of Rick!). > So OpenRD has no future in trixie as far as I understand. At least that > would mean not having to do that again again, if we were to enable > OpenRD images again for bookworm. Yes, imho let's add the image for bookworm and let this be the end of it. ;) But if you just want to close this feature request, I doubt many people will care. -- Martin Michlmayr https://www.cyrius.com/
Bug#1068898: Reinstate OpenRD netboot images for bookworm
Package: debian-installer Version: 20230607+deb12u5 I'm sorry to be that guy who shows up every few years to waste everyone's time... but... I was updating my Kirkwood pages for bookworm and noticed that the OpenRD images are gone. Now you may remember that we had the same situation for bullseye (#934072) and Cyril kindly restored the netboot images: https://salsa.debian.org/installer-team/debian-installer/-/commit/3ef30be60ab128f53a0cd16e6c1e91a3123988b4 I guess this change never got committed to master/main because bullseye was going to be the last release for armel. But armel is still in bookworm and Rick confirmed he's running bookworm on his OpenRD, so I see no reason why d-i wouldn't work if we apply the same patch to the bookworm d-i. Honestly, I'm not sure if it's worth it as Rick is probably the one Debian on OpenRD left, but since bookworm will probably be the last release of armel (or not?) it would be nice if the installer was working on OpenRD. Cyril or Vagrant, can you easily apply the patch above and generate a test image for Rick? Sorry for creating work (again) for such a minor platform... -- Martin Michlmayr https://www.cyrius.com/
Bug#934072: OpenRD images are gone
* Cyril Brulebois [2022-06-23 19:42]: > Here's what I just pushed to the bullseye branch (which is going to be > used when building d-i for the next point release): > > https://salsa.debian.org/installer-team/debian-installer/-/commit/3ef30be60ab128f53a0cd16e6c1e91a3123988b4 > > I'm not certain what you'd like to do with the bug report: consider it > all about restoring netboot support? Or would you like to keep it open > to investigate some possible follow-up regarding u-boot? > > Happy to perform s/see: #934072/closes: #934072/ in the changelog if > that makes sense. Closing it is fine. If armel stays in bookworm, it might make sense to re-enable u-boot for that release, but we'd first file a bug on the u-boot package. Thank you for resolving this issue! -- Martin Michlmayr https://www.cyrius.com/
Bug#934072: OpenRD images are gone
* Rick Thomas [2022-06-23 03:20]: > Short story: > Works a treat! Thank you for testing! > Next test: > 1) Install from/to a uSD card > 2) Install from a uSD card to an eSATA disk drive --leaving the /boot > partition on the uSD. I think the system can boot from SATA (not sure about eSATA). > 3) Anything else you might want to try? I don't think so; thanks a lot! > Detail: > The u-boot version that's on the "ultimate" is > => version > U-Boot 2016.11+dfsg1-4~20170308~1 (Mar 09 2017 - 01:27:49 +) That's fine. OpenRD was actually restored in u-boot upstream, but I doubt it's worth the effort to add it back to Debian since there are so few users. Then again, if you get OpenOCD running and want to try, maybe Vagrant could re-enable it. (Is armel going to be in the next Debian release? I thought it was going to get dropped but it's still there.) -- Martin Michlmayr https://www.cyrius.com/
Bug#934072: OpenRD images are gone
* Rick Thomas [2022-06-22 20:05]: > Great! Thanks! Now for testing: what exactly should I do with this > tar-ball? I've been relying on Martin's instruction page at > https://www.cyrius.com/debian/kirkwood/openrd/install/ which only > mentions downloading two files (uImage and uInitrd) and putting them > on a fat or ext2 USB-stick or MMC-card. As far as I can tell, the build process appends the DTB to the kernel, so just loading uImage and uInitrd (as per instructions) should work. -- Martin Michlmayr https://www.cyrius.com/
Bug#934072: OpenRD images are gone
* Cyril Brulebois [2022-06-22 15:39]: > > Basically to revert the change to build/config/armel/kirkwood/netboot.cfg > > from commit e799d626f45e9c706d05003e3112d481db2870a9 > Tried that, building in bullseye_armel-dchroot on amdahl (following > instructions at https://dsa.debian.org/doc/schroot/); but it fails to Thank you! > build since openrd bits are missing from the u-boot package? I think you completely reverted commit e799d626f4. You should only revert the change to build/config/armel/kirkwood/netboot.cfg but not the change to build/boot/arm/armel-kirkwood-u-boot-image-config (since OpenRD for u-boot was removed). I guess your build failure is because you reverted the change to build/boot/arm/armel-kirkwood-u-boot-image-config as well. (I'm only guessing here since it's been years I looked at this, but I think so.) (If it builds, can you upload the images somewhere so Rick can test them?) Thanks again! -- Martin Michlmayr https://www.cyrius.com/
Bug#934072: OpenRD images are gone
Vagrant, see below: * Martin Michlmayr [2019-08-06 20:10]: > I noticed that there are no pre-built images for OpenRD in buster > anymore. > > I found: > > commit e799d626f45e9c706d05003e3112d481db2870a9 > Author: Vagrant Cascadian > Date: Wed Dec 5 17:45:22 2018 +0100 > > [armel] Disable OpenRD targets, no longer present in u-boot. > > While it's true that there are no u-boot images for OpenRD anymore, > I think the installer and kernel should still work fine (people can > install u-boot from stretch or even use the Marvell u-boot that ships > with the device). > > I think the part of the commit above that removed openrd from > build/config/armel/kirkwood/netboot.cfg should be reverted. > (the change to build/boot/arm/armel-kirkwood-u-boot-image-config > is obviously fine) > > I don't have an OpenRD anymore but I can probably find someone if > testing is required. I became aware recently that this was never fixed. Rick Thomas has two OpenRD (Ultimate and Client) and could test the images. Since bullseye is the last release to support these devices (I think? I never know what the status of armel is), I wonder if it would make sense to add the images back to d-i in a point release. Basically to revert the change to build/config/armel/kirkwood/netboot.cfg from commit e799d626f45e9c706d05003e3112d481db2870a9 Vagrant, do you think you could do a bullseye d-i checkout, make that change and make the OpenRD images available for Rick to test? (I don't have any ARM machines) -- Martin Michlmayr https://www.cyrius.com/
Re: Bug#991878: [armel] no longer supported devices
* Holger Wansing [2021-08-04 21:36]: > A patch based on this is attached (it makes the section only appear in > the armel release-notes - currently the paragraph is visible in all archs - > and changes the model numbers to "TS-xxx"). Looks good to me. -- Martin Michlmayr https://www.cyrius.com/
Re: Bug#991878: [armel] no longer supported devices
* Holger Wansing [2021-08-04 10:57]: > Moreover, couldn't this be simplified then, into something like > > "Support for all QNAP Turbo Station devices (TS-xxx) was dropped?" There are also non-ARM Turbo Station devices (i.e. x86 based devices that will run regular Debian). But since this is in the armel release notes, I think your wording is fine. Support for all QNAP Turbo Station devices based on Marvell chips was dropped, but that might just make it more confusing. -- Martin Michlmayr https://www.cyrius.com/
Re: [installation-guide for armel] no longer supported devices
* Holger Wansing [2021-08-02 20:49]: > https://www.debian.org/releases/testing/armel/release-notes/ch-information.de.html#no-longer-supported-hardware) Unfortunately, that page is incorrect. Support for all QNAP Turbo Station devices was dropped. This page should say: * QNAP TS-109/TS-209 and TS-409 * QNAP TS-11x/TS-12x, TS-21x/TS-22x and TS-41x/TS-42x -- Martin Michlmayr https://www.cyrius.com/
Re: Installer image for HP mv2120 fails to build with Linux 5.2
* Ben Hutchings [2019-08-26 14:25]: > * [armel/marvell] Increase maximum image size (fixes FTBFS): > - This removes support for QNAP TS-109, TS-119, TS-209, TS-219, TS-409, > and HP Media Vault mv2120 Ok, I removed these images from the installer. Thanks for pointing this out, Raphael. The mv2120 images also fail with d-i. The QNAP images were worse because they silently produce a kernel image that will fail to flash. There were few users of the mv2120, but QNAP is a shame... although it seems very doubtful to me armel will be in buster at all (?). If armel stays around, one possible solution (yes, an ugly hack) would be to modify the flash layout in the kernel. Debian changes mtd1/mtd2 anyway, so we could simply reduce mtd2 a bit and make mtd1 larger. If people flash a different OS, they will change mtd1/mtd2 anyway and the new kernel will have the original layout. (And we can document how to flash the original mtd1/mtd2 while running a Debian kernel with the Debian-specific layout.) Hmm, for this to work, we'd also have to change the u-boot environment, which we have avoided so far. So maybe this should be documented as "you can't go back to the original OS" (but then again, I don't think these devices are supported by QNAP anymore). Upgrades would also require changing the u-boot config, but this could be done from within Debian with a script that users run. Ben, is that a hack you'd consider putting into the Debian kernel assuming armel will stay around (or have we reached the point where "stay with stretch" is the right answer)? -- Martin Michlmayr https://www.cyrius.com/
Bug#934072: OpenRD images are gone
Package: debian-installer Version: 20190702 Severity: important I noticed that there are no pre-built images for OpenRD in buster anymore. I found: commit e799d626f45e9c706d05003e3112d481db2870a9 Author: Vagrant Cascadian Date: Wed Dec 5 17:45:22 2018 +0100 [armel] Disable OpenRD targets, no longer present in u-boot. While it's true that there are no u-boot images for OpenRD anymore, I think the installer and kernel should still work fine (people can install u-boot from stretch or even use the Marvell u-boot that ships with the device). I think the part of the commit above that removed openrd from build/config/armel/kirkwood/netboot.cfg should be reverted. (the change to build/boot/arm/armel-kirkwood-u-boot-image-config is obviously fine) I don't have an OpenRD anymore but I can probably find someone if testing is required. -- Martin Michlmayr https://www.cyrius.com/
Bug#892206: Seagate: LUMP not started?
We still haven't figured out the root cause... -- Martin Michlmayr http://www.cyrius.com/
Bug#892206: Seagate: LUMP not started?
Package: debian-installer Version: 20170615 Severity: important Some users have reported that they cannot connect to the u-boot on their Seagate NAS anymore using clunc after installing Debian. I'll add more information about the investigation Simon Guinot did later. We're not sure this really is a bug since all released version of u-boot should listen for the magic packet (LUMP). However, there are version of u-boot that don't automatically do this (probably not released, but not 100% sure about this). In any case, we should modify the debian_boot variable so start lump directly (run start_lump or lump 3). The only downside is that the startup prcoess is 3 seconds longer. I'll add a patch soon and more info to this bug report. -- Martin Michlmayr http://www.cyrius.com/
Re: Failing to install Stretch on QNAP TS-420
I copied debian-boot since this issue may be more appropriate there * Mark Duggan <mdug...@gmail.com> [2018-02-24 09:53]: > I attached the log previously but the reply didn't seem to hit the list > No 'unhandled fault' in the log > > https://pastebin.com/9Ymxeu9b It's possible I missed something but I don't see any errors until it fails with: Feb 18 23:25:17 in-target: Reading package lists... Feb 18 23:25:18 localechooser: error: the command 'validlocale' is not available Feb 18 23:25:30 base-installer: info: Found kernels '' Feb 18 23:26:17 base-installer: error: exiting on error base-installer/kernel/no-kernels-found Feb 18 23:26:19 main-menu[1382]: (process:7509): Aborted Maybe some debian-boots folks can look over the log with their trained eyes. I don't know what the validlocale error is about. And I don't see why no kernel is found. debian-boot, any idea? -- Martin Michlmayr http://www.cyrius.com/
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
ess: >Entry Point: >Verifying Checksum ... OK >Loading Kernel Image ... OK > Starting kernel ... > Uncompressing Linux... done, booting the kernel. > > > > > > Kari Tanninen kirjoitti 1.3.2018 20:01: > > I try tomorrow record Debian "Stretch" U-boot/uImage/uInitrd -terminal > > output with instructions > > "https://www.cyrius.com/debian/kirkwood/sheevaplug/install/; > > > > Sorry delay, I have to load new binaries to GuruPlug and I'm not very > > familiar with unix command line scripting, readable minicom -output > > needs little tee/sed processing. > > > > Kari Tanninen > > > > > > not very handy to make commad line scripting, terminal output > > > > Martin Michlmayr kirjoitti 1.3.2018 15:11: > > > (Adding Ian Campbell.) > > > > > > Ok, I didn't notice the version of u-boot from the log you posted and > > > went on what you wrote. > > > > > > However, looking at the log file again, I notice you're loading the > > > DTB file separately. > > > > > > You say you follow my installation instructions but clearly you're > > > not. In Debian installer, for the various plug devices, we append to > > > the DTB at the end of the kernel rather than loading it separately. > > > > > > Can you please follow the instructions at > > > https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ and post > > > the output of that? > > > > > > > > > > > > * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 15:01]: > > > > I'm using Debian stretch U-boot version (U-boot version number > > > > is visible on > > > > the log-file). I have tried Debian "buster" U-boot version too, > > > > but it > > > > freezes at "Setting egiga0" point. There is warning on "Debian Armel > > > > installation guide", that U-boot does update kernel variables > > > > only on fresh > > > > installation, if first U-boot version is older than 2014, there > > > > will be > > > > problems becouse of "bootm_size" variable is missing and default > > > > value > > > > cannot be set. > > > > > > > > Flattened device tree -mechanism is not using those "ATAG" global > > > > kernel/U-boot -variables, but problem is missing U-boot "boot_args" > > > > -variable, too. > > > > > > > > Fdt-file includes that "Chosen" -field for command line > > > > parameters and > > > > U-boot has a commands to resize fdt -file and append command > > > > line parameters > > > > to it before actual boot. > > > > > > > > U-boot sets and can read correctly that fdt-file "chosen" part. > > > > U-boot > > > > kprint line for that "chosen" value is visible on log-file. > > > > > > > > Martin Michlmayr kirjoitti 1.3.2018 14:02: > > > > > * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 11:26]: > > > > > > HW: Guruplug Server plus with JTAG-box (ARMv5-family) > > > > > > original U-boot pre-2014 > > > > > ... > > > > > > Is there any fix-up/work-aroud trick available or is new kernel > > > > > > compiling > > > > > > only option? > > > > > > > > > > I've never had a GuruPlug so I cannot really comment but why are you > > > > > using the pre-2014 u-boot version? I cannot remember all the > > > > > differences of the u-boot versions of the installation page says you > > > > > should upgrade your u-boot before installing Debian. Maybe you can > > > > > give this a try. > > > > > > > > > > Based on the logs you posted, it seems to me that the kernel and > > > > > ramdisk are loaded but the kernel doesn't see the ramdisk, leading to > > > > > the "no root" issue. -- Martin Michlmayr http://www.cyrius.com/
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
(Adding Ian Campbell.) Ok, I didn't notice the version of u-boot from the log you posted and went on what you wrote. However, looking at the log file again, I notice you're loading the DTB file separately. You say you follow my installation instructions but clearly you're not. In Debian installer, for the various plug devices, we append to the DTB at the end of the kernel rather than loading it separately. Can you please follow the instructions at https://www.cyrius.com/debian/kirkwood/sheevaplug/install/ and post the output of that? * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 15:01]: > I'm using Debian stretch U-boot version (U-boot version number is visible on > the log-file). I have tried Debian "buster" U-boot version too, but it > freezes at "Setting egiga0" point. There is warning on "Debian Armel > installation guide", that U-boot does update kernel variables only on fresh > installation, if first U-boot version is older than 2014, there will be > problems becouse of "bootm_size" variable is missing and default value > cannot be set. > > Flattened device tree -mechanism is not using those "ATAG" global > kernel/U-boot -variables, but problem is missing U-boot "boot_args" > -variable, too. > > Fdt-file includes that "Chosen" -field for command line parameters and > U-boot has a commands to resize fdt -file and append command line parameters > to it before actual boot. > > U-boot sets and can read correctly that fdt-file "chosen" part. U-boot > kprint line for that "chosen" value is visible on log-file. > > Martin Michlmayr kirjoitti 1.3.2018 14:02: > > * Kari Tanninen <ot...@elisanet.fi> [2018-03-01 11:26]: > > > HW: Guruplug Server plus with JTAG-box (ARMv5-family) > > > original U-boot pre-2014 > > ... > > > Is there any fix-up/work-aroud trick available or is new kernel > > > compiling > > > only option? > > > > I've never had a GuruPlug so I cannot really comment but why are you > > using the pre-2014 u-boot version? I cannot remember all the > > differences of the u-boot versions of the installation page says you > > should upgrade your u-boot before installing Debian. Maybe you can > > give this a try. > > > > Based on the logs you posted, it seems to me that the kernel and > > ramdisk are loaded but the kernel doesn't see the ramdisk, leading to > > the "no root" issue. -- Martin Michlmayr http://www.cyrius.com/
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
* Kari Tanninen <ot...@elisanet.fi> [2018-03-01 11:26]: > HW: Guruplug Server plus with JTAG-box (ARMv5-family) > original U-boot pre-2014 ... > Is there any fix-up/work-aroud trick available or is new kernel compiling > only option? I've never had a GuruPlug so I cannot really comment but why are you using the pre-2014 u-boot version? I cannot remember all the differences of the u-boot versions of the installation page says you should upgrade your u-boot before installing Debian. Maybe you can give this a try. Based on the logs you posted, it seems to me that the kernel and ramdisk are loaded but the kernel doesn't see the ramdisk, leading to the "no root" issue. -- Martin Michlmayr http://www.cyrius.com/
Bug#890262: (no subject)
* Arthur <art...@lutz.im> [2018-02-21 23:03]: > I now have another problem (should I file another bugs?), openning up These are different issues so please don't follow up here. Let's continue this on the thread on debian-arm: https://lists.debian.org/debian-arm/2018/02/msg00086.html -- Martin Michlmayr http://www.cyrius.com/
Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD
Unfortunately my memory is quite bad. I *thought* the current installer configured XZ compression by default but it seems that's not the case. So the documentation on my web site is correct. * The installer sets MODULES=dep * It has done so for a long time * But you've upgraded from a really old release where this wasn't the case (I believe) * The installer doesn't configure XZ compression * You don't need it for a normal installation * If you want LVM or RAID, you have to use XZ, as per the hint at http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/ At least I *believe* that's the case. I didn't investigate in detail. -- Martin Michlmayr http://www.cyrius.com/
Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD
The other thing you can do is to enable XZ compression: http://www.cyrius.com/debian/orion/qnap/ts-109/troubleshooting/#bootable I thought this was documented in the release notes but I can't find it. -- Martin Michlmayr http://www.cyrius.com/
Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD
* Gunnar Thorburn <gunnar.thorb...@gmail.com> [2018-02-12 17:52]: > The initial ramdisk is too large. This is often due to the unnecessary > inclusion > of all kernel modules in the image. To fix this set MODULES=dep in one or both > /etc/initramfs-tools/conf.d/driver-policy (if it exists) and > Not enough space for initrd in MTD 'RootFS1' (need 4210887 but is > actually 4194304). Please check the various initramfs-tools configuration files to see if you're using MODULES=dep. Changing to MODULES=dep would be the fix. However, given the size of your ramdisk, I fear you are already using MODULES=dep. Are you using RAID or LVM? Unfortunately, since the MTD partition for the ramdisk is very tiny on the TS-x09, you cannot use RAID or LVM. (And this was possible in the past, which will lead to problems with upgrades.) > But given that TS-109 appears supported > http://www.cyrius.com/debian/orion/qnap/ts-109/install/ > and with no major issues > http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/ > I would not expect this problem well into the upgrade. I have to document the LVM/RAID issue. In fact, the installation page currently says "You can use LVM and RAID and a number of filesystems", which is definitely no longer true to due to the size issue (even with MODULES=dep). -- Martin Michlmayr http://www.cyrius.com/
Bug#878251: Unset the Bootloader-Sets-Incorrect-Root field for HP t5325 Thin Client
* Karsten Merker <mer...@debian.org> [2017-10-11 20:26]: > > Machine: HP t5325 Thin Client > > Bootloader-Sets-Incorrect-Root: no > > as you have been the original contributor of the support for this > device in flash-kernel, I wanted to kindly ask whether you could > perhaps take a look at this and provide some insight about why the > flag was originally included. Well, the HP t5325 u-boot configuration sets root=/dev/sda1, which we cannot rely on. Historically, flash-kernel sets Bootloader-Sets-Incorrect-Root if the default config sets a root= parameter. Maybe the HP t5325 situation is different because the default config doesn't work anyway with Debian and you have to modify it, so you may just as well modify root= too. In any case, this device was never supported by HP t5325 anyway so I don't mind either way. -- Martin Michlmayr http://www.cyrius.com/
Bug#870430: linux-image-4.9.0-3-marvell: Couldn't find DTB in /usr/lib/linux-image-4.9.0-3-marvell or /etc/flash-kernel/dtbs
* Ian Campbell <i...@debian.org> [2017-08-03 20:15]: > Martin, does that fix seem correct to you? Your analysis sounds correct to me. Please go ahead and make the change. Thanks! -- Martin Michlmayr http://www.cyrius.com/
Bug#870869: Segfault during libc-l10n install on kirkwood (armel)
* Peter Mogensen <a...@terplund.dk> [2017-08-12 23:10]: > Yes. I started a debian "reinstall" on a wheezy installation on the > QNAP, by running the kirkwood-qnap to detect the kernel version. > I don't recall getting an error, it just does: Ok. I don't think running the script on wheezy's kernel is necessarily supposed to work, so that error can be disregarded. Unfortunately, I've no idea regarding the segfault. -- Martin Michlmayr http://www.cyrius.com/
Bug#870869: Segfault during libc-l10n install on kirkwood (armel)
* Peter Mogensen <a...@terplund.dk> [2017-08-12 08:42]: > >> (even though the kirkwood-qnap script can't auto-detect the right > >> kernel version on a 419PII) > > > > Maybe the QNAP firmware has changed. If you can easily go back to the > > QNAP firmware, we can look into this issue. > > I have the original firmware "somewhere", but the box has been running > wheezy for 2 years and it hasn't had any upgrades from QNAP. Oh, sorry, I thought you were talking abou the flash-debian script (the script you run on the QNAP firmware to run the installer). But you're talking about kirkwood-qnap, the script in flash-kernel. What error did you get? Which verison of Debian did you run it on? -- Martin Michlmayr http://www.cyrius.com/
Bug#870869: Segfault during libc-l10n install on kirkwood (armel)
* Peter Mogensen <a...@terplund.dk> [2017-08-05 22:23]: > While trying to install stretch on a QNAP 419PII, the installation > consistently fails with a segfault in dpkg when it tries to install > locales and libc-l10n. I received one other report about a segfault on QNAP (when running anna) a few months ago. (This was in private mail and wasn't reported to debian-boot even though I recommened it.) Unfortunately, I don't really know what's going on. > Using the kernel-6282 Are you sure you're using the right kernel? > (even though the kirkwood-qnap script can't auto-detect the right > kernel version on a 419PII) Maybe the QNAP firmware has changed. If you can easily go back to the QNAP firmware, we can look into this issue. -- Martin Michlmayr http://www.cyrius.com/
Bug#865128: Requires optional .txt firmware file
* Cyril Brulebois <k...@debian.org> [2017-06-19 17:50]: > I think that's one file you can retrieve using the newly-udebified > efivarfs module. You'll likely have a few bits of information there > like the MAC address, but I don't have first hand experience with it. > > More context: > https://lists.debian.org/debian-boot/2016/07/msg00239.html > https://bugs.debian.org/862555 Thanks for these links! -- Martin Michlmayr http://www.cyrius.com/
Bug#865128: Requires optional .txt firmware file
Package: hw-detect Version 1.123 When I run the installer on a Dell XPS 13 (late 2015 model), it asks for brcmfmac4350-pcie.bin. When I add that firmware file, it still complains about a missing brcmfmac4350-pcie.txt file. While I'm not sure what this .txt file is supposed to be (I find little information online), running touch /lib/firmware/brcm/brcmfmac4350-pcie.txt in the installer solves the issue. After the installation, I can delete the .txt file and wifi works fine. It would appear that this .txt file is optional, so maybe hw-detect should ignore firmware requests for brcmfmac*.txt. Hopefully someone who knows about these brcmfmac*.txt files can comment. -- Martin Michlmayr http://www.cyrius.com/
Bug#864525: flash-kernel: fails on fat32
* Heinrich Schuchardt <xypron.g...@gmx.de> [2017-06-09 23:18]: > flash-kernel currently fails if the boot partition is FAT32. > > On FAT32 symbolic links cannot be created. Unless something has changed, FAT for /boot isn't supported anyway. See https://lists.debian.org/debian-boot/2014/01/msg00188.html -- Martin Michlmayr http://www.cyrius.com/
Re: Debian-Installer gets stuck at selecting mirror
* Mekeor Melire <mekeor.mel...@gmail.com> [2017-04-26 16:43]: > I just wonder at which exact step I would have to specify this config > option. (Other upcoming questions, I'd ask in IRC while doing it.) If you set up a TFTP server, you can load debian-installer like this: setenv bootargs console=ttyS0,115200n8 root=/dev/ram rw initrd=0xa0,0x8f setenv serverip 192.168.0.2 setenv ipaddr 192.168.0.147 tftpboot 0xa0 ts-212/di/initrd tftpboot 0x80 ts-212/di/kernel-6281 bootm 0x80 You can add DEBCONF_DEBUG=developer at the end of the bootargs line. BTW, based on the logs, you need the kernel-6282 kernel image. -- Martin Michlmayr http://www.cyrius.com/
Re: Debian-Installer gets stuck at selecting mirror
* Cyril Brulebois <k...@debian.org> [2017-04-24 21:45]: > Maybe setting DEBCONF_DEBUG=developer would help figure out what's > successful and what isn't? Mekeor, do you have (or can you make) a serial console for your QNAP (see my web page for some information)? That would be the easiest way to pass the config option. -- Martin Michlmayr http://www.cyrius.com/
Re: Debian-Installer gets stuck at selecting mirror
* Cyril Brulebois <k...@debian.org> [2017-04-13 03:18]: > (Adding tbm to the loop explicitly since he's the QNAP master.) FWIW, I helped Mekeor a bit on IRC originally but since I didn't know what was wrong I recommended to send an email to debian-boot. > > main-menu[1395]: DEBUG: resolver (libgcc1): package doesn't exist > > (ignored) > > main-menu[1395]: INFO: Menu item 'di-utils-shell' selected > > I think that's the first time I'm seeing this “succeeded but requested > to be left unconfigured” status, not sure what's causing this. One of the things I see in the logs is: Apr 8 01:15:46 main-menu[938]: (process:966): ip: SIOCGIFFLAGS: No such device Apr 8 01:15:46 main-menu[938]: (process:966): ip: SIOCGIFFLAGS: No such device but Ethernet is working fine, so I don't think it's a connectivity issue per se. One thing I've always wondered about: oldsys-preseed preseeds eth0 as the default interface and I suspect this is no longer true. However, I never looked into changing it since it doesn't seem to cause any issues. At least I was able to install stretch fine. Also, Mekeor had the issue with the jessie and the stretch installer. It's the first time I saw a QNAP user with this problem and I suspect we would have heard about it already if it was a common issue. So I really have no idea. :/ -- Martin Michlmayr http://www.cyrius.com/
Bug#845818: Re: Re: Bug#845818: flash-kernel: Add support for Hardkernel Odroid-C2
Ok, I'll add the following: Machine: Hardkernel ODROID-C2 Kernel-Flavors: arm64 DTB-Id: meson-gxbb-odroidc2.dtb Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.uboot-generic Required-Packages: u-boot-tools * Heinrich Schuchardt <xypron.g...@gmx.de> [2017-03-18 07:12]: >Please, go ahead with the generic script. > >Am 18.03.17, 02:44, Martin Michlmayr <t...@cyrius.com> schrieb: > > Hi Heinrich, > * Heinrich Schuchardt <xypron.g...@gmx.de> [2017-03-18 02:39]: > > U-Boot 2017-3 does not contain MMC support for the Odroid C2. > > I have seen a recent patch series for MMC support. But I did not > yet > > build with it. > If they are accepted for 2017.05, maybe Vagrant could add them to > the > 2017.03 Debian package. > > You are right in that with MMC support in mainline u-boot we > should be > > able to use a generic boot script. > Are you ok with the approach I proposed (i.e. requiring users to > install a new u-boot, which hopefully weʼll have in Debian unstable > at > some point) or would you prefer your original solution that works > with > the built-in u-boot? My worries are about supporting upgrades from > the original u-boot to mainline u-boot. Going with the generic > u-boot > approach would avoid this issue. > -- > Martin Michlmayr > [1]http://www.cyrius.com/ > > References > >1. http://www.cyrius.com/ -- Martin Michlmayr http://www.cyrius.com/
Bug#845818: Re: Bug#845818: flash-kernel: Add support for Hardkernel Odroid-C2
Hi Heinrich, * Heinrich Schuchardt <xypron.g...@gmx.de> [2017-03-18 02:39]: > U-Boot 2017-3 does not contain MMC support for the Odroid C2. > I have seen a recent patch series for MMC support. But I did not yet > build with it. If they are accepted for 2017.05, maybe Vagrant could add them to the 2017.03 Debian package. > You are right in that with MMC support in mainline u-boot we should be > able to use a generic boot script. Are you ok with the approach I proposed (i.e. requiring users to install a new u-boot, which hopefully we'll have in Debian unstable at some point) or would you prefer your original solution that works with the built-in u-boot? My worries are about supporting upgrades from the original u-boot to mainline u-boot. Going with the generic u-boot approach would avoid this issue. -- Martin Michlmayr http://www.cyrius.com/
Bug#855960: flash-kernel: Please add support for NETGEAR ReadyNAS Duo v2
* Scott Barker <sc...@mostlylinux.ca> [2017-03-17 17:47]: > I know the db entry for the NETGEAR ReadyNAS Duo v2 is missing from this > installer image, which is the one I've been using: Yeah, I just added the db entry to git. It's not even in the archive yet. -- Martin Michlmayr http://www.cyrius.com/
Bug#845818: flash-kernel: Add support for Hardkernel Odroid-C2
* Heinrich Schuchardt <xypron.g...@gmx.de> [2016-11-26 22:57]: > As mainline u-boot support is still under construction boot.scr > is build such that the stock u-boot can execute it. As you know, I added your prerequisite patch but I never added this patch and didn't explain why (apart from hoping someone else would take ownership). Basically, it seems to me like an hack to add this specific boot script when work is going on to support Odroid-C2 properly upstream. I don't have such a device, but I looked at the u-boot list a few weeks ago and it seems there has been a lot of progress recently. So I'm wondering whether this approach makes sense: * In flash-kernel, add an entry that uses the generic boot script * Get an u-boot-armlogic (or whatever) package into unstable using 2017.03 * Document the install process on wiki.deban.org, i.e. take the u-boot from unstable and then install stable. What do you think about this approach? Do you know how well u-boot 2017.03 works on this device? -- Martin Michlmayr http://www.cyrius.com/
Bug#855960: flash-kernel: Please add support for NETGEAR ReadyNAS Duo v2
* Scott Barker <sc...@mostlylinux.ca> [1969-12-31 17:52]: > Please add suuport for NETGEAR ReadyNAS Duo v2. The db entry that works for > me is: Thanks, I added this in git. Do we also have to create any installation images in debian-installer? -- Martin Michlmayr http://www.cyrius.com/
Bug#839595: flash-kernel: Please add support for SolidRun Clearfog
* Christoph Egger <christ...@debian.org> [2016-12-27 17:55]: > Christoph Egger <christ...@debian.org> writes: > > I haven't updated u-boot yet, though it's still on my todo > > Seems to have worked. I have now u-boot 2016-11 SPL and "normal" > u-boot and everything works so far \o/ Karsten, I think this one is waiting for you. Can you take a look? -- Martin Michlmayr http://www.cyrius.com/
Bug#855965: libdebian-installer: Please add support for NETGEAR ReadyNAS Duo v2
* Scott Barker <sc...@mostlylinux.ca> [1969-12-31 18:48]: > Please add support for NETGEAR ReadyNAS Duo v2, which uses a "kirkwood" > processor: Thanks, I added this patch. -- Martin Michlmayr http://www.cyrius.com/
Bug#849532: flash-kernel does not remove dtb backups
* Heinrich Schuchardt <xypron.g...@gmx.de> [2016-12-28 10:10]: > The .bak file should not be created on the first install of a Linux kernel. Yeah, that's a separate issue but it's definitely something I noticed too. The DTB handling code is run several times under some circumstances, see e.g. the log below. I'm afraid to touch that code and hope Ian will look into it at some point. ... Taking backup of tegra210-p2371-2180.dtb. Installing new tegra210-p2371-2180.dtb. flash-kernel: deferring update (trigger activated) /etc/kernel/postinst.d/zz-flash-kernel: DTB: tegra210-p2371-2180.dtb Installing /usr/lib/linux-image-4.9.0-trunk-arm64/nvidia/tegra210-p2371-2180.dtb into /boot/dtbs/4.9.0-trunk-arm64/tegra210-p2371-2180.dtb Taking backup of tegra210-p2371-2180.dtb. Installing new tegra210-p2371-2180.dtb. Installing /usr/lib/linux-image-4.9.0-trunk-arm64/nvidia/tegra210-p2371-2180.dtb into /boot/dtbs/4.9.0-trunk-arm64/tegra210-p2371-2180.dtb Taking backup of tegra210-p2371-2180.dtb. Installing new tegra210-p2371-2180.dtb. flash-kernel: deferring update (trigger activated) Processing triggers for flash-kernel (3.73) ... DTB: tegra210-p2371-2180.dtb Installing /usr/lib/linux-image-4.9.0-trunk-arm64/nvidia/tegra210-p2371-2180.dtb into /boot/dtbs/4.9.0-trunk-arm64/tegra210-p2371-2180.dtb Taking backup of tegra210-p2371-2180.dtb. Installing new tegra210-p2371-2180.dtb. flash-kernel: installing version 4.9.0-trunk-arm64 Generating boot script u-boot image... done. Taking backup of boot.scr. Installing new boot.scr. -- Martin Michlmayr http://www.cyrius.com/
Bug#845779: flash-kernel: flashkernel uses mkimage -A arm on arm64
Thanks, I applied this patch. U-boot on the ARM64 system I tested (a Jetson TX1) accepts boot scripts with both -A arm and -A arm64, but as you point out this may not be the case on all systems. -- Martin Michlmayr http://www.cyrius.com/
Bug#836679: flash-kernel: cannot configure kernel 4.7 with new flash-kernel
* Ian Campbell <i...@debian.org> [2016-12-23 00:23]: > IIRC "set -e" doesn't propagate to subshells with Bash, my > understanding of this is from http://xenbits.xen.org/gitweb/?p=osstest. > git;a=commit;h=6ffbf6eee57d0e4a7f1a669a66dc1a0ae1f7d8d6 > > But flash-kernel uses /bin/sh which these days ought to be dash not > bash and the original bug report does say: > > Shell: /bin/sh linked to /bin/dash > > Maybe there is some similar oddity with function calls in dash? Thanks for pointing out this issue. We use /bin/sh so we're not running into this issue. However, I investigated a bit more and found out that it relates to the use of "local". See e.g. http://superuser.com/questions/363444/how-do-i-get-the-output-and-exit-value-of-a-subshell-when-using-bash-e/1103711#1103711 for an explanation. Fortunately this is easy enough to work around. -- Martin Michlmayr http://www.cyrius.com/
Bug#839595: flash-kernel: Please add support for SolidRun Clearfog
I was just looking at this bug report and it seems Karsten was never
copied on Christoph's last email (see below).
* Christoph Egger <christ...@sieglitzhof.net> [2016-10-24 15:22]:
> Hi!
>
> This seems to be the "new" default environment:
>
> => printenv
> arch=arm
> baudrate=115200
> board=clearfog
> board_name=clearfog
> boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr}
> ${prefix}${script}; source ${scriptaddr}
> boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r}
> efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi
> ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r}
> ${fdtcontroladdr};fi
> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any
> ${scriptaddr} ${prefix}extlinux/extlinux.conf
> boot_net_usb_start=usb start
> boot_prefixes=/ /boot/
> boot_script_dhcp=boot.scr.uimg
> boot_scripts=boot.scr.uimg boot.scr
> boot_targets=mmc0 usb0 pxe dhcp
> bootcmd=run distro_bootcmd
> bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr}
> ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile
> ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile
> ${soc}-${board}${boardver}.dtb; fi; setenv efi_old_vci ${bootp_vci};setenv
> efi_old_arch ${bootp_arch};setenv bootp_vci
> PXEClient:Arch:00010:UNDI:003000;setenv bootp_arch 0xa;if dhcp
> ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr
> ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi
> ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci
> ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv
> efi_old_arch;setenv efi_old_vci;
> bootcmd_mmc0=setenv devnum 0; run mmc_boot
> bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
> bootcmd_usb0=setenv devnum 0; run usb_boot
> bootdelay=3
> console=ttyS0,115200
> cpu=armv7
> devnum=0
> devplist=1
> devtype=mmc
> distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
> efi_dtb_prefixes=/ /dtb/ /dtb/current/
> fdt_addr_r=0x10
> fdt_high=0x1000
> fdtcontroladdr=3fb4ce58
> fdtfile=armada-388-clearfog.dtb
> initrd_high=0x1000
> kernel_addr_r=0x80
> load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r}
> ${prefix}${efi_fdtfile}
> mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run
> scan_dev_for_boot_part; fi
> pxefile_addr_r=0x30
> ramdisk_addr_r=0x180
> scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...;
> for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run
> scan_dev_for_scripts; done;run scan_dev_for_efi;
> scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env
> exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do
> if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run
> scan_dev_for_boot; fi; done
> scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n
> "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for
> prefix in ${efi_dtb_prefixes}; do if test -e ${devtype}
> ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb;
> fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart}
> efi/boot/bootarm.efi; then echo Found EFI removable media binary
> efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED:
> continuing...; fi; setenv efi_fdtfile
> scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart}
> ${prefix}extlinux/extlinux.conf; then echo Found
> ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED:
> continuing...; fi
> scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype}
> ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot
> script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED:
> continuing...; fi; done
> scriptaddr=0x20
> soc=mvebu
> stderr=serial@12000
> stdin=serial@12000
> stdout=serial@12000
> usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run
> scan_dev_for_boot_part; fi
> vendor=solidrun
>
> Environment size: 3819/65532 bytes
>
>
> --
> 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731
> Debian Developer | Lisp Hacker | CaCert Assurer
--
Martin Michlmayr
http://www.cyrius.com/
Bug#845779: flash-kernel: flashkernel uses mkimage -A arm on arm64
* Heinrich Schuchardt <xypron.g...@gmx.de> [2016-11-26 16:54]: > I want to get the Hardkernel Odroid C2 supported by flash-kernel. > > It is a 64bit system. > > Unfortunately in file /usr/share/flash-kernel/functions the functions > mkimage_kernel() and mkimage_initrd() both call mkimage with argument > > -A arm . > > This is incorrect. On 64bit arm systems you have to use > > -A arm64 . > > Otherwise neither u-boot nor the kernel can read the images. Your latest patch looks fine to me but I'm wondering why this is needed in the first place. On modern devices, we no longer wrap the kernel and initrd into an u-boot image, but we boot it directly using bootz (arm) or booti (arm64). I see there's also one "mkimage -A arm" call to generate the boot script. Is that's what causing you the problem? -- Martin Michlmayr http://www.cyrius.com/
Bug#806926: Bug#766400: installation-reports: [armhf] Netgear ReadyNAS104 report
Hi Uwe, Can you review your old Netgear ReadyNAS 102/104 patch for flash-kernel and apply them? -- Martin Michlmayr http://www.cyrius.com/
Bug#836679: flash-kernel: cannot configure kernel 4.7 with new flash-kernel
backup_and_install \
+ "/boot/dtbs/$kvers/$dtb_name.new" \
+ "/boot/dtbs/$kvers/$dtb_name"
+
+ # Historically we installed the dtb as
+ # dtb-$kvers, keep it around as an alternative
+ # for now. Useful for platforms which do not
+ # set ${fdtfile}
+ ln -nfs "dtbs/$kvers/$dtb_name" "/boot/dtb-$kvers"
+
+ # This can be used along with the unversioned
+ # vmlinuz+initrd.gz e.g. as a fallback option
+ ln -nfs "dtbs/$kvers/$dtb_name" "/boot/dtb"
fi
}
@@ -864,9 +868,6 @@ case "$method" in
initrd="$ifile"
if [ "$dtb_append" = "yes" ]; then
dtb=$(find_dtb_file)
- if [ ! -f "$dtb" ]; then
- error "Couldn't find $dtb"
- fi
append_dtb "$kernel" "$dtb" "$tmpdir/kernel"
kernel="$tmpdir/kernel"
elif [ -n "$machine_id" ]; then
@@ -945,9 +946,6 @@ case "$method" in
if [ -n "$boot_dtb_path" ]; then
boot_dtb_path="$boot_mnt_dir/$boot_dtb_path"
boot_dtb=$(find_dtb_file)
- if [ ! -f "$boot_dtb" ]; then
- error "Couldn't find $boot_dtb"
- fi
dtb="$tmpdir/dtb"
cp "$boot_dtb" "$dtb"
backup_and_install "$dtb" "$boot_dtb_path"
--
Martin Michlmayr
http://www.cyrius.com/
Bug#789886: linux-image-3.2.0-4-kirkwood: Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb
It seems I never applied this patch because I was waiting for Ian to review it. Ian, do you have some time to look at the proposed patch? * Martin Michlmayr <t...@cyrius.com> [2016-08-05 19:46]: > * Jesse Adelman <je...@boldandbusted.com> [2015-06-20 20:35]: > > When I upgrade this package on my Debian Wheezy Sheevaplug, I get this > > error: > > > > Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb > > > Full log: > > > > flash-kernel: installing version 3.2.0-4-kirkwood > > Generating kernel u-boot image... done. > > Taking backup of uImage. > > Installing new uImage. > > Generating initramfs u-boot image... done. > > Taking backup of uInitrd. > > Installing new uInitrd. > > Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb > > dpkg: error processing package flash-kernel (--configure): > > subprocess installed post-installation script returned error exit status 1 > > Sorry for the delay in responding to this bug. I believe I know what > the issue is. I've copied Ian Campbell who knows the code best. > > Ian, I've attached a proposed patch below. Do you agree with the > logic described or am I missing something? > > The log also shows: > > > update-initramfs: Generating /boot/initrd.img-3.2.0-4-kirkwood > > /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb not found > > /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb not found > > I'm not sure where this is from but it seems isn't not causing an > actual error. > > > Only create DTB boot file on kernels that require DTB > > Boot-DTB-Path can be specified to install the DTB to a file. Some > machines, such as the SheevaPlug, contain both a DTB-Append-From and > a Boot-DTB-Path. > > If DTB-Append-From is set, a verson check is performed to see if the > DTB is required and dtb_append is set to "yes" or "no" accordingly. > However, there is no version check for Boot-DTB-Path. This can lead > to errors that the DTB couldn't be found on older kernels (i.e. older > than the version specified in DTB-Append-From). > > Arguably, DTB-Append-From and Boot-DTB-Path together don't make sense > (why would you append the DTB _and_ install it to /boot), but it's > possible that users rely on this behaviour. > > Therefore, only honour Boot-DTB-Path if $dtb_append is not "no". If > it's "yes" or empty, we want to install the DTB to Boot-DTB-Path. > But if $dtb_append is "no", it means we're on an old kernel without > DTBs. > > diff --git a/functions b/functions > index 368cbf2..c4ef6a3 100644 > --- a/functions > +++ b/functions > @@ -939,7 +939,7 @@ case "$method" in > boot_script="$tmpdir/boot.scr" > backup_and_install "$boot_script" "$boot_script_path" > fi > - if [ -n "$boot_dtb_path" ]; then > + if [ -n "$boot_dtb_path" ] && [ "$dtb_append" != "no" ]; then > boot_dtb_path="$boot_mnt_dir/$boot_dtb_path" > boot_dtb=$(find_dtb_file) > if [ ! -f "$boot_dtb" ]; then > > -- > Martin Michlmayr > http://www.cyrius.com/ -- Martin Michlmayr http://www.cyrius.com/
Bug#842040: Please add https support
* Rick Thomas <rbtho...@pobox.com> [2016-11-24 21:28]: > >> So how do we move forward here? Exclude wget-udeb from the orion5x-qnap > >> image and otherwise include it by default? > > > > That should work. > > Are there other machines that have equally sever size restrictions? I don't think so. -- Martin Michlmayr http://www.cyrius.com/
Bug#776272: what anice surprise
Hey! I've recieved a message from our friend and he told something really surprising, just take a look <http://vouch.jillofalltradesnola.com/e6xj/511> Martin Michlmayr
Bug#842040: Please add https support
* Philipp Kern <pk...@debian.org> [2016-11-18 17:19]: > > Thanks for the CC. I just added wget-udeb and it adds 345 KB, > > which breaks the orion5x-qnap image. However, this image is really > > quite a special case and I don't want to block https support because > > of it. I can always exclude wget-udeb from this particular image. > > So how do we move forward here? Exclude wget-udeb from the orion5x-qnap > image and otherwise include it by default? That should work. -- Martin Michlmayr http://www.cyrius.com/
Bug#844549: network-console broken: no screen to be resumed matching sh
* Samuel Thibault <sthiba...@debian.org> [2016-11-16 23:03]: > But AIUI the intent was to have screen in ssh connections too. I'm not sure what the intent was. I assume you're right because Roger didn't exclude screen from the network-console images. Personally, I'm not sure I see the point of screen in that case because you can always open a second SSH connection and open a terminal, but I don't have strong feelings either way if there's an advantage of having screen in such cases. > I'm also thinking that we perhaps want to add -x when resuming a > session, so that somebody can connect trough ssh several times ? Yes because right now I get this when I open a 2nd connection: debug1: Sending env LC_COLLATE = C There is a screen on: 1356.network(11/16/16 23:24:12) (Attached) Apart from this, the patch works for me. -- Martin Michlmayr http://www.cyrius.com/
Bug#844549: network-console broken: no screen to be resumed matching sh
* Ben Hutchings <b...@decadent.org.uk> [2016-11-16 21:15]: > > rm -f $font > > - if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = > > serial \) -a "$TERM" != dumb ]; then > > + if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = > > serial \) -a "$TERM" != dumb ]; then > > This makes the comparison with 'serial' redundant; the condition will > be equivalent to: > > [ -x "$screen_bin" -a "$TERM_TYPE" != network -a "$TERM" != dumb ] > > Is that really what we want? Oh, good point. I think that's what we want but I'm not sure. Maybe Roger can comment. In his old code, there was also a $NETBOOT_SCREEN variable which afaict wasn't set set anywhere. -- Martin Michlmayr http://www.cyrius.com/
Bug#844549: network-console broken: no screen to be resumed matching sh
Package: rootskel Version: 1.119 Severity: serious Tags: patch Several users have reported to me that the network-console images are broken. Commit ec6d3c3d79 (Move screen support) moved the screen support around and also changed the logic of when screen is used. Unfortunately, that change broke all network-console images which now lead to: installer@192.168.0.102's password: There is no screen to be resumed matching sh. Connection to 192.168.0.102 closed. This is because d-i is already running in screen on the serial console but it's active and can't be resumed. I believe below is the right fix, i.e. start screen when screen exists and when we're on serial or when we're NOT on network. Samuel, Roger, does that look correct? diff --git a/src/lib/debian-installer.d/S70menu b/src/lib/debian-installer.d/S70menu index 7b35fac..14cad7f 100644 --- a/src/lib/debian-installer.d/S70menu +++ b/src/lib/debian-installer.d/S70menu @@ -11,7 +11,7 @@ if [ -x "$bterm" ] && [ -e "$font" ] && [ -n "$TERM_UTF8" ] && [ -n "$TERM_FRAME set -e else rm -f $font - if [ -x "$screen_bin" -a \( "$TERM_TYPE" = network -o "$TERM_TYPE" = serial \) -a "$TERM" != dumb ]; then + if [ -x "$screen_bin" -a \( "$TERM_TYPE" != network -o "$TERM_TYPE" = serial \) -a "$TERM" != dumb ]; then # there's GNU/screen binary, run menu in it. # call this script again with in GNU/screen, possibly in UTF-8 mode SCREEN_OPT="" -- Martin Michlmayr http://www.cyrius.com/
Bug#843916: debian-installer: fails to FTBFS when u-boot bits go missing
* Cyril Brulebois <k...@debian.org> [2016-11-10 18:27]: > Once a fix is implemented for this specific issue, it would be nice to > know what to do with the kirkwood/u-boot things for openrd. If they're > not going to work (again/at all), the relevant code should go away > from debian-installer.git; or am I missing anything? Sorry, I learned about the removal recently but forgot to update d-i. I pinged the upstream maintainer recently and I hope the u-boot images will be back in time for stretch. -- Martin Michlmayr http://www.cyrius.com/
Bug#842040: Please add https support
* Roger Shimizu <rogershim...@gmail.com> [2016-10-26 00:59]: > > So, approximately 780k extra for the initrd image (3.5% increase) > > I'm not sure whether any libs already is included in the d-i image, if > not, adding 780k extra would definitely affect armel/orion5x qnap d-i > initrd image. > > So I append Martin, the porter of armel/orion5x qnap, to CC list. Thanks for the CC. I just added wget-udeb and it adds 345 KB, which breaks the orion5x-qnap image. However, this image is really quite a special case and I don't want to block https support because of it. I can always exclude wget-udeb from this particular image. -- Martin Michlmayr http://www.cyrius.com/
Re: flash-kernel: arm64 doesn't have bootz
* Karsten Merker <mer...@debian.org> [2016-10-08 13:18]: > I think that keeping the platform-specific boot script generation > handled by flash-kernel is the more flexible approach. Generating a > compatibility boot script fragment within d-i during the > installation process means that this is a one-time operation, i.e. > it cannot be easily adjusted during the lifetime of the system, > which might be necessary sometimes. With the boot scripts generated > from within flash-kernel, we can easily perform any necessary > adjustments with a simple flash-kernel package update. It's true that the flash-kernel approach is more flexible. I think for the board I have in mind, I only need a one-time adjustment but let me play with it first. -- Martin Michlmayr http://www.cyrius.com/
Re: flash-kernel: arm64 doesn't have bootz
* Vagrant Cascadian <vagr...@debian.org> [2016-07-30 17:14]: > At that point, we might want to look into some sort of templating; on > several of the platforms it could basically re-use most of > uboot-generic, by setting compatibility variables for the old > versions. > > With the recent odroid bootscript, I cut-and-pasted u-boot-generic into > it, adding some compatibility variables at the top, but the bulk of the > logic is identical. I think I have a board like this, too. I cannot assume that users have access to u-boot to set environments and I believe some variables are missing. I see that you added some specific bootscripts to flash-kernel. But I wonder if it would make sense instead to do that templating in d-i: have one generic boot script and then prepend some board specific code where needed to set (and save) the variables. This way, we make sure the variables are set. As a side effect, flash-kernel could use one single boot script for all (or most) devices. What do you think? -- Martin Michlmayr http://www.cyrius.com/
Bug#836679: flash-kernel: cannot configure kernel 4.7 with new flash-kernel
* Dominique Dumont <d...@debian.org> [2016-09-15 08:06]: > I guess that the intent is to let user know the the right DTB for his board > is > sun7i-a20-olinuxino-lime.dtb but this file cannot be found in the expected > location (which is I guess /boot). No, it's usually found under /usr/lib/linux-image-$kvers (it ships with the kernel) but flash-kernel also allows users to put DTBs in /etc/flash-kernel/dtbs (flash-kernel will take the DTB from there and then store it under /boot for the boot process.) > I think this require some context knowledge from user to intepret > this correctly. I think also that indicating where the DTB file is > expected would give user a hint to look for an issue with kernel > installation or kernel content. > How about something like: > # flash-kernel > This board requires DTB file: sun7i-a20-olinuxino-lime.dtb > Couldn't find sun7i-a20-olinuxino-lime.dtb in /boot We could definitely do: > This board requires DTB file: sun7i-a20-olinuxino-lime.dtb > Couldn't find sun7i-a20-olinuxino-lime.dtb It's harder to specify the location because there are several options (find_dtb_file accepts absolute paths, and there's /usr/lib/linux-image-$kvers and /etc/flash-kernel/dtbs) Looking at the code, all uses of find_dtb_file() check for the result and produce an error if the file doesn't exist, so maybe we should just move the error messages into find_dtb_file(). Then we could tell the user where we were looking. Ian, any comments? -- Martin Michlmayr http://www.cyrius.com/
Bug#836679: flash-kernel: cannot configure kernel 4.7 with new flash-kernel
* Dominique Dumont <d...@debian.org> [2016-09-05 09:42]: > On the other hand the error message returned by flash-kernel could be > improved. > > When the dtb is missing, flash-kernel shows: > > # flash-kernel > DTB: sun7i-a20-olinuxino-lime.dtb > Couldn't find > > Reading that, I thought that the dtb file was found, but something else was > wrong. > > Could you improve this error message ? Sorry for the delay. I didn't notice the broken error message when you first pointed it out. This happened because I changed the code that looks for the DTB. I can change it to: Couldn't find sun7i-a20-olinuxino-lime.dtb Does this work? -- Martin Michlmayr http://www.cyrius.com/
Bug#836679: flash-kernel: cannot configure kernel 4.7 with new flash-kernel
* Dominique Dumont <d...@debian.org> [2016-09-04 21:16]: > On the other there's no dtb file in linux-image-4.7.0-1-armmp-lpae ... > $ dpkg --listfiles linux-image-4.7.0-1-armmp-lpae | grep dtb > [ nothing ] > > Did I miss something ? Maybe the real bug is that the signed package doesn't contain the DTBs. -- Martin Michlmayr http://www.cyrius.com/
Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro
* Rainer Dorsch <m...@bokomoko.de> [2016-08-22 00:18]: > > Can you 1) attach /var/log/installer/syslog from the SD card and b) > > show the boot log (after the installer). > > I attached the syslog. On the serial console, there was no output indicating > any boot attempt. The installer shutdown for reboot, but then I did not see > further output. The log suggests that flash-kernel was installed successfully, i.e. that a u-boot boot script was generated correctly. I don't know anything about this device so unfortunately I cannot help you. Maybe Vagrant Cascadian knows something? -- Martin Michlmayr http://www.cyrius.com/
Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro
* Rainer Dorsch <m...@bokomoko.de> [2016-08-21 10:41]: > The boot loader installation did not show an error, but the device did not > boot. > > The last "words" of the installer: > > lqu Finishing the installation tqqk > x x > x 95% x > x x > The system is going down NOW!ystem... x > Sent SIGKILL to all processes x > Requesting system rebootj > [ 2730.956106] reboot: Restarting system Can you 1) attach /var/log/installer/syslog from the SD card and b) show the boot log (after the installer). -- Martin Michlmayr http://www.cyrius.com/
Bug#809611: d-i fails to boot on HP mv2120
retitle 809611 armel: HP mv2120 requires change in u-boot setting reassign 809611 release-notes thanks I documented the new settings here: http://www.cyrius.com/debian/orion/hp/mv2120/uboot-config/ I emailed the hackingthemediavault and debian-arm mailing lists. Since we cannot fix this in Debian, I'll reassign this bug to release-notes where we should add a link to the configuration change. -- Martin Michlmayr http://www.cyrius.com/
Bug#809611: d-i fails to boot on HP mv2120
* Mike Thompson <mpthomp...@gmail.com> [2016-08-06 18:32]: > OK Martin, that image worked. I did a full install of Debian Stretch from > it. Below is the output at the tail end of bootup and login. Thanks for testing it! -- Martin Michlmayr http://www.cyrius.com/
Bug#809611: d-i fails to boot on HP mv2120
Hi Mike, * Mike Thompson <mpthomp...@gmail.com> [2016-08-05 20:23]: > The good news is that given the load address change from 0x40 to > 0x60 allowed the MV2120 to boot into the ssh based installer. Great! > The bad news is the installed failed from what looked like some sort of > segmentation faults in the installer from the looks of the logs which I > included below. I wonder if this is the same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833599 Can you please test this image: http://ftp.nl.debian.org/debian/dists/testing/main/installer-armel/current/images/orion5x/network-console/hp/mv2120/netboot.img -- Martin Michlmayr http://www.cyrius.com/
Bug#789886: linux-image-3.2.0-4-kirkwood: Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb
* Jesse Adelman <je...@boldandbusted.com> [2015-06-20 20:35]: > When I upgrade this package on my Debian Wheezy Sheevaplug, I get this error: > > Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb > Full log: > > flash-kernel: installing version 3.2.0-4-kirkwood > Generating kernel u-boot image... done. > Taking backup of uImage. > Installing new uImage. > Generating initramfs u-boot image... done. > Taking backup of uInitrd. > Installing new uInitrd. > Couldn't find /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb > dpkg: error processing package flash-kernel (--configure): > subprocess installed post-installation script returned error exit status 1 Sorry for the delay in responding to this bug. I believe I know what the issue is. I've copied Ian Campbell who knows the code best. Ian, I've attached a proposed patch below. Do you agree with the logic described or am I missing something? The log also shows: > update-initramfs: Generating /boot/initrd.img-3.2.0-4-kirkwood > /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb not found > /usr/lib/linux-image-3.2.0-4-kirkwood/kirkwood-sheevaplug.dtb not found I'm not sure where this is from but it seems isn't not causing an actual error. Only create DTB boot file on kernels that require DTB Boot-DTB-Path can be specified to install the DTB to a file. Some machines, such as the SheevaPlug, contain both a DTB-Append-From and a Boot-DTB-Path. If DTB-Append-From is set, a verson check is performed to see if the DTB is required and dtb_append is set to "yes" or "no" accordingly. However, there is no version check for Boot-DTB-Path. This can lead to errors that the DTB couldn't be found on older kernels (i.e. older than the version specified in DTB-Append-From). Arguably, DTB-Append-From and Boot-DTB-Path together don't make sense (why would you append the DTB _and_ install it to /boot), but it's possible that users rely on this behaviour. Therefore, only honour Boot-DTB-Path if $dtb_append is not "no". If it's "yes" or empty, we want to install the DTB to Boot-DTB-Path. But if $dtb_append is "no", it means we're on an old kernel without DTBs. diff --git a/functions b/functions index 368cbf2..c4ef6a3 100644 --- a/functions +++ b/functions @@ -939,7 +939,7 @@ case "$method" in boot_script="$tmpdir/boot.scr" backup_and_install "$boot_script" "$boot_script_path" fi - if [ -n "$boot_dtb_path" ]; then + if [ -n "$boot_dtb_path" ] && [ "$dtb_append" != "no" ]; then boot_dtb_path="$boot_mnt_dir/$boot_dtb_path" boot_dtb=$(find_dtb_file) if [ ! -f "$boot_dtb" ]; then -- Martin Michlmayr http://www.cyrius.com/
Re: flash-kernel: handle DTBs in vendor subdir
* Ian Campbell <i...@debian.org> [2016-08-04 10:03]: > Seems fine by me. It does assume that DTB filenames are unique even > when the directory hierarchy. That seems fairly likely to be true, > but it may not be guaranteed I guess. True, that's an assumption I made but I think it's pretty safe (given the dtb starts with the platform name). If it ever breaks, I think we could easily allow the subdir in the flash-kernel database and look for subdir/dtb before looking for just dtb. -- Martin Michlmayr http://www.cyrius.com/
Re: Add generic armhf SD card image
* Karsten Merker <mer...@debian.org> [2016-08-01 21:24]: > I have no objections against the idea of providing a "generic" SD > card image, but I would prefer to achieve that by just generating > a "firmware.none.img.gz" that can be concatenated together with > the partition image like we do it for the "real" firmware images. > With this method, the space and bandwidth impact would be > absolutely minimal Yes, I did consider the space impact but went with a full image because it's easier for the user. But I'm fine with doing it the way you suggest. I'll add something. -- Martin Michlmayr http://www.cyrius.com/
Bug#833097: flash-kernel: should exist when DTB doesn't exist
Package: flash-kernel Version: 3.68 At the moment, flash-kernel doesn't exit when the DTB doesn't exist. It will print the DTB to be used but then not copy it. That will result in devices not being able to boot. Ian, is there a reason why we *don't* want to exit? Right now we have: get_dtb_name() prints "DTB: $dtb_name" handle_dtb() returns if there's no DTB. If there's a DTB, handle_dtb() will call local dtb=$(find_dtb_file) But then it only copies the DTB if the file exists: if [ -e "$dtb" ]; then and there's no "else". Surely if a DTB is specified ($dtb_name is not empty) we need the DTB so there should be an else error "Cannot find DTB file $dtb" fi Is there a situation where we want to continue without the DTB file? -- Martin Michlmayr http://www.cyrius.com/
Re: flash-kernel: handle DTBs in vendor subdir
* Ian Campbell <i...@debian.org> [2016-07-31 10:20]:
> I've attached the two patches I had sitting in my branch here, they
> look sensible but I honestly can't remember what state they are in.
>
> AFAICT the main difference is that they preserve the directory layout
> rather than collapsing it. Not sure there is any particular reason to
> favour either way of doing it so feel free to either ignore or pickup
> these patches.
The boot script looks for dtbs/${fk_kvers}/${fdtfile} and $fdtfile
doesn't contain the vendor subdir, so I think this approach is wrong.
> One thing my patches handles which I'm not sure yours does is the pre-
> subdir-transition versions on ARM64, which my commit log says happened
> in v3.19-rc1. That might be important for backports and/or upgrades.
I looked at your other patch and I like the approach since it supports
the old and new way. Personally I found search_for_dtb_file_in_prefix
a bit hard to read and wonder if a simple 'find' might do.
What do you think of this approach? This no longer requires the
vendor subdir in DTB-Id. I think this is better since e.g. the RPi3
has the same device tree on 32 and 64 bit and I assume one will be in
a vendor subdir whereas the other won't be.
Any comments?
diff --git a/README b/README
index 02ba3fd..9458a23 100644
--- a/README
+++ b/README
@@ -115,9 +115,13 @@ The supported fields are:
This option is ignored if a DTB is to be appended, via either DTB-Append or
DTB-Append-From.
-* DTB-Id: (optional) specifies the name of the DTB file for this device. If
- the value begins with a `!' then the field is a script which should be run.
- The script must produce the DTB filename (and nothing else) on stdout.
+* DTB-Id: (optional) specifies the name of the DTB file for this device
+ relative to the kernel package DTB dir or /etc/flash-kernel/dtbs.
+ It's not necessary to specify the directory if the DTB is in a vendor
+ subdirectory as flash-kernel will search for the filename in
+ subdirectories. If the value begins with a `!' then the field is a script
+ which should be run. The script must produce the DTB filename (just the
+ filename, without a vendor subdirectory) on stdout (and nothing else).
* DTB-Append: (optional) when yes the DTB specified by DTB-Id will be appended
to the kernel image.
diff --git a/functions b/functions
index 0f597b8..f008515 100644
--- a/functions
+++ b/functions
@@ -241,6 +241,12 @@ get_dtb_name() {
;;
esac
if [ -n "$dtb_name" ] ; then
+ # DTBs on arm64 are stored in subdirs for each vendor; strip
+ # the dir away (in case someone specified it, although it's
+ # not needed).
+ # The DTB will be stored in /boot/dtbs/$kvers/ without
+ # additional subdirs.
+ dtb_name=$(basename $dtb_name)
echo "DTB: $dtb_name" >&2
fi
}
@@ -558,11 +564,11 @@ find_dtb_file() {
echo "$dtb_name"
;;
*)
- if [ -e "/etc/flash-kernel/dtbs/$dtb_name" ] ; then
- echo "/etc/flash-kernel/dtbs/$dtb_name"
- else
- echo "/usr/lib/linux-image-$kvers/$dtb_name"
+ local dtb=$(find /etc/flash-kernel/dtbs -name $dtb_name
2>/dev/null | head -n 1)
+ if [ -z "$dtb" ]; then
+ dtb=$(find /usr/lib/linux-image-$kvers -name $dtb_name
2>/dev/null | head -n 1)
fi
+ echo $dtb
;;
esac
}
@@ -597,8 +603,8 @@ handle_dtb() {
rmdir --ignore-fail-on-non-empty /boot/dtbs
fi
else
- if [ -e $dtb ]; then
- echo "Installing $dtb_name into
/boot/dtbs/$kvers/$dtb_name" >&2
+ if [ -e "$dtb" ]; then
+ echo "Installing $dtb into /boot/dtbs/$kvers/$dtb_name"
>&2
mkdir -p /boot/dtbs/$kvers/
cp "$dtb" "/boot/dtbs/$kvers/$dtb_name.new"
backup_and_install \
--
Martin Michlmayr
http://www.cyrius.com/
Re: flash-kernel: arm64 doesn't have bootz
* Ian Campbell <i...@debian.org> [2016-07-31 10:14]: > > Are all arm64 boards only going to support booti and not bootz? > > bootz refers to the zImage which is only an ARM image type and not an > ARM64 one, which is an Image and hence booti. And according to this email, all arm64 boards will have booti soon: http://lists.denx.de/pipermail/u-boot/2016-July/262385.html -- Martin Michlmayr http://www.cyrius.com/
Bug#833072: Can't create armel chroot using debootstrap - Invalid Release file, no entry for main/binary-armel/Packages
* Jeffrey Walton <noloa...@gmail.com> [2016-07-31 11:42]: > Primarily because its a port: https://www.debian.org/ports/ and > https://www.debian.org/ports/arm/ . > > Other, lesser reasons include there's no documentation (follow the > links above), and using non-port procedures fails sooner than the > ports procedure: ports.debian.org is for ports that are not officially part of Debian. I realize this isn't obvious. > I: Running command: debootstrap --arch armel --foreign --keyring > /usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd > --exclude=debfoster unstable debian-armel http://ftp.debian.org/ You have to use http://ftp.debian.org/debian -- Martin Michlmayr http://www.cyrius.com/
Bug#809611: d-i fails to boot on HP mv2120
Mike, can you please give these instructions a go? This is what I intend to post to the mv2120 list. -- Mike Thompson reported that Debian stretch (the upcoming Debian 9) doesn't boot on the HP mv2120 anymore. I don't know how many Debian users are left who run Debian on their mv2120. I gave away my device several years ago. Recently I bought an mv2120 from eBay in order to debug this issue. While I found a solution, it requires users to change a setting on their device. Please make sure to make this change, otherwise your device will no longer boot when you upgrade to Debian 9. The new settings are compatible with Debian 8 (jessie) and Debian 9 (stretch), so I suggest you make the changes now. If you have serial console access to the mv2120, you can run some commands in u-boot. Simply interrupt the boot process by pressing a key and type the following: setenv loadAddr 0x060 setenv bootcmd 'bootext2 0,1:1,2 0x060 /boot/uImage /dev/sda /dev/sdb' saveenv If you don't have a serial console, you can make the changes from within Debian. Run the following commands: cat >/etc/fw_env.config <https://d-i.debian.org/daily-images/armel/daily/orion5x/network-console/hp/mv2120/netboot.img will not boot right now with these settings. However, you can change the loadAddr to 0x050 and it should work. I just commited a fix in Git so it should work in a day or so with 0x060. -- Martin Michlmayr http://www.cyrius.com/
Bug#809611: d-i fails to boot on HP mv2120
Here's an explanation of this problem. I'll send another email with instructions for users. By default, the kernel is loaded to 0x040 and the ramdisk exactly 2 MB behind that location. For some reason, it fails with stretch. However, changing the load address to 0x050 or 0x060 makes it work. I don't think it's clear why since the ramdisk is still loaded exactly 2 MB after the kernel. The load address is in two u-boot configs: loadAddr and bootcmd. We adjust them to 0x060. This is something the user has to do manually. I couldn't find a way to workaround the problem by changing the installer or flash-kernel. At the moment, debian-installer and mv2120-recovery-image use 0x0100 as the load address. This means the combined kernel+ramdisk can only be 10 MB. Let's change 0x0100 to 0x0160 to allow for a larger ramdisk. Note that flash-kernel already uses 0x0160 -- Martin Michlmayr http://www.cyrius.com/
Add generic armhf SD card image
Karsten, do you have any objections to this patch? This adds a generic SD card image for armhf. It consists of the kernel, installer, DTBs and boot script but no u-boot. This can be used to easily populate SD card images on devices for which we don't provide u-boot images. --- build/config/armhf/netboot.cfg | 1 + debian/changelog | 1 + 2 files changed, 2 insertions(+) diff --git a/build/config/armhf/netboot.cfg b/build/config/armhf/netboot.cfg index 5da8d92..febce02 100644 --- a/build/config/armhf/netboot.cfg +++ b/build/config/armhf/netboot.cfg @@ -53,4 +53,5 @@ netboot_images_concatenateable: $(KERNEL) $(INITRD) $(TEMP_DTBS) netboot_bootscr fi ;\ done < boot/arm/u-boot-image-config gen-hd-image -v -z -b partition -s "$(FLOPPY_SIZE)" -i "$(TEMP)/netboot_images_concatenateable" -o "$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/partition.img" + gen-hd-image -v -z -b complete -s "$(FLOPPY_SIZE)" -i "$(TEMP)/netboot_images_concatenateable" -o "$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/generic.img" cp boot/README.concatenateable_images "$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/" diff --git a/debian/changelog b/debian/changelog index c8d9f5a..9eb1f0d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -10,6 +10,7 @@ debian-installer (20160704) UNRELEASED; urgency=medium - Split orion5x into orion5x and orion5x-qnap. This is based on work done by Roger Shimizu. - Exclude the text frontend. + * Add generic armhf SD card image. [ Adam Conrad ] * build/Makefile: Don't strip modules; this removes sigs (LP: #1604441) -- Martin Michlmayr http://www.cyrius.com/
Re: flash-kernel: handle DTBs in vendor subdir
* Vagrant Cascadian <vagr...@debian.org> [2016-07-30 17:23]: > Thanks for the patch! Looks good and simple to me. > > I presume the database entries for platforms that need it would then > include the vendor like this: > > DTB-Id: VENDOR/PLATFORM.dtb Correct. -- Martin Michlmayr http://www.cyrius.com/
flash-kernel: handle DTBs in vendor subdir
DTBs on arm64 are stored as vendor/dtb rather than everything in one
directory. flash-kernel doesn't handle this at the moment. I see two
options:
1) Strip the vendor dir away and install the dtb as
/boot/dtbs/$kvers/dtb
2) Keep the directory and install as /boot/dtbs/$kvers/vendor/dtb
In both cases, I think we should accept local DTBs in
/etc/flash-kernel/dtbs either as vendor/dtb or just dtb.
The patch below implements options 1. Do people think this is the
right path or would you prefer option 2?
Actually, now that I look at the boot script, I think the real
question is: does ${fdtfile} from u-boot contain the directory or not?
I believe the answer is no, so option 1 is the right on.
Any problems with the proposed patch?
diff --git a/functions b/functions
index 0f597b8..06a0c39 100644
--- a/functions
+++ b/functions
@@ -560,6 +560,8 @@ find_dtb_file() {
*)
if [ -e "/etc/flash-kernel/dtbs/$dtb_name" ] ; then
echo "/etc/flash-kernel/dtbs/$dtb_name"
+ elif [ -e "/etc/flash-kernel/dtbs/$(basename $dtb_name)" ] ;
then
+ echo "/etc/flash-kernel/dtbs/$(basename $dtb_name)"
else
echo "/usr/lib/linux-image-$kvers/$dtb_name"
fi
@@ -573,6 +575,11 @@ handle_dtb() {
fi
local dtb=$(find_dtb_file)
+ # DTBs on arm64 are stored in subdirs for each vendor; strip the
+ # dir away because we want to put the file in /boot/dtbs/$kvers/
+ # without additional subdirs.
+ local dtb_name=$(basename $dtb_name)
+
if [ "x$FK_KERNEL_HOOK_SCRIPT" = "xpostrm.d" ] ; then
rm -f "/boot/dtbs/$kvers/$dtb_name"
--
Martin Michlmayr
http://www.cyrius.com/
flash-kernel: arm64 doesn't have bootz
bootscript/all/bootscr.uboot-generic uses bootz but arm64 requires booti. My idea was to copy bootscript/all/bootscr.uboot-generic to arm64 and replace bootz with booti: sed "s/bootz/booti/" bootscript/all/bootscr.uboot-generic > bootscript/arm64/bootscr.uboot-generic debian/rules copies all/* over before arm64/* so the latter would be used. Is there a better approach? -- Martin Michlmayr http://www.cyrius.com/
Re: Installation guide architecture table update
* Ben Hutchings <b...@decadent.org.uk> [2016-06-29 15:23]: > - On armel, kirkwood and orion5x are still separate subarchitectures > even though they use the same kernel flavour Yes, but I think the table should just list marvell (it it currently does). Users are not exposed to the d-i subarch (except the directory where they download the image from) whereas they will notice the kernel flavour. -- Martin Michlmayr http://www.cyrius.com/
Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough
* Christian Perrier <bubu...@debian.org> [2016-05-18 07:25]: > I still remember Joey's objections about *not* having users forced > to choose between desktop environmentsbecause, contrary to what > the average geek thinks, most people have no idea about what is a > desktop environment. So, just imagine if we present them with > "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted > strange things. FWIW, I fully agree. I'm not happy to see the new desktop selection in tasksel, even though I can understand why some people want to see this. In my opinion, adding Blends is definitely taking things too far. Most users will have no clue what it's about, even if we add an explanation of what a "blend" is. We've worked hard for years to improve the installation experience and I fear the new tasksel selection will add a lot of confusion for users. -- Martin Michlmayr http://www.cyrius.com/
Bug#815537: Typo for MIPS related section
* Mathieu Malaterre <ma...@debian.org> [2016-02-22 08:25]: > debdiff attached Thanks, Mathieu, and sorry for the delay. I applied the translation fix and also (with minor changes) the package descriptions. Thanks! -- Martin Michlmayr http://www.cyrius.com/
Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap
* Roger Shimizu <rogershim...@gmail.com> [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.) -- Martin Michlmayr http://www.cyrius.com/
Re: Merge orion5x/kirkwood to flavour marvell and marvell-qnap
* Roger Shimizu <rogershim...@gmail.com> [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)? -- Martin Michlmayr http://www.cyrius.com/
Bug#815786: d-i does not ask for hostname
* Roger Shimizu <rogershim...@gmail.com> [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. -- Martin Michlmayr http://www.cyrius.com/
Re: [RFC] screen/tmux support for network-console
* Roger Shimizu <rogershim...@gmail.com> [2016-03-01 00:52]: > > 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 Just copy the .udeb into the directory. daily-build will update it. -- Martin Michlmayr http://www.cyrius.com/
Bug#815786: d-i does not ask for hostname
* Roger Shimizu <rogershim...@gmail.com> [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). > 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. ;-) -- Martin Michlmayr http://www.cyrius.com/
Bug#815786: d-i does not ask for hostname
* Nagel, Peter (IFP) <peter.na...@kit.edu> [2016-02-25 22:45]: > > Anyway, can you tell me if the installer took the hostname from DHCP? > The installer takes the hostname from DHCP. Thanks for confirming this. (I know this isn't the problem you were reporting, but I hear some issues around that and just wanted to ensure this is working.) > Concerning the hostname selection we probably do not have a bug but > would like to add a missing feature. I'm not trying to portray that the current behaviour is ideal. Sorry if I gave that impression. I just wanted to explain why the installer is working the way it is today. -- Martin Michlmayr http://www.cyrius.com/
Bug#815786: d-i does not ask for hostname
* Martin Michlmayr <t...@cyrius.com> [2016-02-25 10:40]: > 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. Never mind... we do the right thing. The code I copied was just setting all default values. But later we call generate_preseed_file which does if verify_hostname "$HOSTNAME"; then add "$1" "netcfg/get_hostname" "string" "$HOSTNAME" fi -- Martin Michlmayr http://www.cyrius.com/
Bug#815786: d-i does not ask for hostname
* Peter Nagel <peter.na...@kit.edu> [2016-02-25 11:02]: > From other installations I'm used to get ask for the new hostname - e.g. the > installer prompts with the following message: ... > However, it looks like that the message (shown above) is missing for the > QNAP (armel) installation. Sorry, my explanation obviously wasn't clear enough. When you install Debian on most devices, you will get asked that question. This is because you interact with the installer before the network configuration is done. However, the QNAP installations are done via SSH (using what we call the network-console d-i image). In order to do an installation via SSH, the installer has to set up networking first. So we at least need to assign an IP address and set the gateway (if any). We *could* do the hostname later, after we set up an IP address and you log in via SSH. But as I mentioned in my last email, the current network configuration program doesn't allow for that. It does *all* network configuration in one step, including the hostname. By that time, you are not connected with SSH yet (we're just setting up the IP address) and so we cannot ask you about the hostname. Does that make sense now? I'm not sure how difficult it would be to run netcfg again after you connect with SSH and to show the hostname selection. Anyway, can you tell me if the installer took the hostname from DHCP? -- Martin Michlmayr http://www.cyrius.com/
Bug#815786: d-i does not ask for hostname
* Roger Shimizu <rogershim...@gmail.com> [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 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. What unset_matching_var does it to unset a variable if it has a particular value. This is because we don't want to use values that are the default values. i.e. only take the value if the user has personally chosen something. -- Martin Michlmayr http://www.cyrius.com/
Re: [RFC] screen/tmux support for network-console
* Roger Shimizu <rogershim...@gmail.com> [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 > 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. -- Martin Michlmayr http://www.cyrius.com/
Bug#815786: d-i does not ask for hostname
* Peter Nagel <peter.na...@kit.edu> [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). We set the hostname to debian and the domain to example.org. Values obtained via DHCP take preference over these defaults. The reason we're setting the hostname is that you need to complete the network configuration, so you can SSH into the installer and afaik it's not possible to set the IP without setting other network parameters, such as hostname (i.e. doing the network configuration in two steps). So I'm not sure what to do about this bug report. I guess my question is: did the installer use the hostname from DHCP (or was it "debian") and if so what's wrong with taking the hostname from DHCP? > The problem is that (in some situations) it can be quite difficult to change > the hostname afterwards. > E.g. if the installer creates a new RAID device this device would contain the > given hostname from the installer. > If this RAID device does later contain the /-directory it can be quite > difficult to change the hostname-settings of the RAID device afterwards. > A quick-fix would be to first (jump into a shell and to) change the hostname > (within the installer) and than continue with the installation. > However, it would be nice if the installer would ask for the hostname before > the installation starts. -- Martin Michlmayr http://www.cyrius.com/
Re: [RFC] screen/tmux support for network-console
* Roger Shimizu <rogershim...@gmail.com> [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". > 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 > > 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. -- Martin Michlmayr http://www.cyrius.com/
Bug#679334: debian-installer: now in alpha3 system total freeze
* BasaBuru <basab...@basatu.org> [2016-02-18 21:46]: > > basaburu, can you confirm things are working for you? > > Yes, At last upgrade it's resolve Ok, that's good. Unfortunately, I cannot tell how BasaBuru's issue relates to the one reported by KiBi originally, so I suggest KiBi closes this bug if it's indeed fixed. -- Martin Michlmayr http://www.cyrius.com/
Re: commit "Bump Linux kernel version from 4.3.0-1 to 4.4.0-1"
* Cyril Brulebois <k...@debian.org> [2016-02-19 11:07]: > Until now I've been waiting for linux to be built everywhere to flip > the switch. I'm fine with revisiting how we do things but I think it > should be discussed somehow. I agree with you (unless there's one arch which takes a long time to get fixed). Sorry, I was a little bit trigger happy yesterday. I thought breaking some builds for a day or two wouldn't be a big problem, but I guess you're the one receiving all the build errors. ;-) Anyway, I agree with your policy. Ben made a new linux upload so hopefully all architectures will be there later today. -- Martin Michlmayr http://www.cyrius.com/
Re: D-I status on device tree based armel orion5x/kirkwood Buffalo Linkstation
* Roger Shimizu <rogershim...@gmail.com> [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. > 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! -- Martin Michlmayr http://www.cyrius.com/
Re: [RFC] screen/tmux support for network-console
* Roger Shimizu <rogershim...@gmail.com> [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. On the other hand, it's not clear how d-i can be started within screen/tmux, but maybe you know. -- Martin Michlmayr http://www.cyrius.com/
Bug#806926: Bug#766400: installation-reports: [armhf] Netgear ReadyNAS104 report
* Uwe Kleine-König <uwe+deb...@kleine-koenig.org> [2016-02-18 20:47]: > Do we need "Bootloader-Sets-Incorrect-Root: yes"? I modified the u-boot > env to pass the right root= and rootflags= parameter. Right, that's requrired, too. > Gijs uses > > U-Boot-Initrd-Address: 0x0 > > on a rn102, but I think this is not optimal. I cannot remember for sure but I thought there was an issue with the numbers you picked. I'd have to check my mails with Gijs if you cannot remember. -- Martin Michlmayr http://www.cyrius.com/
Bug#704162: Wrong sum for GTK installer initrd.gz inside netboot.tar.gz
* Cyril Brulebois <k...@debian.org> [2014-03-03 01:40]: > > There must be a small packaging bug somewhere… > > The timestamp issue was indeed a nice clue. gzip has -n to avoid storing > such information, improving build reproducibility: > I shall note pigz needs has -n and -T: ... > Tagging with patch as the solution has been identified; I haven't > committed a proper patch yet though. Sounds like this bug should be closed: commit c86563eeeb78b4d6b5841a012b21abac55aec56d Author: Cyril Brulebois <k...@debian.org> Date: Thu Nov 26 01:57:36 2015 +0100 build/config/x86.cfg: Also pass -n to gzip. commit d7a975094883477cc708f382e430a280fc8c7488 Author: Cyril Brulebois <k...@debian.org> Date: Thu Nov 26 01:46:33 2015 +0100 Rename GZIP into gzip, and pass an extra -T to pigz. It needs both -n and -T to behave as gzip's -n. -- Martin Michlmayr http://www.cyrius.com/
