Re: [Debian-User] Re: Display image after resume

[Jim Popovitch]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2018-06-04 at 11:07 +1200, Ben Caradoc-Davies wrote:
> On 04/06/18 10:03, Jim Popovitch wrote:
> > What produces the desktop image that is displayed immediately after
> > resuming from hibernation?
> > When resuming, I see the following in order:
> >    1. the boot screen
> >    2. a blank screen
> >    3. the actual desktop (live or a snapshot of it)
> >    4. the lockscreen password prompt
> > What I would like to do is prevent the actual desktop, or the
> > screenshot of it, from appearing after the system boots from
> > hibernation.
> > -Jim P.
> 
> - What is your desktop?

Stretch Cinnamon

> - Are you using systemd?

Yes, but that is not an admission of preferring systemd. ;-)

> - How do you initiate hibernation? Via the desktop or via a keyboard
> or chassis button?

By closing the lid, it's a laptop (asus zenbook)


> - Which screen locker do you use? (e.g. light-locker or
> xscreensaver?)

cinnamon-screensaver

> This looks like a race condition in which system is hibernated
> before your screen is locked. I saw this for suspend when I let
> systemd manage my power button. My solution was to
> edit/etc/systemd/logind.conf to set HandlePowerKey=ignore and to let
> Xfce handle locking and suspend and Xfce Power Manager / Security /
> "Lock screen when system is going for sleep"). I use xscreensaver.

I think you're on to something.  When I CTRL+ATL+L the system, and then
close the lid, the post-hibernation resume works correctly (no screen
leakage).  Unfortunately changing the systemd login settings didn't
seem to have any effect.  I'm comfortable not using systemd on servers,
is it just as straight forward without it on desktops/laptops?

tia,

- -Jim P.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAlsUwmkACgkQJxVetMRa
JwXDlBAAst96C+2lmfL5DVcpAz9VHfiIdMZ0N1/yHcdEIBWsO6xSzjO6It+OWtjW
aDDxOGD94qhtu8gc/nGDRG+qk+cUWg9ENldsSmvkGVMdyAtPzg7is7S38wdbi8T+
rmz+wKc73nkgnLDeK57UgzciBuLcf+mqAvQA/6YIBmBVL9Ujk7peE+aQnH29JaWw
93DxdsEenV3p1DNKkyubOVoDSeanEtCpIndzGjmXME8kA8T0F2KC0z6eZBneyUX4
ocfkgUwrE7VeW6L9OlZfKhElpZkHradYZpZgXXhOOXk0HCJFfkW4KxPy6tz+9f4+
bYvkPqHG98XLfi82vXhvgtn6kDAAP9tykHo4jpaEl/OpitF6M0zsoTqH2L2DisB5
4Q9zg457ipauggnKm6h+ZTRchgpzZ4SZYbClBN4HnytVwG773L9r34LWr5kUROBX
VyF767pxR4b/jt+FKQRkgNj8uF3aP2b4T3qBxSJhGKb9x0aMPa2+YEyh51Hkem1f
1+QFbmDMzM4KybluRQu+QFBKe9vkjYZ0YiZinXL9PtBi9FlRGt3u11Bhlg5ZsSa9
vIS8plUunMXvHpQM7AAqBW9rk25XwSOqEISf/cEJqLqivcDgsjzc2eEHCIycPtVe
1+/vaDieNhA4G4PAikJUHrQ5XAED4gAvEiJSKN0K9HIDL/n2ifo=
=Qmxq
-END PGP SIGNATURE-

Latest buster upgrade gets stuck

[Gary Dale]

I'm running buster on an AMD64 system. I do an apt full-upgrade each 
night but tonight it's getting stuck. It seems to be building the 
initramfs image but having trouble with memtest86+. These are the last 6 
lines that it displays then stops. The terminal window isn't frozen - it 
responds to  for example by scrolling up.


Found initrd image: /boot/initrd.img-4.16.0-1-amd64
Found linux image: /boot/vmlinuz-4.15.0-3-amd64
Found initrd image: /boot/initrd.img-4.15.0-3-amd64
Found memtest86 image: /boot/memtest86.bin
Found memtest86+ image: /boot/memtest86+.bin
Found memtest86+ multiboot image: /boot/memtest86+_multiboot.bin

It originally got stuck on the apt full-upgrade. After waiting 15 or 20 
minutes, I killed the process and ran dpkg --configure -a but got the 
same results.


Any ideas?

Re: Repositorios de versiones viejas

[eduardo gil]

La versión de Debian 5.0 "Lenny" fue dada de alta el 14 de febrero de 2009 y ha 
tenido soporte hasta febrero 2012
Las versiones "estables" SUELEN tener soporte por 4 años "masomeno"
Cuado se deja de dar soporte a una versión SE SUELEN dar de baja los 
repositorios oficiales.
Supongo que habrá alguien que tenga un repo con versiones viejas pero... vaya a 
saber si existe y quién es.
Más ayuda... hmmm... no se me ocurre que decirte más.   


El lun 4-jun-18, Fabián Bonetti  escribió:

 Asunto: Repositorios de versiones viejas
 Para: "Debian" 
 Fecha: lunes, 4 de junio de 2018, 0:36
 
 
 Hola, tuve la necesidad de usar un cd de debian
 5...
 Y cuando estaba instalando... me decia que los
 repos no estaban.
 Cada cuantas versiones dan de baja los
 repositorios?.
 Hay algun servidor que los mantenga a todos los
 repos de debian?...me refieros a todas las
 versiones?
 
 
 ---Friendica
 >
 https://friendica.mamalibre.com.ar

Repositorios de versiones viejas

[Fabián Bonetti]

Hola, tuve la necesidad de usar un cd de debian 5...
Y cuando estaba instalando... me decia que los repos no estaban.
Cada cuantas versiones dan de baja los repositorios?.
Hay algun servidor que los mantenga a todos los repos de debian?...me refieros 
a todas las versiones?

---Friendica > https://friendica.mamalibre.com.ar

Re: Update on my update problem with gnome system.

[Kenneth Parker]

On Fri, May 25, 2018 at 10:02 PM, Kenneth Parker  wrote:

