Bug#783982: D-i: preseed from floppy no longer works !

2015-05-02 Thread Alexey Eromenko 
I'd prefer not to introduce any new dependecies, for portability reasons.
Would like to have floppy support back.

Bug#783982: D-i: preseed from floppy no longer works !

2015-05-02 Thread Ben Hutchings 
On Sun, 2015-05-03 at 03:50 +0300, Alexey Eromenko wrote:
> No idea about GNU cpio.
> Is it compatible with BSD cpio ?
> I can't easily introduce new dependency for portable code. (host-side
> must be very portable code)
> It will require investigation.
> 
> Besides, this command didn't work for me. (preseed.cfg wasn't added)

It certainly works if you use GNU cpio (that's what we use to build the
shipped initramfs, after all).  FreeBSD cpio also supports the '-H newc'
option, but it looks like the NetBSD and OpenBSD equivalent is
'-H sv4cpio'.  I didn't test any of those, though.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.


signature.asc
Description: This is a digitally signed message part

Bug#783982: D-i: preseed from floppy no longer works !

2015-05-02 Thread Alexey Eromenko 
No idea about GNU cpio.
Is it compatible with BSD cpio ?
I can't easily introduce new dependency for portable code. (host-side
must be very portable code)
It will require investigation.

Besides, this command didn't work for me. (preseed.cfg wasn't added)

On Sun, May 3, 2015 at 1:36 AM, Ben Hutchings  wrote:
> On Sat, 2015-05-02 at 16:50 +0300, Alexey Eromenko wrote:
>> I ask to reverse decision about "floppy-modules", because while
>> physical floppies aren't used in years, this functionality is very
>> much used for virtualization.
>>
>> Like my vbox-unattened patch; Without floppy driver there will not be
>> an automated installer for Debian 8 VMs in VirtualBox.
>
> You should be able to add the preseed file to the initrd like this:
>
> echo preseed.cfg | cpio -o -H newc | gzip >> initrd.gz
>
> Does that not work for you?
>
> Ben.
>
> --
> Ben Hutchings
> Q.  Which is the greater problem in the world today, ignorance or apathy?
> A.  I don't know and I couldn't care less.



-- 
-Alexey Eromenko "Technologov"


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOJ6w=fjt3dbqcpag6z5ssntu27d51hqo69aa+kuzal8fs5...@mail.gmail.com

Bug#783323: Broken configuration for OpenBlocks AX3-4

2015-05-02 Thread Ben Hutchings 
On Sat, 2015-05-02 at 20:09 +0100, Ben Hutchings wrote:
> On Sat, 2015-05-02 at 16:35 +0100, Ian Campbell wrote:
[...]
> > Essentially if Boot-Device is set then Boot-*-Path should be relative to
> > that device, if Boot-Device is not set then Boot-*-Path are relative
> > to /.
> > 
> > I think /dev/sda1 is your actual /boot and using Boot-Device in that
> > case is wrong. If you remove it do things improve?
> 
> Yes, this database entry works for me:
> 
> Machine: Plat'Home OpenBlocks AX3-4
[...]

Just kidding, you probably shouldn't change the Machine line.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.


signature.asc
Description: This is a digitally signed message part

Bug#784081: Acknowledgement (debian-installer-8-netboot-amd64:expert netboot install hangs at step install_packages (tasksel):uninitialized value in vec at /usr/bin/debconf-apt-progress)

2015-05-02 Thread Hendrik Schaink 

Hello debian-installer team,

The full text of hang condition as displayed in the last 2 log lines at tty4:

Apr 29 19:38:25 in-target: Use of unitinialzed value in vec at 
/usr/bin/debconf-apt-progress line {274|275},  line 2. 

The only way to get past the hang condition was to kill the most recent 
perl process executing /usr/bin/debconf-apt-progress. At that point the 
installer displayed "Installation step failed" and allowed to continue 
by pressing the Continue button. I ended up skipping install step 
"Select and Install Software" to continue with installing grub2, then 
rebooted successfully. 

I took photos of the errors on the screen so I could report them. 
Please let me know if it would be helpful and I can e-mail those photos. 


Thank you,

Hendrik Schaink

On Sat, 02 May 2015 20:21:06 , Debian Bug Tracking System 
 wrote:


Thank you for filing a new Bug report with Debian. 


