partman-base && GPT

2015-03-19 Thread Turbo Fredriksson
As you may or may not know, I modified partman-zfs to support Linux (ZoL)
a couple of years ago. I've taken up the project again, and got into
a little … 'pickle'.


It _seems_ that when partman creates a GPT partition, it does so using
the 'EBD0A0A2-B9E5-4433-87C0-68B6B72699C7' GUID ('Windows Basic data 
partition').

This gives, amongst other things, the problem that grub can't boot it
(it can't "embed the something' :). I've (well, actually an Illumos
developer) modified grub to recognize the CORRECT guid -
'6A898CC3-1DD2-11B2-99A6-080020736631' (Solaris /usr partition (OSX ZFS)).

The partman-zfs does a "open_dialog NEW_LABEL loop" (which I always
thought was weird, but it seems that all the other partman-*
does the same thing).

But I'm not sure this is "my" fault for 'something else'… Any ideas?
-- 
Try not. Do. Or do not. There is no try!
- Yoda


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/67693599-f3ad-4a9d-9659-5b848cebb...@bayour.com



Re: partman-base && GPT

2015-03-19 Thread Steve McIntyre
On Thu, Mar 19, 2015 at 12:24:24PM +0100, Turbo Fredriksson wrote:
>As you may or may not know, I modified partman-zfs to support Linux (ZoL)
>a couple of years ago. I've taken up the project again, and got into
>a little … 'pickle'.
>
>
>It _seems_ that when partman creates a GPT partition, it does so using
>the 'EBD0A0A2-B9E5-4433-87C0-68B6B72699C7' GUID ('Windows Basic data 
>partition').
>
>This gives, amongst other things, the problem that grub can't boot it
>(it can't "embed the something' :). I've (well, actually an Illumos
>developer) modified grub to recognize the CORRECT guid -
>'6A898CC3-1DD2-11B2-99A6-080020736631' (Solaris /usr partition (OSX ZFS)).
>
>The partman-zfs does a "open_dialog NEW_LABEL loop" (which I always
>thought was weird, but it seems that all the other partman-*
>does the same thing).
>
>But I'm not sure this is "my" fault for 'something else'… Any ideas?

I found a similar-sounding problem for partman-efi - the wrong GUID
was being used there too. AFAICS recent parted versions default to
using the "Windows Basic data partition" GUID and you need to tell
parted to do things differently if you want different behaviour. For
UEFI, adding "write_line esp" helped (commit
7ce58763e8f1766ad5461b9be73fe961d9bbf4e3 in partman-efi). I'm not sure
if something similar will help you...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150319115537.ga...@einval.com



Bug#761815: fixed in partman-target 94

2015-03-19 Thread Steve McIntyre
On Wed, Mar 18, 2015 at 11:03:26PM +0100, Cyril Brulebois wrote:
>Hi,
>
>Christian Perrier  (2015-01-26):
>>  partman-target (94) unstable; urgency=medium
>>  .
>>[ Steve McIntyre ]
>>* Don't add entries for random USB media to /etc/fstab, they're not
>>  useful. Closes: #761815
>
>I'd like to know how that was tested. Using libvirt, importing mini.iso
>as a USB hard drive (appearing as /dev/sda during installation),
>installing on to an IDE disc (appearing as /dev/sdb), leads to the use
>of partman-target 94 per syslog, and yet /etc/fstab ends up containing
>a /media/usb0 entry:
>| # /etc/fstab: static file system information.
>| #
>| # Use 'blkid' to print the universally unique identifier for a
>| # device; this may be used with UUID= as a more robust way to name devices
>| # that works even if disks are added and removed. See fstab(5).
>| #
>| #
>| # / was on /dev/sdb1 during installation
>| UUID=a38aa670-fb4c-4482-8af1-42f34b41ebdb /   ext4
>errors=remount-ro 0   1
>| # swap was on /dev/sdb5 during installation
>| UUID=cd9c4a52-91c4-4b44-8d34-c880357974b9 noneswapsw 
> 0   0
>| /dev/sda1   /media/usb0 autorw,user,noauto  0   0

