IRC channel logs

<damo22>rrq you probably have a terminal where your pwd is in /mnt

<rrq>can I find out?

<rrq>I mean, to learn which command(s) would tell me

<rrq>but I rebooted already and tried again, and now it seems hurd doesn;t reload the partition table... I expanded wd1.img to 10G and have used fdisk to change the partition, but resize2fs still claims the partition is only 4G

<rrq>so fdisk -l says the partition is 10G but resize2fs says the 4G filesystem is as large as it can be

<rrq>perhaps I need to juggle the block translateor for the partition?

<rrq>hmm reboot got into a state where the wd1 disk was readonly... had to power toggle.. and then resize2fs did its thing

<damo22>its possible qemu restricts writes to block 0

<damo22>unless you set the correct parameters

<rrq>I have never had that issue(?) ... (used qemu a fair bit the last 10 years)

<damo22>check the log in the terminal where qemu is running

<damo22>or if you cant, shutdown the instance and then read the log in there

<rrq>well, block 0 certainly got written

<damo22>WARNING: Image format was not specified for '/dev/null' and probing guessed raw.

<damo22> Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.

<damo22> Specify the 'raw' format explicitly to remove the restrictions.

<damo22>that is an example of what it would print out if block 0 is restricted

<rrq>fair enough, but I do use explicit format=raw

<damo22>ok

<damo22>in that case it might have needed fsck

<damo22>and mounted r/o

<rrq>maybe.. I already power toggled, ran resize2fs (without prior fsck) and swapped to run with that image

<damo22>so is it fixed now?

<rrq>well, I'm past the issue; still would like to learn which utilities there are to provide relevant system information

<rrq>and what to do when fdisk and hurd disagree about partitioning

<damo22>1. fsck the partition you intend to resize

<rrq>yes I did that

<damo22>2. unmount it

<rrq>did that

<damo22>3. resize2fs

<damo22>actually you have to unmount before fsck

<rrq>did that, and resize2fs kept saying the filesystem of 4G was as large it could be although the partition was 10G

<damo22>hmm ok

<damo22>maybe it had cached the old partition table

<rrq>probably did that when I mount the partition at first, before unmounting, expanding it, fsck it and trying to resize it

<rrq>btw. where is the partition table(s) cached? gnumach, rumpdisk, ext2fs?

<damo22>not sure

<rrq>when I debootstrap to /X I get a /hurd/rumpdisk set up on /X/dev/rumpdisk and I have no way of getting rid of that

<rrq>even renaming the "node" to another pathname crashes the system

<damo22>this is a problem that pci cards are not exclusively accessible

<damo22>pci-arbiter needs to return EBUSY

<damo22>if a second process accesses the card

<damo22>in your case the AHCI controller is accessed twice

<rrq>right. but there is still just one rumpdisk process ... there's something I don't understand in the setup. I get two pathnames that show rumpdisk as their translator and I don't know any way to undo that.

<damo22>no there are two

<damo22>the boot process is not from /hurd

<damo22>its from a grub module

<rrq>hmm I'll redo; I think I only saw one in the pstree list

<rrq>(takes a couple of minutes)

<rrq>(I run with a "fusefile" overlay on the disk image so the original wd0 is preserved)

<damo22>thats interesting i have not tried that

<rrq>yes, the original disk image is preserved, and updates comes in the overlay, which I can also push into the disk after stopping, if all is good

<rrq>pstree | grep rump gives a single process... showtrans /dev/rumpdisk /X/dev/rumpdisk show both pathnames

<damo22>do they both say "rumpdisk" or does one say /hurd/rumpdisk

<rrq>both are /hurd/rumpdisk

<rrq>settrans -o gived: settrans: /dev/rumpdisk: Device or resource busy

<rrq>and settrans: /X/dev/rumpdisk: Device or resource busy

<damo22>yea so the passive translator entry in the xattr points to /hurd/rumpdisk, but the boot time process that is loaded as grub module inserts itself on /dev/rumpdisk