>
>
>>
>> >dist-upgrade
>> >dist-upgrade in addition to performing the function of
>> upgrade, also intelligently
>> >handles changing dependencies with new versions of packages;
>> apt-get has a "smart"
>> >conflict resolution system, and it will attempt to upgrade
>> the most important packages
>> >at the expense of less important ones if necessary. The
>> dist-upgrade command may
>> >therefore remove some packages. The /etc/apt/sources.list
>> file contains a list of
>> >locations from which to retrieve desired package files. See
>> also apt_preferences(5)
>> >for a mechanism for overriding the general settings for
>> individual packages.
>>
>> Warning:  Ubuntu ("close enough" to Debian to confuse me, multiple years)
> regularly requires dist-upgrade to do their frequent Kernel Upgrades,
> because they change Version Numbers on, among other things, the vmlinuz
> file.  So, when I do "apt-get upgrade" on the remaining Ubuntu Laptop, I
> regularly see things like,
>
> 

Wow!  I said "bad things" about Ubuntu regarding this topic but, just
today, experienced the same kind of thing, with Debian Stretch, regarding
the vlc "uber Package".  Seems it's replacing libvlccore8 with libvlccore9,
along with several other replacements!  So Debian also uses this technique
(dist-upgrade) for, other than "Upgrading the Distribution".

Sorry about that, Ubuntu.  :-)

Kenneth Parker

Re: Display image after resume

[Ben Caradoc-Davies]

On 04/06/18 10:03, Jim Popovitch wrote:

What produces the desktop image that is displayed immediately after
resuming from hibernation?
When resuming, I see the following in order:
   1. the boot screen
   2. a blank screen
   3. the actual desktop (live or a snapshot of it)
   4. the lockscreen password prompt
What I would like to do is prevent the actual desktop, or the
screenshot of it, from appearing after the system boots from
hibernation.
-Jim P.


- What is your desktop?
- Are you using systemd?
- How do you initiate hibernation? Via the desktop or via a keyboard or 
chassis button?

- Which screen locker do you use? (e.g. light-locker or xscreensaver?)

This looks like a race condition in which system is hibernated before 
your screen is locked. I saw this for suspend when I let systemd manage 
my power button. My solution was to edit/etc/systemd/logind.conf to set 
HandlePowerKey=ignore and to let Xfce handle locking and suspend and 
Xfce Power Manager / Security / "Lock screen when system is going for 
sleep"). I use xscreensaver.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Display image after resume

[Jim Popovitch]

What produces the desktop image that is displayed immediately after
resuming from hibernation?  

When resuming, I see the following in order:

  1. the boot screen
  2. a blank screen
  3. the actual desktop (live or a snapshot of it)
  4. the lockscreen password prompt 

What I would like to do is prevent the actual desktop, or the
screenshot of it, from appearing after the system boots from
hibernation.

-Jim P.

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

Re: KPatience cards too small

[Kent West]

On Sat, Jun 2, 2018 at 10:14 AM, arne  wrote:

> Hi,
>
> Looks like a bug in Kpat, the cards are way too small:
> Screenshot:
>
> https://i.paste.pics/652e13761f68299de40c01f409392284.png
>
> To find the cards: top center
>
> Debian Stretch amd64 up-to-date
> 4k monitor
> Nvidia GeForce GTX 1050 videocard
>
> How to solve this?
>
> Thanks!
>
>

Have you tried a different user?


-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com

Re: What's the difference between the dialout and tty groups?

[Cindy-Sue Causey]

On 6/3/18, Martin McCormick  wrote:
>   I added myself to both the dialout and tty groups on a
> stretch installation in order to use the serial ports from the
> user level.  It works fine.  Then I looked at a debian jessie
> installation and found that I had only added myself to dialout
> and it still works fine.
>
>   What is group tty actually for?
>
> This is more of an idle curiosity question than it is one of
> something's broken and I need help.
>
>   I am a retired systems engineer who setup unix systems
> for coworkers to use so I know you can sometimes have too much
> power at the user level and accidentally make it easier to make a
> mess of things.


Hi, Martin.. I found these descriptions on the Debian Wiki
SystemGroups page [0]:

tty: TTY devices are owned by this group. This is used by write and
wall to enable them to write to other people's TTYs, but it is not
intended to be used directly.

dialout: Full and direct access to serial ports. Members of this group
can reconfigure the modem, dial anywhere, etc.

What's on the System Groups wiki page is about as far as I'm versed in
it. So far, that's been enough *for me*. I, too, have read at least
once out there that we need to be members of as few groups as possible
for computer safety reasons.

Cindy :)

[0] https://wiki.debian.org/SystemGroups

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: exim4 and TLS Once Again

[Martin McCormick]

The problem (actually 2 problems) are solved.

The one I was actually posting about turned out to be
that I had put a line which says 

protocol = smtps

in the wrong place in a file named
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost

This caused dpkg-reconfigure exim4-config to throw an
error about not being able to generate the master configuration
file named /var/lib/exim4/config.autogenerated.

It turns out that it's the very last line in the file just as it
was before and I had seen where I thought it should go which was
wrong.

After that, the login worked.  Port 465 is supposed to
start encrypted and 587 starts in the clear.

What I found out, though, was that there was another
issue, that of the user id that suddenlink needs to see versus
the user ID based totally on the user and machine name.

There is a specific debian fix for this problem which
makes life light years easier and it is

/etc/email-addresses

and it installs along with your debian version of exim4 and
starts life empty of anything but comments and explanation.

One simply puts in a line containing their local user ID
followed by a : and then the user ID that the smarthost knows you
as.

exim4 rewrites all the local lines such as Sender: to be
the remote user ID and then you can start your happy dance
because it just works.

You can have multiple smarthosts and multiple lines in
/etc/email-addresses so if there are multiple users on the debian
system or you have multiple smarthosts to deliver to, the user ID
that gets sent over the network is right each time.

This is getting easier with each upgrade but you need to
stick to very recent postings to get the best information.

Anyway, it now works again and I am simply sending it through
exim4 in the normal manner.

Thank you to everybody who helped.
Martin McCormick WB5AGZ

Re: KPatience cards too small

[Brad Rogers]

On Sat, 2 Jun 2018 17:14:13 +0200
arne  wrote:

Hello arne,

>Looks like a bug in Kpat, the cards are way too small:

Works fine here in Testing with an nVidia GeForce GT610 GFX card & 
KPatience version - 4:18.04.1-1

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Never much liked playing there anyway
Banned From The Roxy - Crass


pgpzZ04pYqugC.pgp
Description: OpenPGP digital signature

