Bug#907805: syslinux.efi uses the TFTP server IP for the HTTP domain

[Marco d'Itri]

On Sep 03, Lukas Schwaighofer  wrote:

> This still seems to be the case, since the pxe_dns function in efi/pxe.c
> in the current HEAD
> (http://repo.or.cz/syslinux.git/blob/HEAD:/efi/pxe.c, lines 38-49) will
> `return 0` in all cases.
Yes, it is even worse than this: even if I pass to syslinux in option 67 
a numeric URL like http://10.0.0.1/file it will request that URL from 
the "10.0.0.1" virtual host of the TFTP server IP.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#907814: Absolute PXE paths do not work

[Marco d'Itri]

Package: pxelinux
Version: 3:6.04~git20171011.af7e95c3+dfsg1-4
Severity: normal

With this configuration:

dhcp-option=option:bootfile-name,/pxelinux/lpxelinux.0
dhcp-option-force=209,/syslinux.cfg

I expected that pxelinux would try to download /syslinux.cfg and not
/pxelinux//syslinux.cfg:

dnsmasq-tftp: sent /tmp/boot/pxelinux/lpxelinux.0 to 10.5.0.5
dnsmasq-tftp: sent /tmp/boot/pxelinux/ldlinux.c32 to 10.5.0.5
dnsmasq-tftp: file /tmp/boot/pxelinux//syslinux.cfg not found
dnsmasq-tftp: file /tmp/boot/pxelinux/pxelinux.cfg/01-52-54-00-12-34-56 not 
found
...
dnsmasq-tftp: file /tmp/boot/pxelinux/pxelinux.cfg/default not found

as apparently documented in 
https://www.syslinux.org/wiki/index.php?title=Config#Working_directory:

  All (paths to) file names inside the configuration file are relative to 
  the Working Directory, unless preceded with a slash.

Even if the value of option 209 is not "inside a configuration file" 
I think it should work the same way for consistency, and the "//" is an 
hint that absolute paths processing is missing here.

My goal here is to be able to have a directory with all the common 
pxelinux binaries not mixed with the configuration files.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#907805: syslinux.efi uses the TFTP server IP for the HTTP domain

[Marco d'Itri]

Package: syslinux-efi
Version: 3:6.04~git20171011.af7e95c3+dfsg1-4
Severity: important

When providing to syslinux.efi an http URL in option 67:

dhcp-option=option:bootfile-name,http://pxe.example.net/EFI/SYSLINUX/syslinux.efi

then it will try to download the modules like ldlinux.e64, the 
configuration file and the payload by sending an HTTP request to the 
TFTP server address (with pxe.example.net as virtual host) instead of 
resolving pxe.example.net and using that IP as expected.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Debian images on Microsoft Azure cloud

[Marco d'Itri]

On Nov 12, Thomas Goirand  wrote:

> >> changes, isn't a point of argumentation (see my previous mail). All of
> >> the packages must be taken from stable, unchanged, and if some are taken
> >> from backports, this must be explicit, and the image shouldn't be called
> >> "stable Debian". Official, yes, but not stable (maybe stable + some
> >> backports would be ok...).
> > While this is techically true, I do not think that it would also be 
> > helpful in any way.
> Helpful for who?
Like, our users who are looking for Debian stable images.

> I don't think it's helpful for the project to let $cloud-provider to do
> as his pleased with our Debian trademark, and call whatever as "Debian
> stable", just because it makes sense for the marketing department. We
We build the images and we do call them "Debian stable" because it makes 
sense for our users.

> have long established rules, I don't see why they wouldn't apply for the
> "official Debian" cloud images.
Because it would create a better experience for the affected users with 
no downsides?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Debian images on Microsoft Azure cloud

[Marco d'Itri]

On Nov 12, Thomas Goirand  wrote:

> changes, isn't a point of argumentation (see my previous mail). All of
> the packages must be taken from stable, unchanged, and if some are taken
> from backports, this must be explicit, and the image shouldn't be called
> "stable Debian". Official, yes, but not stable (maybe stable + some
> backports would be ok...).
While this is techically true, I do not think that it would also be 
helpful in any way.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Debian images on Microsoft Azure cloud

[Marco d'Itri]

On Nov 10, Richard Hartmann  wrote:

> with my trademark hat on: We asked waldi & zobel to bounce this
> request off of debian-cloud and debian-cd prior to granting the right
> to use the Debian name. We are looking for rough consensus as defined
> in RFC7282 that these images are close enough to Debian proper and are
> a good faith effort to bring Debian to more platforms and users.
FWIW, the development process used looks fine to me and I agree that 
the images should be advertised as official Debian images.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: More tasks option in Tasksel: what tasks do you want there? (reloaded)

[Marco d'Itri]

On Sep 09, Paul Wise p...@debian.org wrote:

 Isn't tasksel for people with no expectations? People who know
 something about the technology they are looking for will install the
 relevant packages instead of following tasksel recommendations.
Tasksel is not about recommendations: its purpose is to easily install 
a complex set of related packages.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop

[Marco d'Itri]

On Aug 08, Joey Hess jo...@debian.org wrote:

 I recently spent some time installing community computer labs in rural
 Brazil. Internet bandwidth was nearly nonexistant[1], so if you were
I am sure that we could have a great competition for finding potential 
users with even crappier connectivity and even more obsolete computers, 
and somebody would improve the record every time!

 If the xfce iso didn't exist, people in these situtations would
 not be able to install a usable Debian system.
I see a solution that would satisfy everybody: whoever is interested in
supporting this kind of situations could build CD images appropriate for 
them, and everybody else who does not live in the worst connected parts 
of the third world can continue using a modern desktop as usual.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Wheezy release: CDs are not big enough any more...

[Marco d'Itri]

On May 14, Jonas Smedegaard d...@jones.dk wrote:

 It is my impression from my visits in the Fall (although I do not have 
 any hard data to support it) that in India and Indonesia network access 
 is generally so slow that even if computers have DVD drives the common 
 media downloaded and used is CD.
This does not look like a great argument: when your internet access is 
really slow then you either download one image and share it between user 
(and then it does not matter if it is a CD or DVD, since the incremental 
cost per user is negligible), or you just download the netinstall image 
to minimize the number of bytes you need to download from the network to 
what you strictly need (yes, I did a few modem netinstalls...).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Wheezy release: CDs are not big enough any more...

[Marco d'Itri]

On May 14, Neil Williams codeh...@debian.org wrote:

 I'd support XFCE4 as the default Graphical Desktop Environment and
 possibly putting GNOME (and KDE) as alternative options.
What is the point of providing a default which is not what people 
usually want?
Just document that a normal desktop install will require two CDs.

Does anybody actually know that people routinely try to install desktop 
systems with only a CD and no networking, and why?
What is the use case for this? Cheap DVD readers have been around for 
over 10 years now.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

new mirror

[Marco d'Itri]

Server name is ftp3.linux.it AKA ftp.it.debian.org, managed by the
Italian Linux Society, plenty of bandwidth. Methods:
rsync ftp3.linux.it::debian-cd
ftp://ftp3.linux.it/pub/cd-images/
http://ftp3.linux.it/cd-images/

i386 only.

-- 
ciao,
Marco



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]