Re: which package to file a bug report ?

[Jonathan Dowland]

On Tue Feb 27, 2024 at 7:12 AM GMT, Frank Weißer wrote:
> So we are at my original question: Which package to file a bug report ?

Package "debian-installer", I think; and/or submit an installation report,
which can be done with reportbug against the "installation-report" pseudo
package. See 


-- 
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: which package to file a bug report ?

[Frank Weißer]

Marco Moock:

Am Fri, 23 Feb 2024 13:59:41 +0100
schrieb Frank Weißer :


The installer does format it as ext4, but shows ext2 and places that
in fstab, what ends up in emergency mode. That's why I'm here


That is definitely a bug.


So we are at my original question: Which package to file a bug report ?

readU
Frank

Re: which package to file a bug report ?

[Marco Moock]

Am Fri, 23 Feb 2024 13:59:41 +0100
schrieb Frank Weißer :

> First of all: I use german during installation; but I doubt that is 
> relevant.

Try to reproduce it in English if you like.

> Marco Moock:
> > Am 22.02.2024 schrieb Frank Weißer :
> >   
> >> I only choose ext2 for formatting the encrypted partition, because
> >> nothing else is offered.  
> > 
> > That is really strange. If I did install Debian 12, it offered me a
> > list of different file systems, including ext2/3/4.
> >   
> It does on non-crypt partitions, but not if I choose 'physical volume 
> for encryption' there; then afterwards I only have the choices to use
> it as ext2, swap or lvm or leave it unused for the encrypted
> partition.

I chose manual partitioning and I created the LUKS container manually
and then created an ext4 partition inside.

> >> Despite that the partition in fact is getting formatted ext4, so
> >> the entry ext2 in /etc/fstab leads into emergency mode.  
> > 
> > Does the installer format it as ext4, but shows ext2 and places
> > that in fstab?
> > Or do you format it manually?
> >   
> The installer does format it as ext4, but shows ext2 and places that
> in fstab, what ends up in emergency mode. That's why I'm here

That is definitely a bug.

Re: which package to file a bug report ?

[Frank Weißer]

First of all: I use german during installation; but I doubt that is 
relevant.


Marco Moock:

Am 22.02.2024 schrieb Frank Weißer :


I only choose ext2 for formatting the encrypted partition, because
nothing else is offered.


That is really strange. If I did install Debian 12, it offered me a
list of different file systems, including ext2/3/4.

It does on non-crypt partitions, but not if I choose 'physical volume 
for encryption' there; then afterwards I only have the choices to use it 
as ext2, swap or lvm or leave it unused for the encrypted partition.



Despite that the partition in fact is getting formatted ext4, so the
entry ext2 in /etc/fstab leads into emergency mode.


Does the installer format it as ext4, but shows ext2 and places that in
fstab?
Or do you format it manually?


The installer does format it as ext4, but shows ext2 and places that in
fstab, what ends up in emergency mode. That's why I'm here

Re: which package to file a bug report ?

[Marco Moock]

Am 22.02.2024 schrieb Frank Weißer :

> I only choose ext2 for formatting the encrypted partition, because 
> nothing else is offered.

That is really strange. If I did install Debian 12, it offered me a
list of different file systems, including ext2/3/4.

> Despite that the partition in fact is getting formatted ext4, so the
> entry ext2 in /etc/fstab leads into emergency mode.

Does the installer format it as ext4, but shows ext2 and places that in
fstab?
Or do you format it manually?

> I think the partitioning tool in installer should offer to format the 
> encrypted partition in ext4, as LUKS (?) does, instead of ext2 and
> must write ext4 to /etc/fstab, as this is, how it ends up.

LUKS is only a container and doesn't care about the file system inside.
After opening it, it is a file under /dev/mapper that can be formatted
like /dev/sdXY.

Re: which package to file a bug report ?

[Frank Weißer]

Marco Moock:

Am 22.02.2024 um 13:18:48 Uhr schrieb Frank Weißer:


I use to encrypt my swap and /var/tmp partitions during
installation.


That is LUKS.


the partition tool in debian installer offers me randomized keys
for that and has 'delete partition' set to 'yes', which costs lot
of time, not necessary on new hdd/ssd and - my opinion - on
randomized keys. I propose switching to 'no', when selecting
randomized keys.


Why? A user can rather easy select what he wants.


As I said: My opinion; if you miss setting 'no' you have to wait a lot
of time...


Further I can select ext2 or swap for partition format.


That is really strange. swap is only for the special-purpose swap 
partition.



Yes, I choose it for the swap partition


I use ext2 for /var/tmp, but - in /etc/crypttab the marker 'tmp' is
missing for the /var/tmp partition


Which marker?


This one:
frank@pc:~$ cat /etc/crypttab
sda4_crypt /dev/sda4 /dev/urandom cipher=aes-xts-
plain64,size=256,swap,discard
sda5_crypt /dev/sda5 /dev/urandom cipher=aes-xts-
plain64,size=256,tmp,discard
 ^^^

crypttab is only for decrypting the partition and creating a device 
file for the encrypted one.



- in /etc/fstab ext2 is set instead of ext4, that cryptsetup
defaults to. So on reboot I end up in emergency mode.


If you format it in ext2, choose that. Or was that an automatic
decision by the installer?

I only choose ext2 for formatting the encrypted partition, because 
nothing else is offered. Despite that the partition in fact is getting 
formatted ext4, so the entry ext2 in /etc/fstab leads into emergency mode.


I think the partitioning tool in installer should offer to format the 
encrypted partition in ext4, as LUKS (?) does, instead of ext2 and must 
write ext4 to /etc/fstab, as this is, how it ends up.

Re: which package to file a bug report ?

[Marco Moock]

Am 22.02.2024 um 13:18:48 Uhr schrieb Frank Weißer:

> I use to encrypt my swap and /var/tmp partitions during installation.

That is LUKS.

> the partition tool in debian installer offers me randomized keys for 
> that and has 'delete partition' set to 'yes', which costs lot of
> time, not necessary on new hdd/ssd and - my opinion - on randomized
> keys. I propose switching to 'no', when selecting randomized keys.

Why?
A user can rather easy select what he wants.

> Further I can select ext2 or swap for partition format.

That is really strange. swap is only for the special-purpose swap
partition.

> I use ext2 for /var/tmp, but
> - in /etc/crypttab the marker 'tmp' is missing for the /var/tmp
> partition

Which marker?
crypttab is only for decrypting the partition and creating a device
file for the encrypted one.

> - in /etc/fstab ext2 is set instead of ext4, that cryptsetup defaults 
> to. So on reboot I end up in emergency mode.

If you format it in ext2, choose that.
Or was that an automatic decision by the installer?

-- 
Gruß
Marco

Spam und Werbung bitte an ichschickerekl...@cartoonies.org

Re: Which Package To File This Bug Report Under?

[Colin Watson]

On Sun, May 26, 2002 at 08:52:06PM -0400, Ajit George wrote:
 I attempted to do an apt-get dist-upgrade and everything worked fine
 until it attempted to: 
 
 - install libsnmpkit2 (version 0.9-4).  Apt quit with an error saying
 that it was trying to overwrite a .so installed by libsnmpkit1 
 - So I tried to remove libsnmpkit1 and received another error, which was
 pconf-detect(0.5-4) depended on libsnmpkit1 
 -I tried to remove pconf-detect and got another error.  Couldn't remove
 pconf-detect because it depended on libprinterconf0 (0.5-4) which
 depended on libsnmpkit2 which wasn't installed yet 

libsnmpkit1 and libsnmpkit2 appear to be disaster area packages.
libsnmpkit1 should never have installed libsnmpkit.so.2.0.0, and the
maintainer really should have known what was happening rather than
saying I have no idea of what triggers [this bug] so I am trying a wild
guess ...

Anyway, a bug against libsnmpkit2 has already been closed by adding an
explicit conflict (breaking the expectation that you should be able to
install multiple library versions simultaneously, but hey), and a new
version of pconf-detect is available that depends on libsnmpkit2.
Upgrade to those and you should be fine.

-- 
Colin Watson  [EMAIL PROTECTED]


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

Re: Which Package To File This Bug Report Under?

[Tim Dijkstra]

On 26 May 2002 20:52:06 -0400
Ajit George [EMAIL PROTECTED] wrote:

 Hello, 
 
 I'm currently running Debian Unstable...  I'd like to report a bug
 concerning a package but I'm a bit confused as to which package to
 file it under. 
 
 First, I don't think apt-get automatically logs its activities...  I
 can find no mention of that in the man page.  Correct me if I am wrong
 though.  I'd like the logs so I can put up the exact error messages I
 got. 
 
 I attempted to do an apt-get dist-upgrade and everything worked fine
 until it attempted to: 
 
 - install libsnmpkit2 (version 0.9-4).  Apt quit with an error saying
 that it was trying to overwrite a .so installed by libsnmpkit1 
 - So I tried to remove libsnmpkit1 and received another error, which
 was pconf-detect(0.5-4) depended on libsnmpkit1 
 -I tried to remove pconf-detect and got another error.  Couldn't
 remove pconf-detect because it depended on libprinterconf0 (0.5-4)
 which depended on libsnmpkit2 which wasn't installed yet 
 
 I tried using apt-get -f install.  No dice. 
 
 This appears to be the dependency sequence: 
 
 pconf-detectlibsnmpkit1 
 libprinterconf0libsnmpkit2 XX libsnmpkit1 
 
 depends  conflict 
 
 Finally I used dpkg --remove pconf-detect a and removed everything
 down the line.  I installed libsnmpkit2 and then installed back up. 
 Everything seemed to work fine after that and apt didn't have a
 problem... 
 
 Any comments as to how to file this would be appreciated.  I'm
 thinking under libsnmpkit2 
 
I'm not really an apt know-it-all, but I think the bug is the fact that
libsnmpkit2 doesn't conflict with libsnmpkit1. If it did, libsnmpkit1
would have been removed when you tried to install libsnmpkit2. So this
seems to be a bug in libsnmpkit2.

Grtjs,

Tim


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