Como instalar netbeans de estable en testing y que se mantenga sin actualizar

[Gustavo Castro]

Buenas a todos su ayuda
quiero tener netbeans de estable en testing pero por alguna sigo con las
fallas de testing.

tengon el sources.list asi
deb http://ftp.us.debian.org/debian/ stable main contrib non-free

deb http://ftp.us.debian.org/debian/ testing main contrib non-free

deb http://ftp.us.debian.org/debian/ experimental main contrib

en /etc/apt/preferences.d/netbeans tengo asi

Package: netbeans
Pin: release a=stable
Pin-Priority: 1001

Package:libequinox-osgi-java
Pin: release a=stable
Pin-Priority: 1001

y en /etc/apt/apt.conf.d/local  lo tengo asi
APT::Default-Release "testing";
APT::Cache-Limit 5500;
Apt::Get::Purge;
APT::Clean-Installed;
APT::Get::Fix-Broken;
APT::Get::Fix-Missing;
APT::Get::Show-Upgraded "true";

con esta configuración no he podido hacer que trabaje el netbeans de
estable de echo me manda los errores de netbeans de testing

 netbeans
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.netbeans.ProxyURLStreamHandlerFactory
(file:/usr/share/netbeans/platform18/lib/boot.jar) to field
java.net.URL.handler
WARNING: Please consider reporting this to the maintainers of
org.netbeans.ProxyURLStreamHandlerFactory
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release

le agradesco de antemano la ayuda que me brinden para resolver

Saludos

Re: KPatience cards too small

[Mark Neidorff]

On Saturday, June 2, 2018 11:14:13 AM EDT arne wrote:
> Hi,
> 
> Looks like a bug in Kpat, the cards are way too small:
> Screenshot:
> 
> https://i.paste.pics/652e13761f68299de40c01f409392284.png
> 
> To find the cards: top center
> 
> Debian Stretch amd64 up-to-date
> 4k monitor
> Nvidia GeForce GTX 1050 videocard
> 
> How to solve this?
> 
> Thanks!

Hi,

First thing, check on which video driver are you using?  Is there another 
driver that you could try?  That may be your simplest test to finding out where 
the problem is.

Mark

Re: Not power off after shutdown in Jessie

[Miroslav Skoric]

On 05/31/2018 04:18 PM, Curt wrote:


On 2018-05-31, Miroslav Skoric  wrote:

After upgrading from Wheezy LTS to Jessie, one of my machines having 512
MB RAM, does not power off when it reached target shutdown. It seems
some old issue/bug with systemd or else. In fact, everything closes down
properly except it does not unmount the following:

/run/user/1000
/run/user/106
/var
/home
/tmp

... and hangs there forever. That did not happen in Wheezy. Any idea?




You could try logging out, I've read somewhere, switching to a console,
logging in as root (or another user entirely) and executing
'systemd-cgls' to determine what processes are still running for the
user in question (assuming for the moment your problem is related to
some program in your session being "stuck.")




I did so, and noticed just some few Gnome -related things to be active 
for the user 106 - myself? (although I logged out from the Mate desktop 
and not from Gnome), as well as a few items active for user 1000 i.e. 
root (such as 'sudo su' and 'systemd-cgls').


Anyway, to be sure whether any of those processes were needed to run or 
not, I did in parallel the same test with another slower machine running 
Jessie at only 224MB RAM (also the recent upgrade from Wheezy), but 
which one performs proper shutdown/poweroff.


You bet, at both machines exactly the same processes were listed as 
still running for user 106 and user 1000. However, only the better one 
box having 512 MB RAM, does not power off when reached target shutdown.


Any other thing to try?

Nvidia 340 driver bug

[Pétùr]

Le 03/06/2018 à 20:47, floris a écrit :
> Pétùr schreef op 2018-06-02 17:46:
>>> This is a bug in the nvidia driver module. There is not much you can do
>>> until it is fixed upstream.
>>
>> Thanks!
>>
>> I would like to use the nouveau driver waiting for the fix.
>>
>> However I an unable to boot X with the nouveau driver.
>>
>> I did:
>>
>> # apt-get purge nvidia.
>> # apt-get install --reinstall xserver-xorg xserver-xorg-video-nouveau
>> # reboot
>>
>> I have no xorg.conf.
>>
>> $ startx
>>
>> says:
>>
>> XF86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
> 
> Did you also removed the NVidia symlinks? I'm not sure if they are
> removed when you purge the NVidia packages.
> 
> Try:
> sudo update-glx --config glx
> If there are any options choose mesa
> 
> and rebuild initramfs with:
> sudo update-initramfs -u

Thanks for the idea.

In fact, there is a bug with xorg-server-1.20.0 and the "compositor" of
Xfce.

See this bug report and message:

https://lists.debian.org/debian-user/2018/05/msg01008.html

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900550

For the ones affected, if X doesn't start, you have to downgrade
xserver-xorg-core and xserver-org-video-nouveau (apt install
xserver-xorg-core/testing xserver-xorg-video-nouveau/testing), then you
can start X and uncheck the compositor activation check in Xfce. After
that, you can upgrade back the package and reboot.

Pétùr

Re: XFCE: Set default extend-to-direction?

[David Wright]

On Sun 03 Jun 2018 at 12:45:28 (-0500), Paul Johnson wrote:
> On Sun, Jun 3, 2018 at 12:15 PM, Charlie Gibbs  wrote:
> 
> > On 03/06/18 08:45 AM, Paul Johnson wrote:
> >
> > I have a laptop that I frequently use with an external monitor, but on
> >> the lefthand side.  Now by default, XFCE assumes that I want the monitor
> >> to be on the right, and the top of the laptop to be even with the top of
> >> the external monitor.  I would love it if there's a way to get it to
> >> assume I want the external monitor on the left with the laptop
> >> bottom-justified to that instead.  What's the best way to accomplish this?
> >>
> >
> > Check out the xrandr man page.  I have two dissimilar monitors on my
> > desktop and ensure that they're properly set up as follows:
> >
> > xrandr --output DVI-I-1 --mode 1920x1080
> > xrandr --output DVI-I-2 --mode 1280x1024 --right-of DVI-I-1
> >
> > That --right-of parameter tells it that my smaller monitor is to the right
> > of my larger one - I could use --left-of if I wanted it on the other side.
> > I'm not sure how you'd do justification, though.
> 
> 
> I was hoping for something along the lines of getting XFCE's settings to
> cooperate on that, like, remember which side it should be on persistently.
> This is a monitor that gets plugged and unplugged regularly, not one that
> stays permanently attached.

