Re: Trying to install Debian on an Asus VivoTab Smart ME400C
> I'll try to get the same dump under Debian to see if we are seing the same > tables as Windows sees. I have run the acpica-tools under Debian and I got the same 4 tables I had under Windows plus a lot other tables, I have put a new tar available with all the tables at: http://www.manty.net/linuxacpicadump.tgz So I guess that if Windows does something to avoid a the problem with the firmware is not seen through the userspace tools :-( Any ideas? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#791794: UUID not found for root
On Tue, 2015-11-10 at 11:46 +0100, Cyril Brulebois wrote: > Ian Campbell (2015-11-10): > > On Tue, 2015-11-10 at 11:14 +0100, Cyril Brulebois wrote: > > > (As usual: you can safely pretend I didn't follow or fully > understand f-k > > > things.) > > > > > > Given the size of the fix and the fact the comment right above > the code > > > being fixed is explicit about the initial intent makes me want to > > > cherry-pick it right away. It might be a good idea to let it go > through > > > a bit of testing before doing so, just in case something breaks. > > > > > > What do you think? > > > > I was thinking to at least wait for it to hit testing first (should > do so > > at the end of the week) and then probably giving it a little more > time > > (just a week or so) to bake there too, but I may be being too > conservative. > > Seems fair to me; feel free to prod me in two weeks if you saw no > breakages by then, so that I can push/ask SRM for an upload. I've not seen any complaints so far, the fix has been in Stretch for about three weeks now. Ian.
Bug#807129: jessie-pu: package flash-kernel/3.35+deb8u2
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu [ X-D-Cc: debian-boot@lists.debian.org ] Hi, We'd like to fix #791794 in stable, that is a possible hang when a given script is running under d-i. The fix widens the DEBIAN_FRONTEND check to avoid waiting for Ctrl-C (initially only when non-interactive is used, now if any debconf frontend is in use). The fix reached testing some weeks ago, and Ian is rather confident. See the few mails under this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791794#105 Changelog entry: | flash-kernel (3.35+deb8u2) stable; urgency=medium | | [ Ian Campbell ] | * Avoid waiting for Ctrl-C if any debconf frontend is in use, not just | non-interactive. (Closes: #791794) | | -- Cyril Brulebois Sat, 05 Dec 2015 19:16:33 +0100 Thanks for your time. Mraw, KiBi. diff -Nru flash-kernel-3.35+deb8u1/debian/changelog flash-kernel-3.35+deb8u2/debian/changelog --- flash-kernel-3.35+deb8u1/debian/changelog 2015-06-17 09:22:41.0 +0200 +++ flash-kernel-3.35+deb8u2/debian/changelog 2015-12-05 19:16:35.0 +0100 @@ -1,3 +1,11 @@ +flash-kernel (3.35+deb8u2) stable; urgency=medium + + [ Ian Campbell ] + * Avoid waiting for Ctrl-C if any debconf frontend is in use, not just +non-interactive. (Closes: #791794) + + -- Cyril Brulebois Sat, 05 Dec 2015 19:16:33 +0100 + flash-kernel (3.35+deb8u1) stable; urgency=medium * Combine i.MX53 QSB and LOCO board entries, they are the same thing and the diff -Nru flash-kernel-3.35+deb8u1/initramfs-tools/hooks/flash_kernel_set_root flash-kernel-3.35+deb8u2/initramfs-tools/hooks/flash_kernel_set_root --- flash-kernel-3.35+deb8u1/initramfs-tools/hooks/flash_kernel_set_root 2015-06-17 09:22:41.0 +0200 +++ flash-kernel-3.35+deb8u2/initramfs-tools/hooks/flash_kernel_set_root 2015-12-05 19:15:53.0 +0100 @@ -34,7 +34,7 @@ # If debconf appears to be running then it is important that # we do not block on stdin since this would hang the # installer. - if [ "$DEBIAN_HAS_FRONTEND" ] || [ "$DEBIAN_FRONTEND" = "noninteractive" ]; then + if [ "$DEBIAN_HAS_FRONTEND" ] || [ "$DEBIAN_FRONTEND" ]; then echo "Unable to abort; system will probably be broken!" >&2 else echo "Press Ctrl-C to abort build, or Enter to continue" >&2
Bug#791794: UUID not found for root
Hi, Ian Campbell (2015-12-05): > I've not seen any complaints so far, the fix has been in Stretch for > about three weeks now. Thanks for the prod; pu filed accordingly: #807129. Mraw, KiBi. signature.asc Description: Digital signature
Bug#806164: installation-reports: jessie install on dell xps 13 9350 (grub-installer issues)
So, I have some bad news - the issue may not be completely fixed. Or, I might have missed something. I tried to build an iso by following the steps to check out the debian-install stuff[1] but found that the build_all target did not make the netinst ISO as I expected. I next found some directions for altering an existing iso, so I grabbed the net inst and followed the rough directions here[2]. I found I had to modify the directions to generate an efi compatible CD with these here[3]. The directions didn't seem to work due to genisoimage not recognizing all the arguments, so as per the workaround here[4] I had to grab a copy of the genisoimage binary from the ubuntu package. To modify the image, I rsync'd it to a new directory, then deleted the grub-installer 1.127 package and replaced it with a copy of 1.128. I updated the md5sums.txt file and the "Packages.gz" file (leaving everything the same except updating the verison, the path to the package, and the hashes). I then redid the install - and it WORKED! Got no grub error. Unfortunately, when I rebooted after the install, I still have the problem where it drops me into a simple grub command line, and fails to boot the rest of the way. Either something is messed up in my boot loader that a fresh install did not fix, or the fix in the grub-installer package alone is not enough (although it definitely is working better since it doesn't get errors during install anymore). -Carl [1] http://d-i.alioth.debian.org/doc/internals/ch04.html#id321776 [2] https://debmintux.wordpress.com/2010/07/21/howto-create-a-custom-debian-installer-netinstall-iso/ [3] http://askubuntu.com/questions/457528/how-do-i-create-an-efi-bootable-iso-of-a-customized-version-of-ubuntu [4] https://stackoverflow.com/questions/31831268/genisoimage-and-uefi -- Carl Myers PGP Key ID 3537595B PGP Key fingerprint 9365 0FAF 721B 992A 0A20 1E0D C795 2955 3537 595B signature.asc Description: Digital signature
Re: Rebuilding translations when needed (was: translation-check's maxdelta oddities)
Hi, Cyril Brulebois wrote: > Hi, > > [ Initially a debian-boot vs. debian-www topic but I think > vote.debian.org might be having a similar issue. ] > > Holger Wansing (2015-10-31): > > Cyril Brulebois wrote: > > > Could it be that images.data's being updated doesn't lead to a rebuild > > > of the relevant translations? And that those are only rebuilt when their > > > files actually get updated? That would explain why building them locally > > > led to the expected results, while the website getting updated would > > > still have the old contents? > > > > > > (I'm not sure how dependencies between files are declared/detected, and > > > I don't think I'll find time tonight to check this out, hence just > > > throwing the idea for the time being.) > > > > Hmm, looking at the swedish variant of that page, it seems that Kibi's > > assumption might be correct: > > > > The corresponding swedish wml file correctly contains the entity > > , but the website shows "Stretch Alpha 3". > > > > There was no commit for the swedish errata file since the release of > > Alpha 4, and it seems the swedish translation of errata was not newly > > build since then. > > > > I have no clue what to do about this though... > > There's some fun going on with votes right now too. > > https://www.debian.org/vote/index.fr.html has: > | En attente de sponsors > | Résolution générale : mise à jour de la procédure standard de Résolution > > (i.e. waiting for seconds) > > while https://www.debian.org/vote/index.en.html has: > | Voting Open > | General Resolution: Update Standard Resolution Procedure > > The wml_p1_ipp manpage makes me think the following construct might help > get translations rebuilt even if their actual source didn't change: > |Special `Depends' Variant > |You can easily write fragments of Makefiles with the -M flag (see > below) to keep tracks of which > |files the output file depends on, When "ipp" is invoked as a piece > of "WML", the final output file > |may depend on other files. You can tell "ipp" about these hidden > dependencies by using the > |"#depends" variant , e.g. > | > | #depends 'foo.dat' > | #depends "*/*.dat" > | #depends > | > |The contents of the file is not inserted, only information about > dependencies are updated. I have just committed this for the german d-i errata: --- errata.wml 28 Oct 2015 20:18:01 - 1.117 +++ errata.wml 5 Dec 2015 22:08:26 - @@ -1,6 +1,7 @@ #use wml::debian::template title="Debian-Installer - Errata" #use wml::debian::recent_list #include "$(ENGLISHDIR)/devel/debian-installer/images.data" +#depends "$(ENGLISHDIR)/devel/debian-installer/errata.wml" #use wml::debian::translation-check translation="1.220" mindelta="1" maxdelta="1" # $Id: errata.wml,v 1.117 2015/10/28 20:18:01 holger-guest Exp $ # Original-Translator: Frank Lichtenheld , 2003-11-11 Let's see what happens with the next d-i alpha/beta release... (and what the build log looks like tomorrow :-) German builds fine here locally though.) Holger -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0 " J E S S I E " . Registered Linux User #311290 - https://linuxcounter.net/
Bug#806164: installation-reports: jessie install on dell xps 13 9350 (grub-installer issues)
I got my system working. I repeated the chroot experiment from above, confirmed that this time the initrd contained cryptsetup and the other necessary tools (it did), and I was able to then run the grub installer. Since in the past when I did this it didn't work, I was trying to think of something different to try, so I tried making a symlink with a "more expected" name: ln -s /dev/nvme0 /dev/sdb grub-install /dev/sdb I dunno if just running "grub-install" would have been enough, or if it worked specifically because I faked it out with a symlink like this, but after that I rebooted and grub seems to be installed correctly and is able to boot into debian. I'm happy my machine works now but I'm sorry I wasn't able to confirm the fix for you - whatever has been donein grub-installer 1.128 has improved the problem but not totally fixed it - hopefully these details will help you figure out the remaining problems (possibly with the package that provides grub-install, if it is differnet from grub-installer? otherwise some other code path in there...) Thanks! -Carl -- Carl Myers PGP Key ID 3537595B PGP Key fingerprint 9365 0FAF 721B 992A 0A20 1E0D C795 2955 3537 595B signature.asc Description: Digital signature
Re: Trying to install Debian on an Asus VivoTab Smart ME400C
I've been investigating a bit on where the devices are on Windows and I saw
that the Broadcom wifi is on the SDIO bus:
SD\VID_02D0&PID_4330&FN_1\3&18BDEB84&0&0
This device should be supported by the brcmfmac driver but it is not loaded
automatically and if I try to load it it does nothing, I'm guessing that the
card may be the one tied to the mmc2 and thus the messages:
Dec 2 09:29:28 debian kernel: [2.472021] mmc2: no vqmmc regulator found
Dec 2 09:29:28 debian kernel: [2.472026] mmc2: no vmmc regulator found
Dec 2 09:29:28 debian kernel: [2.477573] mmc2: SDHCI controller on ACPI
[INT33BB:01] using ADMA
Dec 2 09:29:28 debian kernel: [2.917231] mmc2: error -22 whilst
initialising SDIO card
Dec 2 09:29:28 debian kernel: [2.974532] sdhci-acpi INT33BB:01: no support
for card's volts
Could give as a hint as to which the problem may be, but still out of luck
searching around on how to fix this.
Also out of luck on the USB devices, Windows lists this as if there were two
EHCI devices and shows two memory ranges:
0xFFA6-0xFFA600FF
0xFFA8-0xFFA800FF
and shows them as:
ACPI\INT33B6\2
ACPI\INT33B9\3
Which indeed is coherent and found at the acpi tables I had sent previously,
those acpi devices exist and are listed on those memory ranges. The question
is... how do I make the Linux kernel find them?
Device (OTG0)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "INT33B6") // _HID: Hardware ID
Name (_CID, "ACPI\\PNP0D20") // _CID: Compatible ID
Name (_UID, 0x02) // _UID: Unique ID
Name (_HRV, 0x02) // _HRV: Hardware Revision
Name (_DEP, Package (0x01) // _DEP: Dependencies
{
\_SB.PEP
})
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource
Settings
{
Name (RBUF, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0xFFA6, // Address Base
0x0100, // Address Length
)
...
If ((Arg0 == ToUUID ("ce2ee385-00e6-48cb-9f05-2edb927c4899") /*
USB Controller */))
So... these are the USB controllers, now... why can't we find them?
some way to relax some checks or similar on either the voltage thing for the
WiFi card or for the USB controller?
/me starts to think I should move this to the lkml as it seems to belong
there more than here.
Regards.
--
Manty/BestiaTester -> http://manty.net