<damo22>you cant kill it

<damo22>it will stop running /

<rrq>yes; and I can't even rename /X/dev/rumpdisk :(

<damo22>what about settrans -fg /X/dev/rumpdisk

<rrq> /hurd/startup: Crashing system; essential task rumpdisk died

<rrq>... on its way donw now

<damo22>thats weird

<damo22>how did you install that translator

<damo22>on /X/dev/rumpdisk

<rrq>it happens with debootstrap

<rrq>probably with "hurd" package

<damo22>eh, does it symlink it?

<damo22>what is showtrans /X/dev/rumpdisk

<rrq>showtrans /dev/rumpdisk /X/dev/rumpdisk => /dev/rumpdisk: /hurd/rumpdisk <newline> /X/dev/rumpdisk: /hurd/rumpdisk

<rrq>I can debootstrap again and see what ls -l says

<rrq>debootstrap --no-check-gpg --arch=hurd-amd64 --extra-suites=unreleased sid /$X http://snapshot.debian.org/archive/debian-ports/20250807T000000Z

<rrq>crw-rw---- 1 root root 0, 0 Aug 7 23:02 /X/dev/rumpdisk

<rrq>hmm /X/servers include /X/servers/acpi and /X/servers/bus/pci as translators

<rrq>I can "go away" those, but still getting "startup: notifying random of reboot" on "-g" for /x/dev/rumpdisk

<rrq>but looks like it stys up regardless

<rrq>nope :(

<damo22>what package does debootstrap belong to

<rrq>same name package

<damo22>ok

<damo22>showtrans /X/dev

<damo22>any bets it /hurd/firmlink /dev

<damo22>so it reuses /dev

<rrq>showtrans /X/dev says nothing

<rrq>debootstrap should build a root filesystem at $X so wouldn't link out of it

<damo22> # firmlink $TARGET/{dev,servers} to the system ones.

<damo22> if [ "$TARGET" != / ]; then

<damo22> settrans -a "$TARGET/dev" /hurd/firmlink /dev

<damo22>yes during the bootstrap it firmlinks /dev and /servers

<damo22>that is probably not ideal

<rrq>ok that does explain things, and yes: not ideal :)

<damo22>perhaps you can try creating a subhurd

<damo22>and debootstrap from inside the subhurd?

<rrq>interesting. is there some scripting for subhurd? ... and how do I remove /X/dev and /X/servers ?

<damo22>or maybe just edit the debootstrap "functions"

<damo22>and stop it from firmlinking dev and servers

<rrq>ok; I'll try that first. Though how do I undo that firmlink?

<damo22>/usr/share/debootstrap/functions

<damo22>edit that

<damo22>try it

<rrq>yes.. is "firmlink" same as "hardlink" (in linux)?

<damo22>i think it is hurd specific

<damo22>it probably replaces the underlying port with the one already running on the source node

<rrq>mmm also /proc

<damo22>you probably want proc firmlinked so the target can find a proc list

<damo22>if it chroots in there

<rrq>it does, and failed

<rrq>I restore /proc

<rrq>still how do I undo it?

<damo22>undo what?

<rrq>firmlink

<damo22>probably settrans -fg /path/to/firmlink/node

<rrq>and it doesn't show up on showtrans ... so need to guess(?)

<damo22>no if it doesnt show up its already removed

<damo22>I: Base system installed successfully.

<rrq>hmm chroot fails still

<damo22>i modified functions to remove the firmlink from /dev and /servers and debootstrap succeeded

<rrq>actually I don't mind firmlink ... now that I know about it :) ...

<rrq>sounds better yes

<damo22>once you debootstrap, you can chroot into the folder

<damo22>but it launches a second rumpdisk and tries to access the controller again

<damo22>but only if you exit the chroot and try to cd X/dev

<damo22>with the 2 firmlink commands gone, i think it behaves more as expected

