[00:50] <cagmz> is it safe to statically allocate 256k bytes in my kernel module?
[19:13] <cinch> where can i get a CK enabled kernel for 16.04?
[19:13] <cinch> with the BFQ scheduler
[19:16] <TJ-> anyone around? got a sysadmin 'on the line' with a server that is failing to install the kernel package for ubuntu-server 16.04, we're in the /target/ and have managed to narrow it down to a problem with the linux-image-4.4.0-21-generic postinst script
[19:17] <DJVG> Hi :-)
[19:19] <TJ-> DJVG: now we know we can manually cause the initrd.img to be generated, it makes it possible to remove it and rerun the postinst script with -x and try to capture the error. Let's wait 5 minutes see if apw or timg or someone is interested in this. If you want to set up the ssh shell in the meantime that'd be really useful
[19:20] <DJVG> TJ-: Do you prefer a shell inside or outside the chroot?
[19:20] <TJ-> DJVG: outside :)
[19:28] <cinch> TJ-, any idea what might cause the problem?
[19:28] <cinch> odd that a kernel fails to install
[19:29] <TJ-> cinch: yes, the postinst script is calling the initrd script with incorrect arguments. 
[19:30] <cinch> a-ha!
[19:33] <TJ-> DJVG: its 20:30 here and I need to go to dinner. I'll return in ~20 minutes if you want to wait around. If not, no worries, I can still write up a bug report although we won't have an identified cause
[19:34] <DJVG> TJ-: I've got the time, no worries!
[19:48] <DJVG> TJ-: Took me a while to put this machine in a different vlan and compile dropbear static but it's working now :)
[19:49] <DJVG> TJ-: You can ssh as root to 91.148.253.252 without a password (I know dangerous but it's a tmp solution) :-)
[19:49] <DJVG> And ofcourse I monitor haha
[19:50] <cinch> oh cool ill login ;)
[19:52] <DJVG> cinch: Seeing anything interesting? ;)
[19:52] <cinch> i see systemd and a debian installer ^.^
[19:54] <DJVG> cinch: Great! ;) Hopefully the kernel devs can figure out later why the installer does not pass the right parameters to update-initramfs
[19:54] <cinch> the kernel sources are unpacked in /usr/src
[19:59] <TJ-> I'm back. DJVG you could relay me through a shared tmux if you wanted :)
[20:01] <DJVG> TJ-: Meh, I know, but this way you can do whatever you want. This machine is not in production and has no data on it
[20:01] <DJVG> TJ-: So it's fine
[20:02] <DJVG> TJ-: I had to compile dropbear anyway
[20:02] <TJ-> DJVG: I was thinking more along the lines of 'more eyes' 
[20:02] <TJ-> I thought dropbear was in the repos :)
[20:02] <DJVG> TJ-: Maybe it is but I'm sure I had to change my PATH to get the libs etc...
[20:03] <DJVG> To be able to run it outside the chroot
[20:04] <TJ-> ahhh, yes it is DLed, I thought it was static. Must have been thinking about busybox for initrd
[20:04] <TJ-> Right, I'll connect now
[20:06] <DJVG> TJ-: 10-4
[20:06] <TJ-> ok, little problem... dropbear seems to be limiting what I can get. no "which" no "chroot" :D
[20:07] <TJ-> oh, PATH :)
[20:07] <DJVG> Yeah
[20:08] <TJ-> I'm in a chroot now, will mess with the installer postinst script now
[20:10] <DJVG> TJ-: Go ahead, she's all yours ;)
[20:11] <TJ-> interesting! since we generated a good initrd.img it won't fail
[20:12] <TJ-> So, some flag is expected to exist but doesn't on first install, breaks it
[20:12] <DJVG> TJ-: If you want I can re-run the install to the point it fails and give you access again
[20:13] <TJ-> DJVG: I'm just reading the postinst Perl script, see if I can spot anything obvious
[20:16] <cinch> reading perl 
[20:17] <DJVG> TJ-: Quite funny to see it fails in a virtualbox machine too with the same error
[20:17] <cinch> perl -> deobfuscator -> brain
[20:17] <TJ-> going to focus on the core error from the original syslog: "mkinitramfs: failed to determine device for /" 
[20:19] <DJVG> TJ-: I'm getting the idea that there's something wrong with the installer itself. Not sure though, I'm not really into the inner workings of the installer
[20:20] <TJ-> looking at /usr/share/initramfs-tools/hook-functions:386:          echo "mkinitramfs: failed to determine device for $dir" >&2
[20:22] <cinch> let's say i want to log each process that was started (with its command line parameters), how would i go about it
[20:23] <TJ-> damn! the UUIDs are different
[20:24] <TJ-> see http://paste.ubuntu.com/16481625/
[20:25] <DJVG> TJ-: That's interesting
[20:25] <TJ-> and the code in hook-functions:dep_add_modules_mount() relies on the /dev/disk/by-uuid/ symlinks 
[20:25] <TJ-> which explains why it failed with the error "failed to determine device for /"
[20:25] <cinch> why is the uuid different?
[20:26] <DJVG> TJ-: Yes, it was trying to use the old(?) UUID
[20:26] <DJVG> TJ-: That's quite weird
[20:26] <DJVG> TJ-: Wasn't it refreshed after a mkfs?
[20:28] <TJ-> DJVG: there were existing partitions on /dev/sda and you replaced them?
[20:28] <TJ-> DJVG: were they the same (3 parts, same size) ?
[20:28] <DJVG> TJ-: It might be possible yes, I can't be entirly sure because I tried to install it multiple times and it's possible I didn't re-init the part. table
[20:30] <TJ-> but whatever, if you repartitioned then partprobe should have been called, and that should have triggered udev to re-do the symlinks
[20:30] <TJ-> let me see if there's a hidden udev dlog file
[20:36] <TJ-> hmmm, nothing I can find, so that doesn't help. I wonder if there's some clue in syslog though
[20:38] <TJ-> when it booted: 17:32:31 kernel: [    2.576702]  sda: sda1 sda2 sda3
[20:39] <DJVG> TJ-: It's possible that I didn't remove the part. table and only assigned the right mountpoints + mkfs on thos part's
[20:39] <DJVG> parts*
[20:44] <TJ-> right, but if that's all you did then the UUIDs would be correct. This looks as if there were partitions on sda, udev creates the symlinks, the installer re-partitions and/or re-formats the file-systems in sda1 and sda2 but udev doesn't get informed and therefore the /dev/disk/by-uuid/ symlink names are not updated
[20:45] <TJ-> so, when allocating existing partitions/file-systems for mountpoints maybe if you set to 'format' it doesn't cause/trigger the symlinks to be updated
[20:45] <TJ-> that sounds like a scenario that could be reproduced easily, too
[20:46] <TJ-> I'll pull in the -server ISO and try it in a VM here
[20:47] <DJVG> TJ-: Yes, if you want me to do anything let me know. I might need to grab some sleep soon but I can keep this machine running if you want. Again, no important data on that thing
[20:47] <TJ-> the bit that has me stumped right now though, is why it now works since the UUIDs are the same
[20:47] <TJ-> DJVG: if you could keep it as-is that would be great, I can hopefully pull some more diagnostics off it into a bug report
[20:48] <DJVG> TJ-: I don't know how how the installer performs the kernel thing but I can suspect a change in behaviour if you want to run it inside or outside the chroot
[20:48] <TJ-> DJVG: and I'll try to reproduce here in a VM too, once its reproducable you can get on with completing the install on that machine :)
[20:49] <DJVG> TJ-: That's fine, I can keep it up as long as you want :)
[20:50] <TJ-> DJVG: let me open a bug report now and give you the ref. so you can check on progress if you need to go sleep
[20:50] <DJVG> TJ-: If I get disconnected from this you can alway reach me at djvg@djvg.net (pgp: 213FEC83)
[20:51] <DJVG> Sure
[20:53] <cinch> so why didnt initrd get its params
[20:53] <cinch> what was the issue, uuids not matching?
[20:57] <TJ-> bug 1582899
[21:01] <cinch> so the installer failed to detect new UUIDs
[21:02] <TJ-> well that's udev's job, when a device is added/changed
[21:03] <cinch> kinda obvious bug... could have been easily avoided
[21:03] <TJ-> but the reformat didn't repartition so presumably it needs triggering manually to update the UUID link names
[21:03] <TJ-> Still got to be able to reproduce it to be sure this is the cause, it's only a hypothesis for now
[21:04] <TJ-> DJVG: I've copied off syslog and partman and attached them to the bug report. I'll look for other useful logs that might help
[21:05] <DJVG> TJ-: Sure, no problem. I'm going to get some rest now. Thanks for all your help and I've subscribed to the bug to keep me posted. Thanks again!
[21:06] <DJVG> TJ-: Btw, if you want to le me know something just touch something in /tmp or you can always contact me by e-mail (like if you're done with the server).
[21:08] <TJ-> DJVG: I'll use the email if it's none public none-bug related
[21:08] <DJVG> TJ-: Perfect!
[21:09] <TJ-> DJVG: I've added your key to my keyring
[21:09] <TJ-> Time for a strong coffee I think :)
[21:14] <TJ-> great time for launchpad to start generating errors - can't attach files now
[21:15] <cinch> strong coffee? what timezone, we sleep here
[21:17] <TJ-> UK here
[21:18] <cagmz> for character device modules, what does the file * in ssize_t (*read) (struct file *, char *, size_t, loff_t *); refer to? i see calls to these methods with an file descriptor to the device file itself
[21:21] <apw> cagmz, right, they should have a kernel file descriptor which points to the chacter device
[21:21] <cagmz> why does the device need to be referenced, though? does the kernel find the device using the fd given in read(), write(), etc?
[21:25] <apw> cagmz, because these are file operations against a file, passed file* representst the kernel view of teh file
[21:25] <apw> that file* is pointed to by the fd numbers given in read/write
[21:25] <cagmz> ah!! because the kernel doesn't differentiate between devices and files, right? i keep making them distinct but linux treats them the same
[21:26] <apw> the are "files" in the strictest sense in the kernel view
[21:55] <cagmz> im supposed to be writing a device that reads/write to an internal data structure in the kernel using IOCTL(). so far, I have created a struct that is passed from user space to kernel space with the # of bytes to write, but I also need to pass the actual string to write. would it be ok to use 2 separate ioctl calls? 1 to set the control register for the device (with # of bytes to write), and ioctl() with a pointer to th
[21:55] <cagmz> e actual string?
[22:00] <mjg59> Why not include all of that in the struct?
[22:01] <cagmz> ah, true! I have a control struct with * of bytes to write/read. I could use a union to store a pointer to the message. but if I do this, will the kernel be able to access the char *?
[22:02] <mjg59> It'll need to do copy_from_user()
[22:02] <mjg59> You can't directly dereference userspace pointers in the kernel
[22:02] <cagmz> for example, in user space, i could have char msg[] = "cat". then I do ctrl.data.message = &msg. if I use copy_from_user, will the kernel copy the message or just a pointer to it?
[22:03] <mjg59> The kernel will get a pointer
[22:03] <cagmz> ah ok, so I would need to use strcpy to store the message in teh struct first, right?
[22:03] <mjg59> No
[22:05] <cagmz> how about passing in ctrl.data.message = &msg, using copy_from_user to copy that whole struct, then using copy_from_user on cmd.data.msg ptr to copy to the module?
[22:06] <mjg59> Yes
[22:06] <mjg59> That'll work
[22:07] <mjg59> But remember that someone could submit a structure with an invalid length
[22:07] <mjg59> Don't assume that the length passed in corresponds to the real length of the string
[22:07] <mjg59> You'll want to null terminate it yourself before doing anything with it
[22:07] <mjg59> Also probably set some upper bound on the size, otherwise someone can DoS you by just allocating huge quantities of kernel memory
[22:08] <cagmz> the data structure inside the device is 256k bytes, so I will check that the ctrl.num_bytes < 256k. and while writing to teh device, I will stop before 256k. this is just academic though
[22:16] <cagmz> mjg59: do you think something like this would work? https://bpaste.net/show/6b4b9ff894e8 can i declare a char * alongside bits in a struct?