I use a different approach which is more flexible (unless I've missed
something about xrandr) but I restart the Xserver when I'm changing
the setup (*to* two screens, but not when reverting to one). I don't
use a Desktop Environment.

I use bash functions to clear and then copy the appropriate set of
files to /etc/X11/xorg.conf.d/ from this selection (basically one of
each number):

/etc/X11/xorg.conf.d/mirrored/10-panelnative.conf :
Section "Monitor"
Identifier "eDP1"
Modeline   "1600x900x60.0"  115.20  1600 1664 1706 2000  900 903
906 960 -hsync -vsync
Option "PreferredMode" "1600x900x60.0"
EndSection

/etc/X11/xorg.conf.d/sidebyside/10-panelmidres.conf :
Section "Monitor"
Identifier "eDP1"
Modeline   "1368x768x60.0"   85.86  1368 1440 1584 1800  768 769
772 795 -hsync +vsync
Option "PreferredMode" "1368x768x60.0"
EndSection

/etc/X11/xorg.conf.d/sidebyside/20-kitchentv.conf :
Section "Monitor"
Identifier "HDMI1"
Modeline   "1368x768x60.0"   85.86  1368 1440 1584 1800  768 769
772 795 -hsync +vsync
Option "PreferredMode" "1368x768x60.0"
Option "Position" "1368 0"
EndSection

/etc/X11/xorg.conf.d/sidebyside/20-othertv.conf :
Section "Monitor"
Identifier "HDMI1"
Modeline   "1600x900x60.0"  108.00  1600 1624 1704 1800  900 901
904 1000 +hsync +vsync
Option "PreferredMode" "1600x900x60.0"
Option "Position" "1600 0"
EndSection

/etc/X11/xorg.conf.d/sidebyside/20-viewsonic.conf :
Section "Monitor"
Identifier "HDMI1"
Modeline   "1152x864x75.0"  108.00  1152 1216 1344 1600  864 865
868 900 +hsync +vsync
Option "PreferredMode" "1152x864x75.0"
Option "Position" "1600 0"
EndSection

/etc/X11/xorg.conf.d/all/30-devicecard.conf :
Section "Device"
Identifier "Card0"
Driver "Intel"
BusID  "PCI:0:2:0"
EndSection

/etc/X11/xorg.conf.d/all/40-screenpanel.conf :
Section "Screen"
Identifier   "Internal"
Device   "Card0"
Monitor  "eDP1"
DefaultDepth 24
EndSection

/etc/X11/xorg.conf.d/all/50-screenhdmi.conf :
Section "Screen"
Identifier   "External"
Device   "Card0"
Monitor  "HDMI1"
DefaultDepth 24
EndSection

As it happens, I use the laptop to the left in each case, so my
Position option is always in the HDMI monitor and positive. You
would either want to insert a minus sign, or move the option to
the other Monitor section to reverse things; either method works.

Why don't I do all this on the fly? Mainly because my .xsession
looks at the resolution and starts up all my (~20) xterms with
font sizes, geometries and positions as appropriate, and also
writes some little helper files for fvwm to be able to move
particular windows back to their "reset" positions automatically
on command (clocks, players, controls etc).

Cheers,
David.

What's the difference between the dialout and tty groups?

[Martin McCormick]

I added myself to both the dialout and tty groups on a
stretch installation in order to use the serial ports from the
user level.  It works fine.  Then I looked at a debian jessie
installation and found that I had only added myself to dialout
and it still works fine.

What is group tty actually for?

This is more of an idle curiosity question than it is one of
something's broken and I need help.

I am a retired systems engineer who setup unix systems
for coworkers to use so I know you can sometimes have too much
power at the user level and accidentally make it easier to make a
mess of things.

Thank you.
Martin McCormick

Re: Intermittent blank screen – Stretch

[floris]

Mike schreef op 2018-06-02 09:08:

On 02/06/18 08:11, floris wrote:

Mike schreef op 2018-06-01 01:27:

I have just installed Stretch and and randomly getting a 2 second (or
so) blank screen. I can go for quite some time without it happening,
or it can happen several times over a few minutes. I can dual boot
with Jessie and do not have the problem with that – so I think I can
rule out a hardware issue.

I have an Nvidia GTX1050 video card, HDMI output to a Samsung 49" TV,
4K video. There is no other type of input into the TV for me to be
able to test.

Here is what I have done
1. Installed Stretch (amd64) with XFCE
2. apt-get install firmware-linux nvidia-driver nvidia-settings 
nvidia-xconfig

3. run nvidia-xconfig
4. turned off screen blanking in power settings

I am quite happy to spend time troubleshooting, but don’t really know
where to start. The blanking happens too quickly for me to be able to
do anything at the time.

Does anyone have any thoughts?

Thanks

Mike


You can try the NVidia driver module from backports [1] and/or run 
journalctl -f in a terminal and wait for the blank screen.


[1] https://packages.debian.org/stretch-backports/nvidia-driver
---
Floris


Thanks Floris. Nothing from journalctl -f.
Can you tell me what installing a backport might do? Is that a later
version of the driver (I only installed Stretch a couple of days ago)

Mike


In backports there is a newer version of the NVidia module with more bug 
fixes. Maybe this line is relevant:
-  Further improved the fix for occasional flicker when using the X 
driver's composition pipeline. This was mostly fixed in 390.42, but now 
the fix should be more complete.


---
Floris

Re: OT: editar pagina en html, cansado de tant troll mentiroso, kdenlive 4k

[juansantiago]

Bueno, ya una vez en otro ámbito  tuve que mandar capturas de como gimp 
si trabaja con capas y se puede setar la profundidad de color, pues aquí 
alguien dijo que kdenlive y blender no hacen render en 4k, pues no 
mientas más, esto aburre, aquí la captura: 
http://piesnegros.org/wp-content/uploads/2018/06/kdenlive4k.png ¿Ta?




El 28/05/18 a las 23:49, Felix Perez escribió:

El 28 de mayo de 2018, 16:44, Fabián Bonetti  escribió:

Creo que se pregunto mal... o se pregunto a media.

Estimado, no re envíe, responda a la lista.


Yo veo tres caminos...

Editor con cualquier editor de texo se puede.

Ahora si se quiere editar con esos editores que tiene tag presetiados que te
marcan los errores...

Hay miles de esos programas.


A su vez hay script generadores de paginas html...lo corres y te crean las
paginas solo debes editar muy poco.



Servicios gratis: http://mamalibre.com.ar/plus
 Mensaje original 
De: Felix Perez 
Fecha: 28/5/2018 15:51 (GMT-03:00)
Para: lista-debian 
Asunto: Re: OT: editar pagina en html

El 28 de mayo de 2018, 14:28, Marcelo Eduardo Giordano
 escribió:


El 28/05/18 a las 12:46, Paynalton escribió:

ves lo que provocas por no saber usar HTML??? jajjajajaj Troya está a
punto de arder jajajaj.


No quise armar este lío.
Me siento un asesino con las manos llenas de sangre y con cara de yo no
fui.
Saludos a todos los de la lista


Es decir le haces honor a tu apellido. :-)  Un culpable de herejía.

Una buena discusión de vez en cuando aporta al intelecto.

Saludos.

--
usuario linux  #274354
normas de la lista:  http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html

Re: Nvidia 340 driver bug

[floris]

dekkz...@gmail.com schreef op 2018-06-02 17:17:

On 06/01, floris wrote:

Pétùr schreef op 2018-05-31 16:20:

I have a recurrent bug with the nvidia 340 driver.

Here is the trace. Any idea is welcomed.

Pétùr

[6.748358] [ cut here ]


snip


f3 eb [6.749313] ---[ end trace dc2afdad83c552e7 ]---

This is a bug in the nvidia driver module. There is not much you can 
do until it is fixed upstream.


https://devtalk.nvidia.com/default/topic/1031067/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899201



That devtalk is for 390 i don't see any reference to 340. FWIW i've
blocked updating xorg-server 1.20 on 2 nvidia machines that run 340,
as of today no fix on debian or arch.


xserver-xorg-video-nvidia-legacy-340xx depends on xserver-xorg-core < 
2:1.19.99, so you don't have to block the xserver manually.


---
Floris

Re: Nvidia 340 driver bug

[floris]

Pétùr schreef op 2018-06-02 17:46:
This is a bug in the nvidia driver module. There is not much you can 
do

until it is fixed upstream.


Thanks!

I would like to use the nouveau driver waiting for the fix.

However I an unable to boot X with the nouveau driver.

I did:

# apt-get purge nvidia.
# apt-get install --reinstall xserver-xorg xserver-xorg-video-nouveau
# reboot

I have no xorg.conf.

$ startx

says:

XF86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)


Did you also removed the NVidia symlinks? I'm not sure if they are 
removed when you purge the NVidia packages.


Try:
sudo update-glx --config glx
If there are any options choose mesa

and rebuild initramfs with:
sudo update-initramfs -u


---
Floris

Re: Debian 9 x64 wine32

[floris]

uli...@web.de schreef op 2018-06-02 13:06:

Hi,

i am trying to install wine32 on a amd64 debian stretch system.

I added architecture i386

Using synaptic the package "wine32" is unknown

Using apt-get the package "wine32" is known, but needs libwine:i386.

Trying to install all dependencies results in a possible complete
chnage of the system-packages, which i have interrupted.

All infos, read from https://wiki.debian.org/Wine do not work.

What about the difference of finding "wine32" between apt-get and
synaptic?

BR

Christian



Please use the Wine version in strech-backports or from WineHQ. Wine 1.8 
(Stretch) is very old and isn't supported anymore.


After you have enabled the backports repo run:
sudo apt-get update
sudo apt-get install wine wine32 wine64 libwine libwine:i386 fonts-wine

If you want the WineHQ packages read:
https://wiki.winehq.org/Debian


---
Floris

Re: XFCE: Set default extend-to-direction?

[Paul Johnson]

On Sun, Jun 3, 2018 at 12:15 PM, Charlie Gibbs  wrote:

> On 03/06/18 08:45 AM, Paul Johnson wrote:
>
> I have a laptop that I frequently use with an external monitor, but on
>> the lefthand side.  Now by default, XFCE assumes that I want the monitor
>> to be on the right, and the top of the laptop to be even with the top of
>> the external monitor.  I would love it if there's a way to get it to
>> assume I want the external monitor on the left with the laptop
>> bottom-justified to that instead.  What's the best way to accomplish this?
>>
>
> Check out the xrandr man page.  I have two dissimilar monitors on my
> desktop and ensure that they're properly set up as follows:
>
> xrandr --output DVI-I-1 --mode 1920x1080
> xrandr --output DVI-I-2 --mode 1280x1024 --right-of DVI-I-1
>
> That --right-of parameter tells it that my smaller monitor is to the right
> of my larger one - I could use --left-of if I wanted it on the other side.
> I'm not sure how you'd do justification, though.


I was hoping for something along the lines of getting XFCE's settings to
cooperate on that, like, remember which side it should be on persistently.
This is a monitor that gets plugged and unplugged regularly, not one that
stays permanently attached.

Re: XFCE: Set default extend-to-direction?

[Charlie Gibbs]

On 03/06/18 08:45 AM, Paul Johnson wrote:


I have a laptop that I frequently use with an external monitor, but on
the lefthand side.  Now by default, XFCE assumes that I want the monitor
to be on the right, and the top of the laptop to be even with the top of
the external monitor.  I would love it if there's a way to get it to
assume I want the external monitor on the left with the laptop
bottom-justified to that instead.  What's the best way to accomplish this?


Check out the xrandr man page.  I have two dissimilar monitors on my 
desktop and ensure that they're properly set up as follows:


xrandr --output DVI-I-1 --mode 1920x1080
xrandr --output DVI-I-2 --mode 1280x1024 --right-of DVI-I-1

That --right-of parameter tells it that my smaller monitor is to the 
right of my larger one - I could use --left-of if I wanted it on the 
other side.  I'm not sure how you'd do justification, though.


--
cgi...@surfnaked.ca (Charlie Gibbs)

Fail2ban na interface Web do Mailman"

[Henrique Fagundes]

Prezado Colegas,

Prezados Colegas,

Primeiramente saudações “pinguianas” a todos.

Estou com uma dificuldade em utilizar o Fail2Ban junto com o software de 
gerência de listas de discussão MailMan.

A minha ideia é que quando o invasor/atacante digitar incorretamente a senha do 
campo de login na interface web por mais de 3 vezes, ele seja bloqueado. Mas 
para que isso funcione, é necessário que o MailMan informe em seu log as 
tentativas de login sem sucesso.

Já pesquisei para ver se existe algum plugin ou extensão (assim como existe 
para o Wordpress e PHPMyAdmin), mas parece que não há nada desenvolvido para 
isso.

Então, gostaria de saber se alguém já teve a necessidade de fazer essa 
implementação, para que eu possa ter algum caminho.

Se alguém puder me ajudar, ficarei muito grato.

Atenciosamente,

Henrique Fagundes
Analista de Suporte Linux
supo...@aprendendolinux.com
Skype: magnata-br-rj
Linux User: 475399

https://www.aprendendolinux.com
https://www.facebook.com/AprendendoLinux
https://youtube.com/AprendendoLinux
https://twitter.com/AprendendoLinux
https://telegram.me/AprendendoLinux
__
Participe do Grupo Aprendendo Linux
https://listas.aprendendolinux.com/listinfo/aprendendolinux

Ou envie um e-mail para:
aprendendolinux-subscr...@listas.aprendendolinux.com

BRASIL acima de tudo, DEUS acima de todos!

XFCE: Set default extend-to-direction?

[Paul Johnson]

I have a laptop that I frequently use with an external monitor, but on the
lefthand side.  Now by default, XFCE assumes that I want the monitor to be
on the right, and the top of the laptop to be even with the top of the
external monitor.  I would love it if there's a way to get it to assume I
want the external monitor on the left with the laptop bottom-justified to
that instead.  What's the best way to accomplish this?

Re: Intermittent blank screen – Stretch

[Gene Heskett]

On Sunday 03 June 2018 07:54:22 Mike wrote:

> On 02/06/18 08:11, floris wrote:
> > Mike schreef op 2018-06-01 01:27:
> >> I have just installed Stretch and and randomly getting a 2 second
> >> (or so) blank screen. I can go for quite some time without it
> >> happening, or it can happen several times over a few minutes. I can
> >> dual boot with Jessie and do not have the problem with that – so I
> >> think I can rule out a hardware issue.
> >>
> >> I have an Nvidia GTX1050 video card, HDMI output to a Samsung 49"
> >> TV, 4K video. There is no other type of input into the TV for me to
> >> be able to test.
> >>
> >> Here is what I have done
> >> 1. Installed Stretch (amd64) with XFCE
> >> 2. apt-get install firmware-linux nvidia-driver nvidia-settings
> >> nvidia-xconfig
> >> 3. run nvidia-xconfig
> >> 4. turned off screen blanking in power settings
> >>
> >> I am quite happy to spend time troubleshooting, but don’t really
> >> know where to start. The blanking happens too quickly for me to be
> >> able to do anything at the time.
> >>
> >> Does anyone have any thoughts?
> >>
> >> Thanks
> >>
> >> Mike
> >
> > You can try the NVidia driver module from backports [1] and/or run
> > journalctl -f in a terminal and wait for the blank screen.
> >
> > [1] https://packages.debian.org/stretch-backports/nvidia-driver
> > ---
> > Floris
>
> Okay, now here is a weird thing.
>
> I just unplugged a USB cable that was, in turn, connected to a
> microcontroller. My screen went blank. When I plugged in back in it
> went blank again. This happened about 4 times until I could plug and
> unplug without the blanking. I left it for 30-odd seconds and was able
> to do the same thing. It did not happen when I unplugged my computer
> keyboard, or my USB camera.
>
> Does this give anyone any ideas?

Yes.  Unplug it again, and install htop, the run it as root so the kill 
button, F9 can kill any thing. Plug the cable to the micro-controller 
back in and see what pops up in the top 10 or so when htop is set to 
watch cpu. My theory is that the micro-controller is spaming your main 
box with lots of traffic.  But its just a theory.

> Thanks.
>
> Mike



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Intermittent blank screen – Stretch

[Mike]

On 02/06/18 08:11, floris wrote:

Mike schreef op 2018-06-01 01:27:

I have just installed Stretch and and randomly getting a 2 second (or
so) blank screen. I can go for quite some time without it happening,
or it can happen several times over a few minutes. I can dual boot
with Jessie and do not have the problem with that – so I think I can
rule out a hardware issue.

I have an Nvidia GTX1050 video card, HDMI output to a Samsung 49" TV,
4K video. There is no other type of input into the TV for me to be
able to test.

Here is what I have done
1. Installed Stretch (amd64) with XFCE
2. apt-get install firmware-linux nvidia-driver nvidia-settings 
nvidia-xconfig

3. run nvidia-xconfig
4. turned off screen blanking in power settings

I am quite happy to spend time troubleshooting, but don’t really know
where to start. The blanking happens too quickly for me to be able to
do anything at the time.

Does anyone have any thoughts?

Thanks

Mike


You can try the NVidia driver module from backports [1] and/or run 
journalctl -f in a terminal and wait for the blank screen.


[1] https://packages.debian.org/stretch-backports/nvidia-driver
---
Floris



Okay, now here is a weird thing.

I just unplugged a USB cable that was, in turn, connected to a 
microcontroller. My screen went blank. When I plugged in back in it went 
blank again. This happened about 4 times until I could plug and unplug 
without the blanking. I left it for 30-odd seconds and was able to do 
the same thing. It did not happen when I unplugged my computer keyboard, 
or my USB camera.


Does this give anyone any ideas?

Thanks.

Mike

Re: Debian 9 x64 wine32

[likcoras]

On 06/02/2018 08:06 PM, uli...@web.de wrote:
> i am trying to install wine32 on a amd64 debian stretch system.

> Using apt-get the package "wine32" is known, but needs libwine:i386.
> 
> Trying to install all dependencies results in a possible complete chnage of 
> the 
> system-packages, which i have interrupted.

What do you mean by a "complete change of system-packages"? If you mean
that libwine:i386 pulls in a lot of :i386 libraries, that's to be
expected, as it needs all of its dependencies in i386. I don't remember
it ever replacing my packages.

If you mean that it's somehow replacing existing packages, try posting
what kind of changes apt-get is suggesting, so we can get a better view
of what's going on in your system.

As for the synaptic thing, no idea, I've never used it. Hopefully
someone else around here knows.