<rrq>settrans -fg doesn;t seem to do it

<damo22>did you get a working debootstrap?

<damo22>ie, does that command succeed?

<rrq>yes; ends with a spurious "worning" that there's nothing more to install

<damo22>i didnt get that

<rrq>I undid my editing

<rrq>and tried using settrans -g in the on_exit function (where it unmounts)

<damo22>no need to touch that

<damo22> hurd*)

<damo22> # Use the setup-translators of the hurd package

<damo22> in_target /usr/lib/hurd/setup-translators -k

<damo22> # firmlink $TARGET/{dev,servers} to the system ones.

<damo22> #if [ "$TARGET" != / ]; then

<damo22> # settrans -a "$TARGET/dev" /hurd/firmlink /dev

<damo22> # settrans -a "$TARGET/servers" /hurd/firmlink /servers

<damo22> #fi

<damo22>just comment out those four lines and run a new bootstrap

<rrq>hmm worked for unfirming /X/proc but not unfirming /X/dev or /X/servers

<rrq>I tried that way and that failed. so I undid all that, and then was trying to manually unfirm after it succeeded

<rrq>and can't :(

<damo22>no

<damo22>i just commented out those 4 lines above and debootstrap works from hurd-i386 -> hurd-i386

<rrq>hmm for me it failed on chroot

<rrq>hurd-amd64

<damo22>which chroot

<rrq>debootstrap's chroot

<damo22>what is the error

<rrq>ok I'll redo editing and try... a sec

<damo22>actually, the fact you cant remove translator /X/dev/rumpdisk is expected, that is resolving via firmlink from /X/dev -> /dev

<rrq>(lsow network now)

<damo22>its the same as trying to remove translator on /dev/rumpdisk

<rrq>yes, but I hope to be able to unfirm /X/dev

<damo22>you dont need to unfirmlink that if you comment out the firmlink command in the first place

<damo22>it sets up new translators one line earlier

<damo22>what are you trying to achieve?

<rrq>well I simply wanted to remove the /X directory tree after some failed debootstrap

<rrq>ok... with those lines commented out, I can unfirmlink /X/proc .. and could remove /X after -g for anything that showtrans found

<rrq>I'll try the same without that patch, and manual un-firmlink of /X/proc /X/dev and /X/servers

<damo22>showtrans only shows the passive xattr translator on there doesnt it?

<damo22>yeah

<damo22>maybe the debootstrap is missing the settrans -fg /X/dev and /X/servers ?

<rrq>ok. without patch, I can manually run settrans -fg on /X/proc /X/dev and /X/servers, and then a traversal that removes translators, files and directories seems to work

<rrq>there's no indication that the manual -fg works for /X/dev and /X/servers while /X/proc changes from having content to not having content

<rrq>but once I know about the firmlinks I can deal with them. (I guess one can check the inodes to sort out linking)

<rrq>e.g when I unfirmlin /X/dev then /X/dev/rumpdisk remain as such, both pathname and translator, but "settrans -g /X/dev/rumpdisk" doesn't crash the system

<rrq>yes, "ls -id /X/dev /dev" tells if they are linked or not

<damo22>i think that is expected behaviour

<damo22>but debootstrap might be missing the unfirmlink on /X/dev and /X/servers ?

<rrq>yes, that's missing. umounts are done on exit but nothing special for "hurd*"

<damo22>patch welcome