This is an automatically generated reply to let you know your message
has been received. 


Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course. 


As you requested using X-Debbugs-CC, your message was also forwarded to
hscha...@infovisi.com
(after having been given a Bug report number, if it did not have one). 


Your message has been sent to the package maintainer(s):
Debian Install System Team 

If you wish to submit further information on this problem, please
send it to 784...@bugs.debian.org. 


Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system. 


--
784081: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784081
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502165610.pli638askkg40...@webmail.shawhosting.ca

Bug#783982: D-i: preseed from floppy no longer works !

2015-05-02 Thread Ben Hutchings 
On Sat, 2015-05-02 at 16:50 +0300, Alexey Eromenko wrote:
> I ask to reverse decision about "floppy-modules", because while
> physical floppies aren't used in years, this functionality is very
> much used for virtualization.
> 
> Like my vbox-unattened patch; Without floppy driver there will not be
> an automated installer for Debian 8 VMs in VirtualBox.

You should be able to add the preseed file to the initrd like this:

echo preseed.cfg | cpio -o -H newc | gzip >> initrd.gz

Does that not work for you?

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.


signature.asc
Description: This is a digitally signed message part

Bug#784081: debian-installer-8-netboot-amd64: expert netboot install hangs at step install_packages (tasksel): uninitialized value in vec at /usr/bin/debconf-apt-progress

2015-05-02 Thread Hendrik Schaink 
Package: debian-installer-8-netboot-amd64
Version: 20150422
Severity: normal
Tags: d-i



-- System Information:
Debian Release: 8.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

debian-installer-8-netboot-amd64 depends on no packages.

debian-installer-8-netboot-amd64 recommends no packages.

Versions of packages debian-installer-8-netboot-amd64 suggests:
pn  tftpd-hpa  


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150502201648.1129.72116.report...@develop.infovisi.com

Bug#783323: Broken configuration for OpenBlocks AX3-4

2015-05-02 Thread Ben Hutchings 
On Sat, 2015-05-02 at 16:35 +0100, Ian Campbell wrote:
> (CCing Nobuhiro who contributed the flash-kernel db entry for this
> device)
> 
> On Sat, 2015-05-02 at 15:40 +0100, Ian Campbell wrote:
> > On Sun, 2015-04-26 at 00:39 +0100, Ben Hutchings wrote:
> > > On Sat, 25 Apr 2015 23:39:44 +0100 Ben Hutchings  
> > > wrote:
> > > > Secondly, if the installation uses LVM, /dev/sda1 is the /boot
> > > > partition, not the root partition.  After fixing the first problem,
> > > > flash-kernel fails like this:
> > > 
> > > Actually, this doesn't depend on LVM.  The installer always creates a
> > > separate /boot partition using the ext2 filesystem, and this makes sense
> > > as u-boot generally doesn't support ext4.  So I think that the /boot
> > > prefix should be removed from the paths for this entry.  (And maybe many
> > > other entries.)
> > 
> > I think you are likely correct.
> > 
> > I'm considering declaring that all such db fields are always relative
> > to /boot and having f-k decide if it needs to prepend /boot or not,
> > perhaps based on "stat -c %m /boot" or something similar.
> 
> Actually, thinking a bit harder...
> 
> Looking back at your original error:
> mv: cannot move '/tmp/flash-kernel.3ft8lyny/uImage' to 
> '/tmp/flash-kernel.V2iwAjyz//boot/uImage': No such file or directory
> 
> I think this is because the db entry includes a Boot-Device. This is
> supposed to be used for devices where the firmware boots from a
> partition which is not typically mounted (i.e. a special VFAT
> partition), hence things in /tmp before copying there.
> 
> For device which can boot from a sensible filesystem

AFAIK it can only boot from ext2 or VFAT filesystems, but they can be on
any partition (probably only MBR) on any drive (SATA or USB).

> then Boot-Device
> shouldn't be used and things will end up in /boot (separate or
> otherwise).

Right.

> Essentially if Boot-Device is set then Boot-*-Path should be relative to
> that device, if Boot-Device is not set then Boot-*-Path are relative
> to /.
> 
> I think /dev/sda1 is your actual /boot and using Boot-Device in that
> case is wrong. If you remove it do things improve?

Yes, this database entry works for me:

