IRC channel logs


back to list of logs

<youpi>damo22: it seems like rumpdisk is not syncing properly on shutdown
<youpi>the daily installation image leaves the filesystem seemingly unmounted
<youpi>even if we do have this in the log:
<youpi>(well yes the "busy" part is problematic, but the shutdown should be enough)
<youpi>yes, we get the same with sd0s1: so the problem would rather be abount properly syncing the disks
<damo22>thats strange
<damo22>maybe there are nested mounts in /target?
<damo22>and it fails to unmount target first
<damo22>is there a way to umount recursively?
<youpi>I'm not really surprised by the "busy" thing
<youpi>there can be some mounts lying out, like /proc, /run, etc.
<youpi>and anyway it shouldn't be a problem provided that the shutdown requested by startup is properly supported
<youpi>yes, I mean inside the chroot
<damo22>it appears from that log that /dev/sd0s1 is notified of shutdown but does not get unmounted?
<youpi>that's the "normal" way on the hurd
<youpi>filesystems don't get actually unmounted, they are just made read-only
<damo22>but then all mounts must be altered
<youpi>which is enough to make them clean ( just not enough to avoid the zero dtime thingy)
<damo22>ive seen "mount" return nothing
<damo22>only the mounts appear in /etc/mtab
<youpi>"all mounts must be alterned", what do you mean?
<youpi>startup doesn't care about /etc/mtab
<damo22>i mean, all mounts that are actively mounted must be made read only
<youpi>it just notifies the translators that requested so
<damo22>at shutdown
<youpi>ideally yes
<damo22>are they?
<youpi>but again, here it doesn't matter, it's not the concern
<youpi>when using an init system they normally are yes
<damo22>which part is misbehaving?
<youpi>because init kills remaining processes
<youpi>but in d-i we don't have such nice init
<youpi>but again we don't have to care normally
<youpi>because startup does notify translators
<youpi>and see the pastebin both ext2fs and rumpdisk do get notified
<youpi>most probably ext2fs behave as it should like in the non-rump case, there is no reason why it shouldn't
<youpi>and most probably it's rumpdisk which misses making the last-minute writes
<youpi>notably telling the disk to flush its fbuffers
<damo22>what about ext2fs for the rumpdisk
<youpi>what do you mean by "ext2fs for the rumpdisk"?
<damo22>there is a second ext2fs process
<youpi>which one do you men?
<youpi>see the pastebin I have made
<youpi>theres is the rd0 and the wd0s1
<youpi>both get notified
<youpi>in the proper order
<youpi>really, I don't think the problem is there
<youpi>since it behaves just like in the non-rump case
<damo22>yes youre right sorry
<damo22>i thought rumpdisk blocks on rump_sys_reboot()
<damo22>i guess we need to know if that is called
<youpi>but does that get called at all?
<youpi>iirc the reference counting for devices is quite often missing deallocs
<youpi>but probably the sync method should be fine enough
<youpi>not sure if sys_sync() does flush disk buffers for instance
<damo22>ive seen it being called at least sometimes
<damo22>when i had debug on
<youpi>testing all of this should be quite simple by building a rumpdisk with prints etc.
<youpi>and putting that inside the initrd (to save having to rebuild the whole image)
<damo22>is there a link to the current image i can test later?
<youpi>it's the daily image, in the topic
<damo22>how do you get the syslog before it reboots the end of the installer?
<youpi>by using the serial console
<youpi>passing console=com0 to gnumach
<youpi>and -serial stdio
<damo22>ok will play with that
***FragByte_ is now known as FragByte
<damo22>youpi: the link in the topic points here, but it does not look up to date
<damo22>i suppose you mean this
<youpi>damo22: ah I thought the daily was linked from the topic, sorry yes it's the daily on people
<damo22>youpi: how do i rebuild a bootable iso, is there some boot sector that needs to be attached with xorriso?
<youpi>you can use grub-mkrescue
<youpi>or you can boot the kernel+initrd directly with qemu
<damo22>grub-mkrescue is cool!
<curiosa>Hello, after upgrading the grub package in debian I get this error: # grub-install /dev/wd0
<curiosa>Installing for i386-pc platform.
<curiosa>grub-install: error: cannot find a GRUB drive for part:2:device:wd0.  Check your
<curiosa>yesterday was working fine
<youpi>which version do you have?
<youpi>("latest" is never precise enough)
<curiosa>grub-install (GRUB) 2.06-2+hurd.4
<youpi>usually rather use dpkg -l to know
<youpi>but apparently the grub maintainer included the exact debian version so ok
<youpi>well I don't know, the +hurd.4 version is working fine here
<damo22>i looked in the initrd.gz, there is no rumpdisk*
<damo22>how is that possible?
<youpi>it's not
<youpi>which URL did you use exactly?
<curiosa>I think I know what went wrong over here
<youpi>damo22: that initrd has it, in /hurd
<curiosa>in apt upgrade: GRUB failed to install to the following devices: /dev/hd0
<curiosa>where the installer get that device?
<curiosa>I should figure it out
<youpi>it's in debconf
<youpi>use dpkg-reconfigure grub-pc to change it
<curiosa>that will not work any more
<youpi>ftr, I have added to some hints to rebuild an iso image, will show up soon
<curiosa>because: /usr/sbin/dpkg-reconfigure: grub-pc is broken or not fully installed
<curiosa>grep -R hd0 /etc/* doesn't return anything meaningfuyul
<youpi>it's in debconf
<youpi>not etc
<curiosa>where is debconf?
<youpi>find / -name \*debconf\*
<curiosa>am I supposed to change the source files of debconf directlt??
<youpi>dpkg-reconfigure grub-pc is that
<damo22>wow i downloaded the initrd.gz inside hurd and then found a different one on my linux system to insert the rumpdisk.... omg
<curiosa>youpi: I managed to change that using dpkg-reconfigure
<curiosa>GRUB failed to install to the following devices: /dev/wd0
<youpi>you can check with grub-probe which way it fails exactly
<curiosa>grub-probe: error: cannot find a GRUB drive for @/dev/disk:wd0.  Check your
<youpi>that version of grub is supposed to be removing that @/dev/disk:
<curiosa>maybe it didn't fully install yet
<curiosa>order of installation might be broken
<damo22> The system is going down NOW!
<damo22> startup: notifying rumpdisk of reboot...XXX device
<damo22> _sync called
<damo22> done
<damo22> startup: notifying ext2fs gunzip:device:rd0 of reboot...done
<damo22> Feb 24 09:57:51 kernel: start ext2fs: XXX device_sync called
<damo22>but "disabled" was enabled
<damo22>i think the kernel was driving sata disk
<youpi>maybe also check that wd_flushcache does get called
<damo22>rump_sys_sync did not get called, just the function did
<damo22>but it returned early
<youpi>yes, I just mean the next action after making the kernel not drive ide
<damo22>why does noide not work anymore?
<youpi>it does in my tests
<damo22>it still probes ahci
<youpi>you're probably not using the proper image
<youpi>when I try
<youpi>and add the noide option to the options
<damo22>multiboot /gnumach.gz noide
<youpi>is that gnumach.gz from the image?
<damo22>i better check
<damo22>-r-xr-xr-x. 1 root root 1402216 Feb 24 13:14 exec.static
<damo22>-r-xr-xr-x. 1 root root 2075908 Feb 24 13:14 ext2fs.static
<damo22>-r--r--r--. 1 root root 558158 Feb 24 13:14 gnumach.gz
<damo22>-r--r--r--. 1 root root 445 Feb 24 20:14 grub.cfg <--- mine
<damo22>-r--r--r--. 1 root root 18943336 Feb 24 20:49 initrd.gz <--- mine
<damo22>task loaded: ext2fs --multiboot-command-line=noide console=com0 --host-priv-port=1
<damo22>maybe it needs a space?
<youpi>ah, yes
<youpi>the strstr is lazy
<youpi>in my tests there are already some parameters
<damo22>startup: notifying rumpdisk of reboot...XXX device_sync called
<damo22>XXX Syncing...done
<damo22>startup: notifying random of reboot...done
<damo22>startup: notifying ext2fs gunzip:device:rd0 of reboot...ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: Assertion '!diskfs_readonly' failed.
<damo22>startup: rebooting Mach (flags 0)...
<damo22>rump_sys_sync was definitely called and returned
***skapata is now known as Guest4571
***skapate is now known as skapata