<rrq>and the confusing thing is that /X/dev/* shows the same whether or not /X/dev is linked

<damo22>no its expected, because the setup-translators is run on /X/dev

<damo22>but the paths are only applicable from inside a chroot

<damo22>youre not supposed to activate the /X/dev translators from outside the chroot

<damo22>otherwise it launches new processes for that

<damo22>translator entries are relative to /

<rrq>i is confused that the content of /X/dev without linking can be set up while it's linked

<damo22>the entries are created on the /X/dev contents before it is firmlinked

<rrq>the linking happens before anything else

<damo22>no, look at functions:

<damo22> hurd*)

<damo22> # Use the setup-translators of the hurd package

<damo22> in_target /usr/lib/hurd/setup-translators -k

<damo22> # firmlink $TARGET/{dev,servers} to the system ones.

<damo22>first it creates the new entries, then it firmlinks {dev,servers}

<damo22>this is so that the entries are ready for a new system, but then to fool the bootstrap it overlays the firmlinked ones

<rrq>right. yes it's in the second stage install

<rrq>clearly I haven't deep studied debootstrap :)

<damo22>i havent either

<damo22>{dev,servers} might not need to be firmlinked at all: if you chroot into TARGET it will launch new translators when you access things as required?

<rrq>worth a try

<rrq>yes it was happy with those 2 settrans commented out

<rrq>and the result /X/dev is not firmlinked with /dev

<rrq>when removing all I still get: settrans: /X/dev/console: Device or resource busy, though that's harmless

<rrq>I guess it shows that console has tied up with the serial line, which I'm using for my shell

<rrq>i.e. actual devices are shared

<rrq>many thanks for your advice, time and effort! I wish you a very enjoyable rest of the year, and onwards.

<damo22>you too

<youpi>sneek: later tell azert I don't see how this plan helps with the drm api. privileged translators can already use vm_read/write to manage the pointers passed by the drm api

<sneek>Got it.

<youpi>rrq: in the rumpdisk case, it's the storeio trnaslators sitting on /dev/wd*s* that would cache the partition table, though I'm surprised that they would

<youpi>damo22: if you kill a translator from the boot chain, startup will indeed crash ; you can't kill them

<youpi>one shouldn't have a reason to do it anyway

<youpi>since one needs a disk driver for the / filesystem anyway

<damo22>youpi: the point of all this discussion was that if you debootstrap from hurd -> hurd and then attempt to remove the directory, it fails

<damo22>because the firmlinked TARGET/{servers,dev} is still firmlinked i think

<damo22>causes haywire when it tries to remove those directories recursively from TARGET

<damo22>the question is whether TARGET/{dev,servers} needs to be firmlinked at all, or if it just needs settrans -fg TARGET/{dev,servers} at the end of the debootstrap

<youpi>the base question is whether the chroot is to be used as such now (and thus the firmlinks are needed to avoid starting newer translators), or later as self-system (in which case the firmlinks are useless)

<youpi>you get the same on linux with the bind mounts

<youpi>we should probably follow the same way

<damo22>ok

<youpi>yes, we need the firmlinks during the bootstrap, otherwise various package installations will fail because it starts new translators from /dev

<youpi>and they won't have network access through /servers (or start a new tcp/ip stack...)

<damo22> unfirmlink_on_exit /dev

<damo22> unfirmlink_on_exit /servers

<damo22>should i add this?

<youpi>probably something like this, yes

<youpi>also /proc

<youpi>though it'd probably just follow the linux/bsd codepaths

<youpi>which would say unmount

<youpi>unfirmlink is just like that unmount, we can merge these notions

<youpi>the only difference then is that hurd doesn't have /sys but it has /servers

<damo22>do i need to special case hurd, or can i call umount

<damo22>i need to use settrans -fg right?

<youpi>I mean just using umount_on_exit like the others

<youpi>-fga

<youpi>normally you don't have a passive translator, and you just want the active one to go

<youpi>possibly the umount command could even work

<youpi>since it's really doing that (though without the -f, which normally shouldn't be needed)

<damo22>hmm umount a firmlink works

<damo22>youpi: i have sent this MR upstream https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/147

<youpi>thanks!

<azert>hello

<sneek>azert, you have 1 message!

<sneek>azert, youpi says: I don't see how this plan helps with the drm api. privileged translators can already use vm_read/write to manage the pointers passed by the drm api

<damo22>merry xmas

IRC channel logs

2025-12-26.log