Bug#751704: partman-base 173: partman overwrites parts of u-boot
Control: tag -1 patch
On Wed, Jun 18, 2014 at 09:44:12PM +0200, Karsten Merker wrote:
[On sunxi-based systems, upon writing the partition table, partman
overwrites parts of u-boot which are located between the end of
the partition table and the beginning of the first partition.]
Hello,
the following patch solves the issue for me. I have run a
successful jessie installation on a Cubietruck with this patch
applied to a locally built d-i based on kernel 3.16 from
experimental.
If there are no objections, I would like apply it to the
partman-base git repository.
Regards,
Karsten
>From 35d41e3bfce60fd08c4da6dc0696a479c78bdcdd Mon Sep 17 00:00:00 2001
From: Karsten Merker
Date: Tue, 12 Aug 2014 23:10:13 +0200
Subject: [PATCH] Take care of the firmware area on sunxi-based systems
By default partman calls ped_disk_clobber when writing the
partition table, but on sunxi-based systems this would overwrite
the firmware area, resulting in an unbootable system (see
bug #751704). Handle this as a special case in command_commit().
---
parted_server.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/parted_server.c b/parted_server.c
index 55cf151..bc4523a 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -1330,6 +1330,25 @@ command_dump()
oprintf("OK\n");
}
+/* Check whether we are running on a sunxi-based system. */
+int
+is_sunxi_system()
+{
+int cpuinfo_handle;
+int result=0;
+char buf[4096];
+int length;
+
+if ((cpuinfo_handle = open("/proc/cpuinfo", O_RDONLY)) != -1 ) {
+length = read(cpuinfo_handle, buf, sizeof(buf)-1);
+buf[length]='\0';
+if (strstr(buf,"Allwinner")!=NULL)
+result=1;
+close(cpuinfo_handle);
+}
+return result;
+}
+
void
command_commit()
{
@@ -1337,6 +1356,21 @@ command_commit()
if (dev == NULL)
critical_error("The device %s is not opened.", device_name);
log("command_commit()");
+
+/*
+ * The boot device on sunxi-based systems needs special handling.
+ * By default partman calls ped_disk_clobber when writing the
+ * partition table, but on sunxi-based systems this would overwrite
+ * the firmware area, resulting in an unbootable system (see
+ * bug #751704).
+ */
+if (is_sunxi_system() && !strcmp(disk->dev->path, "/dev/mmcblk0")) {
+disk->needs_clobber=0;
+log("Sunxi platform detected. Disabling ped_disk_clobber " \
+"for the boot device %s to protect the firmware " \
+"area.", disk->dev->path);
+}
+
open_out();
if (disk != NULL && named_is_changed(device_name))
ped_disk_commit(disk);
--
2.1.0.rc1
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140812223858.ga9...@excalibur.cnev.de
Bug#751704: libparted questions (was: Bug#751704: partman-base 173: partman overwrites parts of u-boot)
[CCing Otavio Salvador and Jim Meyering; the following is a short summary of the situation; the full history can be read in bug #751704: Debian-Installer uses partman for partitioning, which in turn is based on libparted. On sunxi-based systems, upon writing the partition table, partman/libparted overwrites parts of u-boot which are located between the end of the partition table and the beginning of the first partition which results in an unbootable system. An attempt to solve this problem has been to conditionally set PedDisk.needs_clobber to 0 in partman when it detects that it is trying to write to a boot device on sunxi-based systems.] Colin Watson wrote: > PedDisk.needs_clobber is marked as "office use only" in parted; I > interpret that as meaning that it really shouldn't be fiddled with > outside parted, even though it's technically exposed. Could you please > look at fixing parted to avoid clobbering the firmware area instead? I > think that would be more correct. I have no idea what is really meant with the comment /* office use only ;-) */ int needs_clobber; in /usr/include/parted/disk.h, so I would like to ask upstream for clarification. Otavio, Jim: you are listed as parted upstream maintainers on http://www.gnu.org/software/parted/ - could you shed some light on this? Is it ok for an application to fiddle with the needs_clobber element or is this to be considered strictly libparted-internal? @Colin: If the solution is to be completely encapsulated in libparted, I see a large problem in how to solve the conflict between space after the partition table being very differently used by firmware for different SoCs on one side, and libparted trying to make sure that there are no remains of other partition table formats in the respective area on the other side - at least with the prerequisite of keeping both the current defaults (clobbering) as well as keeping the libparted API unchanged. With the current "there is one erase size for all platforms" method in ped_disk_clobber() in libparted/disk.c, we inevitably end up with conflicting requirements. An example: the source for ped_disk_clobber() states: /* How many sectors to zero out at each end. This must be large enough to zero out the magic bytes starting at offset 8KiB on a DASD partition table. Doing the same from the end of the disk is probably overkill, but at least on GPT, we do need to zero out the final sector. */ So for at least one platform (according to Wikipedia DASD seems to be some s/390 format), the area at offset 8KiB has to be wiped out while for another (armhf/sunxi) it may not be wiped out as the u-boot SPL is located there and cannot be relocated because its sector address is hardcoded in the SoC. According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#25, similar problems (but at other offsets) come up for other SoCs. According to the examples listed there, for TI SoCs libparted would have to stop clobbering the GPT header after writing a DOS MBR, but could wipe the DASD area. For a Freescale i.MX SoC libparted could legally clobber the GPT header, but would have to refrain from clobbering the areas behind it. If you extrapolate this to the large number of different SoC families, to handle this completely inside libparted, the library would have to know what exactly is the target system for which it writes a partition table and special-case the handling for each of them. While one might assume that the partition table is for an s/390 system when a DASD partition table is generated, this does not work as easily for the plethora of different architectures and systems that use DOS MBR partition tables. This gets even more complicated by the fact that libparted may run on one platform but modify partition tables for another platform, such as when operating on disk images for use with emulators or when operating on hd-media images for different arm platforms (with different firmware/bootloader requirements) on one autobuild host, so trying to do runtime detection of the host system would still not cover all use cases. In the case of creating images from scratch, the problem can be circumvented by (re-)writing the bootloader at the end of the process, but when the task is to modify existing images with unknown content, this workaround is not available. As a conclusion, I think that the decision whether to clobber the area between the partition table and the beginning of the first partition has to be taken by the calling application and not internally by the library. Kind Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas
Bug#751704: libparted ped_disk_clobber() overwrites firmware on some arm systems
Hello, the following is a discussion from the Debian bugtracking system regarding Debian Bug#751704 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704). It needs involvement from parted upstream, therefore I am forwarding it to bug-par...@gnu.org. Kind regards, Karsten - Forwarded message from Jim Meyering - Date: Sun, 17 Aug 2014 14:51:41 -0700 From: Jim Meyering Subject: Bug#751704: libparted questions (was: Bug#751704: partman-base 173: partman overwrites parts of u-boot) On Wed, Aug 13, 2014 at 12:07 PM, Karsten Merker wrote: > [CCing Otavio Salvador and Jim Meyering; the following is a short summary > of the situation; the full history can be read in bug #751704: > > Debian-Installer uses partman for partitioning, which in turn is > based on libparted. On sunxi-based systems, upon writing the partition > table, partman/libparted overwrites parts of u-boot which are > located between the end of the partition table and the beginning of the > first partition which results in an unbootable system. > An attempt to solve this problem has been to conditionally set > PedDisk.needs_clobber to 0 in partman when it detects that it is > trying to write to a boot device on sunxi-based systems.] > > Colin Watson wrote: >> PedDisk.needs_clobber is marked as "office use only" in parted; I >> interpret that as meaning that it really shouldn't be fiddled with >> outside parted, even though it's technically exposed. Could you please >> look at fixing parted to avoid clobbering the firmware area instead? I >> think that would be more correct. > > I have no idea what is really meant with the comment > > /* office use only ;-) */ > int needs_clobber; > > in /usr/include/parted/disk.h, so I would like to ask upstream > for clarification. Otavio, Jim: you are listed as parted > upstream maintainers on http://www.gnu.org/software/parted/ - could > you shed some light on this? Is it ok for an application to fiddle > with the needs_clobber element or is this to be considered > strictly libparted-internal? > > > @Colin: If the solution is to be completely encapsulated in > libparted, I see a large problem in how to solve the conflict between > space after the partition table being very differently used by > firmware for different SoCs on one side, and libparted trying to make > sure that there are no remains of other partition table formats in > the respective area on the other side - at least with the > prerequisite of keeping both the current defaults (clobbering) as > well as keeping the libparted API unchanged. With the current "there > is one erase size for all platforms" method in ped_disk_clobber() in > libparted/disk.c, we inevitably end up with conflicting requirements. > An example: the source for ped_disk_clobber() states: > > /* How many sectors to zero out at each end. >This must be large enough to zero out the magic bytes >starting at offset 8KiB on a DASD partition table. >Doing the same from the end of the disk is probably >overkill, but at least on GPT, we do need to zero out >the final sector. */ > > So for at least one platform (according to Wikipedia DASD seems to be > some s/390 format), the area at offset 8KiB has to be wiped out while > for another (armhf/sunxi) it may not be wiped out as the u-boot SPL is > located there and cannot be relocated because its sector address is > hardcoded in the SoC. > > According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#25, > similar problems (but at other offsets) come up for other SoCs. > According to the examples listed there, for TI SoCs libparted would > have to stop clobbering the GPT header after writing a DOS MBR, but > could wipe the DASD area. For a Freescale i.MX SoC libparted could > legally clobber the GPT header, but would have to refrain from > clobbering the areas behind it. If you extrapolate this to the large > number of different SoC families, to handle this completely inside > libparted, the library would have to know what exactly is the target > system for which it writes a partition table and special-case the > handling for each of them. While one might assume that the partition > table is for an s/390 system when a DASD partition table is > generated, this does not work as easily for the plethora of different > architectures and systems that use DOS MBR partition tables. This > gets even more complicated by the fact that libparted may run on one > platform but modify partition tables for another platform, such as > when operating on disk images for use with emulators or when > operating on hd-media images for differen
Bug#751704: bug#18289: libparted ped_disk_clobber() overwrites firmware on some arm systems
On Mon, Aug 18, 2014 at 09:59:49AM -0700, Brian C. Lane wrote: > On Mon, Aug 18, 2014 at 08:19:17AM +0200, Karsten Merker wrote: > > Hello, > > > > the following is a discussion from the Debian bugtracking system regarding > > Debian Bug#751704 > > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704). > > It needs involvement from parted upstream, therefore I am forwarding it to > > bug-par...@gnu.org. > > Thanks for forwarding this. parted should only be clobbering these extra > sectors when a new disklabel is applied (eg. mklabel in the ui) which, I > think, is the appropriate thing to do. > > If you are operating on an existing disklabel and want to preserver a > boot loader in the space before the 1st partition you shouldn't be > calling ped_disk_new_fresh(). If you are creating a new disklabel then > any boot loader code should be installed after partitioning. > > I don't think parted needs any changes. Hello, thanks for your swift reply. I fully understand your position, but unfortunately things on arm are fundamentally different from the PC world. U-Boot is more of a BIOS than a bootloader like GRUB; it is highly board specific and handles low-level stuff such as setting the IO pinmuxing for the specific board and configuring the DRAM controller. Without it, the board is completely dead from a user perspective. On a PC, the BIOS is always available in ROM/Flash even when all disk devices have been wiped and the user can still select some other device (such as the network, a CDROM drive or a USB memory stick) to boot from. On the arm systems we are talking about, there is no ROM BIOS and the u-boot image on the SD card (or on an eMMC chip) is the only way to interact with the system at all. The usual case is that the u-boot image is written raw onto the storage medium, i.e. there is no partition table or filesystem on it by default, so we need to create a new disklabel in the installer. You are fully right that normally a bootloader should be installed after partitioning. This works well for the case of a bootloader that uses universally available BIOS functions and is not hardware-specific, such as is the case on PCs. In the case of u-boot on the other hand, in PC-lingo we would have to provide the installer with the ability to flash the BIOS for every PC model on the market as part of the operating system installation, which is not feasible. We might be able to do that for a small selection of devices, but not for all of them --> we need to keep the u-boot image that is on the device even when creating a new disklabel, but we are unsure what is the best way to handle this. The approach in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#60 (setting PedDisk.needs_clobber to 0 before calling ped_disk_commit for specific devices) works in practice, but the question was whether it is ok for the calling application to fiddle around with the needs_clobber flag, or whether we should take some other approach. Kind Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818200759.ga4...@excalibur.cnev.de
Bug#751704: libparted ped_disk_clobber() overwrites firmware on some arm systems
Hello,
as libparted upstream has now confirmed that modifying
PedDisk.needs_clobber from within the calling application is
ok, I would like to apply the following patch to partman-base
unless somebody has further objections against it.
Functionally it is the same patch that I had posted earlier
already, just with some coding style cleanups.
Regards,
Karsten
>From bd3e4f79ea620fefb48c768dec22a3f7d1ad31a2 Mon Sep 17 00:00:00 2001
From: Karsten Merker
Date: Thu, 28 Aug 2014 20:38:12 +0200
Subject: [PATCH] Take care of the firmware area on sunxi-based systems
By default partman calls ped_disk_clobber when writing a new
partition table, but on the MMC device of sunxi-based systems this
would overwrite the firmware area, resulting in an unbootable system
(see bug #751704). Handle this as a special case in command_commit().
---
parted_server.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/parted_server.c b/parted_server.c
index 55cf151..a6283f6 100644
--- a/parted_server.c
+++ b/parted_server.c
@@ -1330,6 +1330,25 @@ command_dump()
oprintf("OK\n");
}
+/* Check whether we are running on a sunxi-based system. */
+int
+is_sunxi_system()
+{
+int cpuinfo_handle;
+int result = 0;
+char buf[4096];
+int length;
+
+if ((cpuinfo_handle = open("/proc/cpuinfo", O_RDONLY)) != -1) {
+length = read(cpuinfo_handle, buf, sizeof(buf)-1);
+buf[length]='\0';
+if (strstr(buf, "Allwinner") != NULL)
+result = 1;
+close(cpuinfo_handle);
+}
+return result;
+}
+
void
command_commit()
{
@@ -1337,6 +1356,20 @@ command_commit()
if (dev == NULL)
critical_error("The device %s is not opened.", device_name);
log("command_commit()");
+
+/* The boot device on sunxi-based systems needs special handling.
+ * By default partman calls ped_disk_clobber when writing the
+ * partition table, but on sunxi-based systems this would overwrite
+ * the firmware area, resulting in an unbootable system (see
+ * bug #751704).
+ */
+if (is_sunxi_system() && !strcmp(disk->dev->path, "/dev/mmcblk0")) {
+disk->needs_clobber = 0;
+log("Sunxi platform detected. Disabling ped_disk_clobber " \
+"for the boot device %s to protect the firmware " \
+"area.", disk->dev->path);
+}
+
open_out();
if (disk != NULL && named_is_changed(device_name))
ped_disk_commit(disk);
--
2.1.0
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140828203143.ga6...@excalibur.cnev.de
Bug#751704: libparted ped_disk_clobber() overwrites firmware on some arm systems
Control: tags -1 pending thanks On Thu, Aug 28, 2014 at 10:31:43PM +0200, Karsten Merker wrote: > as libparted upstream has now confirmed that modifying > PedDisk.needs_clobber from within the calling application is > ok, I would like to apply the following patch to partman-base > unless somebody has further objections against it. > > Functionally it is the same patch that I had posted earlier > already, just with some coding style cleanups. The patch has been committed to the partman-base git repository. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140830083019.ga31...@excalibur.cnev.de
Bug#761514: [armhf/sunxi] [d-i daily 20140914] Cubietruck installation report (installation to MMC)
Package: installation-reports Boot method: netboot Image version: http://d-i.debian.org/daily-images/armhf/daily/netboot/ dated 2014-09-14 05:17 Install Date: 2014-09-14 Machine: Cubietech Cubietruck Processor: Allwinner A20 (2x Cortex A7) Memory:2GB U-boot:u-boot 2014.10~rc2+dfsg1-1 from experimental Console: serial console Partitions (SD card): /dev/mmcblk0p1 ext2240972 10175218356 5% /boot /dev/mmcblk0p2 ext4 14136820 802108 12593544 6% / Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments: - The installation was done in expert mode (debconf priority medium). - I selected Sid instead of Jessie as target suite as kernel 3.16 (required for installation on MMC) has not yet migrated to Jessie. - Partitioning was done using the "guided partitioning" option. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140914141942.ga4...@excalibur.cnev.de
Bug#761514: [armhf/sunxi] [d-i daily 20140914] Cubietruck installation report (installation to MMC)
On Sun, Sep 14, 2014 at 05:25:57PM +0200, Cyril Brulebois wrote: > Karsten Merker (2014-09-14): > > U-boot:u-boot 2014.10~rc2+dfsg1-1 from experimental > > [...] > > > Comments: > > - The installation was done in expert mode (debconf priority medium). > > - I selected Sid instead of Jessie as target suite as kernel 3.16 > > (required for installation on MMC) has not yet migrated to Jessie. > > - Partitioning was done using the "guided partitioning" option. > > I see you also need u-boot from experimental; I'm not sure it'll reach > sid + testing in time for the next release. Are you in touch with its > maintainer/do you his short term plans? [CCing Vagrant Cascadian (Debian u-boot package maintainer) and Ian Campbell (mainline u-boot sunxi platform custodian)] U-Boot v2014.10 is scheduled to be released on Oct 13, 2014. Vagrant is tracking the rc releases in experimental and the plan is to get the final u-boot v2014.10 into unstable as soon as it is released. That is a tight schedule, but I think it is feasible. The mainline u-boot version currently in jessie (2014.07+dfsg1-1) has only very limited sunxi platform support. It works on the Cubietruck, but does not support several other sunxi-based systems for which we have support in d-i, so we are very strongly interested in getting v2014.10 into Jessie. D-i can also work with older u-boot-sunxi versions that are supplied by some board vendors (flash-kernel takes explicit care in the boot scripts it creates to handle this properly), but those older versions do not have the full featureset that mainline u-boot v2014.10 provides. The two major features missing in the vendor-supplied versions are - PSCI support, without which there is no SMP, i.e. the kernel can only initalize the first CPU core - AHCI support, i.e. booting from SATA harddisk is not possible. So using old u-boot-sunxi versions instead of current mainline is technically possible, but from a user point of view really undesireable. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140914162537.ge4...@excalibur.cnev.de
Bug#762253: Tasksel 3.25: fails due to wrong apt invocation (missing "-o" in front of additional apt option)
Package: tasksel Version: 3.25 Severity: grave Justification: breaks d-i Hello, the upload of tasksel 3.25 has broken tasksel in d-i: Sep 20 06:04:28 pkgsel: starting tasksel Sep 20 06:04:56 in-target: E Sep 20 06:04:56 in-target: : Sep 20 06:04:56 in-target: Invalid operation APT::Acquire::Retries=3 Sep 20 06:04:56 in-target: Sep 20 06:04:56 in-target: tasksel: apt-get failed (100) Sep 20 06:04:57 main-menu[190]: WARNING **: Configuring 'pkgsel' failed with error code 1 Sep 20 06:04:57 main-menu[190]: WARNING **: Menu item 'pkgsel' failed. This is caused by the following commit: http://anonscm.debian.org/cgit/tasksel/tasksel.git/commit/?id=645455083756a71f1843c3deebdb73bc6324c66a where a "-o" is missing before the added "APT::Acquire::Retries=3". Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140920062231.gb4...@excalibur.cnev.de
Re: installation-guide is marked for autoremoval from testing
Control: reassign -1 www.debian.org Control: severity -1 normal thanks On Sun, Oct 12, 2014 at 04:39:03AM +, Debian testing autoremoval watch wrote: > installation-guide 20140916 is marked for autoremoval from testing on > 2014-10-26 > > It is affected by these RC bugs: > 763005: installation-guide-amd64: website for wheezy leads to jessie > installation guide >From looking at the bug report this has not actually been a bug in the installation-guide package, but a problem in the cron job that puts the installtion guide onto the website, so this should not result in a package removal from testing. The cron job has been manually fixed up, so the actual problem (wrong version of the guide on the website) does not occur anymore at the moment. What is still open is how to change the cronjob to handle this better/automatically in the future, but that IMHO does not justify an RC bug against the manual itself. I therefore assign this bug to www.debian.org and lower the severity to normal. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012053801.ga4...@excalibur.cnev.de
Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
Package: installation-reports Boot method: hd-media (installer booted from USB stick) Image version: http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz (dated 27-Oct-2014 05:17) together with http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo (dated 2014-10-27 11:58) Date: 2014-10-27 U-Boot: 2014.10+dfsg1-1 Machine: LeMaker Banana Pi Processor: Allwinner A20 (2x Cortex A7) Memory: 1GB Mass Storage: 16GB SD card Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] (see comments below, getting this to work requires manual loading of the proper ethernet PHY driver module) Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: The "detect network hardware" step fails with "No Ethernet card was detected. If you know the name of the driver needed by your Ethernet card, you can select it from the list." dmesg shows: [ 73.100072] stmmaceth 1c5.ethernet: no reset control found [ 73.100103] Ring mode enabled [ 73.100112] No HW DMA feature register supported [ 73.100120] Normal descriptors [ 73.100127] TX Checksum insertion supported [ 73.104782] libphy: stmmac: probed [ 73.104812] eth0: No PHY found i.e. the correct ethernet MAC driver (stmmac) gets loaded automatically, but the necessary PHY driver (realtek) does not. Loading the realtek module after the stmmac driver has probed for a PHY does not change anything; the stmmac driver does not re-probe for a PHY upon later loading of the PHY driver. Manually unloading the stmmac module, loading the PHY driver and then loading the stmmac module again from a shell by running ~ # rmmod stmmac ~ # modprobe realtek ~ # modprobe stmmac results in [ 499.364044] stmmaceth 1c5.ethernet: no reset control found [ 499.364076] Ring mode enabled [ 499.364084] No HW DMA feature register supported [ 499.364090] Normal descriptors [ 499.364097] TX Checksum insertion supported [ 499.392561] libphy: stmmac: probed [ 499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) and the ethernet interface works. The kernel version used in this installer build is 3.16.5-1. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141027213800.ga11...@excalibur.cnev.de
Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Mon, Oct 27, 2014 at 11:54:47PM +, Ben Hutchings wrote: > On Tue, 2014-10-28 at 00:18 +0100, Cyril Brulebois wrote: > > Cc+=debian-kernel@ for input since I seem to recall having seen PHY > > drivers (including in a realtek context) being mentioned lately, at > > least on IRC, maybe on list as well. > > I don't understand this. > > > Karsten Merker (2014-10-27): > [...] > > > [ 73.104782] libphy: stmmac: probed > > > [ 73.104812] eth0: No PHY found > > > > > > i.e. the correct ethernet MAC driver (stmmac) gets loaded > > > automatically, but the necessary PHY driver (realtek) does not. > [...] > > > [ 499.392561] libphy: stmmac: probed > > > [ 499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active > > > [ 499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) > > > > > > and the ethernet interface works. The kernel version used in this > > > installer build is 3.16.5-1. > > $ modinfo -F alias realtek > mdio:???111001100100100010101 > mdio:???111001100100100010010 > > In hex those are 1cc915 and 1cc912. (The 11 most significant bits are > unspecified.) So modprobe certainly should find this module when > requested by phylib. I have retried the installation today and tried something I had not done yesterday: just rmmod and directly afterwards modprobe the stmmac module. This results in the realtek PHY module getting auto-loaded, so the modprobe mechanism seems to work correctly there, but the question remains why this does not happen upon the first loading of the stmmac module. A protocol from d-i: "No Ethernet card was detected. If you know the name of the driver needed by your Ethernet card, you can select it from the list." --> start shell ~ # lsmod Module Size Used by stmmac 73442 0 nls_utf81170 2 nls_cp437 4767 1 loop 16202 2 isofs 31318 1 vfat9621 1 fat52693 1 vfat ext4 485433 0 crc16 1146 1 ext4 mbcache 8210 1 ext4 jbd2 88199 1 ext4 sg 20824 0 sd_mod 38535 2 crc_t10dif 1041 1 sd_mod crct10dif_common1159 1 crc_t10dif usb_storage41751 1 ahci_sunxi 2652 0 libahci_platform4679 1 ahci_sunxi libahci23069 1 libahci_platform libata161761 3 libahci,libahci_platform,ahci_sunxi ohci_platform 4062 0 ohci_hcd 37591 1 ohci_platform scsi_mod 175644 4 sg,usb_storage,libata,sd_mod ehci_platform 4526 0 phy_sun4i_usb 4216 4 ehci_hcd 64373 1 ehci_platform sunxi_mmc 10557 0 ~ # dmesg | tail -8 [ 31.558145] ISO 9660 Extensions: RRIP_1991A [ 77.839161] stmmaceth 1c5.ethernet: no reset control found [ 77.839194] Ring mode enabled [ 77.839202] No HW DMA feature register supported [ 77.839210] Normal descriptors [ 77.839217] TX Checksum insertion supported [ 77.844560] libphy: stmmac: probed [ 77.844589] eth0: No PHY found ~ # rmmod stmmac ~ # modprobe stmmac ~ # dmesg | tail -8 [ 330.112850] stmmaceth 1c5.ethernet: no reset control found [ 330.112883] Ring mode enabled [ 330.112891] No HW DMA feature register supported [ 330.112898] Normal descriptors [ 330.112905] TX Checksum insertion supported [ 330.140101] libphy: stmmac: probed [ 330.140139] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 330.140150] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) ~ # lsmod Module Size Used by realtek 1563 0 stmmac 73442 0 nls_utf81170 2 nls_cp437 4767 1 loop 16202 2 isofs 31318 1 vfat9621 1 fat52693 1 vfat ext4 485433 0 crc16 1146 1 ext4 mbcache 8210 1 ext4 jbd2 88199 1 ext4 sg 20824 0 sd_mod 38535 2 crc_t10dif 1041 1 sd_mod crct10dif_common1159 1 crc_t10dif usb_storage41751 1 ahci_sunxi 2652 0 libahci_platform4679 1 ahci_sunxi libahci23069 1 libahci_platform libata161761 3 libahci,libahci_platform,ahci_sunxi ohci_platform 4062 0 ohci_hcd 37591 1 ohci_platform scsi_mod 175644 4 sg,usb_storage,libata,sd_mod ehci_platform 4526 0 phy_sun4i_usb 4216 4 ehci_hcd 64373 1 ehci_platform sunxi_mmc 10557 0 > As udev is *not* involved in loading MDIO PHY driv
Re: [PATCH V2] d-i hd-media support for armhf
On Sat, Nov 01, 2014 at 12:06:55AM -0700, Vagrant Cascadian wrote:
[d-i hd-media support for armhf, boot script]
> Overall, it appears to be working quite well. I've thought about
> creating a similar bootscript for the netboot images.
>
> > +if test -n "${console}"; then
> > + setenv bootargs "${bootargs} console=${console}"
> > +fi
>
> It would seem that the console variable isn't consistant across u-boot
> platforms. On some (sunxi) it sets both the device and the baudrate
> (i.e. console=ttyS0,115200), but on many other platforms console only
> sets the device (i.e. console=ttyS0) and linux then reverts to 9600
> baud. But the u-boot baudrate is often 115200 with u-boot itself, and
> set in a baudrate variable. It doesn't seem possible to set a sane
> default...
>
> So basically this "generic" boot script only works with platforms where
> the baudrate is included in the "console" variable (or where the
> baudrate defaults to 9600, to match linux's default, though I think most
> of the armhf platforms at least default to 115200). *sigh*
>
> Not sure if u-boot's shell has the ability to match contents of
> variables, so the baudrate could be conditionally added only if not
> already present.
AFAICS there is no such functionality in u-boot's commandline
parser. Ian, do you perhaps have an idea how to implement this
in a u-boot script? Unfortunately the existence of a ${baudrate}
variable is independent from whether ${console} has the baudrate
encoded into it or not, so just checking for the existence of
${baudrate} does not help in this case.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102143335.ga5...@excalibur.cnev.de
Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Tue, Oct 28, 2014 at 11:14:40PM +0100, Karsten Merker wrote: > On Mon, Oct 27, 2014 at 11:54:47PM +, Ben Hutchings wrote: > > I don't understand this. > > > > > Karsten Merker (2014-10-27): > > [...] > > > > [ 73.104782] libphy: stmmac: probed > > > > [ 73.104812] eth0: No PHY found > > > > > > > > i.e. the correct ethernet MAC driver (stmmac) gets loaded > > > > automatically, but the necessary PHY driver (realtek) does not. > > [...] > > > > [ 499.392561] libphy: stmmac: probed > > > > [ 499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active > > > > [ 499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) > > > > > > > > and the ethernet interface works. The kernel version used in this > > > > installer build is 3.16.5-1. > > > > $ modinfo -F alias realtek > > mdio:???111001100100100010101 > > mdio:???111001100100100010010 > > > > In hex those are 1cc915 and 1cc912. (The 11 most significant bits are > > unspecified.) So modprobe certainly should find this module when > > requested by phylib. > > I have retried the installation today and tried something I had > not done yesterday: just rmmod and directly afterwards modprobe > the stmmac module. This results in the realtek PHY module > getting auto-loaded, so the modprobe mechanism seems to work > correctly there, but the question remains why this does not > happen upon the first loading of the stmmac module. > > A protocol from d-i: > > "No Ethernet card was detected. If you know the name of the driver > needed by your Ethernet card, you can select it from the list." > > --> start shell > > ~ # lsmod > Module Size Used by > stmmac 73442 0 > nls_utf81170 2 > nls_cp437 4767 1 > loop 16202 2 > isofs 31318 1 > vfat9621 1 > fat52693 1 vfat > ext4 485433 0 > crc16 1146 1 ext4 > mbcache 8210 1 ext4 > jbd2 88199 1 ext4 > sg 20824 0 > sd_mod 38535 2 > crc_t10dif 1041 1 sd_mod > crct10dif_common1159 1 crc_t10dif > usb_storage41751 1 > ahci_sunxi 2652 0 > libahci_platform4679 1 ahci_sunxi > libahci23069 1 libahci_platform > libata161761 3 libahci,libahci_platform,ahci_sunxi > ohci_platform 4062 0 > ohci_hcd 37591 1 ohci_platform > scsi_mod 175644 4 sg,usb_storage,libata,sd_mod > ehci_platform 4526 0 > phy_sun4i_usb 4216 4 > ehci_hcd 64373 1 ehci_platform > sunxi_mmc 10557 0 > ~ # dmesg | tail -8 > [ 31.558145] ISO 9660 Extensions: RRIP_1991A > [ 77.839161] stmmaceth 1c5.ethernet: no reset control found > [ 77.839194] Ring mode enabled > [ 77.839202] No HW DMA feature register supported > [ 77.839210] Normal descriptors > [ 77.839217] TX Checksum insertion supported > [ 77.844560] libphy: stmmac: probed > [ 77.844589] eth0: No PHY found > ~ # rmmod stmmac > ~ # modprobe stmmac > ~ # dmesg | tail -8 > [ 330.112850] stmmaceth 1c5.ethernet: no reset control found > [ 330.112883] Ring mode enabled > [ 330.112891] No HW DMA feature register supported > [ 330.112898] Normal descriptors > [ 330.112905] TX Checksum insertion supported > [ 330.140101] libphy: stmmac: probed > [ 330.140139] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active > [ 330.140150] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) > ~ # lsmod > Module Size Used by > realtek 1563 0 > stmmac 73442 0 > nls_utf81170 2 > nls_cp437 4767 1 > loop 16202 2 > isofs 31318 1 > vfat9621 1 > fat52693 1 vfat > ext4 485433 0 > crc16 1146 1 ext4 > mbcache 8210 1 ext4 > jbd2 88199 1 ext4 > sg 20824 0 > sd_mod 38535 2 > crc_t10dif 1041 1 sd_mod > crct10dif_common1159 1 crc_t10dif > usb_storage41751 1 > ahci_sunxi 2652 0 > libahci_platform4679 1 ahci_sunxi > libahci23069 1 libahci_platform > libata161761 3 libahci,libahci_platform,a
Bug#769728: [jessie daily 2014-11-15] installation-report: regression when deselecting the "standard system utilities" task
Package: installation-reports Boot method: netboot Image version: http://d-i.debian.org/daily-images/armhf/daily/netboot/ dated 15-Nov-2014 05:25 Date: 2014-11-15 Machine: Cubietech Cubietruck Processor: Allwinner A20 (2x Cortex A7) Memory: 2GB Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: The installation itself works flawlessly, but when installing a minimal system by deselecting "standard system utilities" in tasksel, on booting the installed system the systemd error message "[FAILED] Failed to start Login Service" gets shown several times. "systemctl status -l systemd-logind.service" results in: -8<--8<--8<--8<--8<--8<- systemd-logind.service - Login Service Loaded: loaded (/lib/systemd/system/systemd-logind.service; static) Active: failed (Result: start-limit) since Sat 2014-11-15 22:21:56 CET; 1min 13s ago Docs: man:systemd-logind.service(8) man:logind.conf(5) http://www.freedesktop.org/wiki/Software/systemd/logind http://www.freedesktop.org/wiki/Software/systemd/multiseat Process: 273 ExecStart=/lib/systemd/systemd-logind (code=exited, status=1/FAILURE) Main PID: 273 (code=exited, status=1/FAILURE) Status: "Shutting down..." Nov 15 22:21:56 debian systemd[1]: Failed to start Login Service. Nov 15 22:21:56 debian systemd[1]: Unit systemd-logind.service entered failed state. Nov 15 22:21:56 debian systemd[1]: systemd-logind.service has no holdoff time, scheduling restart. Nov 15 22:21:56 debian systemd[1]: Stopping Login Service... Nov 15 22:21:56 debian systemd[1]: Starting Login Service... Nov 15 22:21:56 debian systemd[1]: systemd-logind.service start request repeated too quickly, refusing to start. Nov 15 22:21:56 debian systemd[1]: Failed to start Login Service. Nov 15 22:21:56 debian systemd[1]: Unit systemd-logind.service entered failed state. -8<--8<--8<--8<--8<--8<- When "standard system utilities" is selected in tasksel, the problem does not occur. Deselecting "standard system utilities" did not have any negatve effect on the boot process when d-i still installed SysV-init as the default init system, so this is a regression. Following is a full boot log of an installation with "standard system utilities" deselected in tasksel: -8<--8<--8<--8<--8<--8<- Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.16.0-4-armmp-lpae (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06) [0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=30c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Cubietech Cubietruck [0.00] Forcing write-allocate cache policy for SMP [0.00] Memory policy: Data cache writealloc [0.00] psci: probing for conduit method from DT. [0.00] psci: Using PSCI v0.1 Function IDs from DT [0.00] PERCPU: Embedded 9 pages/cpu @ee7cc000 s13248 r8192 d15424 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522768 [0.00] Kernel command line: console=ttyS0,115200 console=ttyS0,115200 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 2057220K/2097152K available (6558K kernel code, 837K rwdata, 2208K rodata, 700K init, 396K bss, 39932K reserved, 1318912K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xffe0 (2048 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc0897da0 (8768 kB) [0.00] .init : 0xc0898000 - 0xc09473c0 ( 701 kB) [0.00] .data : 0xc0948000 - 0xc0a197f8 ( 838 kB) [0.00].bss : 0xc0a197f8 - 0x
Debian-Installer support for riscv64
[crossposted to debian-boot and debian-riscv] Hello everybody, I'm working on getting d-i support for riscv64 into a useable state. With the recent upload of elfutils 0.176-1.1 into the archive it is now possible to complete the "install the base system" step on riscv64. What is still missing is bootloader support, for which there are two general options on riscv64: - plain U-Boot - EFI GRUB, either - loaded directly from an EDKII-based EFI firmware or - chainloaded from U-Boot's EFI emulation layer In the long run, we will surely see EFI on riscv64, but right now there is no riscv64 hardware that ships with an EDKII-based EFI firmware, the kernel still lacks EFI stub support on riscv64 and AFAIK some riscv64-related bits in the U-Boot EFI emulation layer and in EFI GRUB are also still missing, so to have something usable now, we need to target plain U-Boot first. When booting from plain U-Boot we have two options: - boot scripts - extlinux.conf-style boot menus Boot scripts can be handled with small modifications to the flash-kernel package that we currently use for arm-based systems; a proof-of-concept is available at https://salsa.debian.org/merker/flash-kernel/tree/riscv64-support but IMHO extlinux-style boot menus are a lot nicer than the interface provided by flash-kernel. There are good reasons why flash-kernel uses boot scripts on arm-based systems, but most of them have their roots in the historic lack of standardized boot environments on arm-based platforms and Debian's attempts at providing compatibility with old vendor U-Boot releases, which is a problem that we thankfully don't have on riscv64 so that I would clearly prefer using extlinux-style U-Boot menus on riscv64 (Fedora has AFAIK taken the same decision). I have therefore made an attempt at implementing a u-boot-menu-installer udeb: https://salsa.debian.org/merker/u-boot-menu-installer Unfortunately both EFI support as well as the U-Boot extlinux-style menus require a small change in the configuration of our riscv64 kernel packages. A corresponding change request has been sent to the kernel maintainers, but for now testing the new udeb requires manually installing a modified kernel package. One problem that I have stumbled about is the combination of U-Boot's distro_bootcmd environment and GPT-partitioned disks. Currently d-i autogenerates GPT-style partition tables for riscv64 and while things work without problems with DOS-style partition tables, U-Boot doesn't find the partition to boot from automatically on a GPT-partitioned disk. The logic used by U-Boot is "if there is a partition marked as bootable, boot from it, otherwise check the first partition on the disk for a menu file or a boot script", which works fine for DOS-style partition tables where d-i marks the partition used for /boot as "bootable" and /boot is usually on the first partition anyway. With GPT this fails because there is AFAICS no "bootable" flag for partitions and the first partition that d-i creates for GPT-partitioned disks is the "BIOS GRUB" partition and not the volume containing /boot. If one tells U-Boot the boot partition number manually with "setenv distro_bootpart 2", everything works. When performing an EFI boot, the bootloader is always loaded from the EFI system partition which can be easily identified by its UUID, so this never poses a problem for EFI-based systems, and going back to DOS-style partition tables isn't really an option with today's hard disk sizes and the 2GB-limit inherent in the DOS-style partition table format. Ideas how to solve this welcome - the only approach I currently see is to change U-Boot's distro_bootcmd logic to check each and every partition, but I'm not sure that upstream would like that. Kibi, a question regarding the handling of the the u-boot-menu-installer package: As it only contains shell scripts, in conformance with normal policy rules I have marked it as an arch-all package that limits its execution to riscv64 with an "isinstallable" file, but AIUI that would mean that it would potentially be pulled in by d-i builds for other architectures, although it wouldn't be executed there. Should I make a riscv64-specific package out of it due to potential d-i image size issues on armel? Another thing that needs to be tackled in d-i is an annoying property of qemu's riscv64 "virt" machine: The "virt" machine emulates both a normal serial console (/dev/ttyS0) and a HVC console (/dev/ttyhvc0). Unfortunately in qemu both share the same physical console device and systemd starts a getty on both /dev/ttyS0 and /dev/ttyhvc0 so that we have two getty instances running on the same physical console which wreks havoc. I would therefore like to add a job to finish-install that tells systemd to run no getty on dev/ttyhvc0 by creating a symlink from /etc/systemd/system/serial-getty@hvc0.service to /dev/null inside /target if it detects that it is run on a qemu riscv64 "virt" machine. Would that be
Bug#895934: [PATCH 1/1] flash-kernel: add Rockchip RK3288 Tinker Board
Control: tag 895934 pending On Tue, Apr 17, 2018 at 05:41:51PM +0200, Heinrich Schuchardt wrote: > Package: flash-kernel > Version: 3.94 > Severity: wishlist > Tags: patch > > Add database entry for the Tinker Board. > > Signed-off-by: Heinrich Schuchardt > --- > db/all.db | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/db/all.db b/db/all.db > index 28d40b1..ff92e17 100644 > --- a/db/all.db > +++ b/db/all.db > @@ -412,6 +412,13 @@ Boot-Script-Path: /boot/boot.scr > U-Boot-Script-Name: bootscr.uboot-generic > Required-Packages: u-boot-tools > > +Machine: Rockchip RK3288 Tinker Board > +Kernel-Flavors: armp armmp-lpae > +DTB-Id: rk3288-tinker.dtb > +Boot-Script-Path: /boot/boot.scr > +U-Boot-Script-Name: bootscr.uboot-generic > +Required-Packages: u-boot-tools > + > Machine: Firefly-RK3399 Board > Kernel-Flavors: arm64 > DTB-Id: rk3399-firefly.dtb Hello, I've committed the patch to the flash-kernel git repository with two tiny changes: - I've fixed a typo in the kernel-flavors line (s/armp/armmp/). - I've moved the entry to another position as we (at least nominally) sort the entries by the "Machine" field and not by the "DTB-Id" field. I'll probably upload the package sometime on the upcoming weekend. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#899118: flash-kernel: add missing arm64 boards
On Sat, May 19, 2018 at 02:57:41PM +0200, Heinrich Schuchardt wrote: > Package: flash-kernel > Version: 3.94 > Severity: normal > Tags: patch > > Add 60 missing database entries for arm64 boards > supported both by U-Boot and by Linux: > > Amlogic Meson GXL (S905X) P212 Development Board > BananaPi-M64 > Freescale Layerscape 2080a QDS Board > Freescale Layerscape 2080a RDB Board > FriendlyARM NanoPi A64 > FriendlyARM NanoPi NEO 2 > FriendlyARM NanoPi NEO Plus2 > GeekBox > HiKey Development Board > HiSilicon Poplar Development Board > Khadas VIM > Libre Computer Board ALL-H3-CC H5 > Libre Technology CC > LS1012A Freedom Board > LS1012A QDS Board > LS1012A RDB Board > LS1043A RDB Board > LS1046A RDB Board > LS1088A QDS Board > LS1088A RDB Board > Marvell Armada 3720 Development Board DB-88F3720-DDR3 > Marvell Armada 7040 DB board > NVIDIA Tegra210 P2371 (P2530/P2595) reference design > NVIDIA Tegra210 P2571 reference design > Olimex A64-Olinuxino > OrangePi Win/Win Plus > OrangePi Zero Plus2 > Pine64 > Renesas Draak board based on r8a77995 > Renesas Eagle board based on r8a77970 > Renesas H3ULCB board based on r8a7795 ES2.0+ > Renesas M3ULCB board based on r8a7796 > Renesas Salvator-X board based on r8a7795 ES2.0+ > Renesas Salvator-X board based on r8a7796 > Renesas Salvator-X board based on r8a77965 > Rockchip PX5 EVB > Rockchip RK3328 EVB > SoCFPGA Stratix 10 SoCDK > UniPhier LD11 Global Board (REF_LD11_GP) > UniPhier LD11 Reference Board > UniPhier LD20 Global Board (REF_LD20_GP) > UniPhier LD20 Reference Board > UniPhier PXs3 Reference Board > Xunlong Orange Pi PC 2 > Xunlong Orange Pi Prime > ZynqMP ZC1232 RevA > ZynqMP ZC1254 RevA > ZynqMP ZC1275 RevA > ZynqMP zc1751-xm015-dc1 RevA > ZynqMP zc1751-xm016-dc2 RevA > ZynqMP zc1751-xm017-dc3 RevA > ZynqMP zc1751-xm018-dc4 > ZynqMP zc1751-xm019-dc5 RevA > ZynqMP ZCU100 RevC > ZynqMP ZCU102 Rev1.0 > ZynqMP ZCU102 RevA > ZynqMP ZCU102 RevB > ZynqMP ZCU104 RevA > ZynqMP ZCU106 RevA > ZynqMP ZCU111 RevA Hello, many thanks for the patch. Just to make sure that we don't run into problems later on: do all these boards really use u-boot's config_distro_bootcmd.h and thereby work properly with bootscr.uboot-generic? When looking at the defconfigs for several of these systems, I see e.g. CONFIG_BOOTARGS settings that don't really match what I would expect for systems using config_distro_bootcmd.h. Three random examples: - r8a77995_draak_defconfig: CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20" - ls1088ardb_sdcard_qspi_defconfig: CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 default_hugepagesz=2m hugepagesz=2m hugepages=256" - hikey_defconfig: CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw" Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#899118: flash-kernel: add missing arm64 boards
On Mon, May 21, 2018 at 01:01:56AM +0200, Heinrich Schuchardt wrote: > On 05/20/2018 09:15 PM, Karsten Merker wrote: > > On Sat, May 19, 2018 at 02:57:41PM +0200, Heinrich Schuchardt wrote: > > > >> Package: flash-kernel > >> Version: 3.94 > >> Severity: normal > >> Tags: patch > >> > >> Add 60 missing database entries for arm64 boards > >> supported both by U-Boot and by Linux: [...] > > many thanks for the patch. Just to make sure that we don't run > > into problems later on: do all these boards really use u-boot's > > config_distro_bootcmd.h and thereby work properly with > > bootscr.uboot-generic? > > > > When looking at the defconfigs for several of these systems, I > > see e.g. CONFIG_BOOTARGS settings that don't really match what I > > would expect for systems using config_distro_bootcmd.h. > > Three random examples: > > > > - r8a77995_draak_defconfig: > > CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs > > nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20" > > > > - ls1088ardb_sdcard_qspi_defconfig: > > CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 > > earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x300 > > default_hugepagesz=2m hugepagesz=2m hugepages=256" > > > > - hikey_defconfig: > > CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw" [,,,] > For a board to be able to benefit from flash-kernel U-Boot must: > > - be capable to load and execute boot.scr > - provide the booti command > - allow the definition of the following environment variables: > - devtype, devnum, partition > - fdtfile > - kernel_addr_r > - fdt_addr_r > - ramdisk_addr_r > > In your examples above I could not find any evidence that U-Boot cannot > be configured and built to fulfill these requirements. > > For instance build > > make r8a77995_draak_defconfig > make menuconfig > CONFIG_DISTRO_DEFAULTS=y > CONFIG_BOOTARGS="console=ttySC0,115200" > CONFIG_ENV_IS_IN_MMC=y (this is a default value) > make -j6 > > Setup missing environment variables interactively and save them to MMC > and you can rely on flash-kernel for booting. > > ls1088ardb_sdcard_qspi_defconfig and hikey_defconfig select > CONFIG_DISTRO_DEFAULTS=y. CONFIG_BOOTARGS has to be reconfigured. > > This patch is only about providing flash-kernel for the boards. It is > not about providing U-Boot configured to match flash-kernel's requirements. > > I think that even for boards for which we do not provide U-Boot as a > Debian package we should allow the usage of flash-kernel without setting > up a local override for the machine database (/etc/flash-kernel/db). Hello, our policy has always been to only add an entry for an armhf/arm64 system to the flash-kernel database if this entry works out of the box with the default mainline u-boot configuration for the respective device. Users usually expect that a system boots out of the box without having to build a non-standard u-boot configuration and modify the default environment if the system is listed in the flash-kernel machine db. I'm open to arguments to the contrary, but for now I believe that is makes sense to keep this policy. Having to build u-boot with an undocumented non-standard configuration and having to modify various non-obvious parts of the default environment (which possibly includes having to find out the platform-specific kernel_addr_r, fdt_addr_r and ramdisk_addr_r values for systems where they are not already defined in the default environment) to make the system boot is an extremely high and completely unexpected hurdle for a "normal" user, and I believe that we would do a large part of our userbase a misservice by including entries that do not work out of the box. For somebody who has the knowledge to perform all the aforementioned steps on the u-boot side, it's usually easy to also add a corresponding local entry to /etc/flash-kernel/db. I'm CCing debian-arm for further opinions on the matter. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#918428: choose-mirror: mirror list generation broken for all ports architectures
Source: choose-mirror Version: 2.96 Hello, while working on riscv64 support in d-i I have stumbled over a problem with choose-mirror: instead of providing a mirror list, choose-mirror only offers the option "enter information manually", even if Mirrors.masterlist is extended to contain a "riscv64" entry in the "Ports-architecture" field for deb.debian.org and ftp.ports.debian.org. I have tracked the source of this issue down to the part of the "mirrorlist" script that tries to filter out mirrors that don't carry the architecture for which choose-mirror is currently built: https://salsa.debian.org/installer-team/choose-mirror/blob/8bc40f7e97afa5fb075535f501abc31614a574dd/mirrorlist#L107 This filter function only takes the "Archive-architecture" fields from Mirrors.masterlist into account, but not the "Ports-architecture" fields, so it always results in an empty list for Debian-Ports architectures. Unfortunately I don't really speak perl (just enough to have a rough idea of what the mirrorlist script does, but not enough to make modifications to it with good conscience), so it would be great if somebody from debian-boot with better perl knowledge than me could take a look. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#735092: flash-kernel: add Raspberry Pi support
Package: flash-kernel
Version: 3.11
Severity: wishlist
Tags: patch
The attached patch adds Raspberry Pi support to flash-kernel.
It is based on current flash-kernel git (as of
7f52719ab0a607b89555baffd1cc8c14207c0f8f).
It is available for merging in the "rpi-support-rebased" branch at
http://anonscm.debian.org/gitweb/?p=users/merker/flash-kernel.git;a=shortlog;h=refs/heads/rpi-support-rebased
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
>From ff2103a10fc27f77c2763d9dd4b043254b6e489d Mon Sep 17 00:00:00 2001
From: "K. Merker"
Date: Wed, 1 Jan 2014 13:17:13 +0100
Subject: [PATCH] Initial Raspberry Pi support
Add a method "rpiconfigtxt" and a new machine database entry for
the Raspberry Pi. The method "rpiconfigtxt" enables flash-kernel
to update the kernel file name to be booted by the Raspberry Pi
firmware.
As the Raspberry Pi firmware can only boot from a FAT partition,
using symlinks to point to the kernel to be booted is not
possible. Therefore the kernel filename entry in the firmware
config has to be changed after installation of a new kernel
package.
---
README| 10 +-
db/all.db |5 +
functions | 19 +++
test_db |2 +-
4 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 51aa15f..c7cde61 100644
--- a/README
+++ b/README
@@ -49,6 +49,7 @@ The following systems are supported:
- QNAP TS-409
- QNAP TS-410 and TS-410U Turbo NAS
- QNAP TS-419P and TS-419U Turbo NAS
+ - Raspberry Pi
- Seagate FreeAgent DockStar
- SheevaPlug
- SheevaPlug eSATA
@@ -153,12 +154,19 @@ The supported fields are:
* Method: (optional) indicates how to support this particular machine;
the default is "generic"; other available methods are: android, multi,
- redboot, slug, symlink
+ redboot, slug, symlink, rpiconfigtxt
* Boot-Device: (optional) block device to mount before installing
kernel, initrd and U-Boot script; Boot-Kernel-Path, Boot-Initrd-Path and
Boot-Script-Path are then taken relative to this boot device
+* Rpi-ConfigTxt-Path: (optional) Raspberry Pi firmware configuration pathname.
+ The Raspberry Pi firmware configuration is stored in a text file on the
+ first (FAT formatted) partition of the SD card in the system and
+ contains settings like kernel file name, video mode, memory split
+ between CPU and GPU, overclocking parameters, etc. Rpi-ConfigTxt-Path
+ contains the full path to this file (default value: /boot/config.txt).
+
Configuration
- - - - - - -
diff --git a/db/all.db b/db/all.db
index c28432a..c0fdf27 100644
--- a/db/all.db
+++ b/db/all.db
@@ -382,3 +382,8 @@ Method: android
Android-Boot-Device: /dev/mmcblk0
Required-Packages: abootimg
Bootloader-Sets-Root: no
+
+Machine: BCM2708
+Method: rpiconfigtxt
+Rpi-ConfigTxt-Path: /boot/config.txt
+Bootloader-Sets-Root: yes
diff --git a/functions b/functions
index 1233981..26a16ed 100644
--- a/functions
+++ b/functions
@@ -440,6 +440,7 @@ boot_script_path="$(get_machine_field "$machine" "Boot-Script-Path")" || :
boot_dtb_path="$(get_machine_field "$machine" "Boot-DTB-Path")" || :
boot_multi_path="$(get_machine_field "$machine" "Boot-Multi-Path")" || :
android_boot_device="$(get_machine_field "$machine" "Android-Boot-Device")" || :
+rpi_configtxt_path="$(get_machine_field "$machine" "Rpi-ConfigTxt-Path")" || :
if [ -n "$dtb_append_from" ]; then
if dtb_append_required; then
@@ -711,6 +712,24 @@ case "$method" in
} > "$imtd" || error "failed."
echo "done." >&2
;;
+ "rpiconfigtxt")
+ rpi_configtxt_path=${rpi_configtxt_path:-"/boot/config.txt"}
+ rpi_configtxt_tempfile=$(tempfile)
+
+ if [ ! -e "${rpi_configtxt_path}" ]; then
+ echo "${rpi_configtxt_path} not found. Creating it."
+ touch "${rpi_configtxt_path}"
+ fi
+
+ grep -E -v "^#fk-old-" < "${rpi_configtxt_path}" | \
+ sed -e 's/^kernel=/#fk-old-kernel=/' \
+ -e 's/^initramfs/#fk-old-initramfs/' \
+ -e 's/^ramfsfile/#fk-old-ramfsfile/' \
+ -e 's/^ramfsaddr/#fk-old-ramfsaddr/' > ${rpi_configtxt_tempfile}
+
+ echo -n "kernel=$(basename ${kfile})\ninitramfs $(basename ${ifile})\n" >> ${rpi_configtxt_tempfile}
+ mv "${rpi_configtxt_tempfile}" "${rpi_configtxt_path}"
+ ;;
esac
}
diff --git a/test_db b/test_db
index aec83f1..217fe64 100755
--- a/test_db
+++ b/test_db
@@ -22,7 +22,7 @@
MACHINE_DB="$(cat "${FK_CHECKOUT:-$FK_DIR}/db/"*.db)"
test_no_unknown_fields() {
-local expected='Android-Boot-Device Boot-Device Boot-DTB-Path Boot-Initrd-Path Boot-Kernel-Path Boot-Multi-Path Boot-Script-Path Bootloader-Sets-Root DTB-Append DTB-Append-From DTB-Id Kernel-Flavors Machine Machine-Id Method Mtd-Initrd Mtd-Kernel Optional-Packages Required-Packages U-Boot-Initrd-Address U-Boot-Kernel-Address U-Boot-Kernel-Entry-Point U-Boot-Multi-Address U-Boot-Script-Address U-Boot-Script-Name'
+
Bug#735093: flash-kernel: does not correctly handle removal of the highest-versioned installed kernel package
Package: flash-kernel
Version: 3.11
Severity: normal
Tags: patch
Flash-Kernel 3.11 does not properly handle a removal of the
highest-versioned kernel package. The same applies to current
git as of 2014-01-12 which will probably be released as 3.12.
When called from the kernel postinst in this case, it just aborts
instead of flashing the remaining then-highest-versioned kernel,
which in specific cases could lead to an unbootable system.
Attached is a patch against current mainline flash-kernel git
(as of 7f52719ab0a607b89555baffd1cc8c14207c0f8f).
It is available for merging in the "rpi-support-rebased" branch at
http://anonscm.debian.org/gitweb/?p=users/merker/flash-kernel.git;a=shortlog;h=refs/heads/rpi-support-rebased
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
>From 989312441af9bdec76ba571eb3c6ae3d65f93d4e Mon Sep 17 00:00:00 2001
From: "K. Merker"
Date: Thu, 2 Jan 2014 14:34:32 +0100
Subject: [PATCH] Add extended kernel package removal handling
Until now, flash-kernel has not properly handled a removal of the
highest-versioned kernel package. When called from the kernel
postinst in this case, it just aborted instead of flashing the
remaining then-highest-versioned kernel, which could lead to an
unbootable system.
This patch adds extended removal handling which takes care
of the issue.
---
debian/copyright|1 +
flash-kernel.8 | 18 ++---
functions | 63 +++
kernel-hook/zz-flash-kernel |6 +++--
4 files changed, 71 insertions(+), 17 deletions(-)
diff --git a/debian/copyright b/debian/copyright
index af21da0..e9fb23c 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -6,6 +6,7 @@ Copyright:
Copyright (C) 2006 Joey Hess
Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011 Martin Michlmayr
Copyright (C) 2011 Loïc Minier
+Copyright (C) 2014 Karsten Merker
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
diff --git a/flash-kernel.8 b/flash-kernel.8
index 7b5bad5..8165372 100644
--- a/flash-kernel.8
+++ b/flash-kernel.8
@@ -3,7 +3,7 @@
.SH NAME
flash-kernel \- put kernel and initramfs in boot location
.SH SYNOPSIS
-.B flash-kernel [--supported] [kvers]
+.B flash-kernel [--machine machine-type] [--context calling-context] [--supported] [kvers]
.SH DESCRIPTION
flash-kernel is a script which will put the kernel and initramfs in
the boot location of embedded devices that don't load the kernel and
@@ -11,7 +11,7 @@ initramfs directly from /boot. flash-kernel supports devices that
boot from flash memory (hence the name) as well as some devices that
require a special boot image on the disk.
.P
-Optionally, it can be passed a version of the kernel to flash; only
+Optionally, it can be passed a version of the kernel to process; only
the highest version will be flashed and other versions will be
ignored. Kernel and initrd are read from /boot.
.P
@@ -20,7 +20,17 @@ the subarchitectures of the machine and the image to be flashed
match. Valid filenames for images to flash are suffixed with the
subarchitecture.
.P
-If the \-\-supported option is used, flash\-kernel will test to see if
+If the \-\-supported option is used, flash\-kernel will test whether
the hardware is supported, and return a true or false value.
+.P
+The \-\-machine option allows to manually override the auto-detected
+machine type string.
+.P
+The \-\-context option is used internally by the kernel
+postinst/postrm scripts which call flash-kernel upon kernel package
+installations and removals. It provides flash-kernel with the
+information that it is running in the kernel packages
+postinst/postrm context. Valid values are postinst.d* and
+postrm.d*.
.SH AUTHOR
-Martin Michlmayr
+Martin Michlmayr , Karsten Merker
\ No newline at end of file
diff --git a/functions b/functions
index 26a16ed..4b1745e 100644
--- a/functions
+++ b/functions
@@ -351,28 +351,69 @@ android_flash() {
}
main() {
-if [ "x$1" = "x--machine" ]; then
- machine="$2"
- shift 2
-else
+
+while [ $# -gt 0 ]
+do
+if [ "x$1" = "x--machine" ]; then
+machine="$2"
+shift 1
+elif [ "x$1" = "x--context" ]; then
+context="$2"
+shift 1
+elif [ "x$1" = "x--supported" ]; then
+do_check_supported="true"
+elif [ $# -eq 1 ]; then
+kvers="$1"
+fi
+shift 1
+done
+
+if [ -z "$machine" ]; then
get_machine
fi
-if [ "x$1" = "x--supported" ]; then
+if [ -n "$do_check_supporte
Bug#735092: flash-kernel: add Raspberry Pi support
On Sun, Jan 12, 2014 at 07:01:36PM +, Ian Campbell wrote: > On Sun, 2014-01-12 at 19:24 +0100, Karsten Merker wrote: > > On Sun, Jan 12, 2014 at 06:00:24PM +, Ben Hutchings wrote: > > > On Sun, 2014-01-12 at 18:34 +0100, Karsten Merker wrote: > > > > > > The attached patch adds Raspberry Pi support to flash-kernel. > > [SNIP] > > > So the boot partition is mounted at /boot? Doesn't that make it > > > impossible to install packaged kernels (as dpkg needs to create hard > > > links)? > > > > Installing a kernel package (locally built using make-kpkg) with > > a VFAT /boot does not show any problems here: > > The normal way of dealing with this is to not have the bootloader > partition mounted on boot, this is described in flash-kernel via the > Boot-Device field. I think this should be honoured for Rpi too. > Rpi-ConfigTxt-Path would then be relative to this device. Having the vfat boot partition as /boot is the standard way in Raspbian (Debian/armhf rebuild for the Pi/armv6, "official" OS distribution for the Pi) and is described this way in all user documentation for the Pi. This is also expected by other software, in particular the firmware update mechanism, which expects the firmware image to be at /boot/bootcode.bin, as well as by the Raspberry Pi foundation's kernel updates (which do not come as a Debian kernel package). Not mounting the vfat boot partition at /boot would of course be technically possible, but nobody actually does that on a Pi and it would pose several problems: - The firmware update mechanism would have to be changed. This is outside the scope of Debian and as installing firmware updates is something that happens rather frequently on the Pi, that must work without problems. - All the Pi user documentation would have to be changed, which is also outside the scope of Debian. - In case the vfat boot partition is not mounted at /boot, the firmware cannot anymore directly boot the /boot/vmlinuz-* and /boot/initrd.img-* files from the kernel package. That would therefore require copying the files from /boot to the actual vfat boot partition. As having the vfat boot partition mounted on /boot is the actual default case, flash-kernel would have to handle this as well. This means either special handling depending on whether the vfat partition is at /boot or not, or generally copying the kernel to the vfat partition under another name. The latter would in the case vfat-at-/boot result in having the kernel and initrd twice on the already quite small system vfat partition, which is a route I would like to avoid. All things taken together I think that we should simply accept that the vfat boot partition gets mounted at /boot on the Pi and use it this way. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112201616.gd10...@excalibur.cnev.de
Bug#735092: flash-kernel: add Raspberry Pi support
On Sun, Jan 12, 2014 at 07:32:56PM +, Ben Hutchings wrote: > On Sun, 2014-01-12 at 19:24 +0100, Karsten Merker wrote: > > On Sun, Jan 12, 2014 at 06:00:24PM +, Ben Hutchings wrote: > > > So the boot partition is mounted at /boot? Doesn't that make it > > > impossible to install packaged kernels (as dpkg needs to create hard > > > links)? > > > > Installing a kernel package (locally built using make-kpkg) with > > a VFAT /boot does not show any problems here: > [...] > > Please also test upgrading (or simply reinstalling the same package > again). Indeed, reinstalling fails: dpkg: error processing linux-image-3.12.6-rpi+_2014010201_armhf.deb (--install): unable to make backup link of `./boot/vmlinuz-3.12.6-rpi+' before installing new version: Operation not permitted Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112202427.ge10...@excalibur.cnev.de
Bug#751012: [flash-kernel] Flash-kernel should fail with exit 0 under debrootstrap
On Mon, Jun 09, 2014 at 05:54:35PM +0200, Bastien ROUCARIES wrote: > On Mon, Jun 9, 2014 at 5:21 PM, Karsten Merker wrote: > > On Mon, Jun 09, 2014 at 03:48:11PM +, bastien ROUCARIES wrote: > > > >> Package: flash-kernel > >> Severity: important > >> > >> Flash-kernel should detect it run under debrootstrap and fail gracefully/ > >> > >> Install message: > >> > >> Processing triggers for libc-bin (2.18-7) ... > >> Processing triggers for initramfs-tools (0.115) ... > >> update-initramfs: Generating /boot/initrd.img-3.14-1-kirkwood > >> /bin/df: Warning: cannot read table of mounted file systems: No such file > >> or directory > >> warning: failed to read mtab > >> ^Cdpkg: error processing package initramfs-tools (--configure): > >> subprocess installed post-installation script was interrupted > >> Errors were encountered while processing: > >> initramfs-tools > >> E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > Hello, > > > > I am trying to understand which problem exactly you have > > encountered, but I am a bit confused: you have filed a bug > > against flash-kernel but in the log you have provided, it is not > > flash-kernel that shows an error message, but initramfs-tools. I > > also cannot see in which context that has happened and how it > > relates to debootstrap - by default debootstrap does neither > > install a kernel image nor flash-kernel. From your log, it looks > > like you have manually interrupted the update-initramfs process, > > resulting in the error message above: > > No I have not interupted. > > I have installed te kirkwood kernel and flash-kernel on my chroot. Hello, I unfortunately cannot yet reproduce your problem. Due to the kernel version (3.14-1) I assume that you are debootstrapping jessie or sid. I have just debootstrapped a sid/armel chroot that included flash-kernel and linux-image-3.14-1-kirkwood on a sid/armhf system without problems: # debootstrap --arch=armel --include=flash-kernel,linux-image-kirkwood sid armel-sid-chroot http://ftp.de.debian.org/debian I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553) [...] I: Configuring linux-image-3.14-1-kirkwood... I: Configuring flash-kernel... I: Configuring libgnutls-openssl27:armel... I: Configuring wget... I: Configuring libcwidget3:armel... I: Configuring aptitude... I: Configuring linux-image-kirkwood... I: Configuring iputils-ping... I: Configuring tasksel... I: Configuring tasksel-data... I: Configuring perl-modules... I: Configuring perl... I: Configuring init-system-helpers... I: Configuring cron... I: Configuring rsyslog... I: Configuring logrotate... I: Configuring libc-bin... I: Configuring initramfs-tools... I: Base system installed successfully. # Just to be sure: On which kind of hardware (kirkwood or non-kirkwood system) and in which Debian release (wheezy, jessie or sid) are you running the debootstrap command and which release are you bootstrapping with debootstrap (jessie or sid)? Have you created your chroot like I did above, i.e. with the "--include" parameter, or have you first run debootstrap without it and later on manually installed linux-image-3.14-1-kirkwood and flash-kernel in the already-created chroot? Please provide a full log of the whole process starting with the invocation of debootstrap up to the point where flash-kernel runs but should not. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609180846.gb9...@excalibur.cnev.de
Re: Support for sunxi-based ARM systems in d-i
On Tue, Jun 10, 2014 at 07:31:29AM +0100, Ian Campbell wrote: > On Mon, 2014-06-09 at 23:34 +0200, Karsten Merker wrote: > > flash-kernel 3.19 has migrated to jessie in the meantime, so I guess nothing > > speaks against adding further machines to the db. > > > > I had limited my first patch to systems with SATA connector (Cubieboard 1/2 > > and Mele A1000), as we had no sunxi MMC driver in the Debian kernel at that > > time. Now (since kernel version 3.15~rc8, currently in experimental) sunxi > > MMC support is available in Debian, so I have added entries for all > > supported sunxi-based systems with MMC/SD slot to the patch. > > > > - Cubietech Cubieboard > > - Cubietech Cubieboard2 > > - LinkSprite pcDuino > > - Mele A1000 > > - Miniand Hackberry > > - Olimex A10-OLinuXino-LIME > > - Olimex A10s-Olinuxino Micro > > - Olimex A13-Olinuxino > > - Olimex A13-Olinuxino Micro > > - Olimex A20-Olinuxino Micro > > - PineRiver Mini X-Plus > > - WITS A31 Colombus Evaluation Board > > Is this derived from the DTB files present in the kernel package or > something else? (Just curious) Yes, the entries are derived from the device-tree data in the kernel package. > > If there are no objections, I'll commit the patch to the flash-kernel > > master branch. > > Go ahead! I have commited the patch (rebased against current master and with the now-redundant "Bootloader-Sets-Incorrect-Root: no" lines removed). Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140610221347.ga4...@excalibur.cnev.de
Bug#751704: partman-base 173: partman overwrites parts of u-boot
Source: partman-base Version: 173 Severity: important Upon testing a locally built debian-installer based on linux 3.15-1 (from experimental) on an Allwinner sunXi-based armhf system, I have found that the system does not boot anymore after partman has written a new partition table to the SD card from which the system loads u-boot. Kernel 3.15-1 is the first kernel in Debian that contains an MMC/SD driver for this platform, i.e. with older versions partitions could only be created on an attached SATA disk but not on the SD card, so this problem has not shown up earlier. In my first attempt, the partition table has been created by the "guided partitioning" option in d-i, which has created the following layout: Disk /dev/sdd: 15 GB, 15718510080 bytes 255 heads, 63 sectors/track, 1911 cylinders, total 30700215 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/sdd1 *2048 499711 257008 83 Linux Warning: Partition 1 does not end on cylinder boundary. /dev/sdd2 4997122930687914402272 83 Linux Warning: Partition 2 does not end on cylinder boundary. /dev/sdd32930892630701567 6988275 Extended Warning: Partition 3 does not end on cylinder boundary. /dev/sdd52930892830701567 698827 82 Linux swap Warning: Partition 5 does not end on cylinder boundary. The layout itself appears ok as the first partition starts at sector 2048, i.e. at 1MB offset, but comparing the state of the first MB of data on the device before and after partman has written the partition table shows that not only the partition table has been written, but also the area from offset 0x2000 up to 0x25ff has been zeroed out. On all Allwinner sunXi-based systems this area contains the u-boot SPL, without which the system cannot boot anymore. A second attempt with manual partitioning showed the same behaviour, i.e. it appears to be a general partman problem and not specific to partman-auto. Partman should only write the partition table but should not touch the area between the partition table and the beginning of the first partition as this area is used by bootloaders. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140615180202.ga12...@excalibur.cnev.de
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
On Sun, Jan 15, 2017 at 10:45:29AM +0100, permondes - sagen wrote:
> Package: flash-kernel
> Version: 3.73
> Severity: important
>
> Dear Maintainer,
>
> I am using an OLinuXino A20 LIME with arm.
> boot.scr used to have the following content (I removed the initial
> non-readable characters) which let boot the device without issues:
>
> setenv mmcpart 1
>
> setenv mmcroot /dev/mmcblk0p2 ro
> setenv mmcrootfstype btrfs rootwait fixrtc
> setenv mmcrootflags subvol=@
>
> setenv console ttyS0,115200n8
>
> setenv kernel_file vmlinuz-4.8.0-2-armmp-lpae
> setenv initrd_file initrd.img-4.8.0-2-armmp-lpae
> setenv fdtfile sun7i-a20-olinuxino-lime.dtb
>
> setenv loadaddr 0x4600
> setenv initrd_addr 0x4800
> setenv fdtaddr 0x4700
>
> setenv initrd_high 0x
> setenv fdt_high 0x
>
> setenv loadkernel load mmc ${mmcdev}:${mmcpart} ${loadaddr}
> ${kernel_file}
> setenv loadinitrd load mmc ${mmcdev}:${mmcpart} ${initrd_addr}
> ${initrd_file}\; setenv initrd_size \${filesize}
> setenv loadfdt load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}
>
> setenv loadfiles run loadkernel\; run loadinitrd\; run loadfdt
> setenv mmcargs setenv bootargs console=${console} root=${mmcroot}
> rootfstype=${mmcrootfstype} rootflags=${mmcrootflags}
>
> run loadfiles; run mmcargs; bootz ${loadaddr} ${initrd_addr}:
> ${initrd_size} ${fdtaddr}
>
> <-- end of file
To my knowledge Debian has never provided a boot script with this
content as a part of its official flash-kernel releases. Is this
perhaps from some non-official Debian image that somebody else
has produced, e.g. from some image provided by the hardware
manufacturer or from some other project that uses Debian as its
base but doesn't use Debian's normal mechanisms for handling the
boot scripts?
Which u-boot version do you have installed? Can you provide the
output of the "printenv" command at the u-boot prompt?
> The new content of that file is:
>
> # boot script for Allwinner SunXi-based devices
>
> # Mainline u-boot v2014.10 introduces a new default environment and
> # a new common bootcmd handling for all platforms, which is not fully
> # compatible with the old-style environment used by u-boot-sunxi.
> # This script therefore needs to check in which environment it
> # is running and set some variables accordingly.
>
> # On u-boot-sunxi, this script assumes that ${device} and ${partition}
> # are set.
>
> # The new-style environment predefines ${boot_targets}, the old-style
> # environment does not.
> if test -n "${boot_targets}"
> then
> echo "Mainline u-boot / new-style environment detected."
> # Mainline u-boot v2014.10 uses ${devtype}, ${devnum} and
> # ${bootpart} where u-boot-sunxi uses ${device} and ${partition}.
> # ${distro_bootpart} replaced ${bootpart} in u-boot v2016.01.
> if test -z "${device}"; then setenv device "${devtype}"; fi
> if test -z "${partition}${distro_bootpart}"; then setenv partition
> "${devnum}:${bootpart}"; fi
> if test -z "${partition}"; then setenv partition "${devnum}:
> ${distro_bootpart}"; fi
> else
> echo "U-boot-sunxi / old-style environment detected."
> # U-boot-sunxi does not predefine kernel_addr_r, fdt_addr_r and
> # ramdisk_addr_r, so they have to be manually set. Use the values
> # from mainline u-boot v2014.10, except for ramdisk_addr_r,
> # which is set to 0x4430 to allow for initrds larger than
> # 13MB on u-boot-sunxi.
> setenv kernel_addr_r 0x4200
> setenv fdt_addr_r 0x4300
> setenv ramdisk_addr_r 0x4430
> fi
>
> if test -n "${console}"; then
> setenv bootargs "${bootargs} console=${console}"
> fi
>
> setenv bootargs ${bootargs} quiet
>
>
> image_locations='/boot/ /'
> if test -z "${fk_kvers}"; then
>setenv fk_kvers '4.8.0-2-armmp-lpae'
> fi
>
> if test -n "${fdtfile}"; then
>setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
> else
>setenv fdtpath dtb-${fk_kvers}
> fi
>
> for pathprefix in ${image_locations}
> do
> if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers}
> then
> load ${device} ${partition} ${kernel_addr_r}
> ${pathprefix}vmlinuz-${fk_kvers} \
> && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath}
> \
> && load ${device} ${partition} ${ramdisk_addr_r}
> ${pathprefix}initrd.img-${fk_kvers} \
> && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..."
> \
> && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize}
> ${fdt_addr_r}
> fi
> done
>
> <- end of file
>
> Which does not allow the device to boot.
> None of the variables in that script is set in the current environment.
This points at a problem with either your u-boot version or your
u-boot environment. The oldest u-boot version that Debian has
ever shipped for the Olinuxino A20 LIME as part of the official
Debian-Installer images has been mainline u-boot v2014.10, and
all mainline u-boot versions since v2014.10 provide a default
environment that is compatible with this boot script.
Bug#851469: flash-kernel: ARM new boot.scr does not allow the device to boot
On Sun, Jan 15, 2017 at 12:02:56PM +0100, permondes - sagen wrote: > Am Sonntag, den 15.01.2017, 11:47 +0100 schrieb Karsten Merker: > > This points at a problem with either your u-boot version or your > > u-boot environment. The oldest u-boot version that Debian has > > ever shipped for the Olinuxino A20 LIME as part of the official > > Debian-Installer images has been mainline u-boot v2014.10, and > > all mainline u-boot versions since v2014.10 provide a default > > environment that is compatible with this boot script. > > > > Please note that u-boot keeps its old environment on upgrade by > > default, i.e. if you originally had e.g. some vendor-specific > > u-boot installed and upgraded to mainline u-boot later, this > > would have kept the environment from the vendor u-boot. You can > > reset the u-boot environment to its current default by running > > "env default -a; saveenv" at the u-boot command prompt. > > > > HTH, > > Karsten > > The device is being used as a FreedomBox, a flavour of Debian. They > provide an initial "live" image which is quite old actually. Updating to > the current version, which is done automatically during set-up, makes > this change of boot.scr, so I guess they switched to standard u-boot. Not necessarily. The boot.scr is generated by the flash-kernel package on every kernel update, but the u-boot in the boot area is not automatically updated with an update of the u-boot-sunxi package, so unless the people who have built the freedombox upgrade mechanism have explicitly implemented a function to update the u-boot in the boot area (which I doubt), you will probably still have whatever older u-boot version was used when building the original freedombox image. > I would like to test the reset of the environment, how do I get into > u-boot prompt? I just have ssh access to the box, no serial, nor > keyboard or so. Hm, that poses a problem. The "normal" way is via serial console, or, if the u-boot version is relatively new, via a display connected to the HDMI port and a USB keyboard. U-Boot isn't memory resident (except for the PSCI functions), i.e. once the Linux kernel is booted, there is no u-boot anymore with which one could interact directly. What you could try is clobbering the area on the SD card in which u-boot stores the environment. This results in a checksum mismatch and u-boot falls back to the integrated default environment. On the LIME, the u-boot environment is stored on the SD card starting at offset 544kB from the start of the device, and is 128kB in size. So on the LIME running $ sudo dd if=/dev/zero bs=1k count=128 seek=544 of=/dev/mmcblk0 should overwrite the complete environment area with zeros, resulting in u-boot falling back to the built-in defaults. But without some form of console you still won't be able to see which version of u-boot is really installed (cf. my mail to debian-arm) and what exactly happens at boot time. If you want to make sure that you have a current u-boot version installed, you can replace whatever version is currently on the SD card by running $ sudo dd if=/usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1k seek=8 Doing all this "blind" without console is of course inherently dangerous, so make an image backup of your SD card that you can restore in case of problems before trying any of this. HTH, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#864457: [d-i daily hd-media 20170608] kernel doesn't initialize USB ports inside d-i on a sunxi-based system
On Thu, Jun 08, 2017 at 10:50:57PM +0200, Karsten Merker wrote: > Package: installation-reports > > Boot method: hd-media tarball from USB stick > Image version: > https://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz > Date: 2017-06-08 > > Machine: LeMaker Banana Pi > Processor: Allwinner A20 (2x Cortex A7) > Memory: 1GB [...] > Comments/Problems: > Installation method is a d-i hd-media tarball and a Debian CD/DVD > ISO image on a USB stick. Booting d-i from the stick works fine, > but inside the installer the USB ports are dead and no USB > devices get recognized by the kernel. > > In an installed system on the same hardware (installed with the > netboot image), the USB ports work normally. In the d-i > environment, the ehci platform driver gets loaded, but for some > reason doesn't initialize the actual host controller. All > relevant USB host driver modules appear to be there: > > Module Size Used by > usb_storage45835 0 > phy_generic 4686 1 sunxi > musb_hdrc 113325 1 sunxi > udc_core 26444 1 musb_hdrc > ohci_platform 4786 0 > ohci_hcd 37898 1 ohci_platform > ehci_platform 5462 0 > ehci_hcd 64996 1 ehci_platform > phy_sun4i_usb 8637 1 sunxi > extcon_core13223 2 sunxi,phy_sun4i_usb > usbcore 196310 6 > usb_storage,ehci_hcd,musb_hdrc,ohci_hcd,ehci_platform,ohci_platform > usb_common 3659 5 udc_core,sunxi,musb_hdrc,phy_sun4i_usb,usbcore > > In the d-i environment: > [2.694030] usbcore: registered new interface driver usbfs > [2.699958] usbcore: registered new interface driver hub > [2.703305] SCSI subsystem initialized > [2.716192] usbcore: registered new device driver usb > [2.724836] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [2.736947] sunxi-mmc 1c0f000.mmc: base:0xf08f4000 irq:28 > [2.750665] ehci-platform: EHCI generic platform driver > [2.751130] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > [2.752551] ohci-platform: OHCI generic platform driver > > While on the installed system: > [2.162185] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [2.168314] ehci-platform: EHCI generic platform driver > [6.187194] ehci-platform 1c14000.usb: EHCI Host Controller > [6.187256] ehci-platform 1c14000.usb: new USB bus registered, assigned > bus number 2 > [6.192414] ehci-platform 1c14000.usb: irq 30, io mem 0x01c14000 > [6.205562] ehci-platform 1c14000.usb: USB 2.0 started, EHCI 1.00 > [6.206170] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 > [6.206184] usb usb2: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [6.206191] usb usb2: Product: EHCI Host Controller > [6.206198] usb usb2: Manufacturer: Linux 4.9.0-3-armmp-lpae ehci_hcd > [6.206204] usb usb2: SerialNumber: 1c14000.usb > [6.207443] hub 2-0:1.0: USB hub found > [6.207557] hub 2-0:1.0: 1 port detected > [6.209230] ehci-platform 1c1c000.usb: EHCI Host Controller > [6.209289] ehci-platform 1c1c000.usb: new USB bus registered, assigned > bus number 3 > [6.216403] ehci-platform 1c1c000.usb: irq 34, io mem 0x01c1c000 > [6.230524] ehci-platform 1c1c000.usb: USB 2.0 started, EHCI 1.00 > [6.231044] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 > [6.231058] usb usb3: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [6.231066] usb usb3: Product: EHCI Host Controller > [6.231072] usb usb3: Manufacturer: Linux 4.9.0-3-armmp-lpae ehci_hcd > [6.231079] usb usb3: SerialNumber: 1c1c000.usb > > We might have a problem with the USB port power supply here. > Comparing the available modules between the installed system and > the d-i environment (full list below) and looking for possibly > related modules shows that the "axp20x_regulator" and > "axp20x_usb_power" modules are available in the installed system, > but not in the d-i environment. I am not sure whether > axp20x_usb_power is really responsible for providing power _to_ > the USB hosts ports, though. It could be that it is responsible > for powering the system _from_ a USB-OTG port, so it might be > unrelated to the problem at hand. "axp20x_regulator" would > possibly be a candidate for a power-supply problem. I have also > tried using a powered USB hub between the USB stick and the host > port, but even then no USB device gets recognized, which kind of > speaks against the theory of only a missing 5V-supply on the USB > port as the sole sourc
Providing (armhf) u-boot images together with d-i images?
Hello,
several armhf systems do not have u-boot (or another firmware) in
non-volatile (i.e. ROM/Flash) memory, but instead store their
system firmware on a removable medium such as an SD card. In
many cases the user does not receive a suitable firmware medium
when buying the hardware, because the vendors often expect these
devices to be used with pre-built android images. This means
that a user who has freshly bought such a system and wants to
install Debian on it, has to first find and install an appropriate
u-boot image to be able to start d-i.
Debian provides appropriate u-boot images for several supported
systems in the u-boot-{exynos,imx,omap,sunxi} packages, but those
are not easily accessible to somebody who does not already run a
Debian/armhf system (or at least Debian on another architecture),
so I am wondering whether we should offer these u-boot images
(in unpacked form) together with the d-i images, similar to what
we do with the device-tree files extracted from the linux-image
package.
Comments welcome :-).
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141203220916.ga17...@excalibur.cnev.de
Re: Providing (armhf) u-boot images together with d-i images?
On Wed, Dec 03, 2014 at 03:10:37PM -0800, Vagrant Cascadian wrote: [providing u-boot images for armhf platforms that do not have u-boot in non-volatile storage] > Simply extracting the relevent u-boot files doesn't seem like enough to > me. They still need to be installed at particular offsets to the raw SD > card, or in some cases, to a fat partition on the SD card, though may be > fussy about exactly where on the fat partition it resides in a rather > hair-pulling way... so providing just the binaries makes it a little > easier, but not a whole lot. I guess it would make sense to provide both the "naked" u-boot binaries for people who want to manually write them to an SD card that already contains a partition table without destroying it, and an additional tiny disk image (<1MB) that contains u-boot at the proper place (but nothing else, i.e. no partition table if not needed for u-boot), which can be written with common disk image handling tools. The latter would make life a lot easier for people setting up the installer from Windows for example. > Providing complete u-boot images for each platform would be 19 images > for jessie, though each one is fairly small (each between > 0.5-1M). Though I don't think we've consolidated all documentation > needed to generate all those platforms with the correct offsets (though > many are all the same, such as sunxi). I only know those for sunxi and i.MX6: - sunxi: combined image (SPL + main image) at offset 8kB - i.MX6: SPL at offet 1kB main image at offset 42kB @debian-arm: Could somebody provide this information for i.MX53 and OMAP? I am unsure about the Exynos platform - IIRC I read somewhere that one needs a signed non-free first-stage loader to load u-boot there, which would make it impossible for us to provide ready-to-boot images, but my memory is shady on that issue and it might only have been the case for particular SoCs/systems. Ian, can you provide some information regarding this? > For images such as hd-media, we'd ideally want to provide complete > u-boot + kernel + initrd ( + gtk initrd) images, which would grow each > image considerably. I know of no armhf system that can load its u-boot from a USB mass storage device, so AFAICS such a full image could only be written to an SD card. This setup would therefore only be useful if the intended installation target is something else than the SD card, because otherwise one would have to install to the medium containing the installer and would therefore not be able to use the space used by the installer and the CD/DVD ISO image for the installed system. I think that for most systems the primary installation target is the SD card, so I think that we should use the "tiny SD card image with only u-boot on it" + "USB stick with hd-media tarball and CD/DVD ISO" model instead of building "full" hd-media images. Kind regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141206184639.ga4...@excalibur.cnev.de
Bug#773127: installation-reports: mostly Successful: Wandboard Quad [armhf]
On Sun, Dec 14, 2014 at 12:02:09PM -0800, Vagrant Cascadian wrote: > Package: installation-reports > Boot method: netboot > Image version: > http://d-i.debian.org/daily-images/armhf/20141214-05:27/netboot/ > Date: 20141214 > > Machine: Wandboard Quad > Installing with the console installer worked fine. Hello, based on your installation report, I have just added the Wandboard Quad to the list of supported systems in the installation guide. Could you perhaps give a short list of which hardware components are working with Debian's kernel, so that I can add that to the installation guide as well? I understand from your installation report that MMC, LAN, USB and HDMI video work. The module list shows modules loaded for SATA and WLAN, but I cannot assess from the module list whether these actually work correctly (on some systems there can be be issues with GPIO-controlled regulators for the SATA power or a requirement for OOB communication to the SDIO WLAN module), so I would appreciate an explicit confirmation. Besides these, do the following components work? - Serial Console - Audio (HDMI, analog, S/PDIF) - USB OTG - Bluetooth Kind Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141214212942.ga22...@excalibur.cnev.de
Bug#773127: installation-reports: mostly Successful: Wandboard Quad [armhf]
On Sun, Dec 14, 2014 at 02:31:45PM -0800, Vagrant Cascadian wrote: > On 2014-12-14, Karsten Merker wrote: > > Could you perhaps give a short list of which hardware components > > are working with Debian's kernel, so that I can add that to the > > installation guide as well? I understand from your installation > > report that MMC, LAN, USB and HDMI video work. > > Yes, those all work. [SATA and serial console ok, WLAN/Bluetooth and Audio not working] Thanks, I have added this information to the installation guide. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141216221115.gb4...@excalibur.cnev.de
[PATCH V3 3/6] Add utils/gen-hd-image
gen-hd-image creates partitioned harddisk images from a directory
tree and optionally installs a bootloader into the image. Supported
target filesystems are fat16, fat32 and ext2.
Its main use is building bootable images for armhf/armel/arm64
systems which use u-boot as their system firmware. U-boot
requires the boot device to have an MBR-style partition table,
therefore booting from "superfloppy" style images (like they
are built by d-i for i386/amd64 systems) does not work there.
---
build/util/gen-hd-image | 380
debian/changelog| 2 +
debian/control | 9 +-
debian/copyright| 5 +
4 files changed, 394 insertions(+), 2 deletions(-)
create mode 100755 build/util/gen-hd-image
diff --git a/build/util/gen-hd-image b/build/util/gen-hd-image
new file mode 100755
index 000..13913f0
--- /dev/null
+++ b/build/util/gen-hd-image
@@ -0,0 +1,380 @@
+#!/bin/sh
+#
+# gen-hd-image V1.01
+# Copyright 2014,2015 by Karsten Merker
+#
+# This file is dual-licensed. It is provided under (at your option)
+# either the terms of the GPL2+ or the terms of the X11 license as
+# described below. Note that this dual licensing only applies to this
+# file, and not this project as a whole.
+#
+# License options:
+#
+# - Option "GPL2+":
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of the
+# License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public
+# License along with this program; if not, write to the Free
+# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+# On Debian systems, the full text of the GPL version 2 is
+# available in the file /usr/share/common-licenses/GPL-2.
+#
+# - or, alternatively, option "X11":
+#
+# Permission is hereby granted, free of charge, to any person
+# obtaining a copy of this software and associated documentation
+# files (the "Software"), to deal in the Software without
+# restriction, including without limitation the rights to use,
+# copy, modify, merge, publish, distribute, sublicense, and/or
+# sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following
+# conditions:
+#
+# The above copyright notice and this permission notice shall be
+# included in all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+# OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+# OTHER DEALINGS IN THE SOFTWARE.
+
+PATH="${PATH}:/bin:/sbin:/usr/bin:/usr/sbin"
+export PATH
+
+FSTYPE="fat32"
+PARTID="0x0c"
+FATSIZE="32"
+BUILDTYPE="complete"
+SOURCEDIR="."
+PARTOFFSET="2048"
+DEFAULT_IMAGESIZE="976560" # default d-i FLOPPY_SIZE for hd-media images
+IMAGESIZE="${DEFAULT_IMAGESIZE}"
+COMPRESS="none"
+COMPRESS_OPTS=""
+VERBOSITY="0"
+PREREQUISITES="fmt sfdisk"
+PREREQUISITES_MISSING=""
+
+log()
+{
+ if [ "${VERBOSITY}" -gt 0 ]; then
+echo "$(basename $0): $1"
+ fi
+}
+
+error()
+{
+ echo "$(basename $0): $1" 1>&2
+}
+
+clean_tempfiles()
+{
+ [ -f "${TEMP_FS_IMAGEFILE}" ] && rm -f "${TEMP_FS_IMAGEFILE}"
+ [ -f "${TEMP_HD_IMAGEFILE}" ] && rm -f "${TEMP_HD_IMAGEFILE}"
+}
+
+check_prerequisites()
+{
+ for TOOL in $1
+ do
+which >/dev/null ${TOOL}
+if [ ! "$?" -eq 0 ]; then
+ PREREQUISITES_MISSING="${PREREQUISITES_MISSING}${TOOL} "
+fi
+ done
+ if [ -n "${PREREQUISITES_MISSING}" ]; then
+error "ERROR: The following programs are unavailable, but required"
+error "ERROR: for the selected options: ${PREREQUISITES_MISSING}"
+error "ERROR: Exiting."
+exit 1
+ fi
+}
+
+usage()
+{
+ fmt -w 75 -s </dev/null if=/dev/zero bs=1k of="${TEMP_HD_IMAGEFILE}"
seek=$((${IMAGESIZE}-1)) count=1
+sfdisk --force -u S "${TEMP_HD_IMAGEFILE}" 1>/d
[PATCH V3 6/6] Handle i.MX6 systems without baudrate in ${console} in bootscr.mainline_common
Most systems encode the console baudrate in the ${console} variable, but
several i.MX6-based systems do not. As ${console} gets passed to the kernel,
we need to explicitly add the baudrate on i.MX6-based systems to avoid
a baudrate mismatch between u-boot and kernel.
---
build/boot/arm/bootscr.mainline_common | 5 +
debian/changelog | 3 +++
2 files changed, 8 insertions(+)
diff --git a/build/boot/arm/bootscr.mainline_common
b/build/boot/arm/bootscr.mainline_common
index 4dc6bf5..c68eb79 100644
--- a/build/boot/arm/bootscr.mainline_common
+++ b/build/boot/arm/bootscr.mainline_common
@@ -22,6 +22,11 @@ if test ! -e ${devtype} ${devnum}:${bootpart}
dtbs/${fdtfile}; then
exit 0
fi
+# Some i.MX6-based systems do not encode the baudrate in the console variable
+if test "${console}" = "ttymxc0" && test -n "${baudrate}"; then
+ setenv console "${console},${baudrate}"
+fi
+
if test -n "${console}"; then
setenv bootargs "${bootargs} console=${console}"
fi
diff --git a/debian/changelog b/debian/changelog
index 9020933..5754f48 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -10,6 +10,9 @@ debian-installer (201410XX) UNRELEASED; urgency=medium
* Add SD-card image build support for hd-media builds on armhf.
* Add SD-card image and tftpboot tarball build support for netboot builds
on armhf.
+ * Make sure to pass the proper console baudrate to the kernel in
+bootscr.mainline_common when booted on i.MX6-based systems that do not
+encode the console baudrate in the ${console} variable.
[ Aurelien Jarno ]
* Add scsi-modules to the cdrom flavour on ppc64el to be able to access
--
2.1.4
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1420124326-7070-7-git-send-email-mer...@debian.org
[PATCH V3 2/6] Provide u-boot binaries for armhf systems without u-boot in flash
---
build/config/armhf.cfg| 2 +-
build/config/armhf/u-boot.cfg | 27 +++
debian/changelog | 1 +
3 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 build/config/armhf/u-boot.cfg
diff --git a/build/config/armhf.cfg b/build/config/armhf.cfg
index 1332c3a..73cdf39 100644
--- a/build/config/armhf.cfg
+++ b/build/config/armhf.cfg
@@ -1,4 +1,4 @@
-MEDIUM_SUPPORTED = hd-media netboot network-console netboot-gtk device-tree
+MEDIUM_SUPPORTED = hd-media netboot network-console netboot-gtk device-tree
u-boot
MKLIBS = mklibs --ldlib=/lib/ld-linux-armhf.so.3
diff --git a/build/config/armhf/u-boot.cfg b/build/config/armhf/u-boot.cfg
new file mode 100644
index 000..f8bcd2c
--- /dev/null
+++ b/build/config/armhf/u-boot.cfg
@@ -0,0 +1,27 @@
+MEDIA_TYPE = u-boot binaries
+
+TARGET = u-boot-binaries
+EXTRANAME = $(MEDIUM)/
+
+.PHONY: u-boot-binaries
+u-boot-binaries:
+ mkdir -p $(SOME_DEST)/$(EXTRANAME)/
+ while read LINE; \
+ do \
+ if [ -n "$${LINE}" ] && ! echo $${LINE}|grep -q -e "^#"; then \
+ set -- $${LINE}; \
+ mkdir -p "$(SOME_DEST)/$(EXTRANAME)/$$1"; \
+ if [ -n "$$2" ]; then \
+ echo "Providing u-boot binaries for $$1 ..."; \
+ cp "$$2" "$(SOME_DEST)/$(EXTRANAME)/$$1/"; \
+ dd 2>/dev/null if="$$2"
of="$(SOME_DEST)/$(EXTRANAME)/$$1/$$1.sdcard.img" bs=512 seek="$$3"; \
+ gzip -9 "$(SOME_DEST)/$(EXTRANAME)/$$1/$$(basename $$2)"; \
+ fi; \
+ if [ -n "$$4" ]; then \
+ cp "$$4" "$(SOME_DEST)/$(EXTRANAME)/$$1/"; \
+ dd 2>/dev/null if="$$4"
of="$(SOME_DEST)/$(EXTRANAME)/$$1/$$1.sdcard.img" bs=512 seek="$$5"
conv=notrunc; \
+ gzip -9 "$(SOME_DEST)/$(EXTRANAME)/$$1/$$(basename $$4)"; \
+ fi; \
+ gzip -9 "$(SOME_DEST)/$(EXTRANAME)/$$1/$$1.sdcard.img"; \
+ fi ;\
+ done < boot/arm/u-boot-image-config
diff --git a/debian/changelog b/debian/changelog
index df06645..d81210a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,7 @@ debian-installer (201410XX) UNRELEASED; urgency=medium
* Add hd-media support for the armhf platform.
* Add boot/arm/u-boot-image-config (a list of u-boot components and their
offsets on disk, needed to create bootable images for arm-based systems).
+ * Provide u-boot binaries for armhf systems without u-boot in flash.
[ Aurelien Jarno ]
* Add scsi-modules to the cdrom flavour on ppc64el to be able to access
--
2.1.4
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1420124326-7070-3-git-send-email-mer...@debian.org
[PATCH V3 1/6] Add boot/arm/u-boot-image-config
The file boot/arm/u-boot-image-config contains the information which u-boot components must be written to which offsets on the disk to create a bootable image for various arm-based systems. --- build/boot/arm/u-boot-image-config | 21 + debian/changelog | 2 ++ 2 files changed, 23 insertions(+) create mode 100644 build/boot/arm/u-boot-image-config diff --git a/build/boot/arm/u-boot-image-config b/build/boot/arm/u-boot-image-config new file mode 100644 index 000..4f00b4b --- /dev/null +++ b/build/boot/arm/u-boot-image-config @@ -0,0 +1,21 @@ +# U-Boot SPL/TPL files and offsets for various platforms +# +# Line format (offsets are given in blocks of 512 Bytes): +# platform_name SPL_filename SPL_offset TPL_filename TPL_offset +# +# Images from u-boot-imx +MX53LOCO /usr/lib/u-boot/mx53loco/u-boot.imx 2 +MX6_Cubox-i /usr/lib/u-boot/mx6_cubox-i/SPL 2 /usr/lib/u-boot/mx6_cubox-i/u-boot.img 84 +Wandboard_Quad /usr/lib/u-boot/wandboard_quad/u-boot.imx 2 +# +# Images from u-boot-omap +BeagleBoneBlack /usr/lib/u-boot/am335x_boneblack/MLO 256 /usr/lib/u-boot/am335x_boneblack/u-boot.img 768 +PandaBoard /usr/lib/u-boot/omap4_panda/MLO 256 /usr/lib/u-boot/omap4_panda/u-boot.bin 768 +# +# Images from u-boot-sunxi +A10-OLinuXino-Lime /usr/lib/u-boot/A10-OLinuXino-Lime/u-boot-sunxi-with-spl.bin 16 +A20-OLinuXino-Lime /usr/lib/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin 16 +BananaPi /usr/lib/u-boot/Bananapi/u-boot-sunxi-with-spl.bin 16 +Cubieboard /usr/lib/u-boot/Cubieboard/u-boot-sunxi-with-spl.bin 16 +Cubieboard2 /usr/lib/u-boot/Cubieboard2/u-boot-sunxi-with-spl.bin 16 +Cubietruck /usr/lib/u-boot/Cubietruck/u-boot-sunxi-with-spl.bin 16 diff --git a/debian/changelog b/debian/changelog index 17f7b18..df06645 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,8 @@ debian-installer (201410XX) UNRELEASED; urgency=medium [ Karsten Merker ] * Add hd-media support for the armhf platform. + * Add boot/arm/u-boot-image-config (a list of u-boot components and their +offsets on disk, needed to create bootable images for arm-based systems). [ Aurelien Jarno ] * Add scsi-modules to the cdrom flavour on ppc64el to be able to access -- 2.1.4 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1420124326-7070-2-git-send-email-mer...@debian.org
[PATCH V3 5/6] Add SD-card image and tftpboot tarball build support for netboot builds on armhf
---
build/boot/arm/bootscr.tftpboot | 21 +
build/config/armhf/netboot.cfg | 69 -
debian/changelog| 2 ++
3 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 build/boot/arm/bootscr.tftpboot
diff --git a/build/boot/arm/bootscr.tftpboot b/build/boot/arm/bootscr.tftpboot
new file mode 100644
index 000..c5a26f4
--- /dev/null
+++ b/build/boot/arm/bootscr.tftpboot
@@ -0,0 +1,21 @@
+if test -z "${fdtfile}"; then
+ echo 'fdtfile environment variable not set. Aborting boot process.'
+ exit 0
+fi
+
+# Some i.MX6-based systems do not encode the baudrate in the console variable
+if test "${console}" = "ttymxc0" && test -n "${baudrate}" ; then
+ setenv console "${console},${baudrate}"
+fi
+
+if test -n "${console}"; then
+ setenv bootargs "${bootargs} console=${console}"
+fi
+
+setenv installer-path "/debian-installer/armhf/"
+
+tftpboot ${fdt_addr_r} ${installer-path}dtbs/${fdtfile} \
+&& tftpboot ${kernel_addr_r} ${installer-path}vmlinuz \
+&& tftpboot ${ramdisk_addr_r} ${installer-path}initrd.gz \
+&& echo "Booting the Debian installer..." \
+&& bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
diff --git a/build/config/armhf/netboot.cfg b/build/config/armhf/netboot.cfg
index ce912c8..517a8ed 100644
--- a/build/config/armhf/netboot.cfg
+++ b/build/config/armhf/netboot.cfg
@@ -1,7 +1,74 @@
MEDIA_TYPE = netboot image
-TARGET = $(INITRD) $(KERNEL)
+FULL_SUFFIX =
+CONCATENATEABLE_SUFFIX = concatenateable
+TFTP_INSTALLER_PATH = debian-installer/armhf/
+
+TARGET = $(KERNEL) $(INITRD) netboot_bootscript_sd netboot_bootscript_tftp
netboot_tarball netboot_images_full
+
EXTRANAME = $(MEDIUM)/
MANIFEST-INITRD = "netboot initrd"
MANIFEST-KERNEL = "kernel image to netboot"
+
+FLOPPY_SIZE = 4
+
+GZIPPED = .gz
+
+.PHONY: netboot_bootscript_sd
+netboot_bootscript_sd:
+ mkimage -T script -A arm -d boot/arm/bootscr.mainline_common
$(SOME_DEST)/$(EXTRANAME)boot.scr
+ update-manifest $(SOME_DEST)/$(EXTRANAME)boot.scr "Universal boot
script for mainline u-boot (>= v2014.10)"
+
+.PHONY: netboot_bootscript_tftp
+netboot_bootscript_tftp:
+ mkimage -T script -A arm -d boot/arm/bootscr.tftpboot
$(SOME_DEST)/$(EXTRANAME)tftpboot.scr
+ update-manifest $(SOME_DEST)/$(EXTRANAME)tftpboot.scr "TFTP boot script
for mainline u-boot (>= v2014.10)"
+
+.PHONY: netboot_tarball
+netboot_tarball: $(KERNEL) $(INITRD) $(TEMP_DTBS) netboot_bootscript_tftp
+ rm -rf $(TEMP)/netboot_tarball
+ mkdir -p $(TEMP)/netboot_tarball/$(TFTP_INSTALLER_PATH)
+ cp $(KERNEL) $(TEMP)/netboot_tarball/$(TFTP_INSTALLER_PATH)vmlinuz
+ cp $(INITRD) $(TEMP)/netboot_tarball/$(TFTP_INSTALLER_PATH)initrd.gz
+ cp -r $(TEMP_DTBS) $(TEMP)/netboot_tarball/$(TFTP_INSTALLER_PATH)dtbs/
+ cp $(SOME_DEST)/$(EXTRANAME)tftpboot.scr
$(TEMP)/netboot_tarball/$(TFTP_INSTALLER_PATH)
+ tar -C $(TEMP)/netboot_tarball/ -zcf
$(SOME_DEST)/$(EXTRANAME)netboot.tar.gz $(TFTP_INSTALLER_PATH)tftpboot.scr
$(TFTP_INSTALLER_PATH)initrd.gz $(TFTP_INSTALLER_PATH)vmlinuz
$(TFTP_INSTALLER_PATH)dtbs/
+
+.PHONY: netboot_images_full
+netboot_images_full: $(KERNEL) $(INITRD) $(TEMP_DTBS) netboot_bootscript_sd
+ -rm -rf $(TEMP)/netboot_images_full
+ mkdir $(TEMP)/netboot_images_full
+ cp $(KERNEL) $(TEMP)/netboot_images_full/vmlinuz
+ cp $(INITRD) $(TEMP)/netboot_images_full/initrd.gz
+ cp $(SOME_DEST)/$(EXTRANAME)boot.scr
$(TEMP)/netboot_images_full/boot.scr
+ cp -r $(TEMP_DTBS) $(TEMP)/netboot_images_full/dtbs/
+ cp boot/README.device-tree $(TEMP)/netboot_images_full/dtbs/README
+ mkdir -p $(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(FULL_SUFFIX)
+ while read LINE; \
+ do \
+ if [ -n "$${LINE}" ] && ! echo $${LINE}|grep -q -e "^#"; then \
+ set -- $${LINE} ;\
+ gen-hd-image -v -z -b complete -s "$(FLOPPY_SIZE)" -i
"$(TEMP)/netboot_images_full" -o
"$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(FULL_SUFFIX)/$${1}.img" "$$2" "$$3"
"$$4" "$$5" ;\
+ fi ;\
+ done < boot/arm/u-boot-image-config
+
+.PHONY: netboot_images_concatenateable
+netboot_images_concatenateable: $(KERNEL) $(INITRD) $(TEMP_DTBS)
netboot_bootscript_sd
+ -rm -rf $(TEMP)/netboot_images_concatenateable
+ mkdir $(TEMP)/netboot_images_concatenateable
+ cp $(KERNEL) $(TEMP)/netboot_images_concatenateable/vmlinuz
+ cp $(INITRD) $(TEMP)/netboot_images_concatenateable/initrd.gz
+ cp $(SOME_DEST)/$(EXTRANAME)boot.scr
$(TEMP)/netboot_images_concatenateable/boot.scr
+ cp -r $(TEMP_DTBS) $(TEMP)/netboot_images_concatenateable/dtbs/
+ cp boot/README.device-tree
$(TEMP)/netboot_images_concatenateable/dtbs/README
+ mkdir -p
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)
+ while read LINE; \
+ do \
+ if [ -n "$${LINE}" ] && ! echo $${LINE}|grep -q -e "^#"; then \
+ set -- $$
[PATCH V3 4/6] Add SD-card image build support for hd-media builds on armhf
---
build/boot/README.concatenateable_images | 30 ++
build/config/armhf/hd-media.cfg | 44 +++-
debian/changelog | 1 +
3 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 build/boot/README.concatenateable_images
diff --git a/build/boot/README.concatenateable_images
b/build/boot/README.concatenateable_images
new file mode 100644
index 000..326054a
--- /dev/null
+++ b/build/boot/README.concatenateable_images
@@ -0,0 +1,30 @@
+This directory provides installer images in the form of a device-specific
+part (containing the partition table and the system firmware) and a
+device-independent part (containing the actual installer), which can be
+unpacked and concatenated together to build a complete installer image.
+
+The device-specific part is named firmware..img(.gz|.bz2|.xz)
+and the device-independent part is named partition.img(.gz|.bz2|.xz).
+
+To create a complete image from the two parts on Linux systems, you can
+use zcat (for .gz images), bzcat (for .bz2 images) or xzcat (for .xz
+images) as follows:
+
+ zcat firmware..img.gz partition.img.gz > complete_image.img
+
+respectively
+
+ bzcat firmware..img.bz2 partition.img.bz2 > complete_image.img
+
+respectively
+
+ xzcat firmware..img.xz partition.img.xz > complete_image.img
+
+
+On Windows systems, you have to first decompress the two parts separately,
+which can be done e.g. by using 7-Zip, and then concatenate the decompressed
+parts together by running the command
+
+ copy firmware..img + partition.img complete_image.img
+
+in a Windows CMD.exe window.
diff --git a/build/config/armhf/hd-media.cfg b/build/config/armhf/hd-media.cfg
index ec119df..5107f40 100644
--- a/build/config/armhf/hd-media.cfg
+++ b/build/config/armhf/hd-media.cfg
@@ -1,9 +1,13 @@
FLAVOUR_SUPPORTED = ""
+FLOPPY_SIZE = 4
GZIPPED = .gz
EXTRANAME = hd-media/
-TARGET = $(KERNEL) $(INITRD) hd-media_bootscript hd-media_tarball
+FULL_SUFFIX =
+CONCATENATEABLE_SUFFIX = concatenateable
+
+TARGET = $(KERNEL) $(INITRD) hd-media_bootscript hd-media_tarball
hd-media_images_full
MANIFEST-INITRD = "Initrd for use on USB memory sticks"
MANIFEST-KERNEL = "Kernel for use on USB memory sticks"
@@ -24,3 +28,41 @@ hd-media_tarball: $(KERNEL) $(INITRD) $(TEMP_DTBS)
hd-media_bootscript
cp boot/README.device-tree $(TEMP)/hd-media/dtbs/README
tar -C $(TEMP)/hd-media -zcf $(TEMP)/hd-media.tar.gz boot.scr initrd.gz
vmlinuz dtbs/
mv $(TEMP)/hd-media.tar.gz $(SOME_DEST)/$(EXTRANAME)
+
+.PHONY: hd-media_images_full
+hd-media_images_full: $(KERNEL) $(INITRD) $(TEMP_DTBS) hd-media_bootscript
+ -rm -rf $(TEMP)/hd-media_images_full
+ mkdir $(TEMP)/hd-media_images_full
+ cp $(KERNEL) $(TEMP)/hd-media_images_full/vmlinuz
+ cp $(INITRD) $(TEMP)/hd-media_images_full/initrd.gz
+ cp $(SOME_DEST)/$(EXTRANAME)boot.scr
$(TEMP)/hd-media_images_full/boot.scr
+ cp -r $(TEMP_DTBS) $(TEMP)/hd-media_images_full/dtbs/
+ cp boot/README.device-tree $(TEMP)/hd-media_images_full/dtbs/README
+ mkdir -p $(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(FULL_SUFFIX)
+ while read LINE; \
+ do \
+ if [ -n "$${LINE}" ] && ! echo $${LINE}|grep -q -e "^#"; then \
+ set -- $${LINE} ;\
+ gen-hd-image -v -z -b complete -s "$(FLOPPY_SIZE)" -i
"$(TEMP)/hd-media_images_full" -o
"$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(FULL_SUFFIX)/$${1}.img" "$$2" "$$3"
"$$4" "$$5" ;\
+ fi ;\
+ done < boot/arm/u-boot-image-config
+
+.PHONY: hd-media_images_concatenateable
+hd-media_images_concatenateable: $(KERNEL) $(INITRD) $(TEMP_DTBS)
hd-media_bootscript
+ -rm -rf $(TEMP)/hd-media_images_concatenateable
+ mkdir $(TEMP)/hd-media_images_concatenateable
+ cp $(KERNEL) $(TEMP)/hd-media_images_concatenateable/vmlinuz
+ cp $(INITRD) $(TEMP)/hd-media_images_concatenateable/initrd.gz
+ cp $(SOME_DEST)/$(EXTRANAME)boot.scr
$(TEMP)/hd-media_images_concatenateable/boot.scr
+ cp -r $(TEMP_DTBS) $(TEMP)/hd-media_images_concatenateable/dtbs/
+ cp boot/README.device-tree
$(TEMP)/hd-media_images_concatenateable/dtbs/README
+ mkdir -p
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)
+ while read LINE; \
+ do \
+ if [ -n "$${LINE}" ] && ! echo $${LINE}|grep -q -e "^#"; then \
+ set -- $${LINE} ;\
+ gen-hd-image -v -z -b firmware -s "$(FLOPPY_SIZE)" -o
"$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${1}.img"
"$$2" "$$3" "$$4" "$$5" ;\
+ fi ;\
+ done < boot/arm/u-boot-image-config
+ gen-hd-image -v -z -b partition -s "$(FLOPPY_SIZE)" -i
"$(TEMP)/hd-media_images_concatenateable" -o
"$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/partition.img"
+ cp boot/README.concatenateable_images
"$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE
[PATCH V3 0/6] d-i: support building bootable images for armhf targets
Following is version 3 of my patchset for building bootable d-i
images for armhf targets.
Changes since V2
- add distinct debian/changelog entries to each commit
- add the "-n" flag to the gzip invocations in gen-hd-image to make
reproducible builds easier
- add copyright info for utils/gen-hd-image to debian/copyright
- fix some typos
- squash the Build-Depends entries in debian/control into the relevant
commits
- add explicit instructions in README.concatenateable_images about how
to concatenate the device-specific and the device-independent part.
- handle the missing baudrate information in the ${console} variable on
some i.MX6-based system in the bootscripts
- disable building the "concatenateable" targets, i.e. build only the
"u-boot-only" and "full image" targets, and disable creating an extra
subdirectory for the "full" images which is not needed in this case
A note regarding the build-dependencies: I have not added a build-depends
on bzip2 because - while gen-hd-image in principle supports using bzip2 -
we do not actually use that feature and I wanted to keep the dependency
list as short as possible. Gzip is used by default and is essential, so
does not need an explict dependency declaration, and if we would want to
go for higher compression rates we would use xz, which already has a
dependency declared for other reasons.
Regards,
Karsten
Karsten Merker (6):
Add boot/arm/u-boot-image-config
Provide u-boot binaries for armhf systems without u-boot in flash
Add utils/gen-hd-image
Add SD-card image build support for hd-media builds on armhf
Add SD-card image and tftpboot tarball build support for netboot
builds on armhf
Handle i.MX6 systems without baudrate in ${console} in
bootscr.mainline_common
build/boot/README.concatenateable_images | 30 +++
build/boot/arm/bootscr.mainline_common | 5 +
build/boot/arm/bootscr.tftpboot | 21 ++
build/boot/arm/u-boot-image-config | 21 ++
build/config/armhf.cfg | 2 +-
build/config/armhf/hd-media.cfg | 44 +++-
build/config/armhf/netboot.cfg | 69 +-
build/config/armhf/u-boot.cfg| 27 +++
build/util/gen-hd-image | 380 +++
debian/changelog | 11 +
debian/control | 9 +-
debian/copyright | 5 +
12 files changed, 619 insertions(+), 5 deletions(-)
create mode 100644 build/boot/README.concatenateable_images
create mode 100644 build/boot/arm/bootscr.tftpboot
create mode 100644 build/boot/arm/u-boot-image-config
create mode 100644 build/config/armhf/u-boot.cfg
create mode 100755 build/util/gen-hd-image
--
2.1.4
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1420124326-7070-1-git-send-email-mer...@debian.org
Bug#777334: [jessie daily 2015-02-07] [armhf] installation-report: A20-OLinuXino-LIME
Package: installation-reports Boot method: hd-media + CD image on a USB stick hd-media version: http://d-i.debian.org/daily-images/armhf/20150207-05:30/hd-media/hd-media.tar.gz CD version: Debian GNU/Linux testing "Jessie" - Official Snapshot armhf CD Binary-1 20150202-10:45 from http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo, dated 2015-02-02 12:06 Date: 2015-02-07 Machine: Olimex A20-OLinuXino-LIME Processor: Allwinner A20 (2x Cortex A7) Memory: 512MB Console: serial console, 115200 baud Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: The installation was done to a 16GB Micro-SD card using serial console (on the UART0 header) and worked without problems; network (100MBit) and the USB host ports work as expected. Partitioning was done using the "guided partitioning, all files in one partition" option. I have not tested using a SATA disk with the board due to lack of a SATA power cable that fits into the board's SATA power connector (2-pin JST-style). As an informational note: due to bug #773645 (lack of u-boot tools on the first armhf CD), hd-media/CD installations on armhf platforms currently require network connectivity during the installation process; pure offline installations are not possible with hd-media/CD at the moment. dmesg output: [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.16.0-4-armmp-lpae (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-16) ) #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) [0.00] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=30c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Olimex A20-OLinuXino-LIME [0.00] Forcing write-allocate cache policy for SMP [0.00] Memory policy: Data cache writealloc [0.00] On node 0 totalpages: 131072 [0.00] free_area_init_node: node 0, pgdat c0a0cb00, node_mem_map dfbf9000 [0.00] DMA zone: 1024 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 131072 pages, LIFO batch:31 [0.00] psci: probing for conduit method from DT. [0.00] psci: Using PSCI v0.1 Function IDs from DT [0.00] PERCPU: Embedded 9 pages/cpu @dfbd4000 s13312 r8192 d15360 u36864 [0.00] pcpu-alloc: s13312 r8192 d15360 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyS0,115200 quiet [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 497040K/524288K available (6562K kernel code, 838K rwdata, 2216K rodata, 701K init, 396K bss, 27248K reserved, 0K highmem) [0.00] Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xffc0 - 0xffe0 (2048 kB) vmalloc : 0xe080 - 0xff00 ( 488 MB) lowmem : 0xc000 - 0xe000 ( 512 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .text : 0xc0008000 - 0xc089aeb8 (8780 kB) .init : 0xc089b000 - 0xc094a400 ( 701 kB) .data : 0xc094c000 - 0xc0a1dab8 ( 839 kB) .bss : 0xc0a1dab8 - 0xc0a80eb4 ( 397 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU dyntick-idle grace-period acceleration is enabled. [0.00] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] Architected cp15 timer(s) running at 24.00MHz (phys). [0.09] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 2863311519744ns [0.19] Switching to timer-based delay loop [0.001002] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns [0.001363] sched_clock: 32 bits at 160MHz, resolution 6ns, wraps every 26843545593ns [0.001801] Console: colour dummy device 80x30 [0.001837] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)
[PATCH V4 2/3] Add SD-card image build support for hd-media builds on armhf
---
build/boot/README.concatenateable_images | 20
build/config/armhf/hd-media.cfg | 25 -
debian/changelog | 1 +
3 files changed, 45 insertions(+), 1 deletion(-)
create mode 100644 build/boot/README.concatenateable_images
diff --git a/build/boot/README.concatenateable_images
b/build/boot/README.concatenateable_images
new file mode 100644
index 000..5749577
--- /dev/null
+++ b/build/boot/README.concatenateable_images
@@ -0,0 +1,20 @@
+This directory provides installer images in the form of a device-specific
+part (containing the partition table and the system firmware) and a
+device-independent part (containing the actual installer), which can be
+unpacked and concatenated together to build a complete installer image.
+
+The device-specific part is named firmware..img.gz
+and the device-independent part is named partition.img.gz.
+
+To create a complete image from the two parts on Linux systems, you can
+use zcat as follows:
+
+ zcat firmware..img.gz partition.img.gz > complete_image.img
+
+On Windows systems, you have to first decompress the two parts separately,
+which can be done e.g. by using 7-Zip, and then concatenate the decompressed
+parts together by running the command
+
+ copy /b firmware..img + partition.img complete_image.img
+
+in a Windows CMD.exe window.
diff --git a/build/config/armhf/hd-media.cfg b/build/config/armhf/hd-media.cfg
index ec119df..ce3852f 100644
--- a/build/config/armhf/hd-media.cfg
+++ b/build/config/armhf/hd-media.cfg
@@ -1,9 +1,12 @@
FLAVOUR_SUPPORTED = ""
+FLOPPY_SIZE = 4
GZIPPED = .gz
EXTRANAME = hd-media/
-TARGET = $(KERNEL) $(INITRD) hd-media_bootscript hd-media_tarball
+CONCATENATEABLE_SUFFIX =
+
+TARGET = $(KERNEL) $(INITRD) hd-media_bootscript hd-media_tarball
hd-media_images_concatenateable
MANIFEST-INITRD = "Initrd for use on USB memory sticks"
MANIFEST-KERNEL = "Kernel for use on USB memory sticks"
@@ -24,3 +27,23 @@ hd-media_tarball: $(KERNEL) $(INITRD) $(TEMP_DTBS)
hd-media_bootscript
cp boot/README.device-tree $(TEMP)/hd-media/dtbs/README
tar -C $(TEMP)/hd-media -zcf $(TEMP)/hd-media.tar.gz boot.scr initrd.gz
vmlinuz dtbs/
mv $(TEMP)/hd-media.tar.gz $(SOME_DEST)/$(EXTRANAME)
+
+.PHONY: hd-media_images_concatenateable
+hd-media_images_concatenateable: $(KERNEL) $(INITRD) $(TEMP_DTBS)
hd-media_bootscript
+ -rm -rf $(TEMP)/hd-media_images_concatenateable
+ mkdir $(TEMP)/hd-media_images_concatenateable
+ cp $(KERNEL) $(TEMP)/hd-media_images_concatenateable/vmlinuz
+ cp $(INITRD) $(TEMP)/hd-media_images_concatenateable/initrd.gz
+ cp $(SOME_DEST)/$(EXTRANAME)boot.scr
$(TEMP)/hd-media_images_concatenateable/boot.scr
+ cp -r $(TEMP_DTBS) $(TEMP)/hd-media_images_concatenateable/dtbs/
+ cp boot/README.device-tree
$(TEMP)/hd-media_images_concatenateable/dtbs/README
+ mkdir -p
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)
+ while read LINE; \
+ do \
+ if [ -n "$${LINE}" ] && ! echo $${LINE}|grep -q -e "^#"; then \
+ set -- $${LINE} ;\
+ gen-hd-image -v -z -b firmware -s "$(FLOPPY_SIZE)" -o
"$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${1}.img"
"$$2" "$$3" "$$4" "$$5" ;\
+ fi ;\
+ done < boot/arm/u-boot-image-config
+ gen-hd-image -v -z -b partition -s "$(FLOPPY_SIZE)" -i
"$(TEMP)/hd-media_images_concatenateable" -o
"$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/partition.img"
+ cp boot/README.concatenateable_images
"$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/"
diff --git a/debian/changelog b/debian/changelog
index ac4be4d..78c12a4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,6 +18,7 @@ debian-installer (20150108) UNRELEASED; urgency=medium
systems in boot/arm/bootscr.mainline_common.
* Add util/gen-hd-image (a script to create partitioned harddisk images
from a directory and optionally install a bootloader into the image).
+ * Add SD-card image build support for hd-media builds on armhf.
[ Helge Deller ]
* alpha: Switch to KERNELVERSION
--
2.1.4
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1426456116-7423-3-git-send-email-mer...@debian.org
[PATCH V4 0/3] d-i: support building bootable images for armhf targets
Hello, this patchset had been postponed to after d-i RC1 as discussions about it were still ongoing at the time for the RC1 release. I have in the meantime met Ian and Steve at FOSDEM and we have discussed the open topics there. We came to the conclusion that using the concatenateable images approach is the way to go and that the space and bandwidth used by those images does not pose a problem for the mirror network. I was busy with other topics during the last weeks, so it unfortunately took me longer than planned to strip the patchset down to the necessary parts and rebase it against the current codebase. Follwing is the updated version of the patchset. I have run successful installation tests with all image types generated by it and it builds cleanly in pbuilder, so I intend to push it to d-i master for inclusion in d-i RC2. Kibi, is that ok for you? Regards, Karsten Karsten Merker (3): Add util/gen-hd-image Add SD-card image build support for hd-media builds on armhf Add SD-card image and tftpboot tarball build support for netboot builds on armhf build/boot/README.concatenateable_images | 20 ++ build/boot/arm/bootscr.tftpboot | 21 ++ build/config/armhf/hd-media.cfg | 25 +- build/config/armhf/netboot.cfg | 50 +++- build/util/gen-hd-image | 380 +++ debian/changelog | 5 + debian/control | 5 +- debian/copyright | 5 + 8 files changed, 507 insertions(+), 4 deletions(-) create mode 100644 build/boot/README.concatenateable_images create mode 100644 build/boot/arm/bootscr.tftpboot create mode 100755 build/util/gen-hd-image -- 2.1.4 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1426456116-7423-1-git-send-email-mer...@debian.org
[PATCH V4 3/3] Add SD-card image and tftpboot tarball build support for netboot builds on armhf
---
build/boot/arm/bootscr.tftpboot | 21 +
build/config/armhf/netboot.cfg | 50 -
debian/changelog| 2 ++
3 files changed, 72 insertions(+), 1 deletion(-)
create mode 100644 build/boot/arm/bootscr.tftpboot
diff --git a/build/boot/arm/bootscr.tftpboot b/build/boot/arm/bootscr.tftpboot
new file mode 100644
index 000..c5a26f4
--- /dev/null
+++ b/build/boot/arm/bootscr.tftpboot
@@ -0,0 +1,21 @@
+if test -z "${fdtfile}"; then
+ echo 'fdtfile environment variable not set. Aborting boot process.'
+ exit 0
+fi
+
+# Some i.MX6-based systems do not encode the baudrate in the console variable
+if test "${console}" = "ttymxc0" && test -n "${baudrate}" ; then
+ setenv console "${console},${baudrate}"
+fi
+
+if test -n "${console}"; then
+ setenv bootargs "${bootargs} console=${console}"
+fi
+
+setenv installer-path "/debian-installer/armhf/"
+
+tftpboot ${fdt_addr_r} ${installer-path}dtbs/${fdtfile} \
+&& tftpboot ${kernel_addr_r} ${installer-path}vmlinuz \
+&& tftpboot ${ramdisk_addr_r} ${installer-path}initrd.gz \
+&& echo "Booting the Debian installer..." \
+&& bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
diff --git a/build/config/armhf/netboot.cfg b/build/config/armhf/netboot.cfg
index ce912c8..8ac58fd 100644
--- a/build/config/armhf/netboot.cfg
+++ b/build/config/armhf/netboot.cfg
@@ -1,7 +1,55 @@
MEDIA_TYPE = netboot image
-TARGET = $(INITRD) $(KERNEL)
+CONCATENATEABLE_SUFFIX =
+TFTP_INSTALLER_PATH = debian-installer/armhf/
+
+TARGET = $(KERNEL) $(INITRD) netboot_bootscript_sd netboot_bootscript_tftp
netboot_tarball netboot_images_concatenateable
+
EXTRANAME = $(MEDIUM)/
MANIFEST-INITRD = "netboot initrd"
MANIFEST-KERNEL = "kernel image to netboot"
+
+FLOPPY_SIZE = 4
+
+GZIPPED = .gz
+
+.PHONY: netboot_bootscript_sd
+netboot_bootscript_sd:
+ mkimage -T script -A arm -d boot/arm/bootscr.mainline_common
$(SOME_DEST)/$(EXTRANAME)boot.scr
+ update-manifest $(SOME_DEST)/$(EXTRANAME)boot.scr "Universal boot
script for mainline u-boot (>= v2014.10)"
+
+.PHONY: netboot_bootscript_tftp
+netboot_bootscript_tftp:
+ mkimage -T script -A arm -d boot/arm/bootscr.tftpboot
$(SOME_DEST)/$(EXTRANAME)tftpboot.scr
+ update-manifest $(SOME_DEST)/$(EXTRANAME)tftpboot.scr "TFTP boot script
for mainline u-boot (>= v2014.10)"
+
+.PHONY: netboot_tarball
+netboot_tarball: $(KERNEL) $(INITRD) $(TEMP_DTBS) netboot_bootscript_tftp
+ rm -rf $(TEMP)/netboot_tarball
+ mkdir -p $(TEMP)/netboot_tarball/$(TFTP_INSTALLER_PATH)
+ cp $(KERNEL) $(TEMP)/netboot_tarball/$(TFTP_INSTALLER_PATH)vmlinuz
+ cp $(INITRD) $(TEMP)/netboot_tarball/$(TFTP_INSTALLER_PATH)initrd.gz
+ cp -r $(TEMP_DTBS) $(TEMP)/netboot_tarball/$(TFTP_INSTALLER_PATH)dtbs/
+ cp $(SOME_DEST)/$(EXTRANAME)tftpboot.scr
$(TEMP)/netboot_tarball/$(TFTP_INSTALLER_PATH)
+ tar -C $(TEMP)/netboot_tarball/ -zcf
$(SOME_DEST)/$(EXTRANAME)netboot.tar.gz $(TFTP_INSTALLER_PATH)tftpboot.scr
$(TFTP_INSTALLER_PATH)initrd.gz $(TFTP_INSTALLER_PATH)vmlinuz
$(TFTP_INSTALLER_PATH)dtbs/
+
+.PHONY: netboot_images_concatenateable
+netboot_images_concatenateable: $(KERNEL) $(INITRD) $(TEMP_DTBS)
netboot_bootscript_sd
+ -rm -rf $(TEMP)/netboot_images_concatenateable
+ mkdir $(TEMP)/netboot_images_concatenateable
+ cp $(KERNEL) $(TEMP)/netboot_images_concatenateable/vmlinuz
+ cp $(INITRD) $(TEMP)/netboot_images_concatenateable/initrd.gz
+ cp $(SOME_DEST)/$(EXTRANAME)boot.scr
$(TEMP)/netboot_images_concatenateable/boot.scr
+ cp -r $(TEMP_DTBS) $(TEMP)/netboot_images_concatenateable/dtbs/
+ cp boot/README.device-tree
$(TEMP)/netboot_images_concatenateable/dtbs/README
+ mkdir -p
$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)
+ while read LINE; \
+ do \
+ if [ -n "$${LINE}" ] && ! echo $${LINE}|grep -q -e "^#"; then \
+ set -- $${LINE} ;\
+ gen-hd-image -v -z -b firmware -s "$(FLOPPY_SIZE)" -o
"$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/firmware.$${1}.img"
"$$2" "$$3" "$$4" "$$5" ;\
+ 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"
+ cp boot/README.concatenateable_images
"$(SOME_DEST)/$(EXTRANAME)/SD-card-images/$(CONCATENATEABLE_SUFFIX)/"
diff --git a/debian/changelog b/debian/changelog
index 78c12a4..1344a62 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -19,6 +19,8 @@ debian-installer (20150108) UNRELEASED; urgency=medium
* Add util/gen-hd-image (a script to create partitioned harddisk images
from a directory and optionally install a bootloader into the image).
* Add SD-card image build support for hd-media builds on armhf.
+ * Add SD-card image and tftpboot tarball
[PATCH V4 1/3] Add util/gen-hd-image
gen-hd-image creates partitioned harddisk images from a directory
tree and optionally installs a bootloader into the image. Supported
target filesystems are fat16, fat32 and ext2.
Its main use is building bootable images for armhf/armel/arm64
systems which use u-boot as their system firmware. U-boot
requires the boot device to have an MBR-style partition table,
therefore booting from "superfloppy" style images (like they
are built by d-i for i386/amd64 systems) does not work there.
---
build/util/gen-hd-image | 380
debian/changelog| 2 +
debian/control | 5 +-
debian/copyright| 5 +
4 files changed, 390 insertions(+), 2 deletions(-)
create mode 100755 build/util/gen-hd-image
diff --git a/build/util/gen-hd-image b/build/util/gen-hd-image
new file mode 100755
index 000..13913f0
--- /dev/null
+++ b/build/util/gen-hd-image
@@ -0,0 +1,380 @@
+#!/bin/sh
+#
+# gen-hd-image V1.01
+# Copyright 2014,2015 by Karsten Merker
+#
+# This file is dual-licensed. It is provided under (at your option)
+# either the terms of the GPL2+ or the terms of the X11 license as
+# described below. Note that this dual licensing only applies to this
+# file, and not this project as a whole.
+#
+# License options:
+#
+# - Option "GPL2+":
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of the
+# License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public
+# License along with this program; if not, write to the Free
+# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+# On Debian systems, the full text of the GPL version 2 is
+# available in the file /usr/share/common-licenses/GPL-2.
+#
+# - or, alternatively, option "X11":
+#
+# Permission is hereby granted, free of charge, to any person
+# obtaining a copy of this software and associated documentation
+# files (the "Software"), to deal in the Software without
+# restriction, including without limitation the rights to use,
+# copy, modify, merge, publish, distribute, sublicense, and/or
+# sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following
+# conditions:
+#
+# The above copyright notice and this permission notice shall be
+# included in all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+# OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+# OTHER DEALINGS IN THE SOFTWARE.
+
+PATH="${PATH}:/bin:/sbin:/usr/bin:/usr/sbin"
+export PATH
+
+FSTYPE="fat32"
+PARTID="0x0c"
+FATSIZE="32"
+BUILDTYPE="complete"
+SOURCEDIR="."
+PARTOFFSET="2048"
+DEFAULT_IMAGESIZE="976560" # default d-i FLOPPY_SIZE for hd-media images
+IMAGESIZE="${DEFAULT_IMAGESIZE}"
+COMPRESS="none"
+COMPRESS_OPTS=""
+VERBOSITY="0"
+PREREQUISITES="fmt sfdisk"
+PREREQUISITES_MISSING=""
+
+log()
+{
+ if [ "${VERBOSITY}" -gt 0 ]; then
+echo "$(basename $0): $1"
+ fi
+}
+
+error()
+{
+ echo "$(basename $0): $1" 1>&2
+}
+
+clean_tempfiles()
+{
+ [ -f "${TEMP_FS_IMAGEFILE}" ] && rm -f "${TEMP_FS_IMAGEFILE}"
+ [ -f "${TEMP_HD_IMAGEFILE}" ] && rm -f "${TEMP_HD_IMAGEFILE}"
+}
+
+check_prerequisites()
+{
+ for TOOL in $1
+ do
+which >/dev/null ${TOOL}
+if [ ! "$?" -eq 0 ]; then
+ PREREQUISITES_MISSING="${PREREQUISITES_MISSING}${TOOL} "
+fi
+ done
+ if [ -n "${PREREQUISITES_MISSING}" ]; then
+error "ERROR: The following programs are unavailable, but required"
+error "ERROR: for the selected options: ${PREREQUISITES_MISSING}"
+error "ERROR: Exiting."
+exit 1
+ fi
+}
+
+usage()
+{
+ fmt -w 75 -s </dev/null if=/dev/zero bs=1k of="${TEMP_HD_IMAGEFILE}"
seek=$((${IMAGESIZE}-1)) count=1
+sfdisk --force -u S "${TEMP_HD_IMAGEFILE}" 1>/d
Bug#706583: Installation report Wheezy DI rc2 amd64 xfce: installation ok
Package: installation-reports Boot method: isohybrid image booted from USB stick Image version: http://cdimage.debian.org/cdimage/wheezy_di_rc2/amd64/iso-cd/debian-wheezy-DI-rc2-amd64-netinst.iso Date: 2013-05-01 Mainboard: ECS P35T-A Processor: Intel E3300 Memory: 4GB Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] (rev 02) 00:01.0 PCI bridge [0604]: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port [8086:29c1] (rev 02) 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DC-2 Gigabit Network Connection [8086:294c] (rev 02) 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) 00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 02) 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 02) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 02) 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 02) 00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 02) 00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 [8086:2946] (rev 02) 00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 [8086:2948] (rev 02) 00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 02) 00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 02) 00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 02) 00:1d.3 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 02) 00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 92) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IH (ICH9DH) LPC Interface Controller [8086:2912] (rev 02) 00:1f.2 IDE interface [0101]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA Controller [IDE mode] [8086:2920] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02) 00:1f.5 IDE interface [0101]: Intel Corporation 82801I (ICH9 Family) 2 port SATA Controller [IDE mode] [8086:2926] (rev 02) 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV505 [Radeon X1550 Series] [1002:7143] 01:00.1 Display controller [0380]: Advanced Micro Devices [AMD] nee ATI RV505 [Radeon X1550 Series] (Secondary) [1002:7163] 06:00.0 SATA controller [0106]: JMicron Technology Corp. JMB361 AHCI/IDE [197b:2361] (rev 02) 06:00.1 IDE interface [0101]: JMicron Technology Corp. JMB361 AHCI/IDE [197b:2361] (rev 02) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: The installation process worked flawlessly. Installation was done using a network mirror; network connectivity was provided via a TP-Link TL-WN727N 802.11n WLAN dongle (USB ID: 148f:5370, Ralink RT5370 chipset). The installer prompted for the WLAN dongle's firmware, which was provided on a USB stick (downloaded from http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/wheezy/current/). Basic X11 functionality worked out of the box, advanced X11 features (in particular XVideo support) required installation of the non-free radeon firmware from the package firmware-linux-nonfree. A sidenote: while the WLAN via the TL-WN727N generally works, interactive use (in particular using logins via ssh) shows that the connection often has short lags or hangs. This happens even when the WLAN dongle is within 2m of the access point with direct line of sight. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130501225255.ga7...@excalibur.cnev.de
Bug#868166: flash-kernel: Patch for Radxa Rock2 Square support
Control: tags 868166 pending On Wed, Jul 12, 2017 at 03:57:13PM +, Eva Ramon wrote: > Package: flash-kernel > Version: 3.82 > Severity: wishlist > > Dear Maintainer, > > please apply the patch provided in order to add support for the Radxa Rock2 > Square board to flash-kernel. > > --- /usr/share/flash-kernel/db/all.db.old 2017-07-12 15:08:15.380566406 > + > +++ /usr/share/flash-kernel/db/all.db 2017-07-12 15:08:34.300272594 + > @@ -378,6 +378,13 @@ > U-Boot-Script-Name: bootscr.uboot-generic > Required-Packages: u-boot-tools > > +Machine: Radxa Rock 2 Square > +Kernel-Flavors: armmp armmp-lpae > +DTB-Id: rk3288-rock2-square.dtb > +Boot-Script-Path: /boot/boot.scr > +U-Boot-Script-Name: bootscr.uboot-generic > +Required-Packages: u-boot-tools > + > Machine: Freescale i.MX53 Quick Start Board > Machine: Freescale MX53 LOCO Board > Kernel-Flavors: armmp mx5 > > Thanks! Hello, many thanks for the patch submission. The machine db entry has been added to the flash-kernel git repository and will enter the archive on the next package upload (probably in a few days). Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#881969: making bootable SD cards
Control: severity 881969 wishlist [CCing Vagrant Cascadian, the Debian u-boot maintainer] On Thu, Nov 16, 2017 at 07:54:42PM -0400, Joey Hess wrote: > Package: flash-kernel > Version: 3.87 > Severity: normal > > Therefore you usually have to setup an SD card with the appropriate u-boot > version for your particular device (see below) as a prerequisite for > installing Debian. If you use the pre-made SD card images with the > installer, this step is not necessary, as these images already contain > u-boot. > -- https://wiki.debian.org/InstallingDebianOn/Allwinner > > This seems to fall squarely in flash-kernel's wheelhouse, since it > already handles the other parts of u-boot installation, and it knows > the name of the board being installed. > > The d-i SD card images avoid the problem, but they are only one way to > install; there are even other ways to use d-i to install that need this > manual step first. > > The main difficulty in putting it in flash-kernel is that it might be > installed in a chroot in a situation where it should not be altering > the boot sector of the host's disk. So, something like grub-installer > seems to be called for, so the user specifies the device to install to. > > A utility in flash-kernel would be much nicer than needing to puzzle out dd > commands from README.Debian files and hope you got it right. I'm currently > having to embed those dd commands inside propellor; they're also embedded > inside debian-installer (build/boot/arm/u-boot-image-config). Hello, to use d-i/flash-kernel on the target device, one obviously needs to already have put a u-boot onto the device in some form (such as preinstalled in the d-i SD card images), otherwise one couldn't have booted it, i.e. flash-kernel could only cover the topic of updating u-boot from within a running system. There has been a discussion about the latter in the past and the consensus reached at that time was that it is practically impossible to safely determine the version of an already installed u-boot image in a platform-independant way, and installing u-boot unconditionally on every invocation of flash-kernel is considered too riscy as there are a number of unsolved problems with such an approach. Among the points of this discussion were: - On some devices u-boot isn't stored on an SD card but on an onboard SPI flash chip with a rather limited number of write cycles (in the area of ~1000) and no defects management. Unconditionally writing u-boot on every invocation of flash-kernel (which includes everything that modifies the initrd) would have the potential to kill these devices in comparatively short time. - Knowing the device type one is running on isn't necessarily enough. Several supported devices are available in different hardware configuration variants that influence where the u-boot image can get written to (SD card, onboard eMMC, onboard raw NAND, SPI flash, and combinations thereof). Once Linux is running, there is no way to determine where the u-boot that brought the system up was loaded from. Flash-kernel pulls the system type from a /proc entry, but that doesn't provide the information whether the current device e.g. has the SPI flash for u-boot populated or not, and if yes, whether it has actually been used for booting the system, so flash-kernel cannot decide without user-interaction where to write the u-boot image. - As u-boot is more than just a bootloader - it also provides BIOS-like functionality - there can be a major difference between messing up automatically installing GRUB and messing up automatically installing u-boot. In the GRUB case, the user can simply boot a rescue system and fix the bootloader. In case of a broken u-boot installation to an SPI flash or to an eMMC on systems where these have a higher boot priority than the SD slot, the system can be completely dead and require specific hardware tooling (such as an external SPI flasher) to revive the system again. As a result of these issues, it was deemed unsuitable for flash-kernel to attempt installing u-boot. What we might do sometime in the future is adding a u-boot-installer udeb to d-i which on a very limited subset of systems allows the user to explicitly decide to install u-boot to a user-selected device (such as eMMC or SPI flash) after being informed about the riscs of doing so. I had started designing a proof-of-concept for such a udeb, but have had to put that on hold due to having to take care of a number of higher-priority issues. I'm setting the severity of this bug down from "normal" to "wishlist" as it is about requesting the addition of a new feature and not about a bug in existing functionality. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#885712: libdebian-installer should not use -Werror
Control: tag 885712 pending On Fri, Dec 29, 2017 at 01:36:47PM +0100, Helmut Grohne wrote: > Source: libdebian-installer > Version: 0.112 > Severity: wishlist > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > > The packaging of libdebian-installer insterts a -Werror into CFLAGS. > This has caused FTBFS with gcc-6 and gcc-7 already and will cause more > FTBFS with gcc-8. Given that these issues are not fixed proactively, it > complicates architecture bootstrap, which somestimes has to use > unreleased compilers. I thus ask you to disable use of -Werror. This > avoids unexpected FTBFS. I still recommend doing maintainer builds with > -Werror to catch issues early. Just save everyone else from the fallout > please. > > Helmut > diff --minimal -Nru libdebian-installer-0.112/debian/changelog > libdebian-installer-0.112+nmu1/debian/changelog > --- libdebian-installer-0.112/debian/changelog2017-11-19 > 18:12:25.0 +0100 > +++ libdebian-installer-0.112+nmu1/debian/changelog 2017-12-29 > 13:32:02.0 +0100 > @@ -1,3 +1,10 @@ > +libdebian-installer (0.112+nmu1) UNRELEASED; urgency=medium > + > + * Non-maintainer upload. > + * Do not compile with -Werror by default. Closes: #-1. > + > + -- Helmut Grohne Fri, 29 Dec 2017 13:32:02 +0100 > + > libdebian-installer (0.112) unstable; urgency=medium > >[ Reiner Herrmann ] > diff --minimal -Nru libdebian-installer-0.112/debian/rules > libdebian-installer-0.112+nmu1/debian/rules > --- libdebian-installer-0.112/debian/rules2017-11-19 17:26:42.0 > +0100 > +++ libdebian-installer-0.112+nmu1/debian/rules 2017-12-29 > 13:31:59.0 +0100 > @@ -6,7 +6,7 @@ > DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) > > #CFLAGS = -Wall -W -Werror -ggdb -Wstrict-prototypes -Wmissing-declarations > -Wmissing-prototypes > -CFLAGS = -Wall -W -Werror -ggdb -Wmissing-declarations > +CFLAGS = -Wall -W -ggdb -Wmissing-declarations > > ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) > CFLAGS += -O0 Hello, the patch has been applied to the libdebian-installer git repository. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Bug#887139: d-i daily 2018-01-14 amd64 damages UEFI setup on Fujitsu Lifebook AH532
Package: installation-reports Version: 2.66 Severity: critical -- Package-specific info: Boot method: Netinstall CD image from USB stick Image version: https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo dated 2018-01-14 04:22 Date: 2018-01-14 Machine: Fujitsu Lifebook AH532, first version (with BIOS version 1.09) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Problems: Short summary: The installation process completed successfully, but the UEFI firmware is broken afterwards; it is impossible to get into the UEFI setup, boot from any external device anymore or get the system to use the CSM to boot from a classical MBR. Detailed description: This was an installation in EFI mode (for the first time on this device). The system was previously running an older BIOS-mode installation without problems, but got a new, bigger harddisk and therefore required a new installation which was done in EFI mode (which is nowadays the default mode the installer starts in). The installation itself worked without problems and the resulting Debian system works fine, but it isn't possible anymore to get into the BIOS/UEFI setup of the machine nor boot from any other device. When powering on the system, the message ": Boot Menu, : BIOS Setup" appears (as always), pressing F2 results in a short "Please wait..." (als always), but then one doesn't get into the UEFI/BIOS setup but instead the system directly boots GRUB. Pressing F12 for the boot menu results in a screen with a menu with the following structure: - Boot Menu debian - Application Menu Diagnostic Screen "Diagnostic Screen" just shows the Firmware splash screen: "Phoenix SecureCore Tiano(TM) Copyright 1985-2011 Phoenix Technologies Ltd. All Rights Reserved Fixed Disk: ATAPI CDROM: Press any key to exit" and the "debian" boot menu entry obviously starts GRUB. There is no way to make the system boot from any external device anymore, so it is impossible to boot a rescue system or reinstall the device from scratch. Fallback to BIOS-mode booting also doesn't work any more. Plugging back the the old harddisk with a BIOS-mode install results in a non-booting system. The UEFI/BIOS always tries to boot the "debian" EFI entry which for obvious reasons doesn't work with a BIOS-mode setup on the disk. There is also a Window 7 UEFI-mode installation on the (new) disk, which can be started from GRUB, but it doesn't show up any more in the firmware-provided boot-menu (which it did before installing Debian). Running "efibootmgr -v" from the installed systems results in "No BootOrder is set; firmware will attempt recovery", which is what doesn't seem to work. It somewhat looks like the UEFI/BIOS setup, the Firmware-level boot menu and the CSM for BIOS-mode booting are EFI applications that cannot be started anymore because some NVRAM entry is broken. BIOS Information from dmidecode: Vendor: FUJITSU // Phoenix Technologies Ltd. Version: Version 1.09 Release Date: 05/22/2012 Address: 0xE Runtime Size: 128 kB ROM Size: 4096 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported 3.5"/720 kB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 1.9 This is the newest BIOS version that is available for this device; newer versions (2.xx) are only available for a newer board revision and are not compatible with this board revision. How can one bring the NVRAM back into a sane state that allows getting into the setup and booting from external devices? Regards, Karsten Technical information about the system: --
Bug#892935: libdebian-installer: Please add support for "nodoc" build options and profile
Control: tags 892935 pending On Wed, Mar 14, 2018 at 06:29:24PM +0100, Manuel A. Fernandez Montecelo wrote: > Source: libdebian-installer > Version: 0.114 > Severity: wishlist > Tags: patch > User: debian-ri...@lists.debian.org > Usertags: riscv64 > > Hi, > > We need changes in this package to help to bootstrap the riscv64 architecture, > in particular it will help to skip using doxygen (in a clean way) for the time > being. > > It will be available at some point in the future, but it's complicate to have > it > in the initial stages, due to the build-depends needed (particularly > yui-compressor and ruby-compass at this moment). This is probably the case > for > any other architecture being bootstrapped now or in the near future. > > I am attaching a patch that makes possible to compile the package by using > profiles (or options) "nodoc", avoiding the dependency in d/control (with > profile) and avoiding those files. The profile helps to avoid the > build-dependency entirel, not needing to force to build with missing > dependencies. > > Besides that, "nodoc" is a standard build option that would be nice to have in > any case. > > Please consider applying the patch (that I will upload in minutes, to have a > bug > number) or providing some alternative solution to the same effect. Looks good to me and local testbuilds haven't shown any problems. The patch has been committed to the libdebian-installer git repository; the CI build on jenkins was successful. I intend to upload the package with the patch included on the weekend unless somebody @debian-boot should voice objections. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Accepted libdebian-installer 0.115 (source armhf) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 16 Mar 2018 18:39:58 +0100 Source: libdebian-installer Binary: libdebian-installer4 libdebian-installer4-dev libdebian-installer4-udeb libdebian-installer-extra4 libdebian-installer-extra4-udeb Architecture: source armhf Version: 0.115 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Karsten Merker Description: libdebian-installer-extra4 - Library of some extra debian-installer functions libdebian-installer-extra4-udeb - Library of some extra debian-installer functions (udeb) libdebian-installer4 - Library of common debian-installer functions libdebian-installer4-dev - Library of common debian-installer functions libdebian-installer4-udeb - Library of common debian-installer functions (udeb) Closes: 892935 Changes: libdebian-installer (0.115) unstable; urgency=medium . * Team upload. . [ Manuel A. Fernandez Montecelo ] * Support "nodoc" in DEB_BUILD_PROFILES and DEB_BUILD_OPTIONS (Closes: #892935) Checksums-Sha1: e37a3e031d22d67ded30152e33fd41b5be8022a5 2231 libdebian-installer_0.115.dsc ad1f60f9c2b5a7dabcbca00ebce442002a1d35b5 71704 libdebian-installer_0.115.tar.xz e74d5c42280956d51390d0c8f8155efebf5e4081 7940 libdebian-installer-extra4-dbgsym_0.115_armhf.deb 68623338f150017043772cfffab2993d9bc97d5c 3124 libdebian-installer-extra4-udeb_0.115_armhf.udeb 104dfb51bee6e15bedfec66a563fcd3839bd14df 16036 libdebian-installer-extra4_0.115_armhf.deb 89a1545717b9527217936c75938d187880c2c48a 55016 libdebian-installer4-dbgsym_0.115_armhf.deb 46b43413abe96c3eef28f3be4b6b243733d1fe67 177440 libdebian-installer4-dev_0.115_armhf.deb db3b24f8a5d70d99a46ab4d56542c95415dcd70f 15296 libdebian-installer4-udeb_0.115_armhf.udeb 36c3abdef1af73ad921e41965f46516ca590ad20 28168 libdebian-installer4_0.115_armhf.deb 3c2251bcb792f105cf70714cea70e19b340f9044 7592 libdebian-installer_0.115_armhf.buildinfo Checksums-Sha256: fa09a4681430126818b7eef04cf02c8bb2406e287fb83d0370b3cd4c1c266a8a 2231 libdebian-installer_0.115.dsc 657c382fefd4b28c4d7400ff1ce2ef8ff43fb15020dfbfcc76779d40079aae6d 71704 libdebian-installer_0.115.tar.xz fed5aa507c2ff633df0c4fc179b76361b0d7b0e7e53885492c2af67981a1584c 7940 libdebian-installer-extra4-dbgsym_0.115_armhf.deb cd1fd3eafe0cf7ce0b4e77a1e3224c8a9cecf711ac31a42ebf78abdb4dd23a23 3124 libdebian-installer-extra4-udeb_0.115_armhf.udeb eaca7b00b5c06ff2770d1387af74f7344859c012dbd638b63a0209a9d89c68ff 16036 libdebian-installer-extra4_0.115_armhf.deb cc58bb98ff8d071489d5b57a0eb96e9b3ca833b6915d80c005af2320049675c4 55016 libdebian-installer4-dbgsym_0.115_armhf.deb a0c4efcc8f98b9d918294cf230c606e57ec405f7067f111d6e1f82047f7f56ee 177440 libdebian-installer4-dev_0.115_armhf.deb 0397b9df8f37dfa6757ad6078c315517ca680201dd66a66c641f18ea884f9bdb 15296 libdebian-installer4-udeb_0.115_armhf.udeb c82c03db71a3092ced18cb182ec0ea2dee0b8c43f20062be2d331e6f716beadb 28168 libdebian-installer4_0.115_armhf.deb 63ae19b4f0c36e1bea6e03060d9bd7cb1cf9289ebf805f5778b69d9ef748737d 7592 libdebian-installer_0.115_armhf.buildinfo Files: 130358424283e01a5f25f7fd804cf57d 2231 libs optional libdebian-installer_0.115.dsc 085ed9b5ef2555ba745567600a914047 71704 libs optional libdebian-installer_0.115.tar.xz e7ee726f293a46284fcd4a327fc213e9 7940 debug optional libdebian-installer-extra4-dbgsym_0.115_armhf.deb e14a27a612317e4157f543b54d3d3574 3124 debian-installer optional libdebian-installer-extra4-udeb_0.115_armhf.udeb d5a77b27e99695e793b0065139b978e1 16036 libs optional libdebian-installer-extra4_0.115_armhf.deb 6770ec5965d6b6af69d466539c707cf1 55016 debug optional libdebian-installer4-dbgsym_0.115_armhf.deb de84c953bf252c7ecc71af16b0de17a0 177440 libdevel optional libdebian-installer4-dev_0.115_armhf.deb 993cb8458eb1a815c62e7889fef0269e 15296 debian-installer optional libdebian-installer4-udeb_0.115_armhf.udeb 76789f419e200b2e02abfae5c8ef37f2 28168 libs optional libdebian-installer4_0.115_armhf.deb 622b80497ebd1ef02ccd73a16fa6b306 7592 libs optional libdebian-installer_0.115_armhf.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEn93aiCIaVkMmfHVORqBfr9bZ1iQFAlqsBWwACgkQRqBfr9bZ 1iTHBg//YyOzyqxI/vor4nF9oADKMMynQaYTrodOlcMes8jcMyoa7fr9L0sWPeo4 SBcgnJT2Dqx76ER2oDNvZGQC38n2fhNlgepiaXZR471iYdm8wvp821E6iAXXbZti cecl0yufWT5o2PLAtWqru9zvm/iGmR/589yYk9M0jw4V94ZLvi3OPCBw8AcboDJW h/rnQTXoqsEo0iaWv3Cubu6cBKLg29ISIhjSWO7baXk6uzg8B4gY1z5HMPBi19C+ urkZT8JGYAyGJntkENp+XtFB6kzL8lgl6WN/w1+3VdLn+Eq1L3Eebuh1kJIx7MiQ dLgPKxSdxKDcGugRIb+nwOGnv9aXFXxvnClXkSBGU0gq49npL3hKKZPNIi8biOuU qvHoliCyhMAyqJ0I5sk2c/M6uS5ZaZhRE+LO8zlErpF2NYe6RTxH/fGA2qlt/4aA kxXCXIDtXqSVKlpOoh/8H+spEEw6rPHXBDCuwEGxE1ldDBYrn2DsXnJm5xBR3Vfl WOv/38zvlv2zQNhz0cIfbO6PJDx2QmlhQ4zwXf/wTvKSumT0jZWL9RXHzcPxQHrx vdLr0GfYh5rttd758JOyrmIzz8nONoRFiiFVGWv/aURllrtnZ2ttmA34c8ZMPHkl q1h/jp0X2dbvdtMV+cFoS+FgnsFOiF6S1YoarllfwRlgqDZ89IE= =wrlc -END PGP SIGNATURE-
Bug#893300: cdebconf: Adding support for a pkg.cdebconf.nogtk build-profile
Package: cdebconf
Version: 0.241
Priority: wishlist
X-Debbugs-CC: Cyril Brulebois , Christian Perrier
, Regis Boudin , Colin Watson
, debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64
[CCing the uploaders for cdebconf]
Hello,
I would like to add support for a "pkg.cdebconf.nogtk" build-profile
to cdebconf. Background for that is that cdebconf (in particular
libdebconfclient0) is needed rather early in the process of
bootstrapping a new Debian architecture, but getting it built during
early architecture bootstrap is difficult due to its build-dependency
on gtk+cairo, which pulls in an enormous list of transitive
build-dependencies that are effectively impossible to fullfill in a
bootstrap scenario.
AIUI, the only binary packages built from the cdebconf source package
that actually need gtk+cairo are cdebconf-gtk and cdebconf-gtk-udeb,
and these aren't required during an architecture bootstrap, so the
approach is to add a build-profile that does two things when set:
- disable building of these two binary packages
- remove the gtk+cairo build-dependency
Attached is a patch that implements that. As nothing changes when
the build-profile isn't explicitly activiated, this should be a
low-risc modification, but as I normally don't work on cdebconf, I
would like to gather feedback from the regular uploaders (in CC)
whether you see some reason to object to this change.
The debdiff between a standard build and a build with the
build-profile set is clean; the only difference with the
build-profile enabled is that the gtk-related binary packages
aren't built.
If the patch is ok for you, I'll apply it to cdebconf git and
upload a new version.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
>From acd6f9d3065137727e7c372c306cda67adfff9b9 Mon Sep 17 00:00:00 2001
From: Karsten Merker
Date: Thu, 15 Mar 2018 20:10:33 +
Subject: [PATCH] Add a pkg.cdebconf.nogtk build-profile.
When the pkg.cdebconf.nogtk profile is set, the build-dependency on
gtk and cairo gets removed and the cdebconf-gtk and cdebconf-gtk-udeb
binary packages (which are the only ones actually depending on gtk
and cairo) aren't built. This is important when bootstrapping a new
architecture as cdebconf is required for building the essential
package set and a dependency on gtk and cairo pulls in an enormous
list of transitive build-dependencies that are effectively impossible
to fullfill in a bootstrap scenario.
---
debian/control | 6 --
debian/rules | 8
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/debian/control b/debian/control
index 1a194849..b87c0861 100644
--- a/debian/control
+++ b/debian/control
@@ -9,8 +9,8 @@ Build-Depends:
libtextwrap-dev (>= 0.1-5),
libdebian-installer4-dev (>= 0.41) | libdebian-installer-dev,
libglib2.0-dev (>= 2.31),
- libgtk2.0-dev (>= 2.24),
- libcairo2-dev (>= 1.8.10-3),
+ libgtk2.0-dev (>= 2.24) ,
+ libcairo2-dev (>= 1.8.10-3) ,
libselinux1-dev (>= 2.3) [linux-any] | libselinux-dev [linux-any],
dh-autoreconf,
dh-exec,
@@ -42,6 +42,7 @@ Section: admin
Depends: cdebconf, ${shlibs:Depends}, ${misc:Depends}
Replaces: cdebconf (<< 0.144)
Priority: extra
+Build-Profiles:
Description: Gtk+ frontend for Debian Configuration Management System
Debconf is a configuration management system for Debian packages. It is
used by some packages to prompt you for information before they are
@@ -151,6 +152,7 @@ Architecture: any
Section: debian-installer
Depends: cdebconf-udeb, ${shlibs:Depends}, ${misc:Depends}, rootskel-gtk [!s390 !s390x]
Package-Type: udeb
+Build-Profiles:
Description: Gtk+ frontend for Debian Configuration Management System
Debconf is a configuration management system for Debian packages. It is
used by some packages to prompt you for information before they are
diff --git a/debian/rules b/debian/rules
index b2b35f4d..8b85a7af 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,6 +21,11 @@ LIBDEBCONF=libdebconfclient0
DEB_FRONTENDS=passthrough text newt gtk
UDEB_FRONTENDS=passthrough text newt gtk
+ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
+DEB_FRONTENDS:=$(filter-out gtk,$(DEB_FRONTENDS))
+UDEB_FRONTENDS:=$(filter-out gtk,$(UDEB_FRONTENDS))
+endif
+
ifeq ($(DEB_HOST_ARCH_OS),linux)
SELINUXFLAG=--enable-selinux
else
@@ -128,6 +133,9 @@ binary-arch: install-arch
dh_installdocs -s
dh_installdebconf -s
dh_installdirs -s
+ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
+ dh_install -plibdebconfclient0-dev src/modules/frontend/gtk/cdebconf_gtk.h usr/include/cdebconf/
+endif
dh_lintian -s
dh_strip -s
dh_compress -s
--
2.11.0
Bug#893300: cdebconf: Adding support for a pkg.cdebconf.nogtk build-profile
On Mon, Mar 26, 2018 at 12:47:18AM +0100, Colin Watson wrote: > On Sat, Mar 17, 2018 at 09:09:11PM +0100, Karsten Merker wrote: > > I would like to add support for a "pkg.cdebconf.nogtk" build-profile > > to cdebconf. Background for that is that cdebconf (in particular > > libdebconfclient0) is needed rather early in the process of > > bootstrapping a new Debian architecture, but getting it built during > > early architecture bootstrap is difficult due to its build-dependency > > on gtk+cairo, which pulls in an enormous list of transitive > > build-dependencies that are effectively impossible to fullfill in a > > bootstrap scenario. > > This approach and patch looks good to me. I'm OK with you committing > and uploading it, modulo the comments below. > > > diff --git a/debian/rules b/debian/rules > > index b2b35f4d..8b85a7af 100755 > > --- a/debian/rules > > +++ b/debian/rules > > @@ -21,6 +21,11 @@ LIBDEBCONF=libdebconfclient0 > > DEB_FRONTENDS=passthrough text newt gtk > > UDEB_FRONTENDS=passthrough text newt gtk > > > > +ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),) > > +DEB_FRONTENDS:=$(filter-out gtk,$(DEB_FRONTENDS)) > > +UDEB_FRONTENDS:=$(filter-out gtk,$(UDEB_FRONTENDS)) > > +endif > > I think this would be clearer reversed, i.e.: > > DEB_FRONTENDS=passthrough text newt > UDEB_FRONTENDS=passthrough text newt > > ifeq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),) > DEB_FRONTENDS+=gtk > UDEB_FRONTENDS+=gtk > endif That's probably a matter of taste :-). I found it clearer to have the primary DEB_FRONTENDS and UDEB_FRONTENDS assignments to always represent the default case when no build-profiles are enabled and only modify them in the "non-standard" case of having a build-profile set. If you have a strong preference for the "additive" version instead of the "subtractive" version, please let me know and I'll change that. > > +ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),) > > + dh_install -plibdebconfclient0-dev > > src/modules/frontend/gtk/cdebconf_gtk.h usr/include/cdebconf/ > > +endif > > I think I may understand what this is doing now after some confusion, > but it's pretty opaque and definitely needs at least a comment. I think > you're trying to keep the package contents identical regardless of build > profile, since the main build system won't handle it in this case due to > the change in *_FRONTENDS? Exactly. I'll add a comment explaining that. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
Accepted cdebconf 0.243 (source armhf all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 26 Mar 2018 23:48:46 +0200 Source: cdebconf Binary: cdebconf cdebconf-gtk libdebconfclient0 libdebconfclient0-dev cdebconf-udeb cdebconf-priority libdebconfclient0-udeb cdebconf-text-udeb cdebconf-newt-udeb cdebconf-gtk-udeb Architecture: source armhf all Version: 0.243 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Karsten Merker Description: cdebconf - Debian Configuration Management System (C-implementation) cdebconf-gtk - Gtk+ frontend for Debian Configuration Management System cdebconf-gtk-udeb - Gtk+ frontend for Debian Configuration Management System (udeb) cdebconf-newt-udeb - Newt frontend for Debian Configuration Management System (udeb) cdebconf-priority - Change debconf priority (udeb) cdebconf-text-udeb - Plain text frontend for Debian Configuration Management System (udeb) cdebconf-udeb - Debian Configuration Management System (C-implementation) (udeb) libdebconfclient0 - Debian Configuration Management System (C-implementation library) libdebconfclient0-dev - Development files for cdebconf libdebconfclient0-udeb - Debian Configuration Management System (C-implementation) (udeb) Closes: 893300 Changes: cdebconf (0.243) unstable; urgency=medium . * Team upload. . [ Karsten Merker ] * Add support for a pkg.cdebconf.nogtk build-profile that allows building a subset of cdebconf's binary packages without requiring gtk and cairo. (Closes: #893300) Checksums-Sha1: 6140f64b92e44566b91c4e413df2355bf15db4ee 2776 cdebconf_0.243.dsc 597c9283268900ecf2a441be6085d4e6421ce817 274404 cdebconf_0.243.tar.xz 31a5fb560fa946b7a9a0d6ab03d075effc68c2e9 249928 cdebconf-dbgsym_0.243_armhf.deb ceaa77341e7461bbbdec4579a380b026dcff26f3 104248 cdebconf-gtk-dbgsym_0.243_armhf.deb 629e9897616cdf7d4e6b61a8733d558c092c24fa 25148 cdebconf-gtk-udeb_0.243_armhf.udeb 68b8c5bbaec2c3fb7849df49e105d0f406fd037b 69572 cdebconf-gtk_0.243_armhf.deb 5d7eea2a00bc7f37c6b99612274a289de54e3f06 17684 cdebconf-newt-udeb_0.243_armhf.udeb faeaf8ba0deb44dd66f11eb5f1213f3ea4a3b64a 2884 cdebconf-priority_0.243_all.udeb af20ed5b5630f3ea47f6bf6a488d5691906e3c21 21732 cdebconf-text-udeb_0.243_armhf.udeb ab28fb06d60647370c2f42910cc67b3dc74a6924 66740 cdebconf-udeb_0.243_armhf.udeb 1bb7080078be7a1d2cfa81aaa5d9269980ab00f4 13855 cdebconf_0.243_armhf.buildinfo 310e8b982ffacf11af66fc4983f91b2ba0ba7e73 162372 cdebconf_0.243_armhf.deb a5cc674c599a887d22d85036d564071b8e5c245b 6096 libdebconfclient0-dbgsym_0.243_armhf.deb 10d4168188d97ab8a756458070a5994b6d57c369 53044 libdebconfclient0-dev_0.243_armhf.deb 301b8361f37a84dea51d79619cc50362f521aece 2896 libdebconfclient0-udeb_0.243_armhf.udeb 463f572b76a1337c95f7cc872d78e268fe8ae928 48068 libdebconfclient0_0.243_armhf.deb Checksums-Sha256: 5e48c96251a4d00413ba02a0f86945d6f3412595b15fb91390b50731127cd92c 2776 cdebconf_0.243.dsc e4c2f47f0ea040e4d18b881cb78b108d125881cfcedeb26f2a0e318fbea40397 274404 cdebconf_0.243.tar.xz 6395276cb53050854e2c98bf338a0241a11f1194f68ee6e35f0b59ac35f0be86 249928 cdebconf-dbgsym_0.243_armhf.deb 9fc3717e1dd330249adf1634d5b009af8f66053d2fdb7963c498bf670ae5a757 104248 cdebconf-gtk-dbgsym_0.243_armhf.deb 1c6e84e50cc5f56730504b264820529caa7c8891874db966d5f1100d1d6b395b 25148 cdebconf-gtk-udeb_0.243_armhf.udeb 13230645e3110b0ab0fcdd5fd30b81a2d55bce50aacf7a1d3be3f75d677e3e17 69572 cdebconf-gtk_0.243_armhf.deb c9846fa98a58abc00914cd303437a7481a86b37caba229dace6027018e9f4a3b 17684 cdebconf-newt-udeb_0.243_armhf.udeb a789b056e544bf01bd1d5039e016b0d888db9f122ac4d8fb3d4219140680a5b4 2884 cdebconf-priority_0.243_all.udeb 2182885748649eeae343de41be01e65cb8479f603fb8b92d869f4bcfe1bb39db 21732 cdebconf-text-udeb_0.243_armhf.udeb 5875888e4445319a6114d99c590d6a4e04c7962ec259017d3018af6d526966b2 66740 cdebconf-udeb_0.243_armhf.udeb e5b299feddff5b918578e80699cfff9fbbe8cf8bd59410474c78923e49f882fe 13855 cdebconf_0.243_armhf.buildinfo e7099884ad377271fc470c6f63b9e84ac37db69f6477745980b290cc75cabdfa 162372 cdebconf_0.243_armhf.deb 2d629dfaceccd497546b0828532b768b86587619655250303872ad0fa121a06e 6096 libdebconfclient0-dbgsym_0.243_armhf.deb 53f37a50b57bf78dc58e308a4b7d136f804bcc29dd87ab43b377a9f42925c281 53044 libdebconfclient0-dev_0.243_armhf.deb 22959e81099eccb6a3616aff8d8641baa89572408c99aef59a53b9f293fb58a1 2896 libdebconfclient0-udeb_0.243_armhf.udeb 57c6d881fa7b87f1d8113c29fedbfabe642a92a56d3348dc0b3f336f684f1b9e 48068 libdebconfclient0_0.243_armhf.deb Files: 31f67340999dac87ba047c4a26308717 2776 utils optional cdebconf_0.243.dsc d3d3486b6bfbe70bcf79114c433b8fda 274404 utils optional cdebconf_0.243.tar.xz 7ec6d04a5df479067ae5b5aac1aa0947 249928 debug optional cdebconf-dbgsym_0.243_armhf.deb abfdb0884fe1c0c2922713a27e1270ac 104248 debug optional cdebconf-gtk-dbgsym_0.243_armhf.deb 06ddcf0c1f9838163ae26bf5cebcc800 25148 debian-installer optional cdebconf-gtk-udeb_0.243_armhf
Re: bootfloppies on DECstation 5000/125
On Fri, Feb 22, 2002 at 06:16:24PM +0100, Jan-Benedict Glaw wrote: [boot-floppies showing crashes on MIPS R3000-based machines] > It *will* fail. R3k needs a little patch to > ./include/asm-mips/pgtable.h to successfully handle swap access. > Otherwise, the kernel will Oops in seconds:-( I have built current CVS boot-floppies with a current Linux/MIPS CVS kernel (including Ralf's R3k-cache handling changes and Maciej's version of the pagetable-patch). Could you please test it on your R3k-based machines? The build is available at ftp://bolugftp.uni-bonn.de/pub/mipsel-linux/woody-bootfloppies/bf-pre3.0.21cvs20020306[.packed]/ Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404950: Installation Report [mips] [rc1] [Failure] SWARM (Broadcom BCM91250a)
Package: installation-reports Severity: grave Boot method: netboot Image version: Etch RC1, http://ftp.nl.debian.org/debian/dists/testing/main/installer-mips/rc1/images/sb1-bcm91250a/netboot/ Date: 2006-12-29 Machine: Broadcom BCM91250a "SWARM", mips/big-endian mode, 256MB RAM, serial console, IDE disk Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [E] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: == In the step "detecting hard drives" a reproducible kernel panic occurs (log follows below). RC1 uses a 2.6.17 kernel. Not sure whether this is relevant in this case, but according to the git commit logs there have been changes to the SWARM IDE code in the Linux/MIPS tree with regard to 2.6.17 and 2.6.18 in November/December 2006. Kernel panic log: = ? Break instruction in kernel code[#1]: ? Cpu 1 ? $ 0 : 8048 0001 ?? $ 4 : 80513088 10001fe1 80513590 $ 8 : 1b00 9b00 b704 0004 $12 : 802d4bac fffc 80423898 $16 : 8053c2e0 9008 8053c300 0008 $20 : a8874000 0001 a8874070 9008 $24 : 0030 $28 : a885 a8853c50 8053b6c0 80336b2c Hi: 000271e9 Lo: d0a3 epc : 80337af4 ide_setup_dma+0x2b4/0x690 Not tainted ra: 80336b2c ide_pci_setup_ports+0x8bc/0x8c8 Status: 10001fe3KX SX UX KERNEL EXL IE Cause : 00808024 PrId : 03040102 Modules linked in: it821x usbhid usbkbd uhci_hcd ehci_hcd ohci_hcd usbcore pm2fb cfbcopyarea cfbimgblt cfbfillrect Process modprobe (pid: 7358, threadinfo=a885, task=a8688da8) Stack : 8053c300 8053c2e0 c00524d8 c005251b 80336b2c 80336644 00070039 a8853d50 0002 0039 a8853d50 0036 a8874000 c00524d8 0001 0039 a8853d50 00447134 00401060 80336d7c a807008a6c00 00138037b464 a8874000 c00524d8 00f0 00447128 004470e8 80337260 01874160 802ccde0 a8874000 c0052330 ffed c004f050 802e07ec 802e07d4 ... Call Trace: [] ide_pci_setup_ports+0x8bc/0x8c8 [] ide_pci_setup_ports+0x3d4/0x8c8 [] do_ide_setup_pci_device+0x244/0x5d0 [] ide_setup_pci_device+0x28/0xd0 [] kobject_get+0x20/0x38 [] it821x_init_one+0x50/0x60 [it821x] [] pci_device_probe+0x84/0xa8 [] pci_device_probe+0x6c/0xa8 [] driver_probe_device+0x58/0x118 [] __driver_attach+0x10c/0x158 [] __driver_attach+0x0/0x158 [] bus_for_each_dev+0x58/0xb8 [] kobject_register+0x60/0x78 [] bus_add_driver+0xb8/0x1f8 [] __pci_register_driver+0x74/0xc8 [] __pci_register_driver+0x74/0xc8 [] sys_init_module+0x10c/0x2b0 [] handle_sys+0x134/0x150 [] compat_sys_fcntl64+0x0/0x3b0 Code: de030960 1463 dfbf0020 <020d> dfbf0020 dfb30018 dfb20010 dfb10008 dfb0 CPU 1 Unable to handle kernel paging request at virtual address 901e, epc == 8032f010, ra == 8032b018 Oops[#2]: Cpu 1 $ 0 : 30001fe1 8053b6c0 $ 4 : 00e0 901e 80422d28 $ 8 : a8000fd6fac0 544d3130 302d3234 $12 : 0020 802d4b9c 80195da8 004010c8 $16 : a8000fad7c10 8053b7d8 8053b6c0 a8b5da00 $20 : 0400 $24 : 0029 8032f008 $28 : a8000fad4000 a8000fad7ae0 7ffbc6dc 8032b018 Hi: 0129 Lo: 1a94 epc : 8032f010 ide_mm_outb+0x8/0x10 Not tainted ra: 8032b018 ide_do_request+0x498/0xbf8 Status: 30001fe3KX SX UX KERNEL EXL IE Cause : 9080800c BadVA : 901e PrId : 03040102 Modules linked in: it821x usbhid usbkbd uhci_hcd ehci_hcd ohci_hcd usbcore pm2fb cfbcopyarea cfbimgblt cfbfillrect Process ata_id (pid: 7434, threadinfo=a8000fad4000, task=a860c0c8) Stack : 0001 a8000fad7
Bug#404951: Installation Report [mips] [daily-2006-12-27] [Failure] SWARM (Broadcom BCM91250a)
Package: installation-reports Severity: grave Boot method: netboot Image version: daily build 2006-12-27, http://people.debian.org/~ths/d-i/mips/images/daily/sb1-bcm91250a/netboot/ Date: 2006-12-29 Machine: Broadcom BCM91250a "SWARM", mips/big-endian mode, 256MB RAM, serial console, IDE disk Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: == Sibyl (the bootloader) starts, loads the kernel and the initrd, jumps into the kernel and the system freezes. Boot log: = CFE> boot -tftp 192.168.2.14:/tftpboot/swarm-daily/sibyl Loader:raw Filesys:tftp Dev:eth0 File:192.168.2.14:/tftpboot/swarm-daily/sibyl Options:(null) Loading: ... 130116 bytes read Entry at 0x2000 Closing network. Starting program at 0x2000 SiByte Loader, version 2.4.2 Built on Oct 4 2005 Network device 'eth0' configured Getting configuration file tftp:192.168.2.14:/tftpboot/swarm-daily/sibyl.conf... Config file retrieved. Available configurations: install rescue Boot which configuration [install]: Loading kernel (ELF64): [EMAIL PROTECTED] done Loading ramdisk at 0x8057e000...3622876 bytes loaded Set up command line arguments to: root=/dev/ram console=duart0 ramdisk_size=3576 rd_start=0x8057E000 rd_size=0x3747DC Setting up initial prom_init arguments Cleaning up state... Transferring control to the kernel. Kernel entry point is at 0x804f7000 Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2) Board type: SiByte BCM91250A (SWARM) Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#590190: d-i sparc squeeze weekly 2010-07-12: unable to partition harddisk properly
Package: installation-reports Boot method: netboot (RARP/TFTP) Image version: http://people.debian.org/~stappers/d-i/sparc/daily/netboot/boot.img (2010-07-12) Install Date: 2010-07-24 Machine: Sun Ultra5 Processor: UltraSparc IIi 400MHz Memory: 384 MB Partitions: partitioning fails Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Partitioning the harddisk (standard 15GB PATA disk) fails with the message "Unable to satisfy all constraints on the partition". This happens a) when using "guided partitioning" and b) when partitioning manually and trying to create more than one partition Creating the first partition works without problems, but as soon as one tries to add another partition, the aforementioned error occurs. When one creates just a root partition (no swap etc.), the rest of the installation process works normally. Attached is a partman log from an installation attempt with manual partitioning. Creating only the root partition worked, trying to add an additional swap partition failed as described above. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. partman.log.gz Description: Binary data
Bug#681388: installation-report: d-i wheezy daily 2012-07-12 business card in KVM
Package: installation-reports Version: 2.47 Severity: wishlist -- Package-specific info: Boot method: CD Image version: business card daily 2012-07-12 Date: 2012-07-12 Installed using the graphical installer Selected desktop environment: Xfce Machine: KVM virtual machine Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on rootfs rootfs 9973272 3029512 6443488 32% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 311500 252311248 1% /run /dev/disk/by-uuid/cd85bb90-2f77-4bb8-9955-23321a31a92c ext4 9973272 3029512 6443488 32% / tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 622996 112622884 1% /tmp tmpfs tmpfs 622996 0622996 0% /run/shm Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: There were no problems with the installation itself. One thing that I have stumbled about is that the default Xfce installation contains both xfburn (Xfce CD burning application) and brasero (GNOME CD burning application). Xfce is usually used for "lightweight" setups, so I think there should be only one CD burning application installed by default. Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="7.0 (wheezy) - installer build 20120712-00:02" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux ditest 3.2.0-3-486 #1 Thu Jun 28 08:08:24 UTC 2012 i686 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000] lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] [8086:7010] lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: Kernel driver in use: ata_piix lspci -knn: 00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 03) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 [1013:00b8] lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:03.0 Ethernet controller [0200]: Red Hat, Inc Virtio network device [1af4:1000] lspci -knn: Subsystem: Red Hat, Inc Device [1af4:0001] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: 00:04.0 Multimedia audio controller [0401]: Intel Corporation 82801AA AC'97 Audio Controller [8086:2415] (rev 01) lspci -knn: Subsystem: Intel Corporation Device [8086:] lspci -knn: Kernel driver in use: snd_intel8x0 lsmod: Module Size Used by lsmod: ufs57656 0 lsmod: qnx4 12992 0 lsmod: ntfs 161713 0 lsmod: reiserfs 167376 0 lsmod: efivars17508 0 lsmod: dm_mod 57354 0 lsmod: md_mod 81567 0 lsmod: xfs 511016 0 lsmod: jfs 131002 0 lsmod: ext4 298051 1 lsmod: crc16 12327 1 ext4 lsmod: jbd2 51542 1 ext4 lsmod: ext3 133836 0 lsmod: jbd42496 1 ext3 lsmod: btrfs 471514 0 lsmod: zlib_deflate 21318 1 btrfs lsmod: crc32c 12576 1 lsmod: libcrc32c 12394 1 btrfs lsmod: vfat 17117 0 lsmod: fat40365 1 vfat lsmod: ext2 49804 0 lsmod: mbcache12897 3 ext2,ext3,ext4 lsmod: virtio_net
Bug#683692: installation report: [i386] [daily 2012/08/02] installation hangs forever
Package: installation-reports Boot method: credit card image booted from USB key Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/jigdo-cd/debian-testing-i386-netinst.jigdo Image date: 2012/08/02 17:27 Installation date: 2012/08/02 Machine: Desktop PC Processor: Pentium DualCore E2200 Memory: 2 GB Partitions: installer fails before partitioning stage Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: The machine has a TP-Link TL-WN721N 802.11n WLAN dongle (based on an Atheros AR9271 chipset) connected via USB. As long as this device is connected to the computer, the "detect network" stage just hangs forever. If the WLAN dongle is not connected to the machine, d-i works as expected. The firmware for the WLAN dongle is non-free and therefore not included in d-i, but the installation should not hang completely just because the device is connected to the computer. The device itself is supported by Linux and works when connected after the installation is finished, provided the (non-free) package firmware-atheros has been installed. Relevant syslog entries: Aug 2 19:03:39 kernel: [2.448030] usb 1-3: new high-speed USB device number 4 using ehci_hcd Aug 2 19:03:39 kernel: [2.604889] usb 1-3: New USB device found, idVendor=0cf3, idProduct=9271 Aug 2 19:03:39 kernel: [2.611200] usb 1-3: New USB device strings: Mfr=16, Product=32, SerialNumber=48 Aug 2 19:03:39 kernel: [2.617486] usb 1-3: Product: USB2.0 WLAN Aug 2 19:03:39 kernel: [2.623615] usb 1-3: Manufacturer: ATHEROS Aug 2 19:03:39 kernel: [2.629689] usb 1-3: SerialNumber: 12345 Aug 2 19:03:49 hw-detect: Missing modules 'eth1394 (FireWire ethernet) Aug 2 19:03:50 check-missing-firmware: /dev/.udev/firmware-missing does not exist, skipping Aug 2 19:03:50 check-missing-firmware: /run/udev/firmware-missing does not exist, skipping Aug 2 19:03:50 check-missing-firmware: no missing firmware in /dev/.udev/firmware-missing /run/udev/firmware-missing Aug 2 19:04:59 kernel: [ 85.337797] cfg80211: Calling CRDA to update world regulatory domain Aug 2 19:04:59 net/hw-detect.hotplug: Detected hotpluggable network interface lo Aug 2 19:04:59 kernel: [ 85.424081] usb 1-3: ath9k_htc: Firmware - htc_9271.fw not found Aug 2 19:04:59 kernel: [ 85.424092] ath9k_htc: probe of 1-3:1.0 failed with error -22 Aug 2 19:04:59 kernel: [ 85.424112] usbcore: registered new interface driver ath9k_htc Aug 2 19:04:59 net/hw-detect.hotplug: Detected hotpluggable network interface eth0 Aug 2 19:04:59 hw-detect: Missing modules 'eth1394 (FireWire ethernet) Aug 2 19:05:00 check-missing-firmware: /dev/.udev/firmware-missing does not exist, skipping Aug 2 19:05:00 check-missing-firmware: missing firmware files (htc_9271.fw) for ath9k_htc Aug 2 19:05:01 kernel: [ 87.334257] FAT-fs (sda): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 2 19:05:01 kernel: [ 87.363899] FAT-fs (sda): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 2 19:05:01 kernel: [ 87.11] FAT-fs (sdc): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 2 19:05:01 kernel: [ 87.519037] FAT-fs (sdc): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 2 19:05:01 kernel: [ 87.584031] end_request: I/O error, dev fd0, sector 0 Aug 2 19:05:01 kernel: [ 87.608030] end_request: I/O error, dev fd0, sector 0 Aug 2 19:05:01 kernel: [ 87.632033] end_request: I/O error, dev fd0, sector 0 Aug 2 19:05:01 kernel: [ 87.656029] end_request: I/O error, dev fd0, sector 0 Aug 2 19:05:01 kernel: [ 87.675372] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 2 19:05:01 kernel: [ 87.705927] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 2 19:05:01 kernel: [ 87.833271] FAT-fs (sda): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 2 19:05:01 kernel: [ 87.846341] FAT-fs (sda): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 2 19:05:01 kernel: [ 87.926912] FAT-fs (sdc): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 2 19:05:01 kernel: [ 88.001788] FAT-fs (sdc): utf8 is not a recommended IO charset for FAT files
