Bug#818065: console-setup is not read correctly at boottime and must be started manually
Hi all, I have this problem on 8 embedded systems running armbian stretch that all reports error like this on the systemd journal: Feb 16 14:17:10 rod-ba82a8 console-setup.sh[293]: /bin/setupcon: 866: /bin/setupcon: cannot open /tmp/tmpkbd.BccRnI: No such file Feb 16 14:17:10 rod-ba82a8 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE Feb 16 14:17:10 rod-ba82a8 systemd[1]: Failed to start Set console font and keymap. Feb 16 14:17:10 rod-ba82a8 systemd[1]: console-setup.service: Unit entered failed state. Feb 16 14:17:10 rod-ba82a8 systemd[1]: console-setup.service: Failed with result 'exit-code' So it look like the /tmp mount is required. I added it into the RequiresMountsFor line of the service file, run systemctl daemon-reload, but this make no change on the boot: console-setup failed with exactly the same error message. Then I tryed to run 'setupcon' and 'reboot', no change. Then I tryed to run 'systemctl start console-setup.service' and 'reboot': it worked !. So my conclusion so far are: 1) Yes setupcon and console-setup.service require /tmp mount but this is not the rot cause of the problem, even if the error message let you think so. 2) Simply running 'systemctl start console-setup.service' manually solved the problem on those 8 systems that also have /tmp added into RequiresMountsFor. Look like a timing and probably a dependency issue that make early console-setup to fail because it didn't find a expected file into /tmp. I don't know how this file is supposed to be there at bot time. Best regards. Jean-Christian
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 07. 10. 16 à 17:09, Lennart Sorensen a écrit :
On Fri, Oct 07, 2016 at 02:48:30PM +0200, Jean-Christian de Rivaz wrote:
You mean the flash-kernel package and not by the flash-kernel-installer ?
flash-kernel takes care of the kernel and the boot script. It doesn't
install u-boot. At least not at this time.
I am a newbie regarding the Debian installer, so it take me some times
to finally understand that some udeb packages control file specify
providing "bootable-system". Below is the list with the related
architecture:
debian-installer$ find -type f ! -ipath "*/\.git*" -iname "control"
-exec grep -li "^Provides:.*bootable-system" {} \; | xargs grep -i
"^Architecture:"
./packages/grub-installer/debian/control:Architecture: i386 hurd-i386
amd64 kfreebsd-i386 kfreebsd-amd64 powerpc ppc64el mipsel arm64 armhf
./packages/arcboot-installer/debian/control:Architecture: mips
./packages/zipl-installer/debian/control:Architecture: s390 s390x
./packages/lilo-installer/debian/control:Architecture: i386 amd64
./packages/flash-kernel/debian/control:Architecture: arm64 armel armhf
./packages/flash-kernel/debian/control:Architecture: arm64 armel armhf
./packages/elilo-installer/debian/control:Architecture: i386 ia64
./packages/nobootloader/debian/control:Architecture: all
./packages/prep-installer/debian/control:Architecture: powerpc
./packages/quik-installer/debian/control:Architecture: powerpc
./packages/yaboot-installer/debian/control:Architecture: powerpc
I don't know why "grub-installer" includes armhf since
packages/grub-installer/debian/isinstallable don't return 1 for armhf.
Now I understand why you point at "flash-kernel". I didn't know that it
was ARM specific.
Regards,
Jean-Christian
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 07. 10. 16 à 17:09, Lennart Sorensen a écrit : On Fri, Oct 07, 2016 at 02:48:30PM +0200, Jean-Christian de Rivaz wrote: On some system, maybe. Not on the Orange Pi Plus Well I guess it is one of the exceptions. As I user I experience the H3 ROM like a PC BIOS, and the H3 U-Boot like GRUB. Like a PC BIOS can always boot a CDROM/USB (or SD card on some laptop) regardless the garbage that might affect the HDD/SSD (or eMMC on cheap laptop), the H3 ROM on the Orange Pi Plus can alway boot a SD card regardless the garbage that might affect the eMMC. Like GRUB on a PC, the H3 U-Boot is needed to boot Linux, and both are usually written into the media where Debian is installed. I know UEFI is now on the mainboard EEPROM, but it's still part of the board and don't require the installation media (CDROM/USB or SD card) to normally boot the system. So if you account all the PC that follow that same schema, I don't think that the Orange Pi Plus is an exception. On the contrary, this is a board that perfectly fit the way the Debian installer act on any PC. Well, I understand the technical part. But from a user point, when he see the Orange Pi Plus in the board list of the Debian installer, I think it's normal that he expect to be able to install a working system like the Debian installer do for a PC. The problem with arm systems with u-boot is that you are dealing with embedded systems, not standard machines. They have options for how to boot (on some systems u-boot needs a recompile depending on if you boot from eMMC or SD, so that's a pain). Given debian for armhf can run on just about any modern arm system, the only bit it doesn't cover is installing the boot loader since that is board specific (and sometimes board configuration specific). Having a wiki or other document listing what else needs to be done for a given system would be handy (and probably exists for at least some of the systems). You mean the flash-kernel package and not by the flash-kernel-installer ? flash-kernel takes care of the kernel and the boot script. It doesn't install u-boot. At least not at this time. Ok. Where the U-Boot install task will be appropriate to add on the installation process ? Yes, but only at the installer time on that board. As soon as you reboot it without the SD card or without FEL OTG injection of u-boot, you are left with a useless board. Well it is still fixable with a tiny bit of one time work. I must admit that for various arm boards I have played with I have never used the installer. I have used debootstrap to create a rootfs and then put it and the required bits on uSD or eMMC or wherever I wanted it. Some of the boards have needed a custom kernel build of course, although some didn't. I also played with debootstrap and the like and frankly from a user point of view there are painful. The Debian installer is a wonderful simple way to install Debian in comparison. Agree, but again take the point of view of a user that simply want to install Debian on the Orange Pi Plus. By fare, the simplest way is to write a SD card image of the Debian installer into a SD card and insert it into the board slot. It could be netboot, or hd.media with an additional partition for the ISO image. Both will work to install Debian on the eMMC. Any others way require more work. Anyway, actually either methods will let the user with a useless board. Well the simplest would be to just dump a premade image on uSD and leave it there and forget eMMC. Of course eMMC often has better performance than uSD and it is nice to have a method for file transfers (although USB keys and ethernet are often more convinient). It sound like if you say to a PC user that it just have to install Debian on a USB memory because of some GURB issues and that it can forget his HDD/SSD. Regards, Jean-Christian
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 07. 10. 16 à 16:53, Karsten Merker a écrit : On Fri, Oct 07, 2016 at 02:48:30PM +0200, Jean-Christian de Rivaz wrote: Le 07. 10. 16 à 13:33, Karsten Merker a écrit : On Fri, Oct 07, 2016 at 01:57:41AM +0200, Jean-Christian de Rivaz wrote: Regarding the hd-media image: installing to the SD card from ^^ which the installer is started works if the CD/DVD iso is ^^ provided on another storage device such as on a USB stick. What's the point to support a such complicated install setup if at the end there is no u-boot to start the system ? I'm sorry to have to say that, but to me this looks like it is intended as flamebait :-(. I'll try to answer the question nonetheless. First, you were talking about the case of installing the system onto the SD card from which you have booted u-boot and the installer, so in this case there _is_ a u-boot. Yes, but only at the installer time on that board. As soon as you reboot it without the SD card or without FEL OTG injection of u-boot, you are left with a useless board. You are again talking about completely different things. Why would you remove the SD card if it was your installation target? The case in question was _installing_ _to_ _the_ _SD_ _card_. See above, I have underlined the corresponding quoted part for you. We are explicitly _not_ talking about installation to eMMC here. Ok, I misunderstand that you was talking about the case when the target is the SD card, because as you agree, this have nothing to do about the target (expect that you can't install with the SD card as a target is the ISO file is on that SD card). As I have said, I did that SD card target test just for my curiosity. Again I am sorry to have to say that, but my impression is more and more that you are trying to troll me which makes me inclined to not further put my time into this thread. The subject of this thread is explicitly about installing to the eMMC, so I assumed too fast that you was still talking about that subject, sorry. Regards, Jean-Christian
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 07. 10. 16 à 13:33, Karsten Merker a écrit : On Fri, Oct 07, 2016 at 01:57:41AM +0200, Jean-Christian de Rivaz wrote: The debian-installer doesn't install u-boot, but it takes explicit care not to destroy an existing u-boot installation during the partitioning step. Yes. It take so much care that it don't write u-boot when it must write it... Such an aggressive undertone doesn't exactly further the discussion. This was a joke, but I understand that it could hurt. Sorry about this. If the installer is able to take care of the region where u-boot is, why don't allow him to optionally copy that region from the SD card to the eMMC ? First, there is a massive difference between taking care to preserve the boot area and thereby an existing u-boot setup (which might not even come from Debian) and performing a write operation that has the potential to wipe out the user's setup and even potentially brick the system. On some system, maybe. Not on the Orange Pi Plus Second, simply copying the u-boot region from SD card to the eMMC has a number of practical problems. The exact layout of u-boot and its environment is system-specific. So while on many systems simply copying the area between the partition table and the first megabyte of the medium works in practice without negative effects, that is not the case for _all_ systems, which again ends up with the point that I already made: installing u-boot is a system-dependent step where there is no "one size fits for all". Agree. Another practical problem is that the installer has no way to know whether there is a valid u-boot setup on the SD card. The user might have a system that came preinstalled with a u-boot at another location (eMMC, SPI NOR flash) and uses that to boot. The SD card images are not the only way the installer can get started, it can be booted by tftp or from a USB stick and there is no way for the installer to know from where it was loaded and whether the SD card that might happen to be in the slot by chance contains a valid u-boot, so blindly copying the boot region from the SD card might end up with a broken system. Ok, I understand that if some code have to install u-boot, it have to get u-boot from a clean place. You wrote an another mail: This thread is explicitly about the Orange Pi Plus board, because there exists a specific Debian installer SD card firmware for that board. This board do the boot order in the right way and it's perfectly safe to write the bootloader on is eMMC. You might have misunderstood the way the SD card images are built. The "firmware" part of the images contains only the partition table and the system-specific u-boot. The actual installer is the same for all platforms. There is no such thing as "the installer for the Orange Pi Plus", therefore all components of the installer must use a platform-neutral design. Well, I understand the technical part. But from a user point, when he see the Orange Pi Plus in the board list of the Debian installer, I think it's normal that he expect to be able to install a working system like the Debian installer do for a PC. Again, I am not against providing an option to install u-boot from within the installer, but it has to be done in a way that works for multiple platforms and doesn't easily brick the user's system. These requirements cannot be fulfilled with "blindly copy some sectors from the SD card in the slot". A possible design could work similar to what the flash-kernel package does, i.e. having a database of systems which lists the specific needs and angles of each system and providing methods to deal with common cases. You mean the flash-kernel package and not by the flash-kernel-installer ? Regarding the hd-media image: installing to the SD card from which the installer is started works if the CD/DVD iso is provided on another storage device such as on a USB stick. What's the point to support a such complicated install setup if at the end there is no u-boot to start the system ? I'm sorry to have to say that, but to me this looks like it is intended as flamebait :-(. I'll try to answer the question nonetheless. First, you were talking about the case of installing the system onto the SD card from which you have booted u-boot and the installer, so in this case there _is_ a u-boot. Yes, but only at the installer time on that board. As soon as you reboot it without the SD card or without FEL OTG injection of u-boot, you are left with a useless board. Second, the setup isn't complicated at all. The function of the hd-media installer is to perform offline installations. It pulls the packages from a CD/DVD which can be available anywhere on the system, be it in form of a physical disk in a CD/DVD drive or in form of an ISO image on any block device. Whether this block device is an SD card or a USB stick doesn't matter at all from the viewpoint of the installer. That the
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 07. 10. 16 à 05:25, Lennart Sorensen a écrit : On Fri, Oct 07, 2016 at 01:44:13AM +0200, Jean-Christian de Rivaz wrote: Did you realize that SD card and eMMC uses both exactly the same signaling and controller on all processors, not only on the Allwinner family ? If a board designer is stupid enough to connect the eMMC instead of the SD card on the controller looked first by the on chip ROM, then it's not an argument to not support all the others boards that did it the right way. Well certainly the SD/MMC controllers are not all the same. Certainly the AM572x has 4 MMC controllers, only one of them can drive eMMC, one can do SDIO, one is only 4 bit so best for uSD, and I forget the limits on the last one. They have different widths and maximum speeds. So yes they are all MMC, but they are not all the same. Ok, you win on that. I still doubt that there exist a processor with a on chip ROM that first look for a bootloader on a eMMC only interface. This would be a major failure. Yet again, stupid chips or boards, are not an argument to not support eMMC u-boot on safe processor and boards like the Orange Pi Plus. Would be possible for the Debian installer to check the board model by reading /sys/firmware/devicetree/base/model and check if it found "Xunlong Orange Pi Plus" into it ? Then it could warn the user and ask if it want to write u-boot on the target device. Regards, Jean-Christian
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 07. 10. 16 à 03:18, Ben Hutchings a écrit : On Fri, 2016-10-07 at 01:44 +0200, Jean-Christian de Rivaz wrote: Did you realize that SD card and eMMC uses both exactly the same signaling and controller on all processors, not only on the Allwinner family ? This is not true. There are many signalling modes for SD and eMMC, few of which work for both of them. As a result there are some controllers that only support one or the other (e.g. in R-Car SoCs). Did you seriously pretend that a single silicon chip uses two different on chip MMC controllers making them unable to support a SD card or an eMMC on only one of his controller ? Please provides a link to it, I would be certain to never use it. Stupid boards need stupid recovery procedure anyway, regardless of the operating system. This is not a Debian problem. Or least Debian should not try to officially support broken boards. [...] Just as all software is buggy, all hardware is buggy. So yes, we should try to support broken boards, so far as we can. I definitely don't agree on this kind of argument. All chips and boards are not equally buggy, far far from that in practice. The market is actually flooded so fast with new boards that's is already a challenge to support good and safe boards before there get replaced by a new generation of board. I see no advantage in loosing time to support broken boards and delaying support of good boards in the process. Regards, Jean-Christian
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 07. 10. 16 à 01:57, Jean-Christian de Rivaz a écrit : Le 07. 10. 16 à 00:39, Karsten Merker a écrit : was wrote by the installer. The debian-installer doesn't install u-boot, but it takes explicit care not to destroy an existing u-boot installation during the partitioning step. Yes. It take so much care that it don't write u-boot when it must write it... If the installer is able to take care of the region where u-boot is, why don't allow him to optionally copy that region from the SD card to the eMMC ? After erasing the eMMC again, I tested this from the SD card netboot Debian installer shell just before the reboot: dd if=/dev/mmcblk0 of=/dev/mmcblk2 bs=1k skip=8 seek=8 count=1016 sync And Debian booted perfectly well from the eMMC, without the SD card :-) I hope that the Debian installer will soon propose this operation to the user. Regards, Jean-Christian
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 07. 10. 16 à 00:39, Karsten Merker a écrit : On Thu, Oct 06, 2016 at 08:13:45PM +0200, Jean-Christian de Rivaz wrote: Right. For my curiosity I tested the netboot SD card image of the Debian installer and tried to tell it to partition, format and install Debian into the very same SD card the installer booted from. To my great surprise this worked flawlessly (just need a power cycle as the reboot simply hang). This work only with the netboot image. The hd-media require an other partition with the ISO file making the partition/format fail because the SD card device is busy. I don't know at this stage if the boot stage is a residual of the image creation on the SD card or if it was wrote by the installer. The debian-installer doesn't install u-boot, but it takes explicit care not to destroy an existing u-boot installation during the partitioning step. Yes. It take so much care that it don't write u-boot when it must write it... If the installer is able to take care of the region where u-boot is, why don't allow him to optionally copy that region from the SD card to the eMMC ? Regarding the hd-media image: installing to the SD card from which the installer is started works if the CD/DVD iso is provided on another storage device such as on a USB stick. What's the point to support a such complicated install setup if at the end there is no u-boot to start the system ? Regards, Jean-Christian
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 07. 10. 16 à 00:30, Karsten Merker a écrit : So the boot order might not be problematic on the Orange Pi Plus, but it can definitely be problematic on A64-based systems and it might possibly be problematic on other H3-based boards. Did you realize that SD card and eMMC uses both exactly the same signaling and controller on all processors, not only on the Allwinner family ? If a board designer is stupid enough to connect the eMMC instead of the SD card on the controller looked first by the on chip ROM, then it's not an argument to not support all the others boards that did it the right way. Stupid boards need stupid recovery procedure anyway, regardless of the operating system. This is not a Debian problem. Or least Debian should not try to officially support broken boards. This is just a wast of time. Better to concentrate into work that yield a productive and safe result. This thread is explicitly about the Orange Pi Plus board, because there exists a specific Debian installer SD card firmware for that board. This board do the boot order in the right way and it's perfectly safe to write the bootloader on his eMMC. This of course doesn't mean that an option to install u-boot to eMMC from inside the installer isn't useful, just that this needs proper planning and also probably a configuration at the board level and not only at the SoC level. I think it's a way too conservative approach, just give the option with a warning. At least this will make some users happy by allowing to install Debian on eMMC from his superb installer. The current situation prevent any users to make a Debian install on a eMMC because of a tiny missing piece. This is frustrating. Regards, Jean-Christian
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 06. 10. 16 à 21:29, Vagrant Cascadian a écrit : I don't believe there is any code in debian-installer to install u-boot; the installer did not install it. I don't believe there is any code within all of Debian to install u-boot automatically (unless you count SD image generation). It is at this point a manual process. And this is the only missing operation still required to fully support Debian a board like the Orange Pi Plus. Installing u-boot from within the debian-installer can be a rather dangerous operation on many systems which is why the installer doesn't try to do that yet. The problem is that u-boot isn't only a bootloader like GRUB but more like a PC BIOS and nobody would expect the debian-installer to flash BIOS-updates on a PC ;-). There are quite a number of systems where writing u-boot to internal storage going wrong completely bricks the system, i.e the system is electronics garbage afterwards. Most sunxi-based systems still have a way to trigger SD boot or FEL boot as a way to manually restore the firmware, but not all of them do, and on many non-sunxi-platforms a broken u-boot write is completely unrecoverable except by unsoldering the flash or - if one is lucky - by accessing it via JTAG, but both are methods that are inaccessible for a normal user. I understand, but the SD card image of the Debian installer is specifically targeted for the Orange Pi Plus board so it can take advantage of it. While the SD card images can be used for recovery in many cases, it is also possible that u-boot installed to eMMC fails in such a way that it doesn't fall back to SD card, requiring a lot of effort to reset the board. It depends entirely on the boot ROM of the board what order it searches for the bootloader... Not on that board. The H3 processor chip integrate a boot ROM that always first look at the SD card and then at the eMMC (unless forced into the special FEL mode). There is no way to break the ROM integrated into the processor chip. Take a look at http://linux-sunxi.org/BROM for the details. Given that experience, I tend to strongly prefer installing u-boot on SD card when possible, as you can easily remove the SD card and reinstall a known-good u-boot from another machine. This is exactly how the H3 boot ROM work already. You can write anything you want into the eMMC, there is absolutely no way to break the SD card boot from the CPU ROM. So there is no danger in writing the bootloader into the eMMC on that board. Writing the bootloader on the eMMC this is exactly what a user will expect while installing Debian into the eMMC. I'll put looking into support for installing u-boot from within the installer at least on certain systems onto my (unfortunately already way too long) todo list, but that will surely take quite some time. I'm also CCing Vagrant Cascadian, the Debian u-boot maintainer for some further input on this topic. Basically, it will require much of the same code as upgrading u-boot: https://bugs.debian.org/812611 Which has been on my todo list for quite some time with little activity. Due to the risk of bricking, both fresh installation and upgrading of u-boot should probably require some sort of opt-in process. Knowing how to install u-boot on a particular set of boards is another feature that's needed, although the SD-card image generation in debian-installer is a good start for several boards. To make matters more complicated, there are definitely some boards (Firefly, maybe BeagleBoard-X15) which can install the OS to eMMC, but u-boot still has to be loaded from SD card. I don't think we have much information on which boards those are. It may also vary from one u-boot version to the next... So, in short, there are quite a few complications to take into consideration. If someone can propose patches that take into account all these issues quite soon, it *might* be feasible for stretch. From a user point of view this would be a major achievement for the Debian armhf port that finally make some ARM boards as easy to install than a regular PC. Well, maybe even easier than the actual UEFI PC... Regards, Jean-Christian
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 06. 10. 16 à 15:26, Karsten Merker a écrit : The raw MLC NAND flash that was commonly used as fixed storage on sunxi-based boards isn't yet properly supported in the mainline kernel and sunxi-based systems with eMMC storage are a fairly recent development. Therefore until recently, on sunxi-based devices installation was only possible to either the SD card that the system was booted from and on which therefore a u-boot was already installed, or to a SATA disk (on SoCs that have a SATA controller), or to a USB mass storage device. As no Allwinner SoC can boot directly from SATA nor from USB mass storage devices, in all cases u-boot still had to be loaded from the SD card because there was no other way and u-boot was already present there, so there was no need to install u-boot somewhere as a part of the installation process. Right. For my curiosity I tested the netboot SD card image of the Debian installer and tried to tell it to partition, format and install Debian into the very same SD card the installer booted from. To my great surprise this worked flawlessly (just need a power cycle as the reboot simply hang). This work only with the netboot image. The hd-media require an other partition with the ISO file making the partition/format fail because the SD card device is busy. I don't know at this stage if the boot stage is a residual of the image creation on the SD card or if it was wrote by the installer. Yet the result is simply amazing already. With boards becoming available now which use eMMC instead of raw MLC NAND flash, the situation changes indeed. AFAIK you are actually the first person reporting about a Debian installation to eMMC on sunxi-based boards. If we can get this working, I am certain that this will become a popular way to install Debian on that kind of board. I observe a trend in the industry toward eMMC. The price is very low with the advantage solve tricky wearing management and compatibility details. From my personal point of view raw NAND are dead already. For booting the system please see below. If that doesn't work, you could try running a rescue shell from the installer. Once you have a shell, get the following file and gunzip it: https://d-i.debian.org/daily-images/armhf/daily/u-boot/orangepi_plus/u-boot-sunxi-with-spl.bin.gz To write it to the eMMC, please run dd bs=1k seek=8 if=u-boot-sunxi-with-spl.bin of=/dev/YOUR_TARGET_DEVICE sync with YOUR_TARGET_DEVICE being the first regular (i.e. non-boot) eMMC partition; in your case probably /dev/mmcblk1p1. Unfortunately I don't know how the H3 BROM handles the eMMC-specific hardware boot partitions (/dev/mmcblk1boot0 and /dev/mmcblk1boot1), i.e. whether it tries to load the u-boot SPL from the first regular partition or from the first hardware boot partition. If the latter, this would probably need extra support in u-boot which to my knowledge isn't there yet. So I have followed this procedure: * Reinstalled the SD card with the netboot SD card image of the Debian installer and powered up the board. * Interrupted U-Boot with some space characters. * Issued the command "run bootcmd_mmc1" into U-Boot and the Debian system on the eMMC started as expected instead of the installer on the SD card. * Logged as root. * Downloaded the file with this command: wget https://d-i.debian.org/daily-images/armhf/daily/u-boot/orangepi_plus/u-boot-sunxi-with-spl.bin.gz * Uncompress the file with: gunzip u-boot-sunxi-with-spl.bin.gz * Wrote the file with: dd bs=1k seek=8 if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk2 * Issued the "sync" command. * Removed the SD card. * Reboot / power cycle. * Welcome to Debian on H3 from eMMC :-) Many thanks for your effective explanations ! This worked perfectly well. I have neither access to a H3-based system nor to any other sunxi-based device with eMMC, so unfortunately I cannot do any tests in this regard. I have some motivation to do that for you on my Orange Pi Plus as long as I found the time to do it. Installing u-boot from within the debian-installer can be a rather dangerous operation on many systems which is why the installer doesn't try to do that yet. The problem is that u-boot isn't only a bootloader like GRUB but more like a PC BIOS and nobody would expect the debian-installer to flash BIOS-updates on a PC ;-). There are quite a number of systems where writing u-boot to internal storage going wrong completely bricks the system, i.e the system is electronics garbage afterwards. Most sunxi-based systems still have a way to trigger SD boot or FEL boot as a way to manually restore the firmware, but not all of them do, and on many non-sunxi-platforms a broken u-boot write is completely unrecoverable except by unsoldering the flash or - if one is lucky - by accessing it via JTAG, but both are methods that are inaccessible for a normal user. I understand, but the SD card image of the Debian installer is specifically targeted for the Orange
Re: Install on Orange Pi Plus eMMC work but no reboot
Le 06. 10. 16 à 02:16, Karsten Merker a écrit : On Wed, Oct 05, 2016 at 10:59:06PM +0200, Jean-Christian de Rivaz wrote: First I wish to congratulate the Debian Installer team for there fantastic work on armhf. I tested both the hd-media and netinst on a Allwinner H3 Orange Pi Plus and the installer worked without any glitch up to the reboot. But unfortunately the installed system on eMMC don't boot. There is no message at all on the console while powering up the board with the eMMC alone, but there is clearly something installed on the eMMC when I inspect it from an other image booted from the SD card. I suspect that the eMMC boot is not supported. Anyone can confirm or not that fact ? Do you have a u-boot on the eMMC or is the u-boot from which you load the installer started from an SD card? The U-Boot and the installer was on a SD card that was only created by decompressing and concatenating this two files: https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/firmware.orangepi_plus.img.gz https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/partition.img.gz At some point this installer make some partitions and format on the eMMC with an offset to make place before them for the boot0 and boot1 files that certainly correspond to first stages bootloader of the H3. The debian-installer doesn't itself install u-boot as a part of the installation process but instead assumes that there already is a u-boot available on the system, because otherwise the installer couldn't have been booted :-). I think this is a wrong assumption. The firmware.orangepi_plus.img contain the first stages bootloaders and U-Boot to boot the installer. Evidence are on that log file: https://d-i.debian.org/daily-images/armhf/daily/build_u-boot.log and the very basic fact that the installer simply boot. Without the SD card inserted there is no message at all on the console. If your u-boot is on the SD card, you install to the eMMC and then remove the SD card, this assumption isn't true anymore. Yes, I think U-Boot is on the SD card to boot the installer. And yes, I expect that the installer install U-Boot on the eMMC, otherwise there is no point in having a such installer. The goal is to install a working system, no ? By the way it look like the installer have installed something that look like the two first stages bootloader on the /dev/mmcblk1boot0 and /dev/mmcblk1boot1 blocks on the eMMC, but for some reason this don't work as expected. So one attempt at a solution could be to manually install u-boot to the eMMC. How ? Does your u-boot build support two MMC devices - i.e. SD card and eMMC - at the same time (IIRC that is a build time config option in u-boot)? If yes, you could start u-boot from the SD card and then boot the rest of the system from the eMMC. I don't know, the U-Boot is not build by me but by the Debian Installer team. This is precisely why I ask the question here. How to configure the U-Boot of the SD card to boot the system on the eMMC ? Regards, Jean-Christian
Install on Orange Pi Plus eMMC work but no reboot
Hi all. First I wish to congratulate the Debian Installer team for there fantastic work on armhf. I tested both the hd-media and netinst on a Allwinner H3 Orange Pi Plus and the installer worked without any glitch up to the reboot. But unfortunately the installed system on eMMC don't boot. There is no message at all on the console while powering up the board with the eMMC alone, but there is clearly something installed on the eMMC when I inspect it from an other image booted from the SD card. I suspect that the eMMC boot is not supported. Anyone can confirm or not that fact ? Some information on what I can see on the eMMC: /dev/mmcblk1: block special (179/16) /dev/mmcblk1boot0: block special (179/32) /dev/mmcblk1boot1: block special (179/48) /dev/mmcblk1p1:block special (179/17) /dev/mmcblk1p2:block special (179/18) /dev/mmcblk1p3:block special (179/19) /dev/mmcblk1p5:block special (179/21) Device BootStart End Sectors Size Id Type /dev/mmcblk1p1 *2048 499711 497664 243M 83 Linux /dev/mmcblk1p2499712 13266943 12767232 6.1G 83 Linux /dev/mmcblk1p3 13268990 15267839 1998850 976M 5 Extended /dev/mmcblk1p5 13268992 15267839 1998848 976M 82 Linux swap / Solaris On dev/mmcblk1p1: 14 3721 -rw-r--r-- 1 root root 3793672 Sep 26 18:07 ./vmlinuz-4.7.0-1-armmp-lpae 23 3 -rw-r--r-- 1 root root 2463 Oct 5 18:49 ./boot.scr.bak 13181 -rw-r--r-- 1 root root 183970 Sep 26 00:48 ./config-4.7.0-1-armmp-lpae 25 3 -rw-r--r-- 1 root root 2463 Oct 5 18:50 ./boot.scr 24 15352 -rw-r--r-- 1 root root 15657733 Oct 5 18:50 ./initrd.img-4.7.0-1-armmp-lpae 12 2860 -rw-r--r-- 1 root root 2914681 Sep 26 00:48 ./System.map-4.7.0-1-armmp-lpae 12053 17 -rw-r--r-- 1 root root16337 Oct 5 18:50 ./dtbs/4.7.0-1-armmp-lpae/sun8i-h3-orangepi-plus.dtb 12052 17 -rw-r--r-- 1 root root16337 Oct 5 18:50 ./dtbs/4.7.0-1-armmp-lpae/sun8i-h3-orangepi-plus.dtb.bak -- Jean-Christian
Bug#602568: squeeze-di-beta1 installer: partman hang
Christian PERRIER a écrit : Quoting Jean-Christian de Rivaz (j...@eclis.ch): Unfortunately there is no /var/log/installer/ directory: That dir exists on the installed system. As you couuldn't install, it is indeed not there ls -al /var/log drwxr-xr-x2 root root 0 Nov 5 22:33 . drwxr-xr-x8 root root 0 Nov 5 22:23 .. -rw-r--r--1 root root 17172 Nov 5 22:33 hardware-summary lrwxrwxrwx1 root root44 Nov 5 22:33 install-report.template - /usr/share/save-logs/install-report.template lrwxrwxrwx1 root root16 Nov 5 22:33 lsb-release - /etc/lsb-release -rw-r--r--1 root root 993 Nov 5 22:23 partman lrwxrwxrwx1 root root20 Nov 5 22:33 status - /var/lib/dpkg/status -rw-r--r--1 root root 71813 Nov 5 22:33 syslog /var/log/partman is what Miguel wanted to mention. Thanks for the clarification, here is the /var/log/partman: /bin/partman: *** /lib/partman/init.d/25md-devices: *** /lib/partman/init.d/30parted: *** parted_server: === Starting the server parted_server: main_loop: iteration 1 parted_server: Opening infifo /lib/partman/init.d/30parted: IN: OPEN =dev=sda /dev/sda parted_server: Read command: OPEN parted_server: command_open() parted_server: Request to open =dev=sda parted_server: Opening outfifo parted_server: OUT: OK parted_server: OUT: OK parted_server: Note =dev=sda as unchanged parted_server: Closing infifo and outfifo parted_server: main_loop: iteration 2 parted_server: Opening infifo /lib/partman/init.d/30parted: IN: OPEN =dev=sdb /dev/sdb parted_server: Read command: OPEN parted_server: command_open() parted_server: Request to open =dev=sdb parted_server: Opening outfifo parted_server: OUT: OK parted_server: OUT: OK I suspect that something like Closing infifo and outfifo for /dev/sdb is missing. On the screen I have at this moment a progress bar Starting up the partitioner fixed at 50% and a statement Scanning disks... on the lower left. If I understand correctly, those /var/log/partman traces are related to this code from /lib/partman/init.d/30parted that seem to talk to a parted_server process: cd $dev open_dialog OPEN $(cat $dev/device) read_line response close_dialog if [ $response = failed ]; then cd / rm -rf $dev fi Maybe parted_server is not responding to /lib/partman/init.d/30parted. A 'ps' give this processes list: PID USER VSZ STAT COMMAND 1 root 1360 S/bin/busybox init 2 root 0 SW [kthreadd] 3 root 0 SW [ksoftirqd/0] 4 root 0 SW [watchdog/0] 5 root 0 SW [events/0] 6 root 0 SW [cpuset] 7 root 0 SW [khelper] 8 root 0 SW [netns] 9 root 0 SW [async/mgr] 10 root 0 SW [pm] 11 root 0 SW [sync_supers] 12 root 0 SW [bdi-default] 13 root 0 SW [kintegrityd/0] 14 root 0 SW [kblockd/0] 15 root 0 SW [kacpid] 16 root 0 SW [kacpi_notify] 17 root 0 SW [kacpi_hotplug] 18 root 0 SW [kseriod] 19 root 0 SW [kondemand/0] 20 root 0 SW [khungtaskd] 21 root 0 SW [kswapd0] 22 root 0 SWN [ksmd] 23 root 0 SW [aio/0] 24 root 0 SW [crypto/0] 44 root 1356 S udevd --daemon --resolve-names=never 202 root 0 SW [ksuspend_usbd] 203 root 0 SW [khubd] 204 root 0 SW [ata/0] 205 root 0 SW [ata_aux] 207 root 0 SW [scsi_eh_0] 208 root 0 SW [scsi_eh_1] 209 root 0 SW [scsi_eh_2] 210 root 0 SW [scsi_eh_3] 222 root 0 SW [scsi_eh_4] 223 root 0 SW [usb-storage] 257 root 1360 S/sbin/syslogd -m 0 -O /var/log/syslog -S 259 root 1360 S/sbin/klogd -c 2 321 root 1364 S/bin/sh /sbin/debian-installer 322 root 1872 S-/bin/sh 323 root 1360 S/bin/busybox init 324 root 1360 S/usr/bin/tail -f /var/log/syslog 334 root 3364 S/usr/bin/bterm -f /lib/unifont.bgf -l C.UTF-8 /lib/d 335 root 14248 Sdebconf -o d-i /usr/bin/main-menu 341 root 1236 S/usr/bin/main-menu 1983 root 0 SW [loop0] 4463 root 1868 Sudhcpc -i eth0 -V d-i -O subnet -O broadcast -O rout 4744 root 1352 S udevd --daemon --resolve-names=never 5212 root 1712 Sudpkg --configure --force-configure partman-base 5213 root 1868 S/bin/sh /var/lib/dpkg/info/partman-base.postinst con 5214 root 1872 S/bin/sh /bin
Bug#602568: squeeze-di-beta1 installer: partman hang
I finally found the parted_servec.c into
http://packages.debian.org/squeeze/partman-base . I think the problem is
in the OPEN command path for /dev/sdb:
void
command_open()
{
log(command_open()); === found in the log
char *device;
scan_device_name();
if (1 != iscanf(%as, device))
critical_error(Expected device name.);
log(Request to open %s, device_name); === in the log
open_out();
if (device_opened(device_name)) {
static char *only_ok[] = { OK, NULL };
log(Warning: the device is already opened);
pseudo_exception(Warning,
The device is already opened., only_ok);
} else {
set_device_named(device_name, ped_device_get(device));
}
oprintf(OK\n); === In the log too
if (NULL != device_named(device_name)) {
oprintf(OK\n); === Last line from the log
deactivate_exception_handler();
set_disk_named(device_name,
ped_disk_new(device_named(device_name)));
unchange_named(device_name);
activate_exception_handler();
} else
oprintf(failed\n);
free(device);
}
So I now suspect that the function ped_disk_new() is where parted_server
failed. But it's actually just a beat, not a proven fact.
I have see that in the install expert mode that parted can be loaded as
a additional component, so I did and give it a try:
parted /dev/sda print
Model: ATA ST9250315AS (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End SizeType File system Flags
1 1049kB 54.5GB 54.5GB primary ntfs
3 54.5GB 55.1GB 537MB primary ext3 boot
4 55.1GB 250GB 195GB extended
5 55.1GB 109GB 53.7GB logical btrfs
2 250GB 250GB 21.2MB primary
Seem to be OK, despite the btrfs partition. Now with /dev/sdb:
parted /dev/sdb print
You found a bug in GNU Parted! Here's what you have to do:
Don't panic! The bug has most likely not affected any of your data.
Help us to fix this bug by doing the following:
Check whether the bug has already been fixed by checking
the last version of GNU Parted that you can find at:
http://ftp.gnu.org/gnu/parted/
Please check this version prior to bug reporting.
If this has not been fixed yet or if you don't know how to check,
please visit the GNU Parted website:
http://www.gnu.org/software/parted
for further information.
Your report should contain the version of this release (2.3)
along with the error message below, the output of
parted DEVICE unit co print unit s print
and the following history of commands you entered.
Also include any additional information about your setup you
consider important.
Assertion (dev != NULL) at ../../libparted/cs/geom.c:78 in function
ped_geometry_new() failed.
Ah! It's now clear that this is the 5MB FAT12 partition on /dev/sdb that
cause the problem. I think that the bug can now safely be assigned to
either parted or libparted0-udeb.
Here is the offending code:
/**
* Create a new PedGeometry object on \p disk, starting at \p start with a
* size of \p length sectors.
*
* \return NULL on failure.
*/
PedGeometry*
ped_geometry_new (const PedDevice* dev, PedSector start, PedSector length)
{
PedGeometry*geom;
PED_ASSERT (dev != NULL, return NULL); === Abort here.
geom = (PedGeometry*) ped_malloc (sizeof (PedGeometry));
if (!geom)
goto error;
if (!ped_geometry_init (geom, dev, start, length))
goto error_free_geom;
return geom;
error_free_geom:
free (geom);
error:
return NULL;
}
Obviously, this problem is not really into ped_geometry_new(), but into
a previously executed code that should have created the const PedDevice*
dev.
Now, is parted abort with a so clear assert message, this don't explain
why parted_server can terminate without generating a comparable message,
and why 30parted is unable to see that parted_server is not there
anymore. So maybe some more bugs should be open to fix all of this.
Regards,
Jean-Christian de Rivaz
--
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/4cd538fb.2030...@eclis.ch
Bug#602568: squeeze-di-beta1 installer: partman hang
Can't easily find what's wrong into the parted-2.3/libparted code. But GNU Parted 1.8.8 from a Lenny machine work on this disk: parted /dev/sdb print Error: Can't have the end before the start! Model: disk2go PURE II (scsi) Disk /dev/sdb: 5243kB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End SizeType File system Flags 1 32.8kB 5243kB 5210kB primary fat16 The problem maybe cam from the message Can't have the end before the start!. Also this version of parted say this is a FAT16 partition, but fdisk say this is a FAT12: fdisk -l /dev/sdb Disk /dev/sdb: 5 MB, 5242880 bytes 256 heads, 32 sectors/track, 1 cylinders Units = cylinders of 8192 * 512 = 4194304 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdb1 1 250881 FAT12 Partition 1 has different physical/logical endings: phys=(40, 255, 32) logical=(1, 63, 32) It also say that something is wrong with the geometry of this partition. I then do a new partition on the /dev/sdb: Disk /dev/sdb: 5 MB, 5242880 bytes 256 heads, 32 sectors/track, 1 cylinders Units = cylinders of 8192 * 512 = 4194304 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdb1 1 140801 FAT12 The parted from Lenny is still not happy: parted /dev/sdb print Error: Can't have the end before the start! Model: disk2go PURE II (scsi) Disk /dev/sdb: 5243kB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End SizeType File system Flags 1 16.4kB 4194kB 4178kB primary And the parted on the Squeeze installer still hang the same way. After that I tryed to use a FAT16 partition: Disk /dev/sdb: 5 MB, 5242880 bytes 256 heads, 32 sectors/track, 1 cylinders Units = cylinders of 8192 * 512 = 4194304 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdb1 1 140806 FAT16 But still, the parted from the installed abort with the same message. At this point, I am a bit confused: why the parted from the Squeeze installer get so ill with this 5MB disk despite the fact that others tools and previous parted version handle it correctly. Finally I removed the partition from that /dev/sdb disk and the installed worked. Ah! So the bug seem to be related to a unusual geometry of that disk. Jean-Christian de Rivaz -- 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/4cd5497f.3010...@eclis.ch
Bug#602568: squeeze-di-beta1 installer: partman hang
Now Squeeze is installed into the notepad and I can test the parted 2.3-3 that is available from it. No problem without partition of course, bt the surprise is that it also have no issue with a FAT12 partition: fdisk -l /dev/sdb Disk /dev/sdb: 5 MB, 5242880 bytes 1 heads, 10 sectors/track, 1024 cylinders Units = cylinders of 10 * 512 = 5120 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdb1 2102451151 FAT12 parted /dev/sdb print Model: disk2go PURE II (scsi) Disk /dev/sdb: 5243kB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End SizeType File system Flags 1 5120B 5243kB 5238kB primary But from http://packages.debian.org/squeeze/libparted0-udeb it seem that this is this 2.3-3 version that is used into the installer. I feel lost in doubt. I rebooted and restarted the installer, only to find that his parted still abort the same way. Now the question is why the parted from the installer react so bad to something that do not hurt the parted from squeeze, since there should be compiled from the same code base ? Or is there something missing in the picture ? Jean-Christian de Rivaz -- 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/4cd5b3a3.6040...@eclis.ch
Bug#602568: squeeze-di-beta1 installer: partman hang
Interesting finding: libparted.so.0.0.1 (from *.deb) != libparted.so.0.0.1 (from *.udeb) I have do this: apt-get source parted cd parted-2.3/ dpkg-buildpackage -rfakeroot -uc -us cd .. mkdir install-bin dpkg -x libparted0-udeb_2.3-3_i386.udeb install-bin/ dpkg -x parted-udeb_2.3-3_i386.udeb install-bin/ cd install-bin/ ls -l * lib: total 484 lrwxrwxrwx 1 jcdr jcdr 18 6 nov 21:46 libparted.so.0 - libparted.so.0.0.1 -rw-r--r-- 1 jcdr jcdr 489596 6 nov 21:37 libparted.so.0.0.1 sbin: total 72 -rwxr-xr-x 1 jcdr jcdr 68012 6 nov 21:37 parted Now test ./sbin/parted with the system library: ldd ./sbin/parted linux-gate.so.1 = (0xb77c) libparted.so.0 = /lib/libparted.so.0 (0xb773d000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb75f7000) libuuid.so.1 = /lib/libuuid.so.1 (0xb75f2000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb75ee000) libdevmapper.so.1.02.1 = /lib/libdevmapper.so.1.02.1 (0xb75cc000) libblkid.so.1 = /lib/libblkid.so.1 (0xb75b) /lib/ld-linux.so.2 (0xb77c1000) libselinux.so.1 = /lib/libselinux.so.1 (0xb7595000) libudev.so.0 = /lib/libudev.so.0 (0xb7586000) ./sbin/parted /dev/sdb print WARNING: You are not superuser. Watch out for permissions. Model: disk2go PURE II (scsi) Disk /dev/sdb: 5243kB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End SizeType File system Flags 1 5120B 5243kB 5238kB primary It use the /lib/libparted.so.0 (with the root /) and work fine. Now test ./sbin/parted with the installer library: LD_LIBRARY_PATH=./lib/ ldd ./sbin/parted linux-gate.so.1 = (0xb78b1000) libparted.so.0 = ./lib/libparted.so.0 (0xb7831000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb76da000) libuuid.so.1 = /lib/libuuid.so.1 (0xb76d5000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb76d1000) libdevmapper.so.1.02.1 = /lib/libdevmapper.so.1.02.1 (0xb76af000) libblkid.so.1 = /lib/libblkid.so.1 (0xb7693000) /lib/ld-linux.so.2 (0xb78b2000) libselinux.so.1 = /lib/libselinux.so.1 (0xb7678000) libudev.so.0 = /lib/libudev.so.0 (0xb7669000) LD_LIBRARY_PATH=./lib/ ./sbin/parted /dev/sdb print WARNING: You are not superuser. Watch out for permissions. You found a bug in GNU Parted! Here's what you have to do: Don't panic! The bug has most likely not affected any of your data. Help us to fix this bug by doing the following: Check whether the bug has already been fixed by checking the last version of GNU Parted that you can find at: http://ftp.gnu.org/gnu/parted/ Please check this version prior to bug reporting. If this has not been fixed yet or if you don't know how to check, please visit the GNU Parted website: http://www.gnu.org/software/parted for further information. Your report should contain the version of this release (2.3) along with the error message below, the output of parted DEVICE unit co print unit s print and the following history of commands you entered. Also include any additional information about your setup you consider important. Assertion (dev != NULL) at ../../libparted/cs/geom.c:78 in function ped_geometry_new() failed. Abandon It use the ./lib/libparted.so.0 (the current directory lib instead of the root /) and failed. I verified that it work this way with the others partitions. There is obviously something different between this two library, despite the fact that there are compiled form the same source package: ls -l /lib/libparted.so.0.0.1 lib/libparted.so.0.0.1 -rw-r--r-- 1 root root 432668 17 oct 12:18 /lib/libparted.so.0.0.1 -rw-r--r-- 1 jcdr jcdr 489596 6 nov 21:37 lib/libparted.so.0.0.1 file /lib/libparted.so.0.0.1 lib/libparted.so.0.0.1 /lib/libparted.so.0.0.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped lib/libparted.so.0.0.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped The installed library is about 56k less in size that the system library. Is some code path not compiled for the installer version ? Jean-Christian de Rivaz -- 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/4cd5c534.7040...@eclis.ch
Bug#602568: squeeze-di-beta1 installer: partman hang
I now have a backtrace: Backtrace has 20 calls on stack: 20: ./libparted/.libs/libparted.so.0(ped_assert+0x28) [0xb77d9073] 19: ./libparted/.libs/libparted.so.0(ped_geometry_new+0x5a) [0xb77e2aed] 18: ./libparted/.libs/libparted.so.0(ped_geometry_duplicate+0x73) [0xb77e2bc6] 17: ./libparted/.libs/libparted.so.0(ped_constraint_init+0x15e) [0xb77e3c92] 16: ./libparted/.libs/libparted.so.0(ped_constraint_new+0x82) [0xb77e3d54] 15: ./libparted/.libs/libparted.so.0(+0x504c8) [0xb781c4c8] 14: ./libparted/.libs/libparted.so.0(+0x50bdd) [0xb781cbdd] 13: ./libparted/.libs/libparted.so.0(+0x51249) [0xb781d249] 12: ./libparted/.libs/libparted.so.0(+0x517b7) [0xb781d7b7] 11: ./libparted/.libs/libparted.so.0(+0x1328f) [0xb77df28f] 10: ./libparted/.libs/libparted.so.0(ped_disk_add_partition+0x15f) [0xb77e1a7a] 9: ./libparted/.libs/libparted.so.0(+0x4e72c) [0xb781a72c] 8: ./libparted/.libs/libparted.so.0(+0x4e94e) [0xb781a94e] 7: ./libparted/.libs/libparted.so.0(ped_disk_new+0xd2) [0xb77dddbe] 6: /home/jcdr/install-O2/sbin/parted() [0x804dec5] 5: /home/jcdr/install-O2/sbin/parted() [0x804b26d] 4: /home/jcdr/install-O2/sbin/parted() [0x8054b7f] 3: /home/jcdr/install-O2/sbin/parted() [0x8051a52] 2: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xb768bc76] 1: /home/jcdr/install-O2/sbin/parted() [0x804af21] I can reproduce this with this command from the package build: parted-2.3/build-udeb$ LD_LIBRARY_PATH=./libparted/.libs/ ~/install-O2/sbin/parted /dev/sdb print While analyzing the debian/rules I found this: # Workaround/fix bug #442308 CFLAGS += -fgnu89-inline UDEB_CFLAGS += -fgnu89-inline This bug is tracked here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442308 This workaround is now obsolete as is was introduced 3 years ago for parted 1.8-7 and we now use parted 2.3-3 that compile just fine without this option. But unfortunately this is not the cause of my problem. After a lot of test with different config.status file, I found this picture by testing only the build-udeb: library fail with CFLAGS=' -Werror' library fail with CFLAGS='-g -Werror' library good with CFLAGS='-g -O2 -Werror' library good with CFLAGS='-O2 -Werror' Something wrong without the -O2 optimization ? Seem incredible. But... I just want to check: library good in build-deb with CFLAGS='-g -O2 -fgnu89-inline -Werror' library good in build-udeb with CFLAGS='-O2 -fgnu89-inline -Werror' library fail in build-deb with CFLAGS='-g -fgnu89-inline -Werror' library fail in build-udeb with CFLAGS='-fgnu89-inline -Werror' Ouch! It better to use the -O2 optimizer ! Ok, now at this stage I can give some facts: 1) The lib/partman/init.d/30parted script is unable to detect and report abnormal parted-server end. 2) The CFLAGS -fgnu89-inline option from the bug #442308 can be removed for the current version of parted-2.3-3 3) Something bad happen with the parted-2.3-3 code when the -O2 optimization is not used. Enough for me. Please, someone from Debian, give me some instruction of what action must be taken now. Should I open others bugs report for 1) and 2) ? Regards, Jean-Christian de Rivaz -- 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/4cd5fe38.6080...@eclis.ch
Bug#602568: squeeze-di-beta1 installer: partman hang
Please find in attachment my current proposition of patch. It remove the
obsolete -fgnu89-inline and use the same flags for build-udeb than for
build-deb to get the -O2 optimization.
This work, but I still don't understand why the code fail without
optimization.
Regards,
Jean-Christian de Rivaz
--- a/debian/rules 2010-11-07 02:57:24.0 +0100
+++ b/debian/rules 2010-11-07 02:59:01.0 +0100
@@ -89,14 +89,11 @@
ifeq (, $(CFLAGS))
CFLAGS = -g
-UDEB_CFLAGS = -g
ifeq (, $(findstring noopt, $(DEB_BUILD_OPTIONS)))
CFLAGS += -O2
-UDEB_CFLAGS += -Os
else
CFLAGS += -O0
-UDEB_CFLAGS += -O0
endif
endif
@@ -118,10 +115,6 @@
CONFFLAGS += --disable-pc98
endif
-# Workaround/fix bug #442308
-CFLAGS += -fgnu89-inline
-UDEB_CFLAGS += -fgnu89-inline
-
# Enable device-mapper only on Linux
ifeq (linux, $(DEB_BUILD_ARCH_OS))
CONFDEVMAPPER = --enable-device-mapper
@@ -186,7 +179,7 @@
dh_testdir
[ -d build-udeb ] || mkdir build-udeb
- cd build-udeb CFLAGS=$(UDEB_CFLAGS) ac_cv_header_execinfo_h=no ../configure --prefix=/usr \
+ cd build-udeb CFLAGS=$(CFLAGS) ac_cv_header_execinfo_h=no ../configure --prefix=/usr \
--sbindir=/sbin --libdir=/lib --mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info --enable-shared --disable-static \
--build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \
Bug#602568: squeeze-di-beta1 installer: partman hang
code 143 Nov 5 22:25:40 main-menu[337]: WARNING **: Menu item 'partman-base' failed. Nov 5 22:26:06 main-menu[337]: INFO: Menu item 'save-logs' selected Nov 5 22:32:55 main-menu[337]: INFO: Menu item 'save-logs' selected Nov 5 22:33:38 main-menu[337]: INFO: Menu item 'save-logs' selected The debian installed log provide a partman log: /bin/partman: *** /lib/partman/init.d/25md-devices: *** /lib/partman/init.d/30parted: *** parted_server: === Starting the server parted_server: main_loop: iteration 1 parted_server: Opening infifo /lib/partman/init.d/30parted: IN: OPEN =dev=sda /dev/sda parted_server: Read command: OPEN parted_server: command_open() parted_server: Request to open =dev=sda parted_server: Opening outfifo parted_server: OUT: OK parted_server: OUT: OK parted_server: Note =dev=sda as unchanged parted_server: Closing infifo and outfifo parted_server: main_loop: iteration 2 parted_server: Opening infifo /lib/partman/init.d/30parted: IN: OPEN =dev=sdb /dev/sdb parted_server: Read command: OPEN parted_server: command_open() parted_server: Request to open =dev=sdb parted_server: Opening outfifo parted_server: OUT: OK parted_server: OUT: OK It seem to hang when processing /dev/sdb if I understand correctly. /dev/sdb is actually a small USB disk that is integrated into the same USB stick as the 2GB /dev/sdc USB disk. When I insert this USB stick into a regular Lenny machine I get this: [130550.986061] usb 2-2: new high speed USB device using ehci_hcd and address 11 [130551.189585] usb 2-2: configuration #1 chosen from 1 choice [130551.190036] scsi15 : SCSI emulation for USB Mass Storage devices [130551.190307] usb-storage: device found at 11 [130551.190317] usb-storage: waiting for device to settle before scanning [130551.190547] usb 2-2: New USB device found, idVendor=1dbe, idProduct=0102 [130551.190557] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [130551.190563] usb 2-2: SerialNumber: AA2719E4 [130556.190280] usb-storage: device scan complete [130556.191114] scsi 15:0:0:0: Direct-Access disk2go PURE II 8.20 PQ: 0 ANSI: 2 [130556.191726] scsi 15:0:0:1: Direct-Access disk2go PURE II 8.20 PQ: 0 ANSI: 2 [130556.194101] sd 15:0:0:0: [sdb] 10240 512-byte hardware sectors (5 MB) [130556.194599] sd 15:0:0:0: [sdb] Write Protect is off [130556.194603] sd 15:0:0:0: [sdb] Mode Sense: 03 00 00 00 [130556.194604] sd 15:0:0:0: [sdb] Assuming drive cache: write through [130556.196098] sd 15:0:0:0: [sdb] 10240 512-byte hardware sectors (5 MB) [130556.196602] sd 15:0:0:0: [sdb] Write Protect is off [130556.196605] sd 15:0:0:0: [sdb] Mode Sense: 03 00 00 00 [130556.196607] sd 15:0:0:0: [sdb] Assuming drive cache: write through [130556.196609] sdb: sdb1 [130556.490327] sd 15:0:0:0: [sdb] Attached SCSI removable disk [130556.495952] sd 15:0:0:1: [sdc] 4184064 512-byte hardware sectors (2142 MB) [130556.497988] sd 15:0:0:1: [sdc] Write Protect is off [130556.497992] sd 15:0:0:1: [sdc] Mode Sense: 03 00 00 00 [130556.497993] sd 15:0:0:1: [sdc] Assuming drive cache: write through [130556.500437] sd 15:0:0:1: [sdc] 4184064 512-byte hardware sectors (2142 MB) [130556.500973] sd 15:0:0:1: [sdc] Write Protect is off [130556.500976] sd 15:0:0:1: [sdc] Mode Sense: 03 00 00 00 [130556.500977] sd 15:0:0:1: [sdc] Assuming drive cache: write through [130556.500980] sdc: [130556.501789] sd 15:0:0:1: [sdc] Attached SCSI removable disk [130556.813803] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [130556.917917] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! So /dev/sdb is just an another innocent small 5MB usb storage disk. It's strange that partman can be getting trouble with this. How can I get more debug informations from partman to go deeper into the analysis ? Note: I first tried a AMD64 install that have the same exact problem before giving this report from a i386 install. The machine is only 2 days old and run without problem Windows 7 and Meego 1.1, so no hardware failure is expected. Regards, Jean-Christian de Rivaz -- 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/4cd48df2.9090...@eclis.ch
Bug#602568: squeeze-di-beta1 installer: partman hang
Miguel Figueiredo a écrit : A Sexta 05 Novembro 2010 23:06:26 Jean-Christian de Rivaz você escreveu: [...] How can I get more debug informations from partman to go deeper into the analysis ? [...] You can check /var/log/installer/partman and the syslog on that location can be useful too. Unfortunately there is no /var/log/installer/ directory: ls -al /var/log drwxr-xr-x2 root root 0 Nov 5 22:33 . drwxr-xr-x8 root root 0 Nov 5 22:23 .. -rw-r--r--1 root root 17172 Nov 5 22:33 hardware-summary lrwxrwxrwx1 root root44 Nov 5 22:33 install-report.template - /usr/share/save-logs/install-report.template lrwxrwxrwx1 root root16 Nov 5 22:33 lsb-release - /etc/lsb-release -rw-r--r--1 root root 993 Nov 5 22:23 partman lrwxrwxrwx1 root root20 Nov 5 22:33 status - /var/lib/dpkg/status -rw-r--r--1 root root 71813 Nov 5 22:33 syslog I already inspected the syslog as you can find the interesting part in my initial report: partman simply hang without verbose message. This is why I search a way to get more informations. Jean-Christian -- 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/4cd4a30a.6030...@eclis.ch
Bug#275481: Sarg Installation problem report
support as LILO have with it raid-extra-boot option. I am open to make a new set of test if someone notify me of a new version with fix on it. I use two old disk to test the install on what is normaly a NFS worksation so it can't trash my datas. I know many people interresting about installing a basic Debian Sarge web server with the same RAID1 setup. I think it make sense to solve the problemes I describs here. Have a good day, -- Jean-Christian de Rivaz mailto:[EMAIL PROTECTED] tel:+41-78-657-7442 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#275481: More informations
I make a new test of the whole installation after a:
cat /dev/null /dev/hda
cat /dev/null /dev/hdc
to be really parano.
I use the script in attachment (as root) to construct the flash content.
I used dayly boot.img.gz and sarge-i386-netinst.iso downloaded from:
http://cdimage.debian.org/pub/cdimage-testing/daily/i386/current/sarge-i386-netinst.iso
http://people.debian.org/~joeyh/d-i/images/daily/hd-media/boot.img.gz
About problem 1)
The result is that same as before: the original boot.img hang the
machine and SPB-Linux master bootsector with ldlinux.sys from syslinux
in testing solve the problem. Obviousely the ldlinux.sys from boot.img
is not from syslinux 2.10-1 from testing. It it more big in size and
don't work with SPB-Linux master boot sector.
I found interresting this comment from SPB-Linux doc:
---
If your usb storage device does not boot even if the syslinux bootloader
is installed you can try to use the spblinux mbr bootloader:
- usual mbr boot loaders use the CHS values in the partition table
- the bios might use other CHS values than linux/windows
- the spblinux mbr boot loader uses the LBA entry in the partition table:
in some cases the bootsector of the active partition can now be loaded
Installation of mbr bootloader code spb2_mbr.sec
if(!) your usb storage device is /dev/sda
dd if=spb2_mbr.sec of=/dev/sda
Disclaimer: spb2_mbr.sec is tested but the author cannot
give any warranty that spb2_mbr.sec works on your system.
this mbr bootloader gives some diagnostic output:
- an excellent reference about int13 can be found at
http://www.ctyme.com/intr/int-13.htm
- the partition table format is documented at
http://www.ata-atapi.com/hiwtab.htm#T2
---
I also found this on the syslinux site:
---
{ Cards that cause trouble no matter what }
Some versions of the Promise ATA RAID cards are known to cause problems
no matter if you boot from them or not. I have received several reports
that conclusively show that the Promise ATA RAID BIOS overwrites random
location in low memory. This BIOS is considered utterly unsupportable.
This phenomenon has been observed even when the ATA RAID is not the boot
device (e.g. using PXELINUX.)
---
And I effectively have a Promise SATA RAID controller PDC20376. But
since no drive are attached, the BIOS say it disable the RAID BIOS. I
can't test without this controller since it's integrated into the
mainboard and the BIOS have no way to disable it and there is no jump to
deactivate it.
Anyway, I found very interresting that the SPB-Linux master boot record
work very wonderfully where syslinux claim it impossible to support!
Maybe Debian have to provids an alternative USB boot with SPB-Linux
master boot sector.
New problem
===
Just after the reboot there is a welcome screen. I got an error just
after pressing enter, Something about language install with a lot of
stuff about perl. It just show for a half second. The rest of the
installer go well but in a more detailled level than the first test. I
don't think it's a installer problem but an base-config problem. Where I
should fill the bug ?
About problem 2)
No change.
About problem 3)
I found a more simple solution:
a) edit the /boot/grub/menu.lst and replace (hd0,0) with (hd0,1)
b) grub
b1) device (hd0) /dev/hda
b2) root (hd0,1)
b3) setup (hd0)
b4) device (hd0) /dev/hdc
b5) root (hd0,1)
b6) setup (hd0)
b7) quit
So I can boot with any disks. Maybe the root instruction is not
required, as already into menu.lst. I will try next time. I am still
very new to GRUB.
Have a good day,
--
Jean-Christian de Rivaz
mailto:[EMAIL PROTECTED]
tel:+41-78-657-7442
go.sh
Description: Bourne shell script