Maybe we've got a misunderstanding here. The change is only expected
to stop *other* USB devices from showing up in /etc/fstab. If you're
installing using /dev/sda as a mini.iso / HD_MEDIA, then that will
still be added for now.

Whether that's *also* right or wrong I'm not 100% sure, but that's not
what I was expecting to change. What happens if you add some other USB
devices in your test?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150319121809.gc...@einval.com



Bug#761815: fixed in partman-target 94

2015-03-19 Thread Cyril Brulebois
(Adding Ansgar to the loop since he already commented on this bug
report.)

Steve McIntyre  (2015-03-19):
> Maybe we've got a misunderstanding here. The change is only expected
> to stop *other* USB devices from showing up in /etc/fstab. If you're
> installing using /dev/sda as a mini.iso / HD_MEDIA, then that will
> still be added for now.

Ah, thanks for clarifying.

> Whether that's *also* right or wrong I'm not 100% sure

Neither am I… that's what we have for cdrom anyway.

> but that's not what I was expecting to change. What happens if you add
> some other USB devices in your test?

I'll try to toy around with it next night. Have some daywork to deal
with first.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: CSS for installation guide ?

2015-03-19 Thread Stéphane Blondon
Hi,

2015-03-18 3:59 GMT+01:00 Samuel Thibault :
> On http://stephane.yaal.fr/tmp/installationguide0/ch02s01.html in the
> table the even/odd colors are odd: all ARM lines have the same color,
> and all MIPS/PowerPC lines have the same color.

It's due to the rowspan on these cells.
If the rowspan is replaced by several cells with the same content, the
even/odd colors will be displayed correctly.
I'm not sure if it's fixable with generic CSS.

> The tables on
> http://stephane.yaal.fr/tmp/installationguide0/ch03s03.html and
> http://stephane.yaal.fr/tmp/installationguide0/ch03s04.html are not
> getting formated.

You're right. I'll fix it.


Thank you for your review!
-- 
Stéphane


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOy+up7sZyekHhLcDA0McnHvkv4072J87cnzGP_jc26cRAFv=w...@mail.gmail.com



Bug#761815: fixed in partman-target 94

2015-03-19 Thread Steve McIntyre
On Thu, Mar 19, 2015 at 01:23:26PM +0100, Cyril Brulebois wrote:
>(Adding Ansgar to the loop since he already commented on this bug
>report.)
>
>Steve McIntyre  (2015-03-19):
>> Maybe we've got a misunderstanding here. The change is only expected
>> to stop *other* USB devices from showing up in /etc/fstab. If you're
>> installing using /dev/sda as a mini.iso / HD_MEDIA, then that will
>> still be added for now.
>
>Ah, thanks for clarifying.
>
>> Whether that's *also* right or wrong I'm not 100% sure
>
>Neither am I… that's what we have for cdrom anyway.

Yeah. To be honest, I think we could/should probably extend this
further then and drop all the USB stuff from partman-target
altogether. Following the same logic, hd-media mounts probably
shouldn't be kept around post-install either.

>> but that's not what I was expecting to change. What happens if you add
>> some other USB devices in your test?
>
>I'll try to toy around with it next night. Have some daywork to deal
>with first.

ACK. Me too...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150319122959.gd...@einval.com



Re: partman-base && GPT

2015-03-19 Thread Turbo Fredriksson
On Mar 19, 2015, at 12:55 PM, Steve McIntyre wrote:

> AFAICS recent parted versions default to using the "Windows Basic
> data partition" GUID

Isn't that a bug? For those that dual-boot, windows might get … "funny"
with that disk. ?

> For UEFI, adding "write_line esp" helped (commit
> 7ce58763e8f1766ad5461b9be73fe961d9bbf4e3 in partman-efi). I'm not sure
> if something similar will help you…


