Processed: tagging 794409

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 794409 + pending
Bug #794409 [os-prober] os-prober: generic detection using /etc/os-release (for 
Void Linux and NixOS)
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
794409: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794409
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 803155

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 803155 + pending
Bug #803155 [os-prober] Typo in README
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
803155: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803155
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 698598

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 698598 + pending
Bug #698598 [os-prober] Small patch to enable/disable debug output
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
698598: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698598
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 674561

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 674561 + pending
Bug #674561 [os-prober] A patch to improve parsing yaboot.conf
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
674561: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674561
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#674561: A patch to improve parsing yaboot.conf

[Colin Watson]

On Fri, May 25, 2012 at 05:14:49PM +0430, Hedayat Vatankhah wrote:
> os-prober assumes that there is no space around '=' sign for append
> directive in yaboot.conf, while there can be. Therefore, both append="some
> options" and append = "some options" are valid in yaboot.conf. This patch
> fixes this parsing bug.

I don't really understand why this only applies to the "append" option
(I suspect that in fact it doesn't), but whatever - this will do for
now.  I converted your patch to POSIX sed syntax and applied it.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Processed: tagging 701814, tagging 648208, tagging 776275, tagging 698733

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 701814 + pending
Bug #701814 [os-prober] os-prober: damages XFS exported via iSCSI but not 
mounted locally; potential data loss
Added tag(s) pending.
> tags 648208 + pending
Bug #648208 [os-prober] os-prober: blockdev --setro affects running kvm 
instances
Bug #788062 [os-prober] os-prober corrupts LVs/partitions while being mounted 
inside a VM
Bug #794849 [os-prober] linux: custom linux-image packages fail to install
Bug #806273 [os-prober] os-prober: remove or disable-per default the non 
grub-mount based probing
Bug #810121 [os-prober] linux: KVM guests randomly get I/O errors on VirtIO 
based devices
Added tag(s) pending.
Added tag(s) pending.
Added tag(s) pending.
Added tag(s) pending.
Added tag(s) pending.
> tags 776275 + pending
Bug #776275 [os-prober] os-prober: use grub-mount-udeb on all linux/freebsd 
arches
Added tag(s) pending.
> tags 698733 + pending
Bug #698733 [os-prober] Fix detection of /usr/ partition as a GNU/Linux root 
partition when /lib* directories are moved to /usr/ completely (e.g. in Fedora 
17/18)
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
648208: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648208
698733: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698733
701814: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701814
776275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776275
788062: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788062
794849: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794849
806273: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806273
810121: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810121
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#851892: To tight permissions on /dev/ptmx

[Thorsten Glaser]

James Clarke dixit:

>#817236 strikes again; the thread there has various workarounds.

Why is this still not fixed in debootstrap, anyway?

Thanks,
//mirabilos
-- 
> Wish I had pine to hand :-( I'll give lynx a try, thanks.

Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine

Processed: Re: Bug#851892: To tight permissions on /dev/ptmx

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 debootstrap
Bug #851892 [cowbuilder] Too tight permissions on /dev/ptmx
Bug reassigned from package 'cowbuilder' to 'debootstrap'.
No longer marked as found in versions cowdancer/0.83.
Ignoring request to alter fixed versions of bug #851892 to the same values 
previously set
> forcemerge 817236 -1
Bug #817236 [debootstrap] schroot: no access to pseudo-terminals in new chroots
Bug #841935 [debootstrap] pbuilder: incorrect permissions on /dev/ptmx breaks 
openpty()
Bug #849168 [debootstrap] pbuilder: Expect programe reported "no more ptys" and 
failed in rebuilding gcc with normal (non-root) user
Bug #851892 [debootstrap] Too tight permissions on /dev/ptmx
Severity set to 'serious' from 'normal'
829299 was blocked by: 849168 817236 841935
829299 was not blocking any bugs.
Added blocking bug(s) of 829299: 851892
Outlook recorded from message bug 851892 message 
Added indication that 851892 affects pbuilder,sbuild,schroot
Marked as found in versions debootstrap/1.0.87 and debootstrap/1.0.85.
Added tag(s) patch.
Bug #841935 [debootstrap] pbuilder: incorrect permissions on /dev/ptmx breaks 
openpty()
Bug #849168 [debootstrap] pbuilder: Expect programe reported "no more ptys" and 
failed in rebuilding gcc with normal (non-root) user
Merged 817236 841935 849168 851892

-- 
817236: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817236
829299: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829299
841935: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841935
849168: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849168
851892: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851892
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#851740: bug report installing 9.0 RC1

[Lennart Sorensen]

On Wed, Jan 18, 2017 at 10:56:58AM +0100, bkk wrote:
> Package: installation-reports
> 
> Boot method: Installer bootet via USB
> Image version: 
> http://cdimage.debian.org/cdimage/stretch_di_rc1/amd64/iso-cd/debian-stretch-DI-rc1-amd64-netinst.iso
> Date: 2017-01-18 09:45
> 
> Machine: SUPERMICRO X10SBA-L-O-P
> Processor: Intel Celeron J1900 (cpu family:6, model: 55, stepping:8)
> Memory: 4GB
> Partitions:
> 
> Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x51e39a8b
> 
> Device Boot  StartEndSectors   Size Id Type
> /dev/sda1  *  2048 1945382911 1945380864 927,6G 83 Linux
> /dev/sda2   1945384958 19535237118138754   3,9G  5 Extended
> /dev/sda5   1945384960 19535237118138752   3,9G 82 Linux swap / 
> Solaris
> 
> 
> 
> Output of lspci -knn (or lspci -nn):
> 
> 00:00.0 Host bridge [0600]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
> Serie s SoC Transaction Register [8086:0f00] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  SoC Transaction Register [15d9:0816]
> Kernel driver in use: iosf_mbi_pci
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor 
> Z36xx x/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  Graphics & Display [15d9:0816]
> Kernel driver in use: i915
> Kernel modules: i915
> 00:13.0 SATA controller [0106]: Intel Corporation Atom Processor E3800 Series 
> SA TA AHCI Controller [8086:0f23] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor E3800 Series SATA 
> AHC I Controller [15d9:0816]
> Kernel driver in use: ahci
> Kernel modules: ahci
> 00:1a.0 Encryption controller [1080]: Intel Corporation Atom Processor 
> Z36xxx/Z3 7xxx Series Trusted Execution Engine [8086:0f18] 
> (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  Trusted Execution Engine [15d9:0816]
> 00:1c.0 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
> Exp ress Root Port 1 [8086:0f48] (rev 0e)
> Kernel driver in use: pcieport
> Kernel modules: shpchp
> 00:1c.2 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
> Exp ress Root Port 3 [8086:0f4c] (rev 0e)
> Kernel driver in use: pcieport
> Kernel modules: shpchp
> 00:1c.3 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
> Exp ress Root Port 4 [8086:0f4e] (rev 0e)
> Kernel driver in use: pcieport
> Kernel modules: shpchp
> 00:1d.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
> Se ries USB EHCI [8086:0f34] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  USB EHCI [15d9:0816]
> Kernel driver in use: ehci-pci
> Kernel modules: ehci_pci
> 00:1f.0 ISA bridge [0601]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
> Series  Power Control Unit [8086:0f1c] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  Power Control Unit [15d9:0816]
> Kernel driver in use: lpc_ich
> Kernel modules: lpc_ich
> 00:1f.3 SMBus [0c05]: Intel Corporation Atom Processor E3800 Series SMBus 
> Contro ller [8086:0f12] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor E3800 Series SMBus 
> Co ntroller [15d9:0816]
> Kernel driver in use: i801_smbus
> Kernel modules: i2c_i801
> 02:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network 
> Conne ction [8086:1533] (rev 03)
> Subsystem: Super Micro Computer Inc I210 Gigabit Network Connection 
> [15d 9:1533]
> Kernel driver in use: igb
> Kernel modules: igb
> 03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network 
> Conne ction [8086:1533] (rev 03)
> Subsystem: Super Micro Computer Inc I210 Gigabit Network Connection 
> [15d 9:1533]
> Kernel driver in use: igb
> Kernel modules: igb
> 
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [E]
> Detect CD:  [ ]
> Load installer modules: [O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[E]
> 

Bug#851790: installation-reports: DNS not working

[Cyril Brulebois]

Steve McIntyre  (2017-01-19):
> On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote:
> >On 2017-01-19 01:53, Cyril Brulebois wrote:
> >
> >> It's been a while since I last looked at/understood mklibs stuff though,
> >> feel free to fix my suspicions/conclusions.
> >
> >The long term solution is to package all the libraries into udeb
> >packages. That way we can simply get rid of the mklibs pass.
> >
> >The workaround are to make sure the chroots are up-to-date (which should
> >be the case now on the build daemons). An other alternative would be to
> >avoid copying a library in mklibs if it is already present in the image.
> >That might break if some very strict dependencies are used, though
> >I guess the way the udebs are downloaded, they should always have the
> >same or a newer version than in the chroot.
> 
> Thanks for the explanation - it's appreciated!

Yeah, thanks for the confirmation.

> Is there anything we could do to fail the build if versions are out of
> sync, rather than let a broken build through?

Well, I think Aurélien mentioned it: ensure chroots are up-to-date.
Tweaking the buildscript might do the trick, I suppose. AFAIUI, the
build isn't broken every time there's a divergence in versions anyway;
you're sometimes (un)lucky.

Can't really devote time right now to investigating the “let's not copy
stuff over if it's already present” suggestion…


KiBi.


signature.asc
Description: Digital signature

Bug#851790: installation-reports: DNS not working

[Steve McIntyre]

On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote:
>On 2017-01-19 01:53, Cyril Brulebois wrote:
>
>> It's been a while since I last looked at/understood mklibs stuff though,
>> feel free to fix my suspicions/conclusions.
>
>The long term solution is to package all the libraries into udeb
>packages. That way we can simply get rid of the mklibs pass.
>
>The workaround are to make sure the chroots are up-to-date (which should
>be the case now on the build daemons). An other alternative would be to
>avoid copying a library in mklibs if it is already present in the image.
>That might break if some very strict dependencies are used, though
>I guess the way the udebs are downloaded, they should always have the
>same or a newer version than in the chroot.

Thanks for the explanation - it's appreciated!

Is there anything we could do to fail the build if versions are out of
sync, rather than let a broken build through?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.

Bug#851790: installation-reports: DNS not working

[Aurelien Jarno]

On 2017-01-19 01:53, Cyril Brulebois wrote:
> Cyril Brulebois  (2017-01-19):
> > Summing up things from IRC:
> >  - in an uptodate sid chroot (both development version and minimal one
> >with daily-build script): no DNS issues with the generated mini.iso
> >(amd64, tested within stable's kvm on amd64). My image was also
> >tested successfully by Steve, so not a setup issue.
> > 
> >  - I can reproduce the issue with dailies from 2017-01-18, and from
> >2017-01-19 (I picked it in advance during its build on barriere).
> > 
> >  - I can reproduce the issue in the above mentioned sid chroot if
> >I downgrade these packages to testing's version (-9 → -8):
> >  sudo apt-get install libc6:amd64=2.24-8 libc6-dev:amd64=2.24-8 
> > libc-dev-bin=2.24-8
> > 
> >  - The older set of libc* packages is installed in barriere's current
> >amd64 sid chroot, too.
> > 
> >  - Steve could only produce broken images when building locally, until
> >he upgraded his libc* packages as well.
> 
> And since Steve was wondering how we could release something for Stretch
> RC 1 with that… I've just confirmed that using -8 .deb with a -8 .udeb
> (reversioned as -9+hack so that its being dropped under localudebs makes
> it take precedence over sid's .udeb) leads to an image that's working
> fine. And AFAICT that's the combination we had at the time.
> 
> I suspect the implementation change through the following patch in -9:
> glibc-2.24/debian/patches/any/cvs-resolv-internal-qtype.diff

Indeed, I haven't done any test, but looking at the code, it shows that
the changes assume that libresolv.so.2 and libnss_dns.so.2 stay in sync.

> plus 283e7a294275a7da53258600deaaafbbec6b96c1 in debian-installer.git is
> what is triggering the issue? (Explaining why host's libc .deb have an
> impact on the built images.)

Indeed this has been done to avoid crashes when libc6-udeb is
re-installed at the beginning if the installer process, often causing
crashes in case of version mismatch (because the libnss* libraries were
in a different package).

Now libc6-udeb is unpacked while building the image, but given we still
have half a dozen of libraries without the corresponding udeb,
mklibs copy them on the image, as well as the dependencies, which
presumably includes libresolv.so.2.

> It's been a while since I last looked at/understood mklibs stuff though,
> feel free to fix my suspicions/conclusions.

The long term solution is to package all the libraries into udeb
packages. That way we can simply get rid of the mklibs pass.

The workaround are to make sure the chroots are up-to-date (which should
be the case now on the build daemons). An other alternative would be to
avoid copying a library in mklibs if it is already present in the image.
That might break if some very strict dependencies are used, though
I guess the way the udebs are downloaded, they should always have the
same or a newer version than in the chroot.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature