Bug#984816:
Tags 984816 + fixed-upstream
Thanks
The attached patch is what upstream applied. (But didn't release yet)
Author: Jordi Pujol Palomer
Date: Fri, 19 Mar 2021 09:20:12 +0100
busybox:
- klibc-utils/resume.c
hibernate-resume from swap file.
- write offset in /sys/power/resume_offset according to the
kernel's document uswsusp.txt
- Doing this the kernel will hibernate and resume successfully from
a swap file.
- Stop writing offset to /sys/power/resume, as this is not a parameter
the kernel takes from this input. (Change added by Sven Mueller)
Signed-off-by: Sven Mueller
--- busybox_1.30.1/klibc-utils/resume.c
+++ busybox_1.30.1-new/klibc-utils/resume.c
@@ -105,6 +105,13 @@
}
ofs = (argv[1] ? xstrtoull(argv[1], 0) : 0);
+ if (ofs != 0ULL &&
+ (fd = xopen("/sys/power/resume_offset", O_WRONLY)) != -1) {
+ s = xasprintf("%llu", ofs);
+ xwrite_str(fd, s);
+ close(fd);
+ }
+
fd = xopen("/sys/power/resume", O_WRONLY);
s = xasprintf("%u:%u:%llu", major(resume_device), minor(resume_device), ofs);
--- klibc-utils/resume.c 2021-03-19 09:18:13.302296333 +0100
+++ klibc-utils-new/resume.c 2021-03-19 09:18:57.221518768 +0100
@@ -105,8 +105,15 @@
}
ofs = (argv[1] ? xstrtoull(argv[1], 0) : 0);
+ if (ofs != 0ULL &&
+ (fd = xopen("/sys/power/resume_offset", O_WRONLY)) != -1) {
+ s = xasprintf("%llu", ofs);
+ xwrite_str(fd, s);
+ close(fd);
+ }
+
fd = xopen("/sys/power/resume", O_WRONLY);
- s = xasprintf("%u:%u:%llu", major(resume_device), minor(resume_device), ofs);
+ s = xasprintf("%u:%u", major(resume_device), minor(resume_device));
xwrite_str(fd, s);
/* if write() returns, resume did not succeed */
Bug#984816:
Tags 984816 + patch upstream Severity 984816 important This is https://bugs.busybox.net/show_bug.cgi?id=12006 - which also has a patch which wasn't adopted yet (but is straight from klibc-utils, so really should get adopted). Setting severity to important, as this makes hibernation to a swapfile (well, resuming from it) impossible with the default initrd setup, while the bug should have been fixed (upstream) years ago Cheers, Sven
Bug#984816: busybox resume fails to resume with swap file after hibernation
Package: busybox-static Version: 1:1.30.1-6 Hi. I wasn't able to figure out all the details yet and likely won't get to that in the next few weeks. However, I tried getting hibernation to work on a machine with only a swap file. This failed miserably (machine appeared to hibernate properly, but on reboot, the script in the initrd (local-premount/resume, from initramfs-tools) did call /usr/bin/resume properly (I added some echo/sleep commands to see what happens), but that just terminated apparently, without any error message or similar. Reproduction (on ext4, btrfs needs more involved procedure for offset): 1) create a sufficiently large file /swap 2) mkswap /swap 3) Add swap to /etc/fstab 4) Figure out parameters for resume/resume_offset, /sys/power/resume_offset and /sys/power/resume resume=$(findmnt -no SOURCE -T /swap) findmnt -no MAJ:MIN -T /swap > /sys/power/resume resume_offset=$(debugfs -R 'bmap /swap 0' $resume 2>/dev/null) cat > /etc/initramfs-tools/conf.d/resume < /sys/power/resume_offset (Note the different capitalization for conf.d/resume - it is needed this way) Run 'update-initramfs -k all -u' Now you should be ready to hibernate (NOTE: Unless the bug is fixed or you configured initramfs-tools to _not_ use busybox, this will potentially lead to data loss, close all programs) echo shutdown > /sys/power/disk echo disk > /sys/power/state your system should now suspend to disk and power off. On power-on, the expected state would be that the machine resumes. The actual state is that the machine does a fresh boot (after running /usr/bin/resume $resume $resume_offset though). Cross-check: Modify /usr/share/initramfstools/hooks/klibc-utils by adding: rm "$DESTDIR/bin/resume" cp -pL /usr/lib/klibc/bin/resume "$DESTDIR/bin/resume" Re-run the steps from "resume=" above. The system properly resumes from hibernation. I know that the "resume" tool in busybox originates from the code in klibc-utils, but right now, the one in busybox doesn't work in this scenario while the one from klibc-utils does. Cheers, Sven
Bug#971700: debootstrap: Please add option to get full log on stderr
Package: debootstrap Version: 1.0.123 Tags: patch Attached is a minimalistic patch to implement what I would need for better logging when automatically creating chroot environments. It preserves the behavior of other output options to have the I:/W:/etc. info on stdout and puts everything else on stderr. I only did relatively limited testing, but this seems to achieve exactly what I want. A better solution would be to _also_ log everything to debootstrap.log, I think, but I found no reasonable way to do that. Regards, Sven Description: Allow stderr to be passed to the caller This change allows the caller of debootstrap to request that stderr is passed to it instead of being swallowed into debootstrap.log Author: Sven Mueller Forwarded: no Last-Update: 2020-10-02 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ Index: debootstrap-1.0.123/debootstrap === --- debootstrap-1.0.123.orig/debootstrap +++ debootstrap-1.0.123/debootstrap @@ -42,6 +42,7 @@ UNPACK_TARBALL="" ADDITIONAL="" EXCLUDE="" VERBOSE="" +FULL_OUTPUT="" CERTIFICATE="" CHECKCERTIF="" PRIVATEKEY="" @@ -91,6 +92,8 @@ usage() --help display this help and exit --version display version information and exit --verbose don't turn off the output of wget + --full-output show full process output on stderr, I:/W: info + on stdout. --download-onlydownload packages, but don't perform installation --print-debs print the packages to be installed, and exit @@ -310,6 +313,11 @@ if [ $# != 0 ] ; then VERBOSE=true export VERBOSE shift 1 +;; +--full-output) +FULL_OUTPUT="yes" +export FULL_OUTPUT +shift 1 ;; --extra-suites|--extra-suites=?*) if [ "$1" = "--extra-suites" ] && [ -n "$2" ]; then @@ -618,6 +626,11 @@ elif am_doing_phase printdebs; then #stderr: I:/W:/etc information #stdout: debs needed exec 4>&2 +elif [ "$FULL_OUTPUT" = yes ]; then + # stdout: I:/W:/etc information + # stderr: full log of debootstrap run (stdout/stderr combined) + exec 4>&1 + exec >&2 else #stderr: used in exceptional circumstances only #stdout: I:/W:/etc information
Bug#904184: Acknowledgement (Partman(-lvm) claims all disk when it shouldn't)
I also realize that this seems to be a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515607 (from early 2009) Am So., 22. Juli 2018 um 05:23 Uhr schrieb Sven Mueller < sven.muelle...@gmail.com>: > I created a pull request on salsa for this: > https://salsa.debian.org/installer-team/partman-auto-lvm/merge_requests/1 > Am So., 22. Juli 2018 um 11:01 Uhr schrieb Sven Mueller > : > > > > As far as the feature request goes, the submits I found in Ubuntu to > > implement guided_size (i.e. limiting the space in the VG that gets > > used) were: > > > https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/partman-auto-lvm/trusty/revision/19 > > > https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/partman-auto-lvm/trusty/revision/21 > > > > However, I do consider it a bug that (a) maximum size is exceeded and > > (b) the last partition/LV gets all remaining space, irrespective of > > priorities. >
Bug#904184: Acknowledgement (Partman(-lvm) claims all disk when it shouldn't)
I created a pull request on salsa for this: https://salsa.debian.org/installer-team/partman-auto-lvm/merge_requests/1 Am So., 22. Juli 2018 um 11:01 Uhr schrieb Sven Mueller : > > As far as the feature request goes, the submits I found in Ubuntu to > implement guided_size (i.e. limiting the space in the VG that gets > used) were: > https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/partman-auto-lvm/trusty/revision/19 > https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/partman-auto-lvm/trusty/revision/21 > > However, I do consider it a bug that (a) maximum size is exceeded and > (b) the last partition/LV gets all remaining space, irrespective of > priorities.
Bug#904184: Acknowledgement (Partman(-lvm) claims all disk when it shouldn't)
As far as the feature request goes, the submits I found in Ubuntu to implement guided_size (i.e. limiting the space in the VG that gets used) were: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/partman-auto-lvm/trusty/revision/19 https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/partman-auto-lvm/trusty/revision/21 However, I do consider it a bug that (a) maximum size is exceeded and (b) the last partition/LV gets all remaining space, irrespective of priorities.
Bug#904184: Partman(-lvm) claims all disk when it shouldn't
Package: debian-installer
Severity: normal
Hi.
I have the following in a preseed file:
(stripped out various confirmation things that are unrelated to paritioning)
d-i partman-auto/method string lvm
# Oh well, the following doesn't exist in Debian and is left
# over from the time the preseed was used for Ubuntu.
d-i partman-auto-lvm/guided_size string 43G
d-i partman-auto/expert_recipe string \
boot-root :: \
1 1 1 free \
$iflabel{ gpt } \
$reusemethod{ } \
method{ biosgrub }\
. \
2048 2048 2048 fat32\
$iflabel{ gpt } \
$reusemethod{ } \
method{ efi } \
format{ } \
. \
2048 2048 2048 ext2 \
$defaultignore{ } \
$primary{ } \
$bootable{ } \
method{ format } \
format{ } \
use_filesystem{ } \
filesystem{ ext2 }\
mountpoint{ /boot } \
. \
26624 26625 41984 $default_filesystem \
$lvmok{ } \
method{ format } \
format{ } \
use_filesystem{ } \
$default_filesystem{ }\
mountpoint{ / } \
. \
2048 2048 2048 linux-swap \
$lvmok{ } \
method{ swap }\
format{ } \
.
As far as the documentation goes, I would expect that on a machine
with ~560GB of disk (array) that all of the following should be true:
- Disk completely consumed by partitions (yep)
- A single large physical volume for LVM (yep)
- /boot partition outside LVM (yep)
- small free space at start and a GPT/efi partition (yep)
- root (/) partition to have at most 41GB (yep)
- swap to have at most 2GB (NO)
- root partition to be much larger than swap (NO)
- LVs in the VG to use no more than 43G (no, but that was an
Ubuntu-only option anyhow)
So despite the max partition size of root and swap, all of the LVM is
used. And to the vast majority by swap (~516G). Which is unexpected:
a) Why is swap larger than root, despite smaller minimal and smaller priority?
b) Why is all of the VG used up, even though the preseed values say
that only ~43GB should be used at most (41GB for root and 2GB for
swap)?
So, this is essentially a bug report that maximum sizes are not
adhered to and a weak feature request to support the guided_size
option Ubuntu has.
Kind regards,
Sven
Bug#489006: have /boot on md0 (dm-raid1), but install grub to MBRs of both disks?
Well, Subject basically says what I try: I want to have /boot on /dev/md0 (raid1, sda1+sdb1) / on /dev/md1 (also raid1, sda5/sdb5 swap, non-critical data on lvm on /dev/md2 (raid0, sda6/sdb6) The Debian installer easily lets me create such a layout, even using preseeding. However, grub (both legacy and grub2) fail to generate a device mapping for md0, thus being unable to install grub. In my opinion such a partition layout should either be impossible to create with d-i (or at least generate a warning) or grub-pc should support this setup. Especially since this sort of partitioning is an example in the partman-raid (or was it partman-lvm?) documentation. Not exactly the way I described it, but with /root on lvm on raid. Regards, Sven -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bc1a07e.4000...@incase.de
d-i beta 3: selecting multple partitions for crypto use, then configure encrypted partitions only configures first partition
hi. I'm unsure wether this was already reported earlier or not, so I'm not posting this as a bug report. I installed two systems with three encrypted partitions each, and while partitioning, I first set each encrypted partition to the appropriate use (for encryption?). I then went to the configure encrypted partitions (or whatever it's exact text is), which properly asked for confirmation and password(s), but it only actually did that for the first partition I marked as for encryption. The only way I got around this was to mark 1 partition as for encryption, select configure par..., fill out the following questions appropriately, mark the next partition as for enc..., configure part..., etc. I certainly hope this description is enough for you to reproduce the bug and fix it, if it wasn't yet fixed. Regards, Sven PS: Please keep me CCed, I'm subscribed but rarely have enough time to actually check the list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
D-I beta 3 can't find CD drive on Dell XPS M1710
Hi. Trying to install with D-I beta 3 (i386, DVD binary-1), the installation fails due to the CD drive not being detected. This seems to be a PIIX/sata problem with the SATA driver blocking the PATA ports without supporting them again. Find attached an lspci -v and dmesg log. If you need any other logs, please let me know, preferrably also by CCing me. I'm subscribed, but sometimes don't have enough spare time to check the list. regards, Sven PS: The selection screen for loading individual modules (IIRC) says ALT-F2 would lead to a prompt and ALT-F1 would lead back to the dialogue even in graphical installs where it is CTRL-ALT-F2 and (CTRL-)ALT-F7 (or F5?) respectively. isapnp: No Plug Play device found PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled RAMDISK driver initialized: 16 RAM disks of 22204K size 1024 blocksize EISA: Probing bus 0 at eisa.0 EISA: Cannot allocate resource for mainboard Cannot allocate resource for EISA slot 1 EISA: Detected 0 cards. NET: Registered protocol family 2 input: AT Translated Set 2 keyboard as /class/input/input0 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 7, 524288 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 8 NET: Registered protocol family 20 Using IPI Shortcut mode ACPI wakeup devices: LID PBTN PCI0 USB0 USB1 USB2 USB3 EHCI AZAL PCIE RP01 RP02 NIC RP04 RP05 RP06 ACPI: (supports S0 S3 S4 S5) Freeing unused kernel memory: 228k freed ieee1394: Initialized config rom entry `ip1394' ACPI: PCI Interrupt :03:01.0[A] - GSI 19 (level, low) - IRQ 193 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[193] MMIO=[dcbff800-dcbf] Max Packet=[2048] IR/IT contexts=[4/4] SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub USB Universal Host Controller Interface driver v2.3 ACPI: PCI Interrupt :00:1d.0[A] - GSI 20 (level, low) - IRQ 58 PCI: Setting latency timer of device :00:1d.0 to 64 uhci_hcd :00:1d.0: UHCI Host Controller uhci_hcd :00:1d.0: new USB bus registered, assigned bus number 1 uhci_hcd :00:1d.0: irq 58, io base 0xbf80 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected libata version 1.20 loaded. ACPI: PCI Interrupt :00:1d.1[B] - GSI 21 (level, low) - IRQ 66 PCI: Setting latency timer of device :00:1d.1 to 64 uhci_hcd :00:1d.1: UHCI Host Controller uhci_hcd :00:1d.1: new USB bus registered, assigned bus number 2 uhci_hcd :00:1d.1: irq 66, io base 0xbf60 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ACPI: PCI Interrupt :00:1d.2[C] - GSI 22 (level, low) - IRQ 74 PCI: Setting latency timer of device :00:1d.2 to 64 uhci_hcd :00:1d.2: UHCI Host Controller uhci_hcd :00:1d.2: new USB bus registered, assigned bus number 3 uhci_hcd :00:1d.2: irq 74, io base 0xbf40 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ACPI: PCI Interrupt :00:1d.3[D] - GSI 23 (level, low) - IRQ 82 PCI: Setting latency timer of device :00:1d.3 to 64 uhci_hcd :00:1d.3: UHCI Host Controller uhci_hcd :00:1d.3: new USB bus registered, assigned bus number 4 uhci_hcd :00:1d.3: irq 82, io base 0xbf20 usb usb4: configuration #1 chosen from 1 choice hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected usb 1-1: new full speed USB device using uhci_hcd and address 2 ata_piix :00:1f.2: version 1.05 ACPI: PCI Interrupt :00:1f.2[B] - GSI 17 (level, low) - IRQ 177 PCI: Setting latency timer of device :00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xBFA0 irq 14 usb 1-1: configuration #1 chosen from 1 choice hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected Synaptics Touchpad, model: 1, fw: 6.2, id: 0xfa0b1, caps: 0xa04713/0x20 input: SynPS/2 Synaptics TouchPad as /class/input/input1 ata1: dev 0 cfg 49:2f00 82:746b 83:7f09 84:6123 85:7469 86:3e09 87:6123 88:207f ata1: dev 0 ATA-7, max UDMA/133, 231496650 sectors: LBA48 ata1: dev 0 configured for UDMA/133 scsi0 : ata_piix Vendor: ATA Model: WDC WD1200BEVS-7 Rev: 02.0 Type: Direct-Access ANSI SCSI revision: 05 ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xBFA8 irq 15 usb 1-1.2: new full speed USB device using uhci_hcd and address 3 ata2: dev 0 cfg 49:0b00 82:0210 83:5000 84:4000 85:0210 86:1000 87:4000 88:0407 ata2: dev 0 ATAPI, max UDMA/33 usb 1-1.2: configuration #1 chosen from 1 choice ata2: dev 0
Re: Debian Installer etch beta 3 released
Frans Pop wrote: The Debian Installer team is proud to announce the third beta release of the installer for Debian GNU/Linux Etch. For what it's worth, I created a .torrent file for the first i386 DVD of the set. If anyone is interested, I'm currently seeding with two machines at a max total of 120kB/s but might increase or decrease that as needed. I intend to keep the seeds up for at least 1 week or until there are at least 3 other seeds. My reason for this: I expect that I'm not the only one who doesn't like jigdo much and hope that torrents would give the installer betas a wider audience (even if not much wider). The d-i beta 3 i386 torrent is available at: http://mail.incase.de/debian-incase/debian-testing-i386-binary-1.iso.torrent cu, sven signature.asc Description: OpenPGP digital signature
Re: Debian Installer etch beta 3 released
Joey Hess wrote: Sven Mueller wrote: My reason for this: I expect that I'm not the only one who doesn't like jigdo much and hope that torrents would give the installer betas a wider audience (even if not much wider). Official torrents are linked to from http://www.debian.org/devel/debian-installer/ True, but none are available for the DVD images. cu, sven signature.asc Description: OpenPGP digital signature
Re: The powerpc port should be removed from etch release candidates ...
Sven Luther wrote on 01/05/2006 08:21: On Mon, May 01, 2006 at 02:20:09AM +0200, Frans Pop wrote: The reason that I did not inform you was because things were already very heated at the moment and because you were at that time still very concerned about the welfare of your mother. I thought it was better not to add to that. And what have you gained ? What did you expect would happen once i noticed ? He thought he would gain not adding more pressure to you. He was wrong and he apologized for that. Stop picking on him, please. Apologizes accepted, but this is not enough. Either you accept the apology or you don't. There is no but. So, this is a first step, but i need more. I need : - the commit access being restored. I would second that request, if it was more humble. You don't need commit access restored, you just want it. So please be so kind to actually state the true thing. - an apology for the lack of decency this action shows. You already got that. The apology might have been weaker than you hoped, but nevertheless, you accepted it (you said: Apologizes accepted). - apologies for continual bashing would be nice, but more important you refraining from doing so in the future. When i post, avoid saying things like 'its the kernels fault' or otherwise indirectly pointing the finger back to me. Stop being too sensitive. If someone says its the kernels fault, why do you think they are pointing at you? Did you write the whole kernel? And it would also be nice if _you_ stopped pointing at various people (and Frans in particular). On my side, i will follow my one-post-per-thread policy, which i have mostly been doing since the last two month, with only two backslides, and those two backslides where always triggered by you being bashful, so i have good faith that if you change a bit your behaviour, and my personal distress situation calmiong down, that this will no more be a problem in the future. If you actually both stop letting of your frustration/anger on one another, but instead talked to each other like most educated people would do, there soon wouldn't be much anger left between the two of you. @d-i people: When Sven annoys you, try ignoring whatever he does at that moment (i.e. that mail, that IRC message, that commit-log). Calm down and come back later if there is a technical issue involved that needs solving. Sven is over-sensitive and attacks when he deems he is being attacked himself. Nevertheless, he did a lot of valuable work on the powerpc port and is willing to continue doing so. While making Colin the lead powerpc porter (at least regarding the d-i team) does make sense, but that doesn't necessarily mean that Sven's contributions aren't needed anymore. @Sven: As a result of this thread, I read a lot of mails in various threads you were involved in. While I somewhat agree that people where picking on you, it has never been as bad as you try to make it look like. You are _way_ over-sensitive and see every hint at a technical problem as a personal attack (see the it's the kernel's fault comment above). People are pointing out that some particular program (or other part of the system) is accountable for a particular problem is _not_ a personal attack on you. But you have to live by the fact that i also have an opinion, and that i will post things in the future which may annoy you, and it is not correct to expect me not to do such posts. If you knowingly post things in a way that annoys others, you pretty much make sure to gather opponents rather than friends. Your posts mostly sound far more aggressive than they would need to. Try to focus on technical things, try to avoid personal issues. So, the ball is in your camp, can you now stop this childish rejection of me, come to your sense, As much as one _might_ see the removal of commit rights as a childish action, your reaction to it isn't any less childish. and that we continue working again ? I may have hit your feelings, and said things that you took badly, and for this i apologize, but you (and others) have done no less. Wise words. If both of you (i.e. primarily Frans and Sven, but also the other people involved, such as the rest of the d-i team) calm down and try to focus on fixing technical things while avoiding personal stuff, you might be able to work together again in the near future. I sure hope so, since that would mean that d-i and especially the PowerPC port would improve more than it would without you cooperating. regards, sven PS: Sven: Frans was right in one aspect: You should have _tried_ to contact Colin before fixing whatever breakage you wanted to fix with your commit, since now Colin is the lead PowerPC porter (for d-i). At least you should have send a mail along the lines of: I noticed this issue, I'm working on a fix. PPS: I intentionally CCed this mail to Sven in the hopes of making sure he is aware of this mail. I apologize if this is unwanted. I