'We're not doing anything like that. So could you catch me up
(so I don't have to dig through EVERYTHING to find out :) what
the SET_FLAGS does here?

The method is 'zfs' and running

partman-command GET_FLAGS 

in the second console (in the device dir) gives me nothing, so
I guess there's currently no flags set…

Primarily, it's the 'boot' and 'efi' flag I'm wondering about.
What do they do, why are they there?

And should I set 'efi' in mine (or perhaps 'zfs' - which makes
more sense) and create the /{zfs_bootable,bootable}?


From a pure guess, I guess I should ONLY set the 'zfs' flag,
and not create the two other files… ?
--
Michael Jackson is not going to buried or cremated
but recycled into shopping bags so he can remain white,
plastic and dangerous for kids to play with.


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1e4a6574-cd66-46a9-9321-3e782a0cf...@bayour.com



Re: partman-base && GPT

2015-03-19 Thread Steve McIntyre
On Thu, Mar 19, 2015 at 01:50:54PM +0100, Turbo Fredriksson wrote:
>On Mar 19, 2015, at 12:55 PM, Steve McIntyre wrote:
>
>> AFAICS recent parted versions default to using the "Windows Basic
>> data partition" GUID
>
>Isn't that a bug? For those that dual-boot, windows might get … "funny"
>with that disk. ?

Apologies. Correcting myself: by default parted is using
0FC63DAF-8483-4772-8E79-3D69D8477DE4, which is "Linux filesystem
data" when we're using it in d-i. Curse this jetlag. :-(

>> For UEFI, adding "write_line esp" helped (commit
>> 7ce58763e8f1766ad5461b9be73fe961d9bbf4e3 in partman-efi). I'm not sure
>> if something similar will help you…
>
>'We're not doing anything like that. So could you catch me up
>(so I don't have to dig through EVERYTHING to find out :) what
>the SET_FLAGS does here?

Apologies, to understand this you're going to need to dig into
parted's internals. :-(

>The method is 'zfs' and running
>
>   partman-command GET_FLAGS 
>
>in the second console (in the device dir) gives me nothing, so
>I guess there's currently no flags set…

Right, OK.

>Primarily, it's the 'boot' and 'efi' flag I'm wondering about.
>What do they do, why are they there?

They're flags that determine behaviour inside parted. In the parted
package, look at include/parted/disk.h for the full list:

/**
 * Partition flags.
 */
enum _PedPartitionFlag {
PED_PARTITION_BOOT=1,
PED_PARTITION_ROOT=2,
PED_PARTITION_SWAP=3,
PED_PARTITION_HIDDEN=4,
PED_PARTITION_RAID=5,
PED_PARTITION_LVM=6,
PED_PARTITION_LBA=7,
PED_PARTITION_HPSERVICE=8,
PED_PARTITION_PALO=9,
PED_PARTITION_PREP=10,
PED_PARTITION_MSFT_RESERVED=11,
PED_PARTITION_BIOS_GRUB=12,
PED_PARTITION_APPLE_TV_RECOVERY=13,
PED_PARTITION_DIAG=14,
PED_PARTITION_LEGACY_BOOT=15,
PED_PARTITION_MSFT_DATA=16,
PED_PARTITION_IRST=17,
PED_PARTITION_ESP=18
};

In partman-efi, we need to set both PED_PARTITION_BOOT and
PED_PARTITION_ESP to create a working EFI System Partition (ESP). But
for more common needs, they shouldn't be necessary. Is a lack of flags
somehow being interpreted as PED_PARTITION_MSFT_DATA somewhere?

I'd compare and see what flags the other filesystems try to set
here...

In terms of GUIDs, libparted/labels/gpt.c contains the list that
parted knows about, and the one you mentioned
(6A898CC3-1DD2-11B2-99A6-080020736631) doesn't seem to be there at
all. But I'm not sure if that matters to be honest. Do you have one of
those on the disk already, or is that what you think you should be
creating?

>And should I set 'efi' in mine (or perhaps 'zfs' - which makes
>more sense) and create the /{zfs_bootable,bootable}?
>
>From a pure guess, I guess I should ONLY set the 'zfs' flag,
>and not create the two other files… ?

There isn't a zfs flag, the flags are more for partition usage rather
than fs type. Although the usage gets quite confuding at times. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150319134822.ge...@einval.com



Re: CSS for installation guide ?

2015-03-19 Thread Lennart Sorensen
On Thu, Mar 19, 2015 at 01:28:56PM +0100, Stéphane Blondon wrote:
> Hi,
> 
> 2015-03-18 3:59 GMT+01:00 Samuel Thibault :
> > On http://stephane.yaal.fr/tmp/installationguide0/ch02s01.html in the
> > table the even/odd colors are odd: all ARM lines have the same color,
> > and all MIPS/PowerPC lines have the same color.
> 
> It's due to the rowspan on these cells.
> If the rowspan is replaced by several cells with the same content, the
> even/odd colors will be displayed correctly.
> I'm not sure if it's fixable with generic CSS.

The highlighting gets all messed up too.  If you point at IXP4xx, it
highlights the entire row including ARm and armel, but if you point at
the next line (kirkwood), then only the last two columns are highlighted.
Quite inconsistent.  If it isn't going to be consistent, it would probably
be better to not have it at all.

Perhaps forgetting the highlighting and alternate row colours and just
using lines around table cells would work better.  Sure it is old
fashioned, but it works.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150319140141.gb25...@csclub.uwaterloo.ca



Bug#780811: [Bug#780811] Add further information

2015-03-19 Thread Christian MOMON

 Dear Maintainer,

 As I am seing several "No space left on device" in syslog file, I add
further information:

a. I have used the default partition setting with "home separated"

b. I joined a screenshot of a df -h command.

 Regards,

 Christian (Cpm)
-- 
DEVINSY sarl - Développements en S.I.
http://www.devinsy.fr
Tél. +33 (0)6 26 72 40 04


Bug#780811: debian-installer: Netinst throws error when MATE is selected in "Software, selection"

2015-03-19 Thread Cyril Brulebois
Hi,

Christian MOMON  (2015-03-19):
> Package: debian-installer
> Version: debian-jessie-DI-rc1-amd64-netinst.iso
> Severity: important
> File: debian-installer
> 
>  Dear Maintainer,
> 
>  Using debian-jessie-DI-rc1-amd64-netinst.iso (md5sum checked), in
> "Software, selection" input window, I select "Debian Desktop
> Environment" and:
> 
> 1. if I select "MATE" in the "Software selection" window then an error
> occured:
> 
> "Select and install software
> Installation step failed
> An installation step failed. You can try to run the failling item again
> from the menu, or skip it and choose something else. The failling step
> is: Select and install software"
> 
> 
> 2. if I do not select "MATE" then no error. When installation is
> finished, install the MATE packages works fine.
> 
> 
> 
>  My computer: 2 cpu, 4096GB memory, 12GB harddisk.
> 
>  Additional information in screenshots (input window, error message,
> logs...).

It looks like 3.6GB is too small for both Gnome and MATE. If installing
with Gnome then MATE once rebooted into the installed system works, I
suspect that's because of the cache directory holding downloaded
packages: holding both desktops' .deb and installing takes too much
space compared to installing one after the other.

I'm afraid there's little we can do in d-i for that.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Processed: Re: Bug#780812: simple-cdd: mount a file system with type ext4 ... failed.

2015-03-19 Thread Debian Bug Tracking System
Processing control commands:

> retitle -1 simple-cdd: mount a file system with type ext4 ... failed.
Bug #780812 [simple-cdd] (no subject)
Set Bug title to 'simple-cdd: mount a file system with type ext4 ... failed.'.
> block -1 by 779922
Bug #780812 [simple-cdd] simple-cdd: mount a file system with type ext4 ... 
failed.
780812 was not blocked by any bugs.
780812 was not blocking any bugs.
Added blocking bug(s) of 780812: 779922
> tag -1 wontfix
Bug #780812 [simple-cdd] simple-cdd: mount a file system with type ext4 ... 
failed.
Added tag(s) wontfix.

-- 
780812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780812
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b780812.142679429512208.transcr...@bugs.debian.org