Re: Installing Debian on a Minnowboard Turbot with installer on USB stick?

[Rick Thomas]

Hi Thomas,

On Jun 3, 2018, at 1:26 AM, Thomas Schmitt  wrote:

> Hi,
> 
> Rick Thomas wrote:
>> Instead, I used
>>   firmware-9.4.0-amd64-netinst.iso
>> to avoid any possible alpha/testing anomalies.
> 
> Normally i'd say that there is no decisive difference to expect.
> In any case copying a "netinst" ISO is much faster than a "DVD-1".
> 
> 
>> When I tried part (a) — just a simple dd — with
>> debian-9.4.0-amd64-netinst.iso, the minnowboard immediately recognized it as
>> bootable and presented it as part of the EFI menu labeled “EFI USB Device”.
> 
> Normally this difference should not appear. Very strange.
> 
> But we can now classify the demand for GPT on
>  https://minnowboard.org/tutorials/best-practice-boot-media-selection
> as spin-off of the usual rumor that EFI needs GPT.
> 
> 
>> it booted without incident and ran the installer.
>> When it came to the part where it looks for a CD, it easily found the USB
>> stick
> 
> This was expectable. As long as the ISO is marked as partition, the
> script in the initrd should find the device.
> 
> 
>> tried
>> part (a) with “firmware-buster-DI-alpha2-amd64-DVD-1.iso”.  And guess what!
>> That worked too, just the same as the other two.
> 
> Hrmpf. At least above "normally"s are not generally put in doubt.
> It would be another riddle if one ISO would fail reproducibly while
> the other succedds reproducibly.
> 
> Maybe you changed a setting in the firmware ?

In the previous experiments (where I modified the partition tables on the stick 
after dd-ing) I did try some different setting in the firmware.  But for the 
above described experiments, I reset the firmware to factory defaults before 
starting the process and made no changes thereafter.


>> or there’s something flakey about the USB ports on this device
> 
> But why did the manual start of “fs0:\efi\boot\bootx64.efi” ran the
> boot loader, loaded the kernel, and came far enough to run into the
> software shortcoming of device detection ?

I’m not absolutely sure that the manual start was necessary.  I may have gotten 
used to never seeing the “EFI USB Device” menu entry.  So when the stars 
aligned and the stick *was* seen, I didn’t notice.  So, maybe, the fact that I 
got it to work from the command line was just because it would have worked 
anyway that time from the EFI menu.

>> In any case, I apologize for all the noise.
> 
> I doubt that this was a hallucination.
> If not the hardware (stick and port) makes itself a suspect by failing
> in normal operation, then i’d bet on the firmware's settings.

I’m pretty sure that everything I’ve been seeing can be explained if we assume 
the minnowboard firmware has trouble recognizing a USB3.0 device as bootable.


> -
> 
>> Thomas, If you would like to follow up on the inability of the installer to
>> recognize itself as a suitable installation CD
> 
> I believe to understand that problem. Let's see whether debian-cd will
> find a time slot to discuss it and whether trying the devices found by
> "list-devices disk" (/dev/sda, /dev/sdb, /dev/sdc on my machine) is
> harmless enough.
> 
> It would be interesting to study the history of cdrom-detect.postinst
> (package "cdrom-detect", 1600+ commits in
> https://salsa.debian.org/installer-team/cdrom-detect/commits/master).
> cdrom-detect/blame brings me to some forth and back, which probably
> does not tell the reason for the decision not to look for "disk".
> 
> I'd need a comfortable method to look at the revison _before_ a commit
> in order to get the next older blaming.
> Or a method to see only commits which affect the interesting code parts
>   devices="$(list-devices cd; list-devices maybe-usb-floppy)"
> and
>   devices="$(list-devices usb-partition)"
>   ...
>if try_mount $device $CDFS; then
> 
> Any GitLab experts here who could help me navigate ?
> Or git experts who can augment my knowledge beyond "clone", "add",
> "commit", and "push", so that i can inspect a clone locally ?
> 
> 
> Have a nice day :)
> 
> Thomas
> 

Re: Installing Debian on a Minnowboard Turbot with installer on USB stick?

[Rick Thomas]

On Jun 3, 2018, at 12:45 AM, deloptes  wrote:

> Rick Thomas wrote:
> 
>> So, I was beginning to wonder if I were going crazy.  In any case, I tried
>> part (a) with “firmware-buster-DI-alpha2-amd64-DVD-1.iso”.  And guess
>> what!  That worked too, just the same as the other two.
> 
> I am not surprised by anything nowdays, but I was wondering if you switched
> off the device, or just rebooted. 
> 
> regards

I actually tried it both ways.

In one case, I halted the minnowboard but left it plugged in, then I hit the 
“reset” button and it acted as I described — found the stick and was willing to 
boot from it.

In the other case, I halted the minnowboard, then unplugged it from the power 
brick, then reconnected it to the power brick. same results as above.

I’m not sure what it means, but that’s what I saw.

Rick

Re: Installing Debian on a Minnowboard Turbot with installer on USB stick?

[Thomas Schmitt]

Hi,

Rick Thomas wrote:
> Instead, I used
>firmware-9.4.0-amd64-netinst.iso
> to avoid any possible alpha/testing anomalies.

Normally i'd say that there is no decisive difference to expect.
In any case copying a "netinst" ISO is much faster than a "DVD-1".


> When I tried part (a) — just a simple dd — with
> debian-9.4.0-amd64-netinst.iso, the minnowboard immediately recognized it as
> bootable and presented it as part of the EFI menu labeled “EFI USB Device”.

Normally this difference should not appear. Very strange.

But we can now classify the demand for GPT on
  https://minnowboard.org/tutorials/best-practice-boot-media-selection
as spin-off of the usual rumor that EFI needs GPT.


> it booted without incident and ran the installer.
> When it came to the part where it looks for a CD, it easily found the USB
> stick

This was expectable. As long as the ISO is marked as partition, the
script in the initrd should find the device.


> tried
> part (a) with “firmware-buster-DI-alpha2-amd64-DVD-1.iso”.  And guess what!
> That worked too, just the same as the other two.

Hrmpf. At least above "normally"s are not generally put in doubt.
It would be another riddle if one ISO would fail reproducibly while
the other succedds reproducibly.

Maybe you changed a setting in the firwmware ?


> or there’s something flakey about the USB ports on this device

But why did the manual start of “fs0:\efi\boot\bootx64.efi” ran the
boot loader, loaded the kernel, and came far enough to run into the
software shortcomming of device detection ?


> In any case, I apologize for all the noise.

I doubt that this was a hallucination.
If not the hardware (stick and port) makes itself a suspect by failing
in normal operation, then i'd bet on the firmware's settings.

-

> Thomas, If you would like to follow up on the inability of the installer to
> recognize itself as a suitable installation CD

I believe to understand that problem. Let's see whether debian-cd will
find a time slot to discuss it and whether trying the devices found by
"list-devices disk" (/dev/sda, /dev/sdb, /dev/sdc on my machine) is
harmless enough.

It would be interesting to study the history of cdrom-detect.postinst
(package "cdrom-detect", 1600+ commits in
https://salsa.debian.org/installer-team/cdrom-detect/commits/master).
cdrom-detect/blame brings me to some forth and back, which probably
does not tell the reason for the decision not to look for "disk".

I'd need a comfortable method to look at the revison _before_ a commit
in order to get the next older blaming.
Or a method to see only commits which affect the interesting code parts
   devices="$(list-devices cd; list-devices maybe-usb-floppy)"
and
   devices="$(list-devices usb-partition)"
   ...
if try_mount $device $CDFS; then

Any GitLab experts here who could help me navigate ?
Or git experts who can augment my knowledge beyond "clone", "add",
"commit", and "push", so that i can inspect a clone locally ?


Have a nice day :)

Thomas

Re: Installing Debian on a Minnowboard Turbot with installer on USB stick?

[deloptes]

Rick Thomas wrote:

> So, I was beginning to wonder if I were going crazy.  In any case, I tried
> part (a) with “firmware-buster-DI-alpha2-amd64-DVD-1.iso”.  And guess
> what!  That worked too, just the same as the other two.

I am not surprised by anything nowdays, but I was wondering if you switched
off the device, or just rebooted. 

regards

Re: Installing Debian on a Minnowboard Turbot with installer on USB stick?

[Rick Thomas]

Well… I have some results.  Just not the kind I was expecting!  (see below)

On Jun 2, 2018, at 5:15 PM, Rick Thomas  wrote:

> I have a confession to make…
> 
> On Jun 2, 2018, at 6:09 AM, Thomas Schmitt  wrote:
> 
>> Rick Thomas reported that the boot process of
>> firmware-buster-DI-alpha2-amd64-DVD-1.iso
>> fails with
>> Incorrect CD-ROM detected
>> after it was re-partitioned to GPT.
> 
> On the advice of another comment in this thread, I didn’t use
>firmware-buster-DI-alpha2-amd64-DVD-1.iso
> for those experiments.  Instead, I used
>firmware-9.4.0-amd64-netinst.iso
> to avoid any possible alpha/testing anomalies.
> 
> I neglected to say that in my earlier report.  I’m sorry for any confusion it 
> has caused!
> 
> 
> This afternoon, I plan to make a comprehensive set of tests: 
>   (a) “as-is” no messing with the partition tables at all; just dd directly 
> to the USB stick.
>   (b) an automatically gdisk-built GPT table deleting partition 1 and leaving 
> partition 2 unmodified except for setting as type EF00.
>   (c) an automatically gdisk-built GPT table based upon the original MBR 
> table deleting partition 1 and leaving partition 2 unmodified except for 
> setting as type EF00.
>   (d) a hand-built (using disk) GPT table with partition 1 having the same 
> start/end as the partition 2 had in the original GPT table and type EF00, and 
> no partition 2.
> 
> I plan to start with
>debian-9.4.0-amd64-netinst.iso
> because it’s the smallest (to minimizing time spend dd-ing) and has the 
> fewest non-fully-supported features to confuse issues.  In particular, this 
> is not the firmware-9.4 I used above.
> 
> I’ll report back as soon as I have some results.
> 
> Thanks for all the help!
> Rick

“Curiouser and curiouser!” cried Alice.

When I tried part (a) — just a simple dd — with debian-9.4.0-amd64-netinst.iso, 
the minnowboard immediately recognized it as bootable and presented it as part 
of the EFI menu labeled “EFI USB Device”.  When I chose that option, it booted 
without incident and ran the installer.  When it came to the part where it 
looks for a CD, it easily found the USB stick (no intervention on my part 
required) and proceeded to read modules from it.  I let it go til it got to the 
partitioning phase.  I stopped it there.

So, I moved on to try the same thing (just part (a)) with 
“firmware-9.4.0-amd64-netinst.iso”.  With the same results — it gave me the EFI 
menu offering the USB stick. When I chose that, it proceeded to install, 
finding and reading the “CD” as usual.

So, I was beginning to wonder if I were going crazy.  In any case, I tried part 
(a) with “firmware-buster-DI-alpha2-amd64-DVD-1.iso”.  And guess what!  That 
worked too, just the same as the other two.

Conclusion:  Either I’m imagining things, or there’s something flakey about the 
USB ports on this device that sometimes causes a USB stick to NOT be recognized 
as a bootable device.

Thomas, If you would like to follow up on the inability of the installer to 
recognize itself as a suitable installation CD after the partition table has 
been modified, please let me know and I’ll be happy to help any way I can.

In any case, I apologize for all the noise.

Rick

PS: One other item that may shed light — the above experiments were performed 
using an 8GB Generic USB2.0 flash drive purchased thru NewEgg direct from a 
factory in China.  On the suspicion that there might be something strange about 
the USB ports on the minnowboard, tried it with a name-brand 16GB USB3.0 flash 
drive from Kingston DataTraveler.

The minnowboard has two USB ports.  The “upper” port is USB2.0 and is usually 
used for a keyboard/mouse combo.  The “lower” port is USB3.0 and recommended 
for attaching mass storage devices, such as the Debian installer.

When I plugged the USB3.0 DataTraveler into the lower (USB3.0) slot, it was NOT 
recognized as bootable.  So I swapped the plugs, plugging the keyboard/mouse 
into the lower (USB3.0) slot, and the DataTraveler into the upper (USB2.0) 
slot.  Guess what!  This time it WAS recognized as a bootable device!

So it appears that the minnowboard firmware (or USB hardware?) has trouble 
recognizing a USB3.0 device as bootable???  Something to take up with the 
Netgate minnowboard support folks, I guess.

Enjoy!