Machine: Plat'Home OpenBlocks AX3-4
Kernel-Flavors: armmp armmp-lpae
DTB-Id: armada-xp-openblocks-ax3-4.dtb
DTB-Append: yes
U-Boot-Kernel-Address: 0x200
U-Boot-Kernel-Entry-Point: 0x240
U-Boot-Initrd-Address: 0x0
Boot-Kernel-Path: /boot/uImage
Boot-Initrd-Path: /boot/uInitrd
Boot-DTB-Path: /boot/dtb
Required-Packages: u-boot-tools

> It seems that the code which handles the Boot-Device case is buggy in
> the face of a firmware partition which has some hierarchy to it.

If the boot images need to be in a specific subdirectory then it's not
so unreasonable to expect that the subdirectory already exists, but
still it might be helpful to add a 'mkdir -p "$(dirname "$path")"'.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.


signature.asc
Description: This is a digitally signed message part

Re: Help with the arm64 and ppc64el installation-guides needed

2015-05-02 Thread Michael Felt 
Just read the link re: PermitRoot --without-password

My comment - typical "developer" string - because many people are looking
for passwordless login for root, and from my UNIX background I would take
"--without-password" very literally. I suspect what is intended is
"--no-password-auth-permitted", meaning some other form of authentication
is accepted, e.g., PKI.

Because of the comment in sshd_config I was thinking it was something in
the PAM configuration I needed to look at. And, FYI - if you follow the
suggestion in the sshd_config (re PAM) no login for anyone (using passwords
at least) is permitted.

Thank you for the link - I shall copy my keys in (later) and report back.
And secondly, for the link - for the changes history! Excellent!

Michael

On Sat, May 2, 2015 at 6:19 PM, Michael Felt  wrote:

> Maybe - last time I tried - I mistyped the login - because login from
> console is working for both - thanks for the reply.
>
> re: root login on sshd - guess I need to read more carefully. I know about
> the cipher changes starting with OpenSSH 6.7, but had not yet stumbled on
> anything extra blocking root login.
>
> My apologies for a false statement! Must test again and again (so I will
> have to reload ubuntu, opensles and fedora to see which ones of those
> refuse root login at console. If both are blocked (with the newer openssh)
> may make some maintenance work difficult.
>
> Further - any interest in a different (in what way please) story on
> installing debian on PowerVM enabled systems?
>
> On Sat, May 2, 2015 at 2:16 PM, Ben Hutchings  wrote:
>
>> On Sat, 2015-05-02 at 11:15 +0200, Michael Felt wrote:
>> [...]
>>
>> > BTW: I notice a slight difference in how 'login as root' works between
>> > wheezy and jessie. On both systems I have enabled 'root login' for my
>> > initial tests. With wheezy I cannot login as root on the console, but
>> > can login using ssh. On Jessie this is the reverse. I assume this is
>> > deliberate.
>> [...]
>>
>> The ssh part: yes, and that's documented in the release notes:
>> <
>> https://www.debian.org/releases/jessie/powerpc/release-notes/ch-information.en.html#openssh
>> >.
>>
>> The console part: I don't think so; this is probably a bug in wheezy.
>> The last time I had that sort of problem, it was due to an omission from
>> the file /etc/securetty (list of devices that root may log in through).
>> But in wheezy that file does include hvc0.
>>
>> Ben.
>>
>> --
>> Ben Hutchings
>> Q.  Which is the greater problem in the world today, ignorance or apathy?
>> A.  I don't know and I couldn't care less.
>>
>
>

Re: Help with the arm64 and ppc64el installation-guides needed

2015-05-02 Thread Michael Felt 
Maybe - last time I tried - I mistyped the login - because login from
console is working for both - thanks for the reply.

re: root login on sshd - guess I need to read more carefully. I know about
the cipher changes starting with OpenSSH 6.7, but had not yet stumbled on
anything extra blocking root login.

My apologies for a false statement! Must test again and again (so I will
have to reload ubuntu, opensles and fedora to see which ones of those
refuse root login at console. If both are blocked (with the newer openssh)
may make some maintenance work difficult.

Further - any interest in a different (in what way please) story on
installing debian on PowerVM enabled systems?

On Sat, May 2, 2015 at 2:16 PM, Ben Hutchings  wrote:

> On Sat, 2015-05-02 at 11:15 +0200, Michael Felt wrote:
> [...]
>
> > BTW: I notice a slight difference in how 'login as root' works between
> > wheezy and jessie. On both systems I have enabled 'root login' for my
> > initial tests. With wheezy I cannot login as root on the console, but
> > can login using ssh. On Jessie this is the reverse. I assume this is
> > deliberate.
> [...]
>
> The ssh part: yes, and that's documented in the release notes:
> <
> https://www.debian.org/releases/jessie/powerpc/release-notes/ch-information.en.html#openssh
> >.
>
> The console part: I don't think so; this is probably a bug in wheezy.
> The last time I had that sort of problem, it was due to an omission from
> the file /etc/securetty (list of devices that root may log in through).
> But in wheezy that file does include hvc0.
>
> Ben.
>
> --
> Ben Hutchings
> Q.  Which is the greater problem in the world today, ignorance or apathy?
> A.  I don't know and I couldn't care less.
>

Bug#783323: Broken configuration for OpenBlocks AX3-4

2015-05-02 Thread Ian Campbell 
(CCing Nobuhiro who contributed the flash-kernel db entry for this
device)

On Sat, 2015-05-02 at 15:40 +0100, Ian Campbell wrote:
> On Sun, 2015-04-26 at 00:39 +0100, Ben Hutchings wrote:
> > On Sat, 25 Apr 2015 23:39:44 +0100 Ben Hutchings  
> > wrote:
> > > Secondly, if the installation uses LVM, /dev/sda1 is the /boot
> > > partition, not the root partition.  After fixing the first problem,
> > > flash-kernel fails like this:
> > 
> > Actually, this doesn't depend on LVM.  The installer always creates a
> > separate /boot partition using the ext2 filesystem, and this makes sense
> > as u-boot generally doesn't support ext4.  So I think that the /boot
> > prefix should be removed from the paths for this entry.  (And maybe many
> > other entries.)
> 
> I think you are likely correct.
> 
> I'm considering declaring that all such db fields are always relative
> to /boot and having f-k decide if it needs to prepend /boot or not,
> perhaps based on "stat -c %m /boot" or something similar.

Actually, thinking a bit harder...

Looking back at your original error:
mv: cannot move '/tmp/flash-kernel.3ft8lyny/uImage' to 
'/tmp/flash-kernel.V2iwAjyz//boot/uImage': No such file or directory

I think this is because the db entry includes a Boot-Device. This is
supposed to be used for devices where the firmware boots from a
partition which is not typically mounted (i.e. a special VFAT
partition), hence things in /tmp before copying there.

For device which can boot from a sensible filesystem then Boot-Device
shouldn't be used and things will end up in /boot (separate or
otherwise).

Essentially if Boot-Device is set then Boot-*-Path should be relative to
that device, if Boot-Device is not set then Boot-*-Path are relative
to /.

I think /dev/sda1 is your actual /boot and using Boot-Device in that
case is wrong. If you remove it do things improve?

It seems that the code which handles the Boot-Device case is buggy in
the face of a firmware partition which has some hierarchy to it.

Ian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1430580916.15640.174.ca...@debian.org

Processed: Re: Bug in installer is still present in Debian Jessie

2015-05-02 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> reassign 745381 apt, apt-setup
Bug #745381 [apt] Unable to retrieve packages from USB flash drive in console 
mode
Bug reassigned from package 'apt' to 'apt,apt-setup'.
No longer marked as found in versions apt/0.9.7.9+deb7u1.
Ignoring request to alter fixed versions of bug #745381 to the same values 
previously set
> # this may be rather an issue in apt-setup-udeb
> found 745381 apt-setup/1:0.97
Bug #745381 [apt,apt-setup] Unable to retrieve packages from USB flash drive in 
console mode
Marked as found in versions apt-setup/1:0.97.
> # reported still in Debian 8.0
> found 745381 apt/1.0.9.8
Bug #745381 [apt,apt-setup] Unable to retrieve packages from USB flash drive in 
console mode
Marked as found in versions apt/1.0.9.8.
> found 745381 apt/0.9.7.9+deb7u1
Bug #745381 [apt,apt-setup] Unable to retrieve packages from USB flash drive in 
console mode
Marked as found in versions apt/0.9.7.9+deb7u1.
> thanks
Stopping processing here.

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


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.143058026714358.transcr...@bugs.debian.org

Processed: Re: Bug#781882: frequent flash-kernel triggers on Wheezy->Jessie upgrade

2015-05-02 Thread Debian Bug Tracking System 
Processing control commands:

> reassign -1 flash-kernel flash-kernel/3.34
Bug #781882 [upgrade-reports] frequent flash-kernel triggers on Wheezy->Jessie 
upgrade
Bug reassigned from package 'upgrade-reports' to 'flash-kernel'.
No longer marked as found in versions 3.34.
Ignoring request to alter fixed versions of bug #781882 to the same values 
previously set
Bug #781882 [flash-kernel] frequent flash-kernel triggers on Wheezy->Jessie 
upgrade
Marked as found in versions flash-kernel/3.34.

-- 
781882: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781882
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b781882.14305794599871.transcr...@bugs.debian.org

Bug#783073: bootscripts: Support using fdtfile variable passed from u-boot

2015-05-02 Thread Ian Campbell 
On Tue, 2015-04-21 at 08:54 -0700, Vagrant Cascadian wrote:
> Package: flash-kernel
> Version: 3.35
> Severity: wishlist
> Tags: patch

Hi Vagrant,

> The following patch prefers the use of the dtb file identified by the
> u-boot variable ${fdtfile}, which makes it easier to support installs
> where a single u-boot image can support multiple boards, but need to
> load different fdt files at boot.
> 
> It essentially makes a second copy of the .dtb file in
> /boot/dtbs-${kver}/${fdtfile}. Ideally, it would copy all of the .dtb
> files (to support the widest number of boards), but that should be
> made conditional for resource-constrained systems, so I started off
> with simply making a second copy.

There were moves at one point to consolidate/standardise this across
distros:
https://lists.linaro.org/pipermail/cross-distro/2014-May/000676.html

From
https://lists.linaro.org/pipermail/cross-distro/2014-June/000727.html it
seems that the preferred path was /boot/dtbs/$(uname -r) so I suppose we
ought to follow that here.

> I don't expect to see this in jessie, but hopefully something like this
> could be considered for jessie+1.

Absolutely.
> diff --git a/functions b/functions
> index a7ff6de..fc2c21b 100644
> --- a/functions
> +++ b/functions
> @@ -420,13 +420,18 @@ handle_dtb() {
>  
>   local dtb="/usr/lib/linux-image-$kvers/$dtb_id"
>   if [ "x$FK_KERNEL_HOOK_SCRIPT" = "xpostrm.d" ] ; then
> - rm -f "/boot/dtb-$kvers"
> + rm -f "/boot/dtb-$kvers" "/boot/dtbs-$kvers"

The second one is a directory, so I think this won't work.

I think best is to rm the expected file and then "rmdir
--ignore-fail-on-non-empty" the dir.

>   else
>   if [ -e $dtb ]; then
>   echo "Installing $dtb_id into /boot/dtb-$kvers" >&2
>   cp "$dtb" "/boot/dtb-$kvers.new"
>   backup_and_install "/boot/dtb-$kvers.new" 
> "/boot/dtb-$kvers"
>   ln -nfs "dtb-$kvers" "/boot/dtb"
> + echo "Installing $dtb_id into 
> /boot/dtbs-$kvers/$dtb_id" >&2
> + mkdir -p /boot/dtbs-$kvers/
> + cp "$dtb" "/boot/dtbs-$kvers/$dtb_id.new"
> + backup_and_install "/boot/dtbs-$kvers/$dtb_id.new" 
> "/boot/dtbs-$kvers/"
> + ln -nfs "dtbs-$kvers" "/boot/dtbs"

Do we really need the symlink too?

>   else
>   echo "$dtb not found" >&2
>   fi
> 
> 
> live well,
>   vagrant


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1430577997.15640.153.ca...@debian.org

Bug#783323: Broken configuration for OpenBlocks AX3-4

2015-05-02 Thread Ian Campbell 
On Sun, 2015-04-26 at 00:39 +0100, Ben Hutchings wrote:
> On Sat, 25 Apr 2015 23:39:44 +0100 Ben Hutchings  wrote:
> > Secondly, if the installation uses LVM, /dev/sda1 is the /boot
> > partition, not the root partition.  After fixing the first problem,
> > flash-kernel fails like this:
> 
> Actually, this doesn't depend on LVM.  The installer always creates a
> separate /boot partition using the ext2 filesystem, and this makes sense
> as u-boot generally doesn't support ext4.  So I think that the /boot
> prefix should be removed from the paths for this entry.  (And maybe many
> other entries.)

I think you are likely correct.

I'm considering declaring that all such db fields are always relative
to /boot and having f-k decide if it needs to prepend /boot or not,
perhaps based on "stat -c %m /boot" or something similar.

> (I know u-boot has optional support for ext4 now, but there's no sign of
> it in this version.  For reference, that's:
> U-Boot 2011.12 (Aug 26 2013 - 13:08:34)
> Plat'Home version: 2.0.7 (Marvell version: 2012_Q4.0p17)
> )

Typical ancient u-boot, oh well!

Ian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1430577628.15640.149.ca...@debian.org

Bug#759657: console-setup w/ systemd forgets font setting

2015-05-02 Thread Anton Zinoviev 
On Fri, Aug 29, 2014 at 09:53:20AM +0200, Karsten Hilbert wrote:
> 
> When systemd was introduced console-setup started to "forget" setting the

I don't known how exactly systemd works but it seems Bug#783976 may be 
related to this:

> Package: console-cyrillic
> Severity: normal
>
> Dear Maintainer,
> When booting under systemd, the /etc/init.d/console-cyrillic init script
> launches /usr/bin/cyr, which expects linux console as its terminal.
>
> However, LSB compatibility for systemd captures the init script's
> STDOUT and STDERR, so cyr fails with the error message:
> cyr: This command may be executed only in Linux console.
>
> Sorry for not having a patch ready. There can be several approaches, from
> setting 'Conflicts: systemd-sysv' to providing a systemd unit file which
> sets the TTY as needed.

I like the solution 'Conflicts: systemd-sysv'. :)

Anton Zinoviev

-- 
Ако не отговарям на писмата ви: http://6lyokavitza.org/mail


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150502130536.ga3...@logic.fmi.uni-sofia.bg

Bug#783982: D-i: preseed from floppy no longer works !

2015-05-02 Thread Alexey Eromenko 
I ask to reverse decision about "floppy-modules", because while
physical floppies aren't used in years, this functionality is very
much used for virtualization.

Like my vbox-unattened patch; Without floppy driver there will not be
an automated installer for Debian 8 VMs in VirtualBox.

-- 
-Alexey Eromenko "Technologov"


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOJ6w=GLDET9N-xubU23f0EQ=l4+nvoaigjhpazembsopfk...@mail.gmail.com

Bug#783982: D-i: preseed from floppy no longer works !

2015-05-02 Thread Ben Hutchings 
On Sat, 2015-05-02 at 16:15 +0300, Alexey Eromenko wrote:
> I have created /dev/fd0 via.
> # mknod /dev/fd0 b 2 0
> # mkdir floppy
> 
> Results: mknod never reported any problem, But (!)
> 
> # mount /dev/fd0 floppy
> Works in Debian 7 (d-i), and fails in Debain 8 (d-i) with message:
> mount: mounting /dev/fd0 on floppy failed: No such device or address

Right, this was an intentional change.  From the kernel changelog,
regarding modules to be included in the installer:

  * udeb: Remove obsolete and unsupported drivers and filesystems
- Remove ppa from scsi-modules
- Remove floppy-modules, irda-modules, parport-modules, plip-modules,
  qnx4-modules, reiserfs-modules, ufs-modules

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.


signature.asc
Description: This is a digitally signed message part

Bug#783982: D-i: preseed from floppy no longer works !

2015-05-02 Thread Alexey Eromenko 
I have extracted initrd from all 3 medias: Debian(6,7,8)-amd64-DVD,

alexey@deb6-xrig:~/debian6-auto/bootiso/install.amd/tmp2$ find . |
grep ko | grep floppy
./lib/modules/2.6.32-5-amd64/kernel/drivers/block/floppy.ko

alexey@deb6-xrig:~/debian7-auto/bootiso/install.amd/tmp2$ find . |
grep ko | grep floppy
./lib/modules/3.2.0-4-amd64/kernel/drivers/block/floppy.ko

alexey@deb6-xrig:~/debian8-auto/bootiso/install.amd/tmp2$ find . |
grep ko | grep floppy
alexey@deb6-xrig:~/debian8-auto/bootiso/install.amd/tmp2$

Basically we have a proof, that Debian 8 d-i kernel lacks
"drivers/block/floppy.ko" module. Which causes the problem.

Now what ? Who is responsible for d-i kernels ? Should I open a separate bug ?

Thanks for help,
-- 
-Alexey Eromenko "Technologov"


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOJ6w=flxhockvaicdw6z4spx5srcr9x0aqgnzutjwhkfwb...@mail.gmail.com

Bug#784045: debian-installer-launcher needs to depend on sudo

2015-05-02 Thread Daniel Baumann 
Package: debian-installer-launcher
Severity: serious

debian-installer-launcher uses su-to-root which is in menu and doesn't
automatically pull in sudo. debian-installer-launcher however doesn't
work without sudo.

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5544d001.8050...@progress-technologies.net

Bug#783982: D-i: preseed from floppy no longer works !

2015-05-02 Thread Alexey Eromenko 
I have created /dev/fd0 via.
# mknod /dev/fd0 b 2 0
# mkdir floppy

Results: mknod never reported any problem, But (!)

# mount /dev/fd0 floppy
Works in Debian 7 (d-i), and fails in Debain 8 (d-i) with message:
mount: mounting /dev/fd0 on floppy failed: No such device or address

-- 
-Alexey Eromenko "Technologov"


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOJ6w=hz3kmbebf-z37m9ontnbzdp8o5n56sg67lyesri67...@mail.gmail.com

Bug#783982: D-i: preseed from floppy no longer works !

2015-05-02 Thread Milan Kupcevic 
On 05/01/2015 06:09 PM, Alexey Eromenko wrote:

[...]

> 
> Debian 8 (mini-)kernel (inside amd64-DVD) does NOT see /dev/fd0 ! 
> (part of debian-installer); This works just fine with Debian 6 and 7
> ! Post-install Debian 8 kernel _does_ see /dev/fd0, can loop-mount
> and can read files from it. (after installing from Debian 8
> amd64-DVD), so no problem here.
> 
> The natural question: Are those kernels different ? (I always
> assumed it is the *same* kernel) It seems the mini-kernel does not
> provide me with "/proc/config.gz", so I have no clue what's included
> and what's excluded. How can I check ?
> 

The kernel is the same but the number of modules included in d-i
initrd.gz is reduced to bare minimum needed for d-i to boot up. The list
of included modules is different on cdrom d-i image, netboot d-i image,
and hd-media d-i image.

One way to check it out would be to unpack the d-i image initrd.gz and
look what is in there. The "/proc/config.gz" would not help as it would
provide info about what is compiled, but not what is included in d-i.

The fact that floppy works in final installation likely means the module
is in fact compiled but not included in d-i image.

Therefore, the way to go would be to figure out which module is needed
to provide access to floppy on your platform and then work with kernel
team on inclusion of the module in in the d-i initrd.

Milan



signature.asc
Description: OpenPGP digital signature

Re: Help with the arm64 and ppc64el installation-guides needed

2015-05-02 Thread Ben Hutchings 
On Sat, 2015-05-02 at 11:15 +0200, Michael Felt wrote:
[...]

> BTW: I notice a slight difference in how 'login as root' works between
> wheezy and jessie. On both systems I have enabled 'root login' for my
> initial tests. With wheezy I cannot login as root on the console, but
> can login using ssh. On Jessie this is the reverse. I assume this is
> deliberate.
[...]

The ssh part: yes, and that's documented in the release notes:
.

The console part: I don't think so; this is probably a bug in wheezy.
The last time I had that sort of problem, it was due to an omission from
the file /etc/securetty (list of devices that root may log in through).
But in wheezy that file does include hvc0.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.


signature.asc
Description: This is a digitally signed message part

Re: Help with the arm64 and ppc64el installation-guides needed

2015-05-02 Thread Michael Felt 
By the way - I just looked at your installation instructions and I did not
find anything about how to install in POWER Server environment, i.e., as a
virtual machine (aka LPAR) on IBM POWER5 and later.
The ppc64le using KVM will obviously be different, but people using powerpc
(historically 32-bit - is that correct, and why I cannot  SMOKE perl with
-Duse64bitall ?).

Anyway - I have an installation 'story' I wrote up quite a while ago.
http://www.rootvg.net/content/view/560/88/ I just reused this procedure to
install Jessie and it still works fine. I like the command-line install
very much. One of my reasons that debian is my personal favorite for Linux
on Power.

BTW: I notice a slight difference in how 'login as root' works between
wheezy and jessie. On both systems I have enabled 'root login' for my
initial tests. With wheezy I cannot login as root on the console, but can
login using ssh. On Jessie this is the reverse. I assume this is
deliberate. (I'll open a new thread to ask how to manage this, because
sshd_config - which I know - seems to permit RootLogin (--without-password)
but I have not managed to get it to work. Normally I do not want this, but
for testing - logging in as root is how I start learning many things (i.e.,
I skip installing sudo and sudo su -).

So, the question for here - regarding documentation - is there a CHANGES
document I have missed that summarizes and/or details the changes
(intended) between wheezy and jessie?

Michael

On Mon, Apr 13, 2015 at 9:46 PM, Holger Wansing 
wrote:

> Hi,
>
> "Lennart Sorensen"  wrote:
> > On Mon, Apr 13, 2015 at 09:37:42PM +0200, Holger Wansing wrote:
> > > Hi,
> > >
> > > Samuel Thibault  wrote:
> > > > Holger Wansing, le Sat 11 Apr 2015 17:13:06 +0200, a écrit :
> > > > > +arch_porturl="ppc64el"
> > > > > +arch_listname="ppc64el"
> > > >
> > > > Please take care when updating these to be sure to understand
> > > > what they mean. http://www.debian.org/ports/ppc64el and
> > > > http://lists.debian.org/debian-ppc64el don't exist.
> > >
> > > I knew this!
> > > But there needs to be created a site under
> > > http://www.debian.org/ports/ for ppc64el, when ppc64el gets a release
> arch.
> > > The only page for ppc64el on the ports page ATM is on the debian wiki.
> > > That will have to be changed.
> > > Otherwise that above entity in our d-i manual will fail to work, no
> > > matter which arch name you choose.
> >
> > I would think that just like armhf uses the debian-arm list, ppc64el
> > will continue to use the debian-powerpc list.
>
> Yeah, I just saw that Samuel left the above entities at "powerpc".
> That does of course work :-)
>
>
> Holger
>
> --
> 
> Created with Sylpheed 3.2.0 under
> D E B I A N   L I N U X   7 . 0   W H E E Z Y !
>
> Registered Linux User #311290 - https://linuxcounter.net/
> 
>
>
> --
> To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/20150413214642.d550d8d8f90c341da72e7...@wansing-online.de
>
>

Re: New d-i contributor

2015-05-02 Thread Cyril Brulebois 
Hi,

Christian PERRIER  (2015-05-02):
> Quoting Mathieu Trudel-Lapierre (mathieu...@gmail.com):
> > Hi everyone,
> > 
> > I'm Mathieu, from Montreal. I've just subscribed to debian-boot@,
> > but I've already been idling in #debian-boot for a while, I was one
> > of the drivers of the Montreal bid for Debconf16, and I've been
> > taking on d-i work for Ubuntu. I've already been bugging cjwatson
> > every once in a while to review changes or merge git branches for
> > things like grub, but I realise I should reach out more :)
> 
> Yes! Oui ! ;-)

\o/ Welcome on board!

> > What would be the preferred method for this? My initial focus will
> > be patches for multipath support that don't appear to have
> > associated BTS bugs. Is it fine to push to git for code to be
> > reviewed (in my own people/cyphermox-guest/xyz branch), or should I
> > file bugs and attach patches?
> 
> Well, let's get Kibi's stance on this, but I think the best should be
> that you directly commit things in git, just like Colin has been doing
> for years.
> 
> If you do so, it's likely that the "bubulle manual autobuilder" will
> catch your changes and upload them quite soon so that they get tested
> (well, assuming people really testing daily images and unstable
> installs)

If you're convinced your changes are OK and can go to master, push them
there. If you want them to be reviewed/commented upon/refined, feel free
to push them into a branch with a descriptive name, and tell us about
it. :)


Mraw,
KiBi.


signature.asc
Description: Digital signature