Re: not loading non-free firmware in 11.00 network installation debian-installer
Hi, Nick Gawronski wrote (Sun, 26 Sep 2021 12:48:57 -0500): > Hi, Here is the syslog file from the working installed system. Possibly > someone can look at it and find out what is different and why the newer > installers are not loading the needed firmware. Nick Gawronski >From your "successful installation" syslog file, the relevant part for loading the firmware is this: Mar 4 17:55:36 check-missing-firmware: looking at dmesg again, restarting from \[5.102665\] Mar 4 17:55:36 check-missing-firmware: timestamp found, truncating dmesg accordingly Mar 4 17:55:36 check-missing-firmware: saving timestamp for a later use: [ 83.704740] Mar 4 17:55:36 check-missing-firmware: looking for firmware file iwlwifi-6000g2b-6.ucode requested by iwlwifi Mar 4 17:55:36 check-missing-firmware: looking for firmware file iwlwifi-6000g2b-5.ucode requested by iwlwifi Mar 4 17:55:36 check-missing-firmware: /dev/.udev/firmware-missing does not exist, skipping Mar 4 17:55:36 check-missing-firmware: /run/udev/firmware-missing does not exist, skipping Mar 4 17:55:36 check-missing-firmware: missing firmware files (iwlwifi-6000g2b-6.ucode iwlwifi-6000g2b-5.ucode) for iwlwifi iwlwifi Mar 4 17:55:40 check-missing-firmware: installing firmware package /cdrom/firmware/firmware-iwlwifi_20190717-2_all.deb Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sda on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sda on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdb on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdb on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdc on /media failed: Device or resource busy Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdc on /media failed: Device or resource busy Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdd on /media failed: No medium found Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdd on /media failed: No medium found Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sda1 on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sda1 on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sda2 on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sda2 on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdb1 on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdb1 on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdc1 on /media failed: Device or resource busy Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdc1 on /media failed: Device or resource busy Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sda on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sda on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdb on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdb on /media failed: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdc on /media failed: Device or resource busy Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't unmount /media: Invalid argument Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdc on /media failed: Device or resource busy Mar 4 17:55:51 main-menu[610]: (process:4890): mount: mounting /dev/sdd on /media failed: No medium found Mar 4 17:55:51 main-menu[610]: (process:4890): umount: can't
Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
Hi, On 2021-09-26 20:46, Adam D. Barratt wrote: > On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote: > [...] > > In the meantime another issue that would need to be fixed in sid > > > > came > > as > > bug#994042. > > > > This time the issue is in the preinst. To summarize, in the case > > debconf is not usable to prompt the user about the upgrade, the > > preinst switches to text prompt. However as the debconf module has > > been loaded got control of the tty, which prevent any input from the > > user. For skilled users it still possible to kill the upgrade from > > another, but other users will probably try other actions that might > > have damaging effects (like rebooting the system). > > > > The fix is to get the debconf configuration without using the debconf > > module, as suggested by Colin Watson. > > > > Thanks. That looks OK to me, particularly with Colin's review. Thanks for the review. I guess that now it just needs a kibi-ack. > Is there an ETA for getting the fix into unstable? Upgrades from buster to bookworm are not supported, so it means upgrade to bookworm starts from bullseye, which has a fixed debconf (the issue has been fixed in version 1.5.76). Therefore the fix in unstable has been done in glibc 2.32-3 by just dropping all the workaround: https://salsa.debian.org/glibc-team/glibc/-/commit/66359576b1aa793ae6c79618b188738287cf8789 Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote: [...] > In the meantime another issue that would need to be fixed in sid > > > came > as > bug#994042. > > This time the issue is in the preinst. To summarize, in the case > debconf is not usable to prompt the user about the upgrade, the > preinst switches to text prompt. However as the debconf module has > been loaded got control of the tty, which prevent any input from the > user. For skilled users it still possible to kill the upgrade from > another, but other users will probably try other actions that might > have damaging effects (like rebooting the system). > > The fix is to get the debconf configuration without using the debconf > module, as suggested by Colin Watson. > Thanks. That looks OK to me, particularly with Colin's review. Is there an ETA for getting the fix into unstable? Regards, Adam
Bug#931368: marked as done (Can't set hungarian keyboard layout with preseeded installer)
Your message dated Sun, 26 Sep 2021 20:37:43 +0200 with message-id <20210926203743.c305a906d2ef94bb2e9d7...@mailbox.org> and subject line Re: #931368: Can't set hungarian keyboard layout with preseeded installer has caused the Debian Bug report #931368, regarding Can't set hungarian keyboard layout with preseeded installer to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 931368: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931368 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: debian-installer Severity: normal Hi, I added my preseed configuration to initrd on a Debian 9.9.0 installer media and installed the OS. I set the localization as I saw in the example configuration of Stretch installer: Contents of the preconfiguration file (for stretch) ### Localization # Preseeding only locale sets language, country and locale. d-i debian-installer/locale string hu_HU # The values can also be preseeded individually for greater flexibility. d-i debian-installer/language string hu d-i debian-installer/country string HU d-i debian-installer/locale string hu_HU.UTF-8 # Optionally specify additional locales to be generated. #d-i localechooser/supported-locales multiselect hu_HU.UTF-8 # Keyboard selection. d-i keyboard-configuration/xkb-keymap select hu # d-i keyboard-configuration/toggle select No toggling When I boot the installed OS I have the expected locales set but the keyboard layout is "us" on the console. I have no "/etc/default/keyboard" file where it should be set because the installer isn't installed the "console-setup" and the "keyboard-configuration" packages. If I write "console-setup" into the "d-i pkgsel/include string" option it installs it and the result will be hungarian layout, but there's a popup when installing the package and I have to choose(just press an enter) the keyboard layout. It's unwanted interaction while preseeding. If I install Debian with the newt interactive installer the keymap and the locales are set correctly, so everything available in the installer to use hungarian layout. I tried also to set anything else the keymap, e.g. "de" or "cz". The result was the same: no "console-setup" and "keyboard-configuration" packages were installed and I got "us" layout. How should I set the expected keyboard layout with preseeding? Is it a bug? Is there any solution or workaround? I found a similar bugreport in the past: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721460 Thanks! --- End Message --- --- Begin Message --- Hi, Using the Debian 11.0 bullseye installer: with the text installer and setting the preseeding options like this: d-i debian-installer/locale string hu_HU d-i keyboard-configuration/xkb-keymap select hu I get an installer localized in Hungarian with Hungarian keyboard, and also the installed system is localized in Hungarian, with hungarian keyboard layout. An /etc/default/keyboard file exists and contains: XKBMODEL="pc105" XKBLAYOUT="hu" XKBVARIANT="" XKBOPTIONS="" So I think, your problem has been dealed with in the meantime. Closing this bug. Thanks for reporting it! Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076--- End Message ---
Re: #931368: Can't set hungarian keyboard layout with preseeded installer
Hi, Using the Debian 11.0 bullseye installer: with the text installer and setting the preseeding options like this: d-i debian-installer/locale string hu_HU d-i keyboard-configuration/xkb-keymap select hu I get an installer localized in Hungarian with Hungarian keyboard, and also the installed system is localized in Hungarian, with hungarian keyboard layout. An /etc/default/keyboard file exists and contains: XKBMODEL="pc105" XKBLAYOUT="hu" XKBVARIANT="" XKBOPTIONS="" So I think, your problem has been dealed with in the meantime. Closing this bug. Thanks for reporting it! Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: not loading non-free firmware in 11.00 network installation debian-installer
Hi, Here is the syslog file from the working installed system. Possibly someone can look at it and find out what is different and why the newer installers are not loading the needed firmware. Nick Gawronski On 9/25/2021 2:40 PM, Holger Wansing wrote: Hi, Nick Gawronski wrote (Sat, 25 Sep 2021 12:47:25 -0500): Hi, I just tried this same process with the debian non-free DVD and educational versions with the same results. My system was installed with an earlier version of debian-installer so where can I locate the installation report on my system as sending this to you might help? That's under /var/log/installer/ Holger syslog.xz Description: Binary data
Re: partman, growlight, discoverable partitions, and fun
John Paul Adrian Glaubitz left as an exercise for the reader: > So, you are not using libparted then? i am not. > Yes, it is important as we're supporting these architectures in Debian Ports > and I invested quite some time to get Atari partition support added [1], > for example. I'd be delighted to support them -- as in, I am honestly eager to add ATARI support; that sounds awesome -- I just need some way to test the implementations, either via someone running it on the environment, or getting access to such a machine. > I think it makes little sense to not use libparted as it already supports > all common and less common partition types and reimplementing everything > that libparted makes little sense to me. parted did not have ZFS support when I embarked on this project (it appears to have it now). i would not be opposed to leveraging libparted if it presents a definite advantage; supporting more partition types, so long as it exposes an API i can easily work with, would be such an advantage. i do note that libparted2 is 621K in the archive, whereas growlight itself is only 555K. it is of course possible that all that weight is desirable functionality. with that said, i would *still want to test on the target environment*, to make sure i'm using libparted correctly there. so that necessity remains. would this allay your concerns? --nick -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
On Sun, 26 Sept 2021 at 10:05, John Paul Adrian Glaubitz wrote: > > Hello Nick! > > On 9/26/21 00:49, Nick Black wrote: > > It supports MBR, GPT, and APM: > > > > https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123 > > > > (sorry for the gmail-style top posting; i can't find your mail in my mbox > > for whatever reason) > > > > Any other partition schemes ought be trivial to add; they've not been added > > yet > > simply because I don't have means with which to test them. > > So, you are not using libparted then? > > > Looking at the "partition types" section of the Linux configuration, I see: > > Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris > > x86, Unixware, > > Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68. > > > > Looking at the disk-label code from partman, I see: > > gpt, msdos, amiga, atari, mac, sun > > > > So the only ones covered by partman and not covered by growlight would be: > > amiga, atari, sun, > > and mac (if mac is not the same as APM). I don't see any difficulty in > > adding these four, so long > > as there's someone with an Amiga or ATARI who'd be willing to test them > > out. If there are no such > > people, is it that important? > > Yes, it is important as we're supporting these architectures in Debian Ports > and I invested quite some time to get Atari partition support added [1], > for example. > > I think it makes little sense to not use libparted as it already supports > all common and less common partition types and reimplementing everything > that libparted makes little sense to me. > > Adrian Does libparted support the discoverable partitions spec? Kind Regards, Luca Boccassi
Bug#995108: d-i: partman-crypto: plain dm-crypt device management issues
Package: partman-crypto Version: 114 Tags: patch Hello d-i team, I found several issues related to plain dm-crypt (i.e. non LUKS) encrypted devices in partman. 1) Partman does not add option "plain" for non LUKS devices in crypttab. This causes warnings at startup and when running update-initramfs: "cryptsetup: WARNING: sda10_crypt: couldn't determine device type, assuming default (plain)" 2) Partman adds the option "swap" in crypttab entry for encrypted devices used as swap regardless of the key type. This option is ony needed with random key and uselessly formats persistent encrypted devices (LUKS or plain dm-crypt with keyfile). Fortunately The initramfs ignores it and won't destroy an hibernation image before it is used. 3) Partman adds the option "tmp" in crypttab entry only if the mount point is /tmp. The option should be added for any encrypted device with random key used as a filesystem even if the mount point is not /tmp. 4) Partman does not specify the filesystem type in option "tmp". This defaults to format as ext4 at system startup. However partman allows only ext2 and sets the filesystem type as ext2 in fstab, causing a mismatch at startup I propose to set tmp= and allow any POSIX filesystem type (non POSIX filesystems are not suitable for /tmp). 5) Partman uses LUKS UUID in crypttab regarless of its own keytype info. If a partition containing a LUKS header is re-used as plain dm-crypt, partman will wrongly write the old LUKS UUID in crypttab regardless of the keytype info. It should use the LUKS UUID only if keytype=passphrase. 6) Partman uses non persistent physical device names for plain dm-crypt in crypttab. Unlike LUKS, plain dm-crypt physical volumes do not have a UUID so they are designated with their block device name in the generated crypttab. This is fine with LVM logical volumes for which persistent device names /dev/mapper/* are used. However some devices such as SCSI/ATA/USB drives and partitions (/dev/sd*) or software RAID arrays (/dev/md*) may not be assigned the same names across boots. I have neither experience or knowledge about SD/MMC drives, NVMe SSDs nor hardware RAID arrays. Partition numbers are not so reliable either; for example, logical partitions may be renumbered after creating or deleting another logical partition. Using non persistent physical device names may lead to boot failure if the device name in /etc/crypttab does not exist or even more catastrophic consequences if the device name is assigned to the wrong device which will be overwritten. This has happened to me and others (cf. bug #697905). For this reason IMO /etc/crypttab should use a persistent identifier whenever possible. For instance it could use the PARTUUID for partitions on disk labels which provide it, or a symlink in /dev/disk/by-id/ like the grub-pc package does to record installation devices in debconf: The attached patch makes the following changes: /lib/partman/finish.d/55crypto_config - add option "plain" in crypttab for non-LUKS devices - add option "swap" in crypttab only for devices with random key - add option "tmp" in crypttab even if mountpoint is not /tmp - add explicit filesystem to option "tmp" in crypttab - use partman info instead of only cryptsetup to check if LUKS device before retrieving LUKS UUID - use PARTUUID or /dev/disk/by-id/* if available instead of non-persistent device file for plain devices in crypttab Discussion: is this adequate for RAID devices /dev/md* ? md* names should be rather persistent when defined in /etc/mdadm/mdadm.conf, and have two symlinks in /dev/disk/by-id/*: one based on the array name attribute and the other based on the array UUID. The one based on the name attribute is selected by the patch because it is found first, but the name attribute is derived from the hostname at creation time and may lack uniqueness. Discussion: I used blkid to retrieve the PARTUUID because parted_server does not seem to provide this feature. Is blkid supported by non-Linux architectures ? /lib/partman/veto_filesystems/crypto - allow all POSIX filesystems on encrypted devices with random key Discussion: is getting the filesystem type from $id/filesystem the right way of doing things ? It does not work with FAT16 and FAT32, so I excluded them (for not being POSIX compliant thus unusable as /tmp). diff -ur a/finish.d/crypto_config b/finish.d/crypto_config --- a/finish.d/crypto_config 2021-05-30 23:37:15.0 +0200 +++ b/finish.d/crypto_config 2021-09-26 00:58:47.912184745 +0200 @@ -26,7 +26,7 @@ return 1 fi done - opts="cipher=$cipher-$ivalgorithm,size=$keysize" + opts="plain,cipher=$cipher-$ivalgorithm,size=$keysize" if [ $keytype != random ] && [ -n "$keyhash" ]; then opts="$opts,hash=$keyhash" fi @@ -49,10 +49,10 @@ if [ -f $cryptdevdir/mountpoint ]; then mnt=$(cat $cryptdevdir/mountpoint) fi - if [ $method = swap ]; then + if [ $method = swap ] && [
Re: partman, growlight, discoverable partitions, and fun
Hello! On 9/26/21 12:40, Luca Boccassi wrote: > Does libparted support the discoverable partitions spec? I'm not sure, this thread is the first time I have heard about discoverable partitions. I have read up first what the motivations for these are and how useful they would be for Debian. Also, since parted is maintained by RedHat, I would expect that this feature would land in parted soon as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#995104: d-i: partman-basicfilesystems; swap
Package: partman-basicfilesystems
Version: 156
Tags: patch
Hello d-i team,
I am not happy with current swap management in manual partitioning.
1) All existing swaps are automatically marked as used and formatted.
Formatting an existing swap changes its UUID. On multiboot setups this
breaks other installed systems such as Debian which use these swaps and
rely on UUID to identify them. I have read multiple reports on Debian
user forums from people which did not notice that all swaps were marked
as used and to be formatted and broke already installed systems.
On the other hand, I cannot see any benefit in formatting an existing
swap. The transition from old swap format v0 to current format v1 was 20
years ago, so I doubt that any v0 swap still exists on any disk in use.
Is it to avoid on-disk format incompatibilities between architectures
(endianness, page size...) ?
Also, activating a shared swap removes the hibernation image that may
have been written by another system. This breaks suspending a system to
disk and rebooting another system.
For these reasons I propose to disable this feature. I think it is
better that people who use manual partitioning select swaps they want to
use instead of deselecting swaps they do not want to use.
2) Partman forces used existing swaps to be formated.
As explained above, formatting an existing swap is useless and may break
other installed systems which use it.
3) Partman does not allow the user to choose to format or not format an
existing swap.
Actually most of the needed code is present but can never be reached due
to improper checks.
The attached patch makes the following changes:
- disable automatic use and format of existing swaps
init.d/autouse_swap
- do not format existing swap by default when manually selected
choose_method/swap/do_option
- enable choice to format or not format an existing swap
active_partition/basicfilesystems/choices
active_partition/basicfilesystems/do_option
Caveat: I don't know how this is compatible with non-Linux architectures
which may use different swap formats.
diff -ur a/active_partition/basicfilesystems/choices b/active_partition/basicfilesystems/choices
--- a/active_partition/basicfilesystems/choices 2021-07-23 19:14:05.0 +0200
+++ b/active_partition/basicfilesystems/choices 2021-09-26 01:08:03.102852685 +0200
@@ -10,19 +10,24 @@
cd $dev
-[ -f $part/method -a -f $part/acting_filesystem ] || exit 0
+[ -f $part/method ] || exit 0
method=$(cat $part/method)
-filesystem=$(cat $part/acting_filesystem)
-case "$filesystem" in
-ext2|fat16|fat32|ntfs)
+if [ "$method" = swap ]; then
:
- ;;
-*)
+elif [ -f $part/acting_filesystem ]; then
+ filesystem=$(cat $part/acting_filesystem)
+ case "$filesystem" in
+ ext2|fat16|fat32|ntfs)
+ ;;
+ *)
+ exit 0
+ ;;
+ esac
+else
exit 0
- ;;
-esac
+fi
choice_mountpoint () {
case "$filesystem" in
@@ -40,6 +45,7 @@
}
choice_options () {
+ [ "$filesystem" ] || return 0
db_metaget partman-basicfilesystems/text/options description
printf "options\t%s\${!TAB}%.45s\n" "$RET" "$(get_mountoptions $dev $id)"
}
@@ -51,11 +57,10 @@
description="$RET"
if [ -f $part/format ]; then
db_metaget partman-basicfilesystems/text/yes description
- printf "dont_format_swap\t%s\${!TAB}%s\n" "$description" "${RET}"
else
db_metaget partman-basicfilesystems/text/no description
- printf "format_swap\t%s\${!TAB}%s\n" "$description" "${RET}"
fi
+ printf "format_swap\t%s\${!TAB}%s\n" "$description" "${RET}"
fi
}
diff -ur a/active_partition/basicfilesystems/do_option b/active_partition/basicfilesystems/do_option
--- a/active_partition/basicfilesystems/do_option 2021-07-23 19:14:05.0 +0200
+++ b/active_partition/basicfilesystems/do_option 2021-09-26 01:08:15.655006505 +0200
@@ -8,8 +8,11 @@
cd $dev
-[ -f $part/method -a -f $part/acting_filesystem ] || exit 0
-filesystem=$(cat $part/acting_filesystem)
+[ -f $part/method ] || exit 0
+if [ "$(cat $part/method)" != swap ]; then
+ [ -f $part/acting_filesystem ] || exit 0
+ filesystem=$(cat $part/acting_filesystem)
+fi
do_fatmountpoint () {
local noninteractive tpl
@@ -94,14 +97,12 @@
select_mountoptions $dev $id
;;
format_swap)
- >$part/format
- update_partition $dev $id
- ;;
-dont_format_swap)
if [ -f $part/format ]; then
rm $part/format
- update_partition $dev $id
+ else
+ >$part/format
fi
+ update_partition $dev $id
;;
label)
label=''
diff -ur a/choose_method/swap/do_option b/choose_method/swap/do_option
--- a/choose_method/swap/do_option 2021-07-23 19:14:05.0 +0200
+++ b/choose_method/swap/do_option 2021-09-26 01:09:39.976109430 +0200
@@ -11,6 +11,17 @@
old_method=do_not_use
fi
+# keep settings if already selected as swap
+[ "$old_method" = swap ] && exit 0
+
echo swap >$dev/$id/method
->$dev/$id/format
+
+# format only if does not already contain swap
+if [ -f $dev/$id/detected_filesystem ] &&
+ [ "$(cat
Re: partman, growlight, discoverable partitions, and fun
Hello Nick! On 9/26/21 00:49, Nick Black wrote: > It supports MBR, GPT, and APM: > > https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123 > > (sorry for the gmail-style top posting; i can't find your mail in my mbox > for whatever reason) > > Any other partition schemes ought be trivial to add; they've not been added > yet > simply because I don't have means with which to test them. So, you are not using libparted then? > Looking at the "partition types" section of the Linux configuration, I see: > Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris > x86, Unixware, > Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68. > > Looking at the disk-label code from partman, I see: > gpt, msdos, amiga, atari, mac, sun > > So the only ones covered by partman and not covered by growlight would be: > amiga, atari, sun, > and mac (if mac is not the same as APM). I don't see any difficulty in > adding these four, so long > as there's someone with an Amiga or ATARI who'd be willing to test them > out. If there are no such > people, is it that important? Yes, it is important as we're supporting these architectures in Debian Ports and I invested quite some time to get Atari partition support added [1], for example. I think it makes little sense to not use libparted as it already supports all common and less common partition types and reimplementing everything that libparted makes little sense to me. Adrian > [1] > https://git.savannah.gnu.org/cgit/parted.git/commit/?id=9c266205416ec956d6205c828211480de3767